Deploying Blockscout for a network: where data gets lost
A public explorer is convenient as long as you view someone else's network from the outside.
As soon as your own transactions are involved, it turns out that only the last few thousand operations are returned by address, internal transfers between contracts are not indexed, and proxy calls are not visible in the interface at all.
The balance on the page reconciles, but reconciliation with the accounting system does not, and discrepancies have to be investigated manually by hashes.
The second layer of the problem is data access. Public services throttle request rate and log query depth, so completeness of transaction history is unattainable in principle: some events are simply not returned through their interface.
Network search is limited to what the service owner has indexed — you cannot add your contracts, custom events, or internal address labels there.
Export for reporting, audit, or incident investigation runs into the fact that data cannot be retrieved in full and in the required form.
Your own block explorer on your servers removes both limitations. Deploying Blockscout starts with an indexer that traverses the network from the first block and stores logs, traces, and transfers in its own database — history is not truncated by depth or number of requests. How it is structured and what breaks along the way — we explain how it is addressed.
Effect: search speed, history completeness, access control
An explorer built for a specific EVM network delivers an effect that is measured, not debated. Below is what exactly changes after deploying a custom block explorer based on Blockscout and by which metrics it is accepted.
- Network search speed. Response by address, transaction hash, or block number is fractions of a second on a warm cache, without queuing to a public service or dependence on third-party load.
- Completeness of transfer indexing. Internal transfers, contract calls, and token events are fully captured in the database — history and balances reconcile with network state rather than being limited to external transactions.
- Offloading network nodes. Heavy history queries move to a separate explorer database, and access points no longer bear peak load from analytics and exports.
- Explorer access control. Roles are configured for the task: public viewing, closed environment for audit, separate rights for data retrieval and export.
- Custom block explorer. Your own filters, fields, and labels for the network's internal logic — things you cannot show in a public service.
Acceptance is based on metrics: we measure response time for typical queries, reconcile the index with network state at control blocks, and record which nodes have been freed from analytical load.
How to host the explorer: cloud, your own servers, hybrid
An explorer is a search engine for your network: it collects blocks and transactions, stores them in a database, and serves an API and web pages.
The hosting decision determines three things at once: who owns the index, where performance will hit a ceiling under load, and what can be customized at all.
We deploy Blockscout and its forks in three modes — from fully managed to fully self-hosted. The difference between them is not in "convenience" but in which limitations you consciously accept.
| Option | When it fits | Limitations |
|---|---|---|
| Cloud explorer | Quick start, no in-house operations team, standard network | Ready-made explorer: fixed set of interface methods, cannot edit indexing schema or add your own metrics; the index physically resides with the provider |
| Self-hosting | Need control over data, non-standard contracts, your own analytics modules | You take on fault tolerance, replication, and updates; indexer downtime stops network search |
| Hybrid indexing scheme | Index and archive must reside inside the environment, while serving goes outward | A stable channel is needed between environments; query routing is more complex, and part of the output is delayed |
| Vendor public explorer | Test network, demo, early prototyping | No privacy, no custom tokens or metadata, there are request rate limits |
The choice of mode is not a matter of taste but a consequence of data and load requirements. Next, we show how we transfer the index between environments without losing history.
How Blockscout deployment proceeds: implementation stages
The work sequence is arranged so that data schema errors do not surface during synchronization, when rebuilding indexes costs days of downtime.
First we understand the network and what it provides to the node, then we bring up the environment, and only after that do we enable the indexer. Below are the explorer deployment stages as we go through them.
-
Pre-launch network audit. We check which contract standards are in use, whether there are internal transfers via traces, how many events occur per day, and what history depth is needed.
We calculate whether it fits on a regular node or requires archive mode — this determines initial synchronization time.
-
Environment preparation. We bring up nodes in the required mode, a database for indexer data, a proxy layer with traffic encryption, and access segmentation by network.
We describe the fault-tolerance scheme in advance: what will survive a restart and what will have to be resynchronized.
-
Indexer configuration. We set the starting height, the set of processed modules, the trace traversal strategy, queue sizes, and retries on failures. An incorrect start causes balance discrepancies across hundreds of blocks, so we verify the height against the node twice.
-
Synchronization and data reconciliation. We selectively compare blocks, address balances, and internal transfers with node data, looking for gaps and duplicates.
Separately, we look at how the indexer behaves after a restart — whether it picks up the tail without manual intervention.
-
Load testing. We run address searches, event filters, and exports under a stream of requests, measuring indexer lag behind the network head. If lag grows at peak, we add resources before acceptance, not after.
-
Explorer acceptance. We go through scenarios: search by hash, contract verification, token history, correctness of internal transfers. The customer receives a checklist with results for each item.
-
Access handover. We hand over roles and keys, access to the database and monitoring, metrics on lag and indexing errors, and instructions for recovery after a failure.
Each stage is closed with an artifact — a configuration, reconciliation report, or checklist entry. Therefore the question "why is the explorer showing the wrong thing" is resolved through documents, not blind searching.
Deliverables: configurations, diagrams, policies
The deliverables are not an archive with a short instruction but a set of artifacts by which the Blockscout explorer can be brought up again on clean infrastructure, handed over to another team, and pass an access review.
Everything done during deployment is recorded in the repository: configurations, database schema migrations, service descriptions, and policies. Below is exactly what goes to the customer.
- Working node configurations: explorer files, environment variables, connection parameters for the node and database, separate value sets for test and production environments.
- Deployment diagram: service composition and connections between them, entry points, balancing, location of cache and indexing queue, separation of environments.
- Access policies and roles: role-action matrix, service accounts, permission separation for the admin panel, keys for external integrations, and their rotation procedure.
- Backup policy: what is backed up and how often, where copies are stored, how restoration is verified, and how long it takes for the explorer to return to working state.
- Update policy: procedure for rolling out a new version, database schema compatibility check, rollback point, and criteria for stopping an update.
- Support instructions: standard operations, diagnostics of a lagging indexer, log reading, and actions to take when data diverges from the node.
- Explorer documentation set: architecture description, service map, list of external dependencies, acceptance and handover-to-operation checklist.
Case study: explorer for a growing network, metrics before and after
A network with a dense transaction flow was constrained by a third-party explorer: history was limited by the depth of third-party indexing, and during activity peaks an address page took tens of seconds to open.
Every block view pulled a queue of calls to our nodes — they competed with wallets and internal services. Indexing failures after chain reorganizations had to wait until the provider resolved them.
We deployed our own Blockscout alongside the network: the indexer reads blocks directly and writes to our database from the genesis block, the interface responds from a local cache, and heavy queries do not reach the nodes.
Metrics before and after
| What we measure | Before | After |
|---|---|---|
| Address page opening | more than 20 seconds at peaks | 1–2 seconds |
| Node calls per view | dozens | single digits, the rest from the indexer database |
| History depth | limited by third-party indexing | full, from the first block |
| Indexing failures | regular during chain reorganizations | eliminated, automatic recovery |
What it delivered
Nodes stopped being the bottleneck: the load from the public explorer moved to a separate read environment, and wallets again respond without queuing.
We added indexer state metrics — lag behind the chain head, queue depth, response time — they make degradation visible before users notice it.
How your own explorer differs from a ready-made vendor one
A ready-made vendor explorer is someone else's indexer with a public interface on top of it. You see exactly the data the platform decided to collect: indexing depth, the set of supported calls, and update delay are determined not by your network but by the platform owner.
Your own explorer begins with the indexer, its database, and processing rules belonging to you.
In Blockscout, access to index configuration is open: custom system contracts, internal transfers, non-standard events, and metadata from your services — things a vendor build usually does not pass through.
Access to source network data is the second difference. The vendor option serves a slice via a third-party API with request rate and export limits, often without raw logs and internal transactions.
Your own instance opens the full set — for analytics, investigation of disputed operations, and reporting.
Explorer customization is also on a different scale. With a vendor, it is a logo and color scheme; with your own, it is additional tabs and fields, links to internal systems, restricted sections per role, and different data sets for the team and for external users.
The third is dependence on someone else's policy: the vendor decides when to rebuild the indexer for a network rule update, how to change terms, and in what form to serve data.
Extending the explorer for a task — from auditing internal transfers to bridge monitoring — here is a matter of development, not negotiations with a platform.
Technical concerns: load, access, updates
When deployed, Blockscout is a separate service with its own database and indexing queue; it does not live inside the node.
If the node lags or restarts, the indexing process simply catches up on missed blocks by block numbers, and the pages show the current height and lag amount — we configure an alert at this threshold.
Roles are also separated: the node, database, and web part have their own rights, keys, and network access. The administrator does not access the database from a browser, and updates are rolled out one component at a time with verification after each step. Below are answers to what is most often asked before starting.
What happens if the node lags or falls out of the network?
Indexing will stop at the reached height, but data will not be lost: after connectivity is restored, the process will continue from the same place. While the node catches up, pages serve already collected data, and the discrepancy is visible in the monitoring dashboard.
How is access separated?
A viewer only looks, an operator sees metrics and logs without write access to the database, and an administrator works through a separate access environment. Accounts are issued individually, keys are rotated, and a shared login is not used.
How is the explorer updated without data loss?
Components are updated one at a time: first the web part, then the indexer. Database schema changes are applied step by step, and the previous image remains available for rollback. Downtime during switchover is measured in minutes.
Who is responsible for backups and security?
Database backups are taken on schedule and stored separately from the production environment; we verify restoration on a clean test environment.
Only web access is exposed externally via a secure connection with request rate limiting; the admin panel is restricted by an address allowlist.
What to send so we come back with a plan and estimate
To come back with a plan and estimate rather than clarifying questions, one message with network and infrastructure inputs is enough. Below is the minimum from which we assemble the deployment diagram and timeline estimate for launching a Blockscout explorer for the task.
- Network parameters: chain id, type — own EVM network, rollup, or sidechain, consensus mode, system contract addresses.
- Node access: RPC and WebSocket endpoints of an archive node, credentials, hosting environment for the explorer and its constraints.
- Load and history: number of transactions per day, indexing depth — from genesis block or from a specific height, whether internal transactions and logs are needed.
- Task-specific functionality: contract verification, token and address pages, public API, custom interface, moderator roles — this determines the scope of work.
- Current state: whether an explorer is running now, whether the indexed database needs to be migrated, and whether old addresses and links must be preserved.
- Team and access: who provides nodes and access on your side, who accepts the result, and what maintenance windows are available.
- Support: which events are critical, whether alerts and an update policy are needed for explorer support.
From this, a work plan for the explorer is assembled: stages, deployment diagram, responsibility area of each party, and a timeline estimate with a buffer for network instability. Describe the task in this scope — we will come back with an estimate and plan.