Igneum/Light wallet
Reference app 1 · Devnet 3, no value

A balance verified in your browser, trust stated.

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 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.

Trusted inputs, stated

Why this only works on a proven chain. 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

Devnet 3, no value. Nothing here is a wallet that sends. It reads and proves.

What is checked, in order

  1. 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 and two thirds of total weight), and the header chain from the previous lock.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

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). Devnet 3, no value.

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