Reference app 3 · the devnet, no value

Devnet balances, read from Sepolia.

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

A contract on Ethereum Sepolia stores Igneum 2.0 devnet finality certificates that anyone submits, checked by a shared certificate verifier, and state roots bound to those checkpoints through the header chain, the coinbase and the segment record. Other contracts then read a proven the devnet balance or storage slot with an ordinary Merkle Patricia proof. No relayer is trusted: a wrong certificate or a wrong proof reverts.

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 technology does not automatically make transactions private. Another chain can only use Igneum state if a contract can check it without running an Igneum node: a weighted certificate over a checkpoint and a state root proven under it are small enough to verify in a few hundred thousand gas. A chain whose state is only "what most nodes say" has nothing a contract can check.

Source: tools/reference-apps/oracle/contracts/ (IgneumStateOracle.sol and its libraries), tools/reference-apps/oracle/demo.mjs (the demo that reads a the devnet balance from Sepolia), tools/reference-apps/oracle/test.mjs (the negative cases through eth_call). The shared certificate verifier is the DEX lane's contracts/bridge/src/IgneumCertificateVerifier.sol.

On Sepolia

Oracle

0x06c12c0c44c952ae10dcbbe3d5450a13168baccb IgneumStateOracle for the Igneum 2.0 devnet (igneum-devnet-4: statements with chain id 4465, coinbase amounts 16 bytes wide at 18 decimals), deployed 8 October 2026 on the devnet-4 verifier (block 11871931). Earlier oracles stay as deployed with their records: 0xbb345004…9e34 (devnet-4 chain id, the 8-byte width), 0x3ad71d46…3ab6 (Devnet 3 on its verifier), 0xefe9879d…a1b2 (the stand-in verifier at first).

Verifier

0x874D8Be5385474414aeb69EE4AB8374DA34b8c1F the shared IgneumCertificateVerifier for igneum-devnet-4 (the DEX lane's, a real BLS12-381 check on chain through the EIP-2537 precompiles), set on this oracle by setVerifier on 8 October 2026 (tx 0x7ccffe23…3df1); its voter table installs at the first lock (the chain's first finality certificate, when the weight window fills at DAA 7,200), so no devnet-4 certificate is recorded before that: "table installs at the first lock". The earlier devnet's verifier 0xAf74f3F5…D744 holds that devnet's table at checkpoint 2127.

Chain

Sepolia, chain id 11155111; the Igneum 2.0 devnet (igneum-devnet-4), no value

Proven roots

On the 2.0 devnet: certificate 249 (0x181c5dfd…, 38 voters, signed weight 4,968 of 7,151) verified by the devnet-4 verifier against the table it installed at the chain's first lock (checkpoint 241); chain block 3815's post_root stored on this oracle with a 3-header path, tx 0x490deea5…d869, 1,545,112 gas; provenBalance read 5,731.050719 IGN for 0x53fe9802…144b on Sepolia, equal to the devnet node's eth_getProof. On Devnet 3 (its own verifier and oracles): certificate 2232 recorded with a real BLS check (tx 0x1794b785…, 792,677 gas), block 28439's root stored (tx 0x3629525e…, 1,624,984 gas), 721.451608 IGN read for 0xcaed79d8…c087.

How to read a balance from another contract: IIgneumStateOracle(oracle).provenBalance(number, account, accountProof), where number is a devnet chain block whose state root the oracle holds and accountProof is the eth_getProof account proof at that block. A storage slot: provenStorage(number, account, slot, accountProof, storageProof). Both revert on any mismatch.

Until the Igneum 2.0 devnet has its first finality certificate, this page answers: no finality certificate yet; the first lock comes when the weight window fills at DAA 7,200 (the live DAA is shown with the answer). A certificate naming any network other than the release manifest's (/release.json, network.id) is refused before any check runs.

What the contract checks

The certificate, through the shared verifier: the aggregate BLS signature over the checkpoint under the installed voter table and the weight rule.
The header path from the carrier block up to the certified checkpoint: BLAKE2b-256 keyed BlockHash through the precompile, every parent link.
The coinbase transaction under the carrier's hash_merkle_root, and the segment record parsed out of its extra data: the record's post_root for its block is stored under the certificate's index.
Every read: a keccak-keyed Merkle Patricia proof against the stored root, verified on chain.

Recovery locks are not accepted by this verifier. Both Sepolia verifiers apply the two-thirds rule only: a certificate signed under the recovery rule (more than half of the anchored weight after a full window with no lock, Review B F04) carries under two thirds of the installed table and submitCertificate reverts, so every root this oracle answers passed the final rule. A recovery lock is never presented here as a final lock because it is never stored. The verifier reads weight against its installed table and nothing else; a re-installed table moves the threshold with it.

Trust anchors and unchecked signatures, named (also returned by the contract's `trust()`)

Deployer-installed trust anchor, disclosed, not removed: the shared verifier's voter table. It stays because no header field commits to the table yet; the day one does, the table is read from the chain and this anchor goes. The devnet-4 verifier's table installs at the chain's first lock; the roots and certificate recorded below are the earlier devnet's, under its verifier's table (checkpoint 2127).
The voter table and weights the shared verifier checks certificates against were installed by the verifier's deployer (read from a node at checkpoint 2127), not read from the chain. A certificate is verified against that installed table; a later table that drifts past the rule's margin needs a new install by that deployer.
The aggregator's BLS signature over the segment record is not checked on chain, and the SP1 proof behind its statement is not verified on chain. A stored root rests on the aggregator's statement as the nodes check and pay it.
A balance read from a stored root is executed and finalised state under those assumptions, not a payment outcome.

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.

Said plainly on the page and in trust(): the same two unchecked items, the installed table and the aggregator signature. Gas on Sepolia, measured 8 October 2026: a 62-header path 13.3 million (about 215,000 per header, 15 precompile blocks each), a 10-header path about 2.2 million, the state-root store 177,000, a balance read 153,000. The negative cases in test.mjs are a flipped proof node, a wrong block number, a header removed from the path, a merkle sibling altered, a record with its post_root altered, a header with its nonce altered: each reverts.

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.

Recovery lock

Not a fifth state and never shown as finalised. After a full weight window with no lock, the finality rule accepts a checkpoint signed by more than half of the anchored weight (the recovery rule, Review B F04). The node reports each lock's kind beside its checkpoint (lockKind: final or recovery); the certificate bytes carry none, so the kind is the node's report. These pages print a recovery lock as recovery lock, not final on the result, in the receipt file (lock_state) and in the one-file verifier, and refuse a receipt that claims final under a reported recovery lock. On a node before the field nothing is shown. Devnet 3 and the 2.0 devnet, no value.

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