A balance your browser proves.
Paste a Devnet 3 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 checks every byte itself: BLS over the checkpoint, every header hash and parent link, the merkle path, the aggregator's signature, the Merkle Patricia proof under the proven state root. The service cannot lie about the balance. It can only refuse to answer.
Why this only works on a proven chain. The balance rests on a state root that an aggregator signed inside a block, after proving the segment's execution, and that every node checks against its own execution before paying the record. On a chain without proofs a light client has only a node's word for a balance.
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/igneum-devnet-3 || index || checkpoint hash, the canonical voter order, the rule (two thirds of active weight, 17/30 of total), 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.
What is trusted and said so on the result: the aggregator's statement being the true execution result (nodes check it natively before paying; the SP1 proof behind it is verified by nodes, not in this tab yet), and the voter table with weights, which comes from the node (spec 10.1). The read service names the node it reads.
Devnet 3, no value. The chain may reset. Pages like this one are demonstrations of the verification path, not a product.