Feature Requests

Hi Blockscout team, We would like to request support for identifying transactions sent by EIP-8004 registered Agents. Currently, transactions sent by registered Agents appear as normal EOA transactions in Blockscout. This makes it difficult to distinguish Agent-originated transactions from regular user transactions. Requested Feature Add support to: • Detect whether a transaction sender is a registered EIP-8004 Agent • Display a visible label or badge (e.g., “Agent”) next to the sender address • Optionally show a note in the transaction details page indicating it was sent via an EIP-8004 Agent Agents are registered through an on-chain registry contract, so detection should be possible by checking the sender against the registry. Why This Matters As Agent-based execution models (e.g., delegated execution / account abstraction patterns) become more common, clear explorer-level visibility is important for transparency, analytics, and debugging. We’re happy to provide additional technical details if helpful. Thanks for your work on Blockscout!

Sử dụng cài đặt như đã cái đặt Vũ Đức anh Vu123

Why can't I see the transaction records for converting the main currency to ETH, but I can see the transaction records for the tokens? Could it be that the genesis block settings are incorrect?

Request: Add token branding on Flare Explorer Token name: Energon Symbol: EON Contract address: 0x9458Cbb2e7DafFE6b3cf4d6F2AC75f2d2e0F7d79 Decimals: 18 Total supply: 30,000,000 EON Description: Energon (EON) is the native ERC-20 utility token powering the Energon Grid on Flare. It is used for protocol rewards, controller ticks, and ecosystem incentives. Logo (PNG, 256x256, transparent): https://red-secret-dragonfly-529.mypinata.cloud/ipfs/bafybeiccfdp4aez6gqva5yx5cmixc7dugqxl6eee5nhb54sdhpnidpmt7u Explorer: https://flare-explorer.flare.network/token/0x9458Cbb2e7DafFE6b3cf4d6F2AC75f2d2e0F7d79

Sometimes when a deep reorg happens in L2 when the batch is expired, blockscout takes a huge amount of time to recover. In this case, I often clear the data and force it to re-index. But this will also clear the contract verification result. It would be great if there's support for exporting/importing contract verification result. Btw, I know there's a bytecode db service, but it introduces an architecture change which I want to avoid.

Currently, all images used in the docker-compose setup are tagged as latest. When switching to earlier branches, the setup fails to work properly. This is likely because the latest tag does not guarantee compatibility with older code versions, and the dependent images may lack forward compatibility. To improve stability and reproducibility, could you please provide a version mapping list that clearly associates docker image tags with specific releases or branches? This would help ensure that earlier branches can be used reliably without unexpected breakage due to incompatible image updates. Having such a version-to-branch mapping will greatly increase confidence in deploying and testing older versions, avoiding issues caused by implicit latest image updates. Thank you for considering this enhancement.

add gas tracker with table high and low gas history

Hi team! Thanks for your effort with this product! I have a use case where I'm using K8s deployment (via blockscout-stack helm chart) and I've deployed the blockscout API without a public endpoint (no ingress) but the frontend is not able to resolve the private service DNS from K8s: _service_._namespace_.svc.cluster.local We need a way to deploy the API privately (best case scenario) or have a secure way to deploy the API publicly (OK-ish scenario). If it's the latter we rather not resort to IP whitelisting and have some type of auth support (basic auth, jwt, etc.) between the stack components. Best regards