Block Verification Explorer
The Block Verification Explorer is a FastSet application that verifies and records the state of external blockchains, starting with Ethereum.
Instead of relying on a single node as the source of truth, the explorer creates cryptographically signed claims for every block and state update. These claims are validated and settled on FastSet, producing a permanent, auditable record of blockchain history.
The result is a trust-minimized way to query blockchain data: developers and applications can access a verified view of Ethereum without the costs, risks, or complexity of running a node themselves.
Architecture
The Block Verification Explorer is built on top of FastSet, with several components working together to mirror and verify a blockchain like Ethereum.
The diagram below shows the full architecture:
Figure 1: Block Verification Architectural Diagram
Below is a quick overview of each part:
Client Node EVM: A standard Ethereum node (such as Geth or Reth) that streams new blocks to the system.
Block verification: The core application that generates witnesses from an Ethereum block, where the computation claim is to be verified, and the state claim is to be settled in FastSet.
KEVM Verifier: Independent verifier(s) that replay blocks using stateless validation with KEVM and sign the result that it can attest as being correct.
FastSet: The settlement layer where both computational and state update claims are validated, signed, and permanently recorded.
Explorer: The backend and interface that stores claim certificates and makes them available to developers.
OmniSet: Consumes settled certificates to enable cross-chain transfers with strong guarantees.
dApps: Applications that query the Explorer to access verified blockchain data.
Together, these components provide a way to maintain a transparent, verifiable copy of a blockchain that can be trusted by developers, applications, and cross-chain systems.
Claims and verification model
As you’ve seen earlier from Figure 1, at the heart of the Block Verification Explorer are two kinds of claims: computational claims and state claims.
These claims are how the system proves what happened on Ethereum (or any mirrored chain) and keeps the verified copy in sync.
Computational claims
These are all about block execution. You can think of them as statements like: “Block 12345 is a valid successor to Block 12344, because all of its transactions execute correctly.” To make this trustworthy, multiple independent verifiers replay the block using KEVM, which guarantees the execution was correct according to the EVM semantics. Then, each one signs off if it checks out. A claim only goes through, once enough signatures are collected to meet the quorum. That way, no single verifier can push through a bad block.
State update claims
Before the Explorer can start moving the chain forward, it needs to know where to begin. This is done with a state initialization claim, which is a special claim that sets the very first block of the verified chain (usually the genesis block or another chosen checkpoint). The initialization claim is only used once, which is at the very beginning.
From that point on, the system relies on state update claims to move the chain forward. Once a block is proven valid through a settled computational claim, a state update claim is issued to advance the “tip” of the verified chain.
For example: “The verified chain has advanced from Block 12344 to Block 12345.”
FastSet only accepts a state update claim if there’s already a computational claim proving that transition is correct. This ensures the recorded chain tip is always consistent with the verified history.
Together, the initialization claim (one-time) and the sequence of state update claims (ongoing) keep the Explorer’s record of the blockchain aligned and auditable from the very first block.
By splitting these into two kinds of claims, the explorer gains flexibility. You can have multiple computational claims floating around (different candidate blocks) before deciding which one actually updates the chain tip. This design is especially useful for chains that don’t finalize instantly, like Solana.
But, how does all this work?
When a new block is produced on Ethereum, it flows directly from the Client Node EVM into the block verification application, which acts as the coordination hub. The application takes this block and turns it into a computational claim, which is essentially a statement that the block correctly follows from its parent.
That claim is then sent to a network of independent KEVM Verifiers. Each verifier replays the block using stateless validation. If the block checks out, the verifier signs the claim. Once enough signatures are collected to meet the required quorum, the application submits the claim to FastSet for settlement. At this point, FastSet validates that quorum rules have been met, records the claim, and produces a settlement certificate that serves as permanent proof that the block was correctly verified.
With the block validated, the application then issues a state update claim. This updates the chain tip in FastSet, moving it forward from the previous block to the newly verified one. FastSet validates this claim as well, ensuring both correctness and consistency with the settled computational claim. The result is a live, cryptographically guaranteed record of the blockchain’s state as it advances block by block.
These settled certificates are then stored and made queryable by the Explorer, giving developers a transparent way to inspect the chain’s verified history. Other systems, such as OmniSet, can consume these certificates to power secure cross-chain transfers, while dApps can build directly on top of this trusted data.
This loop repeats for every new block, creating a live, cryptographically guaranteed record of Ethereum’s state.
What can you build on top of this?
The Explorer isn’t just a behind-the-scenes service. It’s meant to be a foundation; something other systems can plug into and immediately trust.
Here are a few ways you can use it:
Querying verified history: You’ll no longer need to spin up a full node or worry about whether the data you’re reading is accurate. With the Explorer, you can fetch proofs of blocks and state directly and know they’ve already been cryptographically verified.
Cross-chain transfers with OmniSet: When moving assets across chains, trust is everything. OmniSet relies on the Explorer’s settled certificates as its source of truth, so transfers can happen without depending on external oracles or unverified nodes.
dApp integrations: For applications whether they be DeFi protocols, analytics dashboards, or even experimental cross-chain services, the Explorer provides a base layer of trustworthy state.
General-purpose verification layer: Looking ahead, the Explorer could also serve as a verification layer for blockchains themselves. By replacing the need for long optimistic proof windows or complex zk-proof systems, it can help chains reach global finality in less than 100 ms while maintaining the same level of security.
Next steps
If all of this sounds exciting, the best way to understand it, is to see it in action. Head over to the Block Verification Explorer interface and watch Ethereum being verified in real time.
Curious about how to use the interface? You can check out our user guide, where we’ll walk you through what each part of it does and how you can make the most of it.
Last updated
Was this helpful?