zkAPI

Contracts and proof artifacts

Reviewed ethereum/zkapi revision, whose vault, adapter and circuits match the deployment revision reported by the production manifest. Compile with the checked-in configuration: solc 0.8.28, optimizer 200, viaIR and Prague.

git clone https://github.com/ethereum/zkapi.git
cd zkapi
git checkout 045b444ea1b52538d1b40273c7cb6ed09468a052
cd demo/contracts
forge build --skip test --build-info
cast tx 0xf753fd93c7e672f7b851f261f600e06930e502bdfd73be29ce8a065643df6985 --json --rpc-url "$ZKAPI_RESEARCH_RPC_URL" > vault-tx.json
cast tx 0x45f2f5259476afd5f64a6a62a36c9012c3a26efcdd35b048a7fac5ae1ba43780 --json --rpc-url "$ZKAPI_RESEARCH_RPC_URL" > verifier-tx.json

The adapter creation bytecodeGenerally, an instruction set designed for efficient execution by a software interpreter or a virtual machine. Unlike human-readable source code, bytecode is expressed numerically. Within the context of rollups, often related to the concept of compatibility: whether the bytecode of programs on the rollup are capable of being run as-is on Ethereum as well, and vice versa. matches exactly, including metadata. The vault matches after linking the discovered Poseidon address. Decode its ten constructor arguments from the remaining transaction input. Sources are verified on Etherscan: vault, adapter, Poseidon.

The deployed verification-key coordinates and public inputs match the published setup artifacts, and the proving-key hashes match the SDK and production pins. A single-party setup with fresh randomness yields different keys each time, so matching artifacts show that the deployed keys are the published ones. Only the setup party knows whether its secrets were erased.

Frontend and local clientSometimes labelled interchangeably as a “node”, they are tasked with processing transactions and managing the blockchains's state. They run the computations for each transaction according to the rollup's virtual machine and protocol rules. If comparing to Ethereum clients, these would be execution clients such as Geth, as opposed to consensus clients.

The browser frontend and the local API daemon have public source and build instructions. Both still depend on the operatorAn operator is the entity charged with managing a rollup and progressing its state. A rollup operator can be a centralized sequencer, proposer, prover, challenger, pauser of admin that is able to perform upgrades.’s authorization and inference services.

VerifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. enclave

The mainnet verifier is verifier-production-20260917.openanonymity.ai, pinned in the hosted app’s browser config. It runs in an Azure confidential container on AMD SEV-SNP and serves a hardware attestation. Its source, OpenAnonymity/oa-verifier, is pinned to commit 4299cfa by the production rollout.

curl -sS "https://verifier-production-20260917.openanonymity.ai/attestation?nonce=$(date +%s)" > attestation.json
# 1. the JWT in .token is signed by Azure Attestation (.verify_at), its x-ms-sevsnpvm-hostdata equals sha256 of the decoded .policy
# 2. the policy lists one dm-verity layer hash for the verifier container
git clone https://github.com/OpenAnonymity/oa-verifier && cd oa-verifier
git checkout 4299cfa136c90550737dd46c89dba586c213159b
nix build .#container && docker load < result
# 3. push oa-verifier:latest to a local registry, then
go install github.com/Microsoft/hcsshim/cmd/[email protected]
dmverity-vhd roothash -i localhost:5000/oa-verifier:latest

The rebuilt image matches the published ghcr.io/openanonymity/oa-verifier@sha256:60f9892b… in nix store path, config and layer, and its layer root hashA fixed-length fingerprint of variable-size input, produced by a hash function. equals the attested policy. Pushing through a different docker version changes the compressed manifest digest, while the measured layer hash stays. The attestation also binds the TLS key of the live endpoint. Both clients pin only the verifier’s address, so repeat the check when it matters.