Skip to content

Block Explorer Development (Blockscout)

In short

Block explorer development and operations for EVM chains and rollups. We deploy, customize for non-standard networks, and operate Blockscout explorers in production, from standard throughput to million-TPS chains.

99.99%
explorer uptime (Gnosis)
300,000+
addresses indexed (Gnosis)
103M
daily tx indexed (Somnia)
1M+ TPS
chain supported (Somnia)
Trusted by teams building on-chain

A chain without a working block explorer has no transparency, no way for developers to debug failed transactions, and no way for users to independently verify that a transaction settled. For chains, rollups, and app-chains, that means no ecosystem credibility and no developer trust at launch.

A block explorer is the web interface that makes a blockchain readable: every block, transaction, address, token, and smart contract, searchable in real time. Block explorer development is the engineering work of standing one up for a specific network and keeping it accurate under load.

For EVM chains and rollups the open-source standard is Blockscout, and deploying it well is rarely a stock install. Protofire deploys, customizes, hosts, and operates Blockscout explorers for chains, rollups, and foundations in production. We treat the explorer as core ecosystem infrastructure and build it accordingly: branded UI, custom indexing for non-standard networks, source-code verification, public APIs, and long-term maintenance and incident response. When a network's data outgrows a default deployment, we tune the database and the hardware until the explorer keeps pace with the chain.

We work with EVM L1/L2 chains and app-chains that want a production-grade explorer at mainnet without pulling their core team off protocol work. We also work with high-throughput or non-standard networks (UTXO/EVM hybrids, multi-sharded chains) where a stock Blockscout install simply will not keep up.

A Blockscout explorer stack built and operated end to end

Every layer from the chain's RPC endpoints to the user's browser, deployed, tuned, and maintained by Protofire.

01

Chain / RPC Layer

The node and RPC endpoints the explorer reads from; Protofire can deploy and operate these as part of the same engagement.
02

Indexer

The Blockscout ingestion pipeline that reads blocks and transactions as they are produced, with batch sizes and concurrency tuned for the network's throughput.
03

Database (Postgres)

Optimized Postgres stores indexed chain data, tuned for memory handling, vacuum thresholds, and query performance at scale.
04

Contract Verification

Developers upload Solidity source, matched against deployed bytecode to enable read/write contract UIs inside the explorer.
05

Backend API

A public, well-optimized API serves blocks, transactions, addresses, token transfers, and analytics to wallets, ecosystem tools, and builders.
06

Branded Frontend

A customized UI with search, gas tracking, token lists, and contract interaction, branded to match the network.
01

What is a block explorer?

A block explorer (also called a blockchain explorer) is a search and visualization tool for on-chain data. It reads from a node and an index of the chain, then renders blocks, transactions, addresses, balances, token transfers, contract code, and event logs in a browsable interface.

Developers use it to verify and read smart contracts, debug failed transactions, and track gas; validators and operators use it to monitor network health; end users use it as the trust layer, the proof that a transaction actually settled. For a chain, an explorer is table-stakes ecosystem tooling: without one, developers cannot debug and users cannot independently verify activity.

Block explorer development covers all three layers: the indexer that ingests chain data, the backend API that serves it, and the frontend that renders it. It also covers the operations that keep them in sync as the chain produces new blocks.

02

How does Protofire deploy and customize Blockscout?

Blockscout is the most widely used open-source explorer for EVM networks, and it is the base we deploy from. A deployment is more than running the stack: we wire up chain config, RPC, and indexing, apply branding so the explorer matches the network, and build custom development where a default install does not fit. Quai, for example, combines the EVM and UTXO models with multi-sharding, a non-standard execution model that stock Blockscout does not handle out of the box, so we extended the deployment to index it correctly and improve overall network productivity.

We also host the full solution, including on bare metal for networks with many users and heavy usage, where managed cloud gets expensive; for Harmony, a multi-sharded network with heavy usage, we enhanced the UI and optimized infrastructure cost that way. Because Blockscout is open-source, there is no per-seat licensing and no vendor lock-in as the network grows.

03

Indexing, contract verification, and explorer APIs

The hard part of a custom block explorer is keeping the index in lockstep with a live chain. Indexing has to ingest blocks as fast as they are produced. On a high-throughput network that means tuning the database (Postgres memory, vacuum thresholds, critical indexes, query plans) and the ingestion pipeline (batch sizes, concurrency) rather than accepting the defaults.

04

Who is block explorer development for?

This service is for EVM L1/L2 chains and app-chains, typically around a mainnet launch or a testnet upgrade, that need a branded explorer as an ecosystem primitive but do not want to build and staff one in-house. It is for foundations and ecosystem-growth teams closing tooling gaps against competitor chains, where explorer quality is starting to block ecosystem credibility.

It is for rollups and high-throughput networks where a stock install cannot keep pace, and for networks with non-standard execution (UTXO/EVM hybrids, multi-sharding) that need genuine custom Blockscout development. The common trigger is the same: the core team would rather stay on protocol priorities than own explorer operations. It is not a fit for non-EVM chains with no EVM compatibility, or for pre-mainnet networks with no production chain data to index yet.

05

How a deployment works

1

Setup

Infrastructure, chain config, and branding. We validate RPC and indexing access and the inputs we need (branding, domain). Deliverable: a launch-readiness plan.
2

Deployment

Indexing, UI, and tests. We bring the explorer into production with contract verification, search, and analytics working against live chain data.
3

Ongoing Support

Infrastructure monitoring, maintenance and Blockscout code updates, bug fixing, and development of new features and functionality.
06

What chains come to us for

Branded Blockscout deployment for mainnet or testnet
Custom block explorer development for non-standard chains (UTXO/EVM, multi-sharding)
Indexing tuning for high-throughput networks
Source-code (contract) verification
Public explorer API for builders and ecosystem tools
Bare-metal hosting and cost optimization
Infrastructure monitoring and observability
Blockscout code updates, maintenance, and bug fixing
New explorer feature development
Long-term explorer operations and support
07

How we scaled a Blockscout explorer to a million-TPS network

Somnia is an EVM-compatible Layer 1 designed for bursts of up to one million transactions per second with sub-second finality; during testnet it processed up to 103 million transactions per day. A default Blockscout deployment could not absorb that: a rapidly growing Postgres database (19+ TB, 2B+ rows) caused query slowdowns and indexing delays, and stock infrastructure was insufficient for the throughput.

We optimized the explorer at the database, infrastructure, and application layers at once: tuning Postgres for large-scale ingestion (memory, vacuum thresholds, critical indexes, query optimization), deploying a 96-core, 1 TB RAM, 100+ TB storage machine with containerized orchestration, and tuning batch sizes and concurrency for high-throughput indexing, while preserving contract verification, address lookups, search, and analytics under load. The result: the explorer indexed up to 103 million transactions in a single day, held a 2B+-row dataset without query slowdown, and kept near-instantaneous block, transaction, and contract lookups despite record-breaking throughput.

08

An infrastructure team that operates the explorers it installs

Protofire is a blockchain infrastructure and development company that has shipped 250+ projects since 2016, across 60+ networks and 95+ protocols. On the data and infrastructure side we are a top-3 indexer in The Graph ecosystem, a Filecoin infrastructure partner since 2021, an official Safe Guardian, and the maintainer of Solhint, the open-source Solidity linter used by 1M+ developers.

We run Blockscout and explorer infrastructure in production: the Somnia Blockscout explorer built to scale toward one million TPS, and a rebuilt Gnosis explorer holding 99.99% uptime across 300,000+ validated addresses while lifting developer activity 40% with sub-second queries. When we deploy an explorer we also operate it, monitoring, updates, and incident response, so your team never inherits a static install to maintain alone.

“Explorers designed as core infrastructure, not a default install left to rot.”

Blockscout explorers in production
103M tx/dayMillion-TPS Explorer

We deployed and optimized the Somnia Blockscout explorer to index up to 103 million transactions per day on a network targeting one million TPS, tuning Postgres (19+ TB, 2B+ rows) and deploying a 96-core, 1 TB RAM machine to keep the explorer in lockstep at record-breaking throughput.

SomniaView project →
99.99% uptimeConditional Tokens Explorer

We enhanced the Gnosis Conditional Tokens Explorer to deliver 99.99% uptime across 300,000+ validated addresses with sub-second queries, driving a 40% increase in developer engagement.

GnosisView project →

A stock Blockscout install vs a production explorer

A stock Blockscout installProtofire
Non-standard networksBreaks on UTXO/EVM hybrids and multi-sharded chainsCustom indexing for non-standard networks
Scale under loadFalls behind as the chain growsDatabase and hardware tuned to keep pace
Branding and APIsDefault UI, generic endpointsBranded UI, source-code verification, public APIs
OperationsYou host, monitor, and patch itHosted, monitored, maintained, with incident response

FAQ

What is a block explorer?
A block explorer (or blockchain explorer) is a web tool that makes a blockchain's data readable, letting anyone search and view blocks, transactions, addresses, balances, token transfers, and smart contracts in real time. It reads from a node and an index of the chain, then serves that data through a frontend and a public API. Developers use it to verify contracts, debug failed transactions, and track gas; validators use it to monitor network health; and end users use it as the trust layer, the proof that a transaction actually settled. For an EVM chain, an explorer is basic ecosystem tooling: without one, builders cannot debug and users cannot independently verify activity. Block explorer development covers all three layers: the indexer that ingests chain data, the backend API that serves it, and the frontend that renders it. It also covers the operations that keep them in sync with the chain.
Blockscout vs Etherscan, what's the difference?
Etherscan is a proprietary, closed-source explorer operated as a hosted product. Blockscout is open-source and self-hostable, which means a chain owns its explorer outright: it can be branded, customized, extended for non-standard chains, hosted on its own infrastructure (including on bare metal for networks with heavy usage, where managed cloud gets expensive), and scaled without per-seat licensing or vendor lock-in. For a network that wants an explorer as a controllable ecosystem primitive rather than a third-party dependency, Blockscout is usually the better fit. It is also the most widely used open-source explorer for EVM networks, the base we deploy from. We do more than run the stack: we wire up chain config, RPC, and indexing, apply branding to match the network, and build custom development where a default install does not fit, then host and operate the result in production.
Can you customize Blockscout for a non-standard chain?
Yes, and it is much of the work. We have extended Blockscout for networks with non-standard execution, including Quai, which combines the EVM and UTXO models with multi-sharding that a default install does not handle out of the box; we extended the deployment to index it correctly and improve overall network productivity. For high-throughput chains like Somnia, customization is mostly database and indexing tuning: Postgres memory, vacuum thresholds, critical indexes, and query plans, plus batch sizes and concurrency in the ingestion pipeline, so the explorer stays in lockstep with the chain as blocks are produced. We also enhanced the UI and optimized infrastructure cost for Harmony, a multi-sharded network with heavy usage, by hosting on bare metal. Because Blockscout is open-source, this kind of deep customization is possible without per-seat licensing or vendor lock-in as the network grows.
How long does a Blockscout deployment take?
A branded deployment runs through three phases: setup (infrastructure, chain config, and branding, plus validating RPC and indexing access), deployment (indexing, UI, and tests, bringing the explorer into production with contract verification, search, and analytics working against live chain data), and then ongoing support. The exact timeline depends on chain throughput and how much customization the network needs. A standard EVM chain is faster than a high-throughput or non-standard one, because tuning indexing for a chain like Somnia or extending execution for a chain like Quai is genuine engineering rather than a stock install. We confirm the schedule on the first call, scoped against your network's throughput, execution model, and branding requirements. Once live, the explorer is not left static: support covers infrastructure monitoring, Blockscout code updates, bug fixing, and new feature development so it keeps pace with the chain.
Do you host and maintain the explorer, or just deploy it?
Both. Beyond deployment, our support covers infrastructure monitoring, maintenance and Blockscout code updates, bug fixing, and development of new features and functionality, so the explorer stays reliable and current as the chain evolves, without your team owning explorer operations. We host the full solution, including on bare metal for networks with many users and heavy usage where managed cloud gets expensive, as we did for Harmony. An infrastructure team that operates explorers does more than hand one over: we monitor the indexer, keep it in sync as the chain produces new blocks, push Blockscout updates, and respond to incidents. We run explorers in production today: the Somnia Blockscout explorer built to scale toward one million TPS, and a rebuilt Gnosis explorer holding 99.99% uptime. Operating one is routine for us.
We're a chain or foundation, can you run our explorer as an ecosystem primitive?
Yes, this is the primary use case. We deploy, host, and operate a branded Blockscout explorer as managed ecosystem infrastructure for chains and foundations, so builders get a production-grade explorer at mainnet and you close the tooling gap against competitor chains, without diverting your core team from protocol work. For a chain, an explorer is table-stakes ecosystem tooling: without one, developers cannot debug and users cannot independently verify activity. We treat it as core ecosystem infrastructure and build it accordingly: branded UI, custom indexing for non-standard networks, source-code verification, public APIs, and long-term maintenance. We pair the explorer with the RPC endpoints it reads from and our subgraph indexing, so the read side of your network is engineered as one coherent data layer rather than disconnected services. It is a fit for EVM L1/L2 chains and app-chains, typically around a mainnet launch or testnet upgrade.

Reviewed by Arsenii Petrovich, Infrastructure & DevOps Lead at Protofire. Last reviewed: June 2026.

Book a call with Margaret Apanasevich

Schedule a call with our CTO to receive practical recommendations and a prompt proposal for upgrading your solution.

Protofire 2026. All rights reserved