HomeAll dAppsZK Commitments

ZK Rollup with validity proofs

Correction, 2026-08-01, and it is worth reading before you trust an address on any page. This page printed two addresses, one labelled the rollup and one labelled its Groth16 verifier. We probed both by walking their live runtime bytecode and matching the function selectors it contains. Neither is what the label said. The first has no stateRoot, no batchCount, no submitBatch and no verifyProof; it is a bridge contract with a mint entry point. The second is a plain ERC-20: name() returns "Aere-Bridged USDC", symbol() returns "aUSDC", decimals() returns 6 and the total supply is 50 aUSDC. There is no ZK rollup and no rollup verifier deployed on chain 2800. The addresses are removed rather than corrected, because there is nothing to correct them to. The circuit and the browser prover below are real; the deployment is not.

The design: state is a Poseidon commitment of two account balances, and each batch is a transfer carrying a Groth16 proof that the transfer was applied correctly. An L1 verifier would check the proof, so there is no fraud window and finality is immediate on inclusion. This is the validity-proof model, in two-account form to show the cryptographic core, and the same pattern extends to N accounts through a Merkle-tree state. Everything in this paragraph describes what the circuit does, not what chain 2800 runs today.

Rollup status

AereZKRollupnot deployed on chain 2800 (measured 2026-08-01)
Verifiernot deployed on chain 2800 (measured 2026-08-01)
Account 0,
Account 1,
State root,
Batches submitted,

1 · Track local state

The chain only stores a Poseidon commitment of the two balances. To advance the rollup, you must know the pre-image. Anyone can post a batch as long as they know the current balances. The genesis is account 0 = 1000, account 1 = 0.

,

2 · Build a transfer

,

3 · Submit batch on-chain

The verifier will reject any proof that doesn't match the current on-chain state root or violates the transfer rules. Submitting advances the rollup; the verifier costs no fees on AERE.

,

Recent batches

,

How it works

Off-chain (browser)                       On-chain (AERE L1)
─────────────────                         ──────────────────
1. Read on-chain stateRoot               ┐
2. Know (bal0, bal1) such that            │
   Poseidon(bal0,bal1) == stateRoot       │
3. Pick (direction, amount)               ├── Verifier (Groth16) checks:
4. Compute newBal0, newBal1               │     • prover knew pre-image of stateRoot
5. Compute newState = Poseidon(...)       │     • amount ≤ sender balance
6. Run circom witness + Groth16 prove     │     • newState matches Poseidon of new balances
7. Submit (newState, dir, amount, proof)──┘
                                            8. State root advances to newState
                                            9. BatchPosted event emitted