Reference app 1 · the devnet, no value

A balance verified in your browser, trust stated.

A GPU-secured network for Ethereum-compatible applications and verifiable computation. Devnet, no value.

Paste a devnet address. This tab fetches the latest finality certificate, the header chain, the carrier block's coinbase, the segment record and an account proof from a read service, then recomputes every link itself: BLS over the checkpoint, every header hash and parent link, the merkle path, the aggregator's signature, the Merkle Patricia proof under the committed state root. This is a verification path with stated trust assumptions, listed below; it is not a browser that needs no trusted inputs. The read service cannot change what those inputs commit to. It can only refuse to answer.

What this page authenticates, and what it does not

Authenticated here: the starting point (the certificate it starts from, fetched fresh each run; the page has no shipped checkpoint yet, so the starting point is the node's latest certificate, verified by its signatures), the voter weights as the rule is applied to them, the header chain to the carrier block, the coinbase inclusion, the segment record's signature, and the account proof under the committed root.
Not authenticated here: the voter table itself and authority changes between tables (no header field commits to the table yet; the list comes from the node and a lying node could present other signers), and the execution: this page takes the aggregator's signed statement for the state root. That statement is not a proof. The permitted execution proof (SP1, verified by nodes before the record is paid) is not verified in this browser, so the balance rests on the aggregator's statement as the nodes checked it.
The read service cannot change what those inputs commit to; it can only refuse to answer.

Proof boundary. A proof of execution is not a proof of authenticated consensus inputs, canonical history or data availability. Included, executed, proven and finalised are four states; a safe pause is shown as a pause.

Why this only works on a proven chain. Three boundaries hold wherever the proof architecture is explained: proven execution is not finality; EVM compatibility is not Ethereum security; ZK is not privacy. Account proofs exist on Ethereum too; what differs here is how the state root is authenticated. The root comes from a segment record an aggregator signed inside a block after proving the segment's execution, which nodes check against their own execution before paying, under a finality certificate the miners signed. The page states what that chain rests on.

Source: site/lc/core.js (the checks), site/lc/app.js (this page), tools/reference-apps/light-service/serve.mjs (the read service), fork branch light-apps-node (eth_getProof on the node). Test with the negative cases: /lc/test in the browser, tools/reference-apps/light-service/verify.test.mjs under Node.

Verify a balance

What is checked, in order

The certificate: the aggregate BLS signature of the signers over igneum-vote-v1/{network id} || index || checkpoint hash, the canonical voter order, the rule (two thirds of active weight and two thirds of total weight), and the header chain from the previous lock.
The header path from the carrier block up to the certified checkpoint: every header hash recomputes (BLAKE2b-256 keyed BlockHash over the header fields), every next header names the previous as a direct parent.
The coinbase transaction is in the carrier block: its hash recomputes (BLAKE2b-256 keyed TransactionHash over the serialized transaction) and the merkle path reaches the header's hash_merkle_root.
The segment record in the coinbase extra data: the aggregator's BLS signature over the record under the network's tag, whether the key is a voter with weight or a prove-only key, and the statement names the chain and the block whose state it commits.
The account proof: a keccak-keyed Merkle Patricia proof under the record's post_root, every node hashed on the way down, the balance read from the leaf.

The result shows a balance that is proven and finalised in the sense of the four words below, under the trusted inputs stated above. The read service names the node it reads.

Data availability: how the state is obtained and reconstructed

Every block body (the coinbase and the raw EVM transactions) travels on the p2p network and is kept by full nodes; the execution state is not a separate publication. A node reconstructs the state by executing every chain block from genesis (the read service's reader does exactly that), or starts from an execution snapshot another node exported and replays forward; a snapshot is accepted only when its tip is a block the node holds. The pages here read headers, bodies and state proofs from one node and recompute every commitment; they do not check that every body is held by many nodes, and a block whose body no node serves cannot be re-executed or proven again.

Four words, used exactly

Included

The transaction is in a block's body: its hash is a leaf under the block header's hash_merkle_root. Proves the block carries it, nothing about what it did.

Executed

A node ran it at a chain block and reports a result (status, gas, logs). On these pages an execution result is reported by the node, not authenticated, unless the page says it is.

Proven

An aggregator's segment record, carried in a block's coinbase and signed with its vote key, commits to the state root after that chain block; nodes check the statement against their own execution before paying it. The SP1 proof behind the statement is verified by nodes, not in the browser or on Sepolia.

Finalised

A certified checkpoint has the block in its past: an aggregate BLS signature by voters holding two thirds of active weight and at least 17/30 of total weight over the checkpoint, checked here against the voter table the node supplies.

The same four definitions sit on /light, /receipt and /oracle (one source: site/partials/terms.html). The devnet, no value.

The devnet, no value. The chain may reset. Pages like this one are demonstrations of the verification path, not a product.