a42dc344 (main)
and
095402af (PR)
+150 -8
+31 -0
[
{
"address": "0xaf73Dd51D1eb8a079BB097f39c832cDD00ac691c",
"sinceTimestamp": 1782803327,
"tokens": [
"AZTEC"
],
"contract": {
"isVerified": true,
"address": "eth:0xaf73Dd51D1eb8a079BB097f39c832cDD00ac691c",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"url": "https://etherscan.io/address/0xaf73Dd51D1eb8a079BB097f39c832cDD00ac691c#code"
},
"chain": "ethereum",
"includeInTotal": true,
"chainId": 1
},
{
"address": "0xdf410ad448A0f7165181FBdB32f8896f4a0d9449",
"sinceTimestamp": 1790298635,
"tokens": [
"DAI"
],
"contract": {
"isVerified": true,
"address": "eth:0xdf410ad448A0f7165181FBdB32f8896f4a0d9449",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "zk.money escrow. Withdrawals need a proven Aztec L2->L1 message and a signature from a TEE signer (AWS Nitro enclave) registered on the portal, so exits depend on a live enclave running the approved image.",
"url": "https://etherscan.io/address/0xdf410ad448A0f7165181FBdB32f8896f4a0d9449#code"
},
"chain": "ethereum",
"includeInTotal": true,
"source": "custom-canonical",
"bridgedUsing": {
"bridges": [
{
"name": "Canonical + additional trust assumptions"
}
]
},
"chainId": 1
}
]+3 -3
{
"dataAvailability": [
{
"name": "All transaction results (state diffs) are published in Ethereum blobs",
"description": "Each checkpoint proposal includes EIP-4844 blob commitments for state diffs, checked against the blob hashes in the proposing transaction. The epoch proof revalidates the accumulated commitments before finalization. Public transaction bodies and client CHONK proofs propagate offchain; withholding them can prevent permissionless proving, causing the pending checkpoint to expire and be pruned rather than finalized.",
"references": [
{
"title": "Rollup.sol - propose() on Etherscan",
"url": "https://etherscan.io/address/0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34#code"
},
{
"title": "Rollup.sol - validateBlobs() on Etherscan",
"url": "https://etherscan.io/address/0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34#code"
}
],
"risks": []
}
],
"exitMechanisms": [
{
"name": "Regular messaging",
"description": "The user initiates L2->L1 messages by submitting a regular transaction on this chain. When the block containing that transaction is settled, the message becomes available for processing on L1. ZK proofs are required to settle blocks. Once the epoch root proof has been verified, the rollup inserts the epoch root into the Outbox, from which withdrawals and other L2->L1 messages can be consumed on Ethereum. Withdrawals can be initiated privately on L2, revealing only the L1-facing portion of the transaction. There is no canonical bridge escrow: only the canonical messaging layer is immutable, while each token bridged through a locking escrow may introduce additional trust assumptions tied to that specific escrow.",
"risks": [],
"references": [
{
"title": "Rollup.sol - submitEpochRootProof() on Etherscan",
"url": "https://etherscan.io/address/0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34#code"
},
{
"title": "Outbox.sol - consume() on Etherscan",
"url": "https://etherscan.io/address/0x5B062aB5fD3A66BC7e73b04CeD38587673b6A2D7#code"
}
]
}
],
"forceTransactions": {
"name": "Bonded, probabilistic self-sequencing",
"description": "There is no L1 forced-transaction queue. A censored user must wait for an honest regular committee or for an honest, sufficiently capitalized escape-hatch candidate to enroll, become eligible, be selected, include the transaction, and produce a valid proof.",
"risks": [
{
"category": "Users can be censored if",
"text": "no honest regular proposer or eligible bonded escape-hatch proposer includes and proves their transactions."
}
],
"references": [
{
"title": "EscapeHatch.sol on Etherscan",
"url": "https://etherscan.io/address/0xF459348962F5eA3A9A101826B03A2CE1F459E51A#code"
}
]
},
"operator": {
"name": "There is no central operator",
"description": "There is no privileged sequencer. Anyone can stake 200.00 K AZTEC to join the sequencer queue, and anyone can call flushEntryQueue() to activate queued sequencers once the queue rules allow it.",
"risks": [],
"references": [
{
"title": "Rollup.sol - deposit() on Etherscan",
"url": "https://etherscan.io/address/0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34#code"
},
{
"title": "Rollup.sol - flushEntryQueue() on Etherscan",
"url": "https://etherscan.io/address/0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34#code"
}
]
},
"otherConsiderations": [
{
"name": "Upgrades replace the canonical rollup",
"description": "The core contracts are immutable, but Governance owns the Registry and GSE and can register a new rollup version as canonical after the governance delay.",
"references": [
{
"title": "Registry.sol - addRollup() on Etherscan",
"url": "https://etherscan.io/address/0x35b22e09Ee0390539439E24f06Da43D83f90e298#code"
},
{
"title": "Governance.sol - execute() on Etherscan",
"url": "https://etherscan.io/address/0x1102471Eb3378FEE427121c9EfcEa452E4B6B75e#code"
}
],
"risks": []
},
{
"name": "No canonical bridge escrow",
"description": "There is no default canonical escrow. The rollup is deployed only with an immutable canonical messaging bridge, which can be used by any escrow. As a result, each token bridged to Aztec via Ethereum lock-mint must be assessed individually by examining its specific locking escrow. The trust assumptions of a given escrow may differ from those of the immutable rollup itself. Gas tokens are bridged through the FeeJuicePortal, an immutable one-way portal that only supports bridging to public L2 addresses. Although the rollup and its canonical messaging bridge are immutable, an upgradeable escrow could migrate its funds to a new rollup version without requiring users to migrate, effectively trading immutability for convenience.",
"references": [
{
"title": "FeeJuicePortal.sol - on Etherscan",
"url": "https://etherscan.io/address/eth:0xaf73Dd51D1eb8a079BB097f39c832cDD00ac691c#code"
},
{
"title": "Outbox.sol - on Etherscan",
"url": "https://etherscan.io/address/0x5B062aB5fD3A66BC7e73b04CeD38587673b6A2D7#code"
}
],
"risks": []
},
{
"name": "Inclusion is probabilistic",
"description": "All protocol-level censorship-resistance tools are probabilistic. Unlike an L1 forced-transaction queue, they do not guarantee inclusion after a fixed delay. The launch-era decentralized-sequencer model estimated 20d to reach its target exit probability under its stated assumptions; it is not a current protocol guarantee and does not model validator-set changes, the escape hatch, or adversarial queue saturation. Private transactions and the bonded escape hatch can improve inclusion probability, but neither creates a deterministic deadline.",
"references": [
{
"title": "CRsim - Simulated inclusion probability on Aztec",
"url": "https://sekuba.github.io/crsim"
}
],
"risks": []
}
],
"sequencing": {
"name": "Transactions are ordered by a staked validator committee",
"description": "Joining the sequencer set is permissionless and requires staking 200.00 K AZTEC. For each epoch, the Rollup samples a 48-member committee from the active set of 3187 and selects one proposer per slot. The proposer for slot N builds the checkpoint and collects attestations during slot N-1, then submits the assembled checkpoint to Ethereum in slot N. More than two-thirds of the sampled committee must attest; the proof path verifies the attestation data before the checkpoint can become final.",
"description": "Joining the sequencer set is permissionless and requires staking 200.00 K AZTEC. For each epoch, the Rollup samples a 48-member committee from the active set of 3053 and selects one proposer per slot. The proposer for slot N builds the checkpoint and collects attestations during slot N-1, then submits the assembled checkpoint to Ethereum in slot N. More than two-thirds of the sampled committee must attest; the proof path verifies the attestation data before the checkpoint can become final.",
"sequencingSpec": {
"type": "sequencer-set",
"blockTime": {
"value": "6s",
"description": "Current expected interval between L2 block proposals. Multiple blocks can be produced by the same proposer within one slot, so this interval can differ from the proposer rotation interval."
},
"proposerRotationTime": {
"value": "1m 12s"
},
"committeeRotationTime": {
"value": "38m 24s",
"description": "A random committee is sampled from the sequencer set for each epoch, a random block producer is sampled from the committee for each slot in the epoch"
},
"sequencerCount": {
"value": "3187 sequencers",
"value": "3053 sequencers",
"secondLine": "586.92 M AZTEC"
},
"blockProductionAccess": {
"value": "Open",
"sentiment": "good"
},
"stakePerValidator": {
"value": "200.00 K AZTEC, constant"
},
"rateLimit": {
"value": "4 sequencers / epoch",
"description": "Can be changed by onchain Governance, but the contract requires nonzero minimum, divisor, and maximum queue-flush parameters."
},
"deterministicCrGadget": {
"value": "No",
"sentiment": "warning"
},
"additionalCrGadgets": {
"value": "Bonded escape hatch, private transactions",
"secondLine": "332.00 M AZTEC; every 2d 23h",
"sentiment": "good",
"description": "Escape hatch: 332.00 M AZTEC bond to enter a set from which one proposer is periodically selected every 2d 23h to bypass the regular committee, include transactions, and prove the resulting checkpoints. 1.66 M AZTEC proposal tax. Private transactions: allow users to cheaply resist censorship based on transaction content while the chain is live."
},
"inclusionDelayChart": {
"type": "committeelike",
"validatorCount": 3187,
"validatorCount": 3053,
"committeeSize": 48,
"epochSlots": 32,
"slotSeconds": 72,
"blockingThreshold": 15,
"target": 0.99,
"maxCensorFraction": 0.5,
"stakeDistribution": {
"stakeToken": "AZTEC",
"dateType": "fetched",
"date": "2026-08-06T08:48:58.509Z",
"totalStake": 586930000,
"entities": [
{
"name": "Nethermind",
"stake": 106400000
},
{
"name": "Nansen | Stake to Stack Points",
"stake": 72000000
},
{
"name": "Sigma Prime",
"stake": 64600000
},
{
"name": "P2P.org",
"stake": 38250000
},
{
"name": "snoopfear|PON",
"stake": 37200000
},
{
"name": "ZKV",
"stake": 30816000
},
{
"name": "Wonderland",
"stake": 27308000
},
{
"name": "GabbexNodes",
"stake": 27000000
},
{
"name": "Nightwolf Labs",
"stake": 23000000
},
{
"name": "DCG",
"stake": 22600000
}
]
}
},
"inclusionDelayChartDescription": "The chart models live-chain selective censorship only. It does not model the escape hatch, validator-set changes, validator-set lag, and blanket-censorship resistance gadgets."
},
"censorshipResistance": "The regular committee can be circumvented by the escape hatch, which uses RANDAO to designate a previously enrolled bonded candidate that may publish checkpoints without committee attestations. Enrollment requires 332.00 M AZTEC, a high bond intended to protect the single-proof system while providing a last-resort path around the regular sequencer set. A designated candidate that fails to propose and prove loses 9.60 M AZTEC from their bond. Aztec's private execution environment can also make selective censorship harder because transaction contents are hidden.\n\n### Selective censorship\n\nOn a live network with some censoring sequencers, users can submit private transactions or wait for an honest committee and proposer to include their public transaction.\n\n### Blanket censorship\n\nIf the entire active set censors or stops producing checkpoints, a new sequencer can join through the permissionless staking queue, subject to its churn limits. A sufficiently capitalized account can instead enroll for the escape hatch, but enrollment, candidate-set snapshots, eligibility, and RANDAO selection are lagged. Specialized proving hardware is still required. Adversaries can also saturate the entry queue or candidate set and reduce an honest user's inclusion probability.\n\n### Walkaway\n\nHatch opportunities occur approximately every 2d 23h, but the candidate set can be empty and selection, proposal, and proving can fail. The protocol therefore provides no deterministic maximum inclusion delay; permissionless validator entry and the bonded hatch only improve the probability that the chain eventually recovers.",
"references": [
{
"title": "Aztec docs - Privacy considerations",
"url": "https://github.com/AztecProtocol/aztec-packages/blob/next/docs/docs-developers/docs/resources/considerations/privacy_considerations.md#function-fingerprints-and-tx-fingerprints"
},
{
"title": "Rollup.sol - getProposerAt() on Etherscan",
"url": "https://etherscan.io/address/0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34#code"
},
{
"title": "EscapeHatch.sol - selectCandidates() on Etherscan",
"url": "https://etherscan.io/address/0xF459348962F5eA3A9A101826B03A2CE1F459E51A#code"
}
],
"risks": []
},
"stateValidation": {
"description": "Each epoch root proof is verified by the HonkVerifier smart contract on Ethereum before the proven checkpoint number is advanced and the epoch outbox state root is inserted into the Outbox. Proving is permissionless, and a single proof can cover one Checkpoint (1m 12s) to one epoch (38m 24s). The current maximum proof window is 1h 16m; checkpoints later in an epoch have less time, and unproven checkpoints are pruned.",
"categories": [
{
"title": "State root proposals",
"description": "The rollup only advances the proven chain after submitEpochRootProof() succeeds. That call verifies the epoch proof and then inserts the epoch outbox state root for L2->L1 messaging.",
"references": [
{
"title": "Rollup.sol - submitEpochRootProof() on Etherscan",
"url": "https://etherscan.io/address/0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34#code"
}
],
"risks": []
},
{
"title": "Validity proofs",
"description": "Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.",
"risks": [],
"references": [
{
"title": "Rollup.sol - submitEpochRootProof() on Etherscan",
"url": "https://etherscan.io/address/0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34#code"
},
{
"title": "HonkVerifier.sol - verify() on Etherscan",
"url": "https://etherscan.io/address/0x098f47c00F4df22a8030746Eb11378236C24b4bC#code"
}
]
},
{
"title": "Slashing",
"description": "Each 200.00 K AZTEC stake used to join the sequencer set and vote in governance can be slashed. The designated proposer for each slot can submit one separate signed ballot on L1. Ballots are grouped into rounds spanning 4 epochs (2h 33m).\n\nSlashing conditions are implemented in sequencer-node software and can change when operators update or modify that software. The onchain `SlashingProposer` enforces the voting and execution rules:\n\n* Ballots in a round target committee members from 2 rounds earlier.\n* Quorum is evaluated separately for each validator position and penalty level, not for the round as a whole. At least 65 matching ballots out of up to 128 slots are required. Votes for a higher penalty also count toward every lower level, and each validator is slashed once at the highest level that reaches quorum.\n* A round becomes executable after more than 28 rounds (approximately 2d 23h) and expires at age 34 rounds, leaving a 6-round execution window.\n* Anyone can call `executeRound()` during that window. It verifies committee commitments, skips escape-hatch epochs, deploys a deterministic payload for the approved actions, and asks the authorized Slasher to execute it.\n\nThe current onchain penalty levels are large (5.00 K AZTEC), medium (5.00 K AZTEC), and small (2.00 K AZTEC). Offenses that node software can ballot for include:\n\n* **Inactivity:** a sequencer fails to attest or propose when selected.\n* **Data withholding:** a sequencer publishes state-diff blobs but withholds public transaction bodies or CHONK proofs needed for permissionless proving.\n* **Invalidity or equivocation:** a sequencer attests to an invalid proposal, signs conflicting proposals or attestations, or uses an invalid signature.\n\nThis list and the mapping of offenses to penalty levels are not exhaustive or defined by the L1 contracts; they depend on the software each sequencer runs.\n\nThe SlashVeto Council is a 5/9 Multisig. It can permanently veto a specific payload, repeatedly renew a global 3d pause, or re-enable slashing before a pause expires. Governance can submit Slasher payloads without ballot approval, but it cannot bypass these veto and pause checks.",
"references": [
{
"title": "SlashingProposer.sol on Etherscan",
"url": "https://etherscan.io/address/eth:0x8A36b8F2Ca71D8d8Bd98e03Ebf8B4D0939Daf0bA#code"
},
{
"title": "Slasher.sol on Etherscan",
"url": "https://etherscan.io/address/eth:0xCD6855470A01aBcd989126A1183Fb50673952548#code"
},
{
"title": "SlashVeto Council - Github",
"url": "https://github.com/aztec-slash-veto/council"
},
{
"title": "slashveto.me - Monitor Slashing",
"url": "https://slashveto.me"
}
],
"risks": []
}
]
},
"upgradesAndGovernance": {
"content": "# Standard path (sequencer signaling)\n\nSequencers stake AZTEC to secure the L2 and also participate in protocol governance. Every proposal is a smart contract payload on Ethereum. The public proposal flow takes at least 12d before execution, after which Governance can change the bounded parameters described below or deploy and register a new canonical rollup version.\n\n## 1. Signaling (`GovernanceProposer`)\n\nAztec uses an onchain \"Empire\" signaling system. The designated proposer for each slot on the canonical rollup can separately signal support for one payload on L1. A round consists of 1,000 slots. A payload that receives at least 600 signals wins the round and can be submitted to `Governance`.\n\n## 2. Token voting (`Governance`)\n\nOnce submitted, a proposal passes through these states:\n\n* **Pending (3d):** voting power is snapshotted at the end of this delay.\n* **Active (7d):** AZTEC holders vote. The snapshot must contain at least 100.00 M AZTEC of total voting power, at least 20% of that power must vote, and `yea` must be strictly greater than 66.5% of votes cast (the configured `yea`-minus-`nay` margin is 33%).\n* **Queued (2d):** a successful proposal waits before it can be executed. This final phase alone is shorter than the validator withdrawal delay, but the complete public process provides at least 12d of notice. Initiating an exit immediately removes a validator from the active set, while its stake becomes withdrawable after 4d.\n* **Executable (7d):** anyone can execute the proposal during this grace period; otherwise it expires.\n\n## Emergency proposal path\n\nIf sequencer signaling is unavailable, anyone can call `proposeWithLock()` directly on `Governance`. The proposer must lock **258.75 M AZTEC**, roughly 2.5% of the total supply, for 3mo. The payload then follows the same pending, voting, queued, and executable phases as a signaled proposal.\n\n## Immutable deployments and bounded ownership\n\nThe `Rollup`, verifier, `Inbox`, `Outbox`, and installed `EscapeHatch` code cannot be upgraded in place. Feature upgrades deploy a new stack and use Governance to register its Rollup in the `Registry` and GSE. Validators staked to the bonus instance (`0x9064Fb41156D300196d5Eb95E0B3c1f08eBc39a8`) follow the newest GSE Rollup automatically; validators explicitly bound to an older Rollup remain associated with it.\n\nGovernance owns the Rollup, but its setter surface is intentionally constrained: it can change the sequencer/prover reward split and checkpoint reward, only increase the mana target, change proving cost delayed and within bounds, and update validator-entry rate within non-zero values. It can queue a replacement Slasher with a 2mo delay. The outgoing Slasher then remains active for 1mo. The EscapeHatch, the reward distributor and reward-booster addresses are fixed for the deployment.\n\nGovernance also owns the GSE and can register a new latest Rollup or set the proof-of-possession gas limit too low for new validator deposits. These powers can move incentives and bonus-instance validators away from the current version, but they do not mutate this deployment's verifier, messaging contracts, or installed EscapeHatch.\n\n## Slashing and the SlashVeto Council\n\nAztec's onchain slashing path uses `SlashingProposer` ballots and the `Slasher`. Governance can bypass the proposer and submit a payload directly to the Slasher, and can rotate the authorized Slasher through the delayed Rollup process described above. Both the ballot and direct-governance paths remain subject to payload vetoes and global pauses by the SlashVeto Council.\n\nThe **Vetoer** role is held by the SlashVeto Council. It cannot upgrade the protocol or relay arbitrary calls. It can:\n\n* veto a specific payload permanently; and\n* disable all slashing for 3d. Calling the function again renews the pause, while the Council can also re-enable slashing early.\n\n## Economics and treasury\n\n* **CoinIssuer:** the owner can mint AZTEC within an annual cap of 20% of the current total supply.\n* **ProtocolTreasury:** the DAO's treasury is gated until approximately Nov 2026 and is additionally subject to an ATP-derived activation timestamp and proposal-ordering checks. Once every gate is satisfied, a Governance proposal can relay arbitrary calls and value through the treasury."
},
"warning": "Aztec v5 has a [known critical proving-system vulnerability](https://aztec.network/blog/alpha-v5-proving-system-vulnerability) that puts funds, applications, and contract state at risk. A fix is planned for v6."
}+26 -0
[
{
"mode": "auto",
"id": "aztecnetwork-AZTEC",
"priceId": "aztec",
"symbol": "AZTEC",
"name": "AZTEC",
"iconUrl": "https://coin-images.coingecko.com/coins/images/70681/large/aztec.png?1763091883",
"amount": {
"type": "balanceOfEscrow",
"chain": "ethereum",
"sinceTimestamp": 1782803327,
"address": "0xA27EC0006e59f245217Ff08CD52A7E8b169E62D2",
"decimals": 18,
"escrowAddress": "0xaf73Dd51D1eb8a079BB097f39c832cDD00ac691c"
},
"category": "other",
"source": "canonical",
"isAssociated": true
},
{
"mode": "auto",
"id": "aztecnetwork-DAI",
"priceId": "dai",
"symbol": "DAI",
"name": "Dai Stablecoin",
"iconUrl": "https://assets.coingecko.com/coins/images/9956/large/Badge_Dai.png?1696509996",
"amount": {
"type": "balanceOfEscrow",
"chain": "ethereum",
"sinceTimestamp": 1790298635,
"address": "0x6B175474E89094C44Da98b954EedeAC495271d0F",
"decimals": 18,
"escrowAddress": "0xdf410ad448A0f7165181FBdB32f8896f4a0d9449"
},
"category": "stablecoin",
"source": "custom-canonical",
"isAssociated": false,
"bridgedUsing": {
"bridges": [
{
"name": "Canonical + additional trust assumptions"
}
]
}
}
]+28 -3
{
"ethereum": {
"roles": [],
"actors": [
{
"id": "Governance",
"name": "Governance",
"accounts": [
{
"address": "eth:0x1102471Eb3378FEE427121c9EfcEa452E4B6B75e",
"type": "Contract",
"isVerified": true,
"name": "0x1102…B75e",
"url": "https://etherscan.io/address/0x1102471Eb3378FEE427121c9EfcEa452E4B6B75e"
}
],
"chain": "ethereum",
"description": "DAO contract used for proposals and token voting. Heavily interdependent with the GSE for voting power snapshots.\n* Can interact with CoinIssuer\n * mint new AZTEC within the annual cap, accept ownership of the AZTEC token when pending, and transfer or renounce CoinIssuer ownership [via: ProtocolTreasury GATED_UNTIL has passed, the oldest unmarked Governance proposal was created after the ATP-derived activation timestamp, and markNext was not called in the same block]\n* Can interact with Registry\n * register a new canonical rollup version, update the Registry-selected reward distributor pointer, and transfer or renounce Registry ownership. Updating the pointer does not change a distributor fixed in an already deployed Rollup \n* Can interact with RewardDistributor\n * recover AZTEC from any implicit or earmarked accounting bucket and recover any non-AZTEC token held by the distributor \n* Can interact with ProtocolTreasury\n * relay arbitrary calls and ETH from the ProtocolTreasury \n* Can interact with Rollup\n * change the sequencer reward share and checkpoint reward, only increase the mana target, update proving cost within its step and cooldown bounds, update validator entry-queue limits subject to nonzero normal-phase limits and bounded bootstrap settings, queue or cancel a Slasher replacement subject to the replacement delay, set the EscapeHatch once if still unset, and transfer or renounce ownership \n * slash and eject validators while this contract is configured as the active Slasher [via: Slasher slashing is enabled and the payload has not been vetoed the active Slasher authorizes the call under its own execution rules]\n* Can interact with GSE\n * set Governance once if still unset, change the proof-of-possession gas limit (including to a value that prevents new deposits), add a new latest rollup that controls bonus-instance validators, and transfer or renounce ownership \n* Can interact with Slasher\n * execute arbitrary payload actions through the Slasher, bypassing all proposer validation including ballots, quorum, target construction, delay, and lifetime ",
"discoveryDrivenData": true
},
{
"id": "SlashingProposer",
"name": "SlashingProposer",
"accounts": [
{
"address": "eth:0x8A36b8F2Ca71D8d8Bd98e03Ebf8B4D0939Daf0bA",
"type": "Contract",
"isVerified": true,
"name": "0x8A36…f0bA",
"url": "https://etherscan.io/address/0x8A36b8F2Ca71D8d8Bd98e03Ebf8B4D0939Daf0bA"
}
],
"chain": "ethereum",
"description": "Collects one signed slashing ballot from the designated proposer in each slot. After the execution delay, anyone can tally the ballots per validator and penalty level, deploy the resulting payload, and ask the Slasher to execute it before the round expires.\n* Can interact with Rollup\n * slash and eject validators while this contract is configured as the active Slasher [via: Slasher matching ballots meet the proposer quorum, the execution delay has elapsed, the voting round is still within its lifetime, slashing is enabled, and the payload has not been vetoed the active Slasher authorizes the call under its own execution rules]\n* Can interact with Slasher\n * execute payload actions accepted by its validator-ballot tally after the proposer-enforced delay ",
"discoveryDrivenData": true
},
{
"id": "SlashVeto Council",
"name": "SlashVeto Council",
"description": "A Multisig with 5/9 threshold. \n* Can interact with Slasher\n * veto specific payloads, repeatedly disable all slashing for 3d at a time, or re-enable slashing before a pause expires ",
"accounts": [
{
"address": "eth:0xBbB4aF368d02827945748b28CD4b2D42e4A37480",
"type": "Contract",
"isVerified": true,
"name": "0xBbB4…7480",
"url": "https://etherscan.io/address/0xBbB4aF368d02827945748b28CD4b2D42e4A37480"
}
],
"chain": "ethereum",
"references": [],
"participants": [
{
"address": "eth:0xb33a08eF4624eE8F409F749Ee73766E225bEd0F4",
"type": "EOA",
"isVerified": true,
"name": "0xb33a…d0F4",
"url": "https://etherscan.io/address/0xb33a08eF4624eE8F409F749Ee73766E225bEd0F4"
},
{
"address": "eth:0xb6Da7B7a0d8c7349630183f4Bd6F13D4a8AD9216",
"type": "EOA",
"isVerified": true,
"name": "0xb6Da…9216",
"url": "https://etherscan.io/address/0xb6Da7B7a0d8c7349630183f4Bd6F13D4a8AD9216"
},
{
"address": "eth:0xB216FcaF63c6C0f73a557B342e1Da9710C95DA81",
"type": "EOA",
"isVerified": true,
"name": "0xB216…DA81",
"url": "https://etherscan.io/address/0xB216FcaF63c6C0f73a557B342e1Da9710C95DA81"
},
{
"address": "eth:0x81062F03742B88923eaB121243B69D0a0092089e",
"type": "EOA",
"isVerified": true,
"name": "0x8106…089e",
"url": "https://etherscan.io/address/0x81062F03742B88923eaB121243B69D0a0092089e"
},
{
"address": "eth:0x32e90E88bb2E6Ee4382e6884cC5c299a6bA27920",
"type": "EOA",
"isVerified": true,
"name": "0x32e9…7920",
"url": "https://etherscan.io/address/0x32e90E88bb2E6Ee4382e6884cC5c299a6bA27920"
},
{
"address": "eth:0x23d4A9533627eA70915026638ff5989a967Be667",
"type": "EOA",
"isVerified": true,
"name": "0x23d4…e667",
"url": "https://etherscan.io/address/0x23d4A9533627eA70915026638ff5989a967Be667"
},
{
"address": "eth:0x8138c46A572D989E54837d5e5dEB506889edFb5D",
"type": "EOA",
"isVerified": true,
"name": "0x8138…Fb5D",
"url": "https://etherscan.io/address/0x8138c46A572D989E54837d5e5dEB506889edFb5D"
},
{
"address": "eth:0x0Fb6215099f48D723CfB89434C2cb887357Bc871",
"type": "EOA",
"isVerified": true,
"name": "0x0Fb6…c871",
"url": "https://etherscan.io/address/0x0Fb6215099f48D723CfB89434C2cb887357Bc871"
},
{
"address": "eth:0x7EAbE4F636B937628A7Fe503bD7F06772C047FEe",
"type": "EOA",
"isVerified": true,
"name": "0x7EAb…7FEe",
"url": "https://etherscan.io/address/0x7EAbE4F636B937628A7Fe503bD7F06772C047FEe"
}
],
"discoveryDrivenData": true
},
{
"id": "GovernanceProposer",
"name": "GovernanceProposer",
"accounts": [
{
"address": "eth:0x06Ef1DcF87E419C48B94a331B252819FADbD63ef",
"type": "Contract",
"isVerified": true,
"name": "0x06Ef…63ef",
"url": "https://etherscan.io/address/0x06Ef1DcF87E419C48B94a331B252819FADbD63ef"
}
],
"chain": "ethereum",
"description": "Intermediary contract through which the designated proposer for each L2 slot can signal support for an L1 payload. A signalling round comprises 1000 slots. A payload that receives at least 600 signals can be submitted to the L1 Governance contract within the configured lifetime.\n* Can interact with Governance\n * create proposals ",
"discoveryDrivenData": true
},
{
"id": "EOA-1",
"name": "EOA 1",
"id": "EOA-1-and-EOA-2",
"name": "EOA 1 and EOA 2",
"accounts": [
{
"address": "eth:0xdFd008642F54aCD44A2a03438A86A25f55c4D3Bc",
"type": "EOA",
"isVerified": true,
"name": "0xdFd0…D3Bc",
"url": "https://etherscan.io/address/0xdFd008642F54aCD44A2a03438A86A25f55c4D3Bc",
"displayName": "EOA 1"
},
{
"address": "eth:0xefc45B71e9432a6149a7d52f11a125A19E3A11DC",
"type": "EOA",
"isVerified": true,
"name": "0xefc4…11DC",
"url": "https://etherscan.io/address/0xefc45B71e9432a6149a7d52f11a125A19E3A11DC",
"displayName": "EOA 2"
}
],
"chain": "ethereum",
"description": "* Can interact with ZkMoneyPortal\n * co-sign withdrawals and refunds. Without a signature from a registered TEE signer, no funds can leave the portal ",
"discoveryDrivenData": true
},
{
"id": "EOA-3",
"name": "EOA 3",
"accounts": [
{
"address": "eth:0x92Ba0FD39658105FaC4dF2B9BADE998B5816b350",
"type": "EOA",
"isVerified": true,
"name": "0x92Ba…b350",
"url": "https://etherscan.io/address/0x92Ba0FD39658105FaC4dF2B9BADE998B5816b350",
"displayName": "EOA 1"
"displayName": "EOA 3"
}
],
"chain": "ethereum",
"description": "* Can interact with AztecTokenPositionRegistry_ProtocolTreasury\n * add and resolve milestones, register staker implementations, set revoker roles, only decrease the execution and token unlock timestamps, and transfer or renounce ownership ",
"discoveryDrivenData": true
}
]
}
}+47 -1
{
"addresses": {
"ethereum": [
{
"name": "HonkVerifier",
"isVerified": true,
"address": "eth:0x098f47c00F4df22a8030746Eb11378236C24b4bC",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "ZK proof verification contract.\n",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x098f47c00F4df22a8030746Eb11378236C24b4bC#code"
},
{
"name": "RewardBooster",
"isVerified": true,
"address": "eth:0x4490cAb7Ce3499353E1b0090b9e530c1AD03B551",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Calculates boosted reward shares for active provers based on a configured curve, incentivizing consistent participation.\n* Roles:\n * **rollup**: Rollup",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x4490cAb7Ce3499353E1b0090b9e530c1AD03B551#code"
},
{
"name": "RollupOperationsExtLib",
"isVerified": true,
"address": "eth:0x516f010C9AB452d70E0c6f78b9E698249a66d2AC",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Library immutably linked into the Rollup for checkpoint proposal, proof verification, pruning, and chain-tip operations. Its functions operate on the calling Rollup's storage through DELEGATECALL, so direct getter calls on the library are ignored.\n",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x516f010C9AB452d70E0c6f78b9E698249a66d2AC#code"
},
{
"name": "RewardDistributor",
"isVerified": true,
"address": "eth:0x555bAAc4757A89f1CE0c84fA35afE9dD7aa8E1d3",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Holds tokens allocated for protocol rewards. The canonical Rollup contract, as defined by the Registry, can draw from the implicit reward pool while any address can claim only funds explicitly earmarked to it.\n* Roles:\n * **canonicalRollup**: Rollup\n * **registryOwner**: Governance",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x555bAAc4757A89f1CE0c84fA35afE9dD7aa8E1d3#code"
},
{
"name": "SlashPayloadCloneable",
"isVerified": true,
"address": "eth:0x57576AbA1932df7Cc30F971ACC9d4Fc6E86B6e87",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "A template for specific slashing payload contracts deployed deterministically to encode one or more slashing actions (validators and amounts) that the Slasher executes.\n",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x57576AbA1932df7Cc30F971ACC9d4Fc6E86B6e87#code"
},
{
"name": "Rollup",
"isVerified": true,
"address": "eth:0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Core rollup logic contract. It processes checkpoint proposals, verifies ZK proofs for state transitions, manages data availability, and coordinates validator selection and chain tip updates.\n* Roles:\n * **getSlasher**: Slasher the active Slasher authorizes the call under its own execution rules; ultimately Governance the active Slasher authorizes the call under its own execution rules, SlashingProposer the active Slasher authorizes the call under its own execution rules\n * **owner**: Governance",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34#code"
},
{
"name": "Slasher",
"isVerified": true,
"address": "eth:0xCD6855470A01aBcd989126A1183Fb50673952548",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Executes payload actions submitted by the authorized slashing proposer or Governance. Execution is blocked while slashing is disabled or when the vetoer has vetoed the payload; voting and execution-delay rules are enforced by the proposer, while Governance can bypass the proposer.\n* Roles:\n * **governance**: Governance slashing is enabled and the payload has not been vetoed\n * **proposer**: SlashingProposer matching ballots meet the proposer quorum, the execution delay has elapsed, the voting round is still within its lifetime, slashing is enabled, and the payload has not been vetoed\n * **vetoer**: SlashVeto Council",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0xCD6855470A01aBcd989126A1183Fb50673952548#code"
},
{
"name": "RewardExtLib",
"isVerified": true,
"address": "eth:0xD6E890c615d6f99681a00771C20ed04516288898",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Library immutably linked into the Rollup for sequencer and prover reward accounting. Its functions operate on the calling Rollup's storage through DELEGATECALL, so direct getter calls on the library are ignored.\n",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0xD6E890c615d6f99681a00771C20ed04516288898#code"
},
{
"name": "ZkMoneyPortal",
"isVerified": true,
"address": "eth:0xdf410ad448A0f7165181FBdB32f8896f4a0d9449",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Escrow of zk.money on the Aztec Network. A withdrawal needs both a proven Aztec L2->L1 message from the zk.money L2 contract and a signature from a registered TEE signer. Anyone can register a TEE signer with a fresh AWS Nitro attestation of an approved enclave image. Once the Aztec Registry's canonical rollup is no longer ROLLUP, anyone can permanently freeze the portal, stopping deposits and fixing the refund snapshot at the last proven checkpoint. Withdrawals within the frozen checkpoint and epoch bounds remain available alongside refunds that need a zk proof and a TEE signature. L2 transfers are not disabled but do not change refundable ownership.\n* Roles:\n * **teeSigners**: EOA 1, EOA 2",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0xdf410ad448A0f7165181FBdB32f8896f4a0d9449#code"
},
{
"name": "ValidatorOperationsExtLib",
"isVerified": true,
"address": "eth:0xe4F0b9769Ca04a6E3d93b5BA732b5aD80797D411",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Library immutably linked into the Rollup for validator entry, exits, slashing, and Slasher rotation. Its functions operate on the calling Rollup's storage through DELEGATECALL, so direct getter calls on the library are ignored.\n",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0xe4F0b9769Ca04a6E3d93b5BA732b5aD80797D411#code"
},
{
"name": "EscapeHatch",
"isVerified": true,
"address": "eth:0xF459348962F5eA3A9A101826B03A2CE1F459E51A",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Provides a fallback mechanism for block production if the primary sequencer committee fails or censors. Candidates post a bond of 332,000,000 AZTEC and enter the candidate set. For each hatch, the contract snapshots the eligible set and uses RANDAO to select one designated proposer; posting a bond does not grant immediate proposal rights. If the designated proposer fails to propose and prove, their bond is slashed by 9,600,000 AZTEC. The minimum tax deducted from their bond is 1,660,000 AZTEC, even if the proposal is successful. The escape hatch regularly opens every 112 epochs, given there are any eligible bonded candidates.\n* Roles:\n * **getRollup**: Rollup",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0xF459348962F5eA3A9A101826B03A2CE1F459E51A#code"
},
{
"name": "CoinIssuer",
"isVerified": true,
"address": "eth:0x02FAdF157d551aa6d761b2A2237D03Af68E41CA6",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Manages the inflation and minting schedule of the Aztec token. It enforces an annual percentage cap and mints new tokens for the budget.\n* Roles:\n * **owner**: ProtocolTreasury; ultimately Governance",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x02FAdF157d551aa6d761b2A2237D03Af68E41CA6#code"
},
{
"name": "Registry",
"isVerified": true,
"address": "eth:0x35b22e09Ee0390539439E24f06Da43D83f90e298",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Central directory that tracks the current 'canonical' (active) Rollup contract address and key system contracts like the Reward Distributor.\n* Roles:\n * **owner**: Governance",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x35b22e09Ee0390539439E24f06Da43D83f90e298#code"
},
{
"name": "ProtocolTreasury",
"isVerified": true,
"address": "eth:0x662De311f94bdbB571D95B5909e9cC6A25a6802a",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Holds the protocol's funds controlled by Governance. It acts as a timelocked executor for spending or relaying transactions approved by the DAO.\n* Roles:\n * **governance**: Governance GATED_UNTIL has passed, the oldest unmarked Governance proposal was created after the ATP-derived activation timestamp, and markNext was not called in the same block",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x662De311f94bdbB571D95B5909e9cC6A25a6802a#code"
},
{
"name": "BaseStaker",
"isVerified": true,
"address": "eth:0x79075C8E314Ab4A84d54F90b1c7032Dc5469082d",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Implementation registered by the ATP Registry for upgradeable staker proxies that manage locked AZTEC positions.\n",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x79075C8E314Ab4A84d54F90b1c7032Dc5469082d#code"
},
{
"name": "AZTEC Token",
"isVerified": true,
"address": "eth:0xA27EC0006e59f245217Ff08CD52A7E8b169E62D2",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "AZTEC token contract\n* Roles:\n * **owner**: CoinIssuer",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0xA27EC0006e59f245217Ff08CD52A7E8b169E62D2#code"
},
{
"name": "GSE",
"isVerified": true,
"address": "eth:0xa92ecFD0E70c9cd5E5cd76c50Af0F7Da93567a4f",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Central staking manager independent of Rollup implementations. Sequencers deposit stake here through their chosen Rollup contract. Their stake is then transferred to the Governance contract and activated for voting. The GSE tracks which rollup instance validators are securing, and gives them an option to automatically move to the latest Rollup version.\n* Roles:\n * **getLatestRollup**: Rollup\n * **owner**: Governance",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0xa92ecFD0E70c9cd5E5cd76c50Af0F7Da93567a4f#code"
},
{
"name": "AztecTokenPositionRegistry_ProtocolTreasury",
"isVerified": true,
"address": "eth:0xD938bE4A2cB41105Bc2FbE707dca124A2e5d0c80",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "AZTEC token-position Registry referenced by the ProtocolTreasury for its activation cutoff and by other ecosystem vesting contracts.\n* Roles:\n * **owner**: EOA 1",
"description": "AZTEC token-position Registry referenced by the ProtocolTreasury for its activation cutoff and by other ecosystem vesting contracts.\n* Roles:\n * **owner**: EOA 3",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0xD938bE4A2cB41105Bc2FbE707dca124A2e5d0c80#code"
},
{
"name": "Outbox",
"isVerified": true,
"address": "eth:0x5B062aB5fD3A66BC7e73b04CeD38587673b6A2D7",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Facilitates L2 to L1 communication. It stores the roots of L2 to L1 message trees per epoch, which are inserted by the Rollup contract. Users and portals can consume these messages on L1 by providing a Merkle proof against the stored root. A nullifier bitmap prevents double consumption.\n* Roles:\n * **rollup**: Rollup",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x5B062aB5fD3A66BC7e73b04CeD38587673b6A2D7#code"
},
{
"name": "Inbox",
"isVerified": true,
"address": "eth:0x7d4Ef0676c2032bbCC09227501D34d86641ab8cA",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Facilitates canonical L1 to L2 communication. It accepts messages (including fee asset deposits) from L1, accumulates them in an append-only frontier tree per checkpoint, and forces the Sequencers and the Rollup contract to sequentially consume the roots of these message trees, ensuring message inclusion.\n* Roles:\n * **rollup**: Rollup",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x7d4Ef0676c2032bbCC09227501D34d86641ab8cA#code"
},
{
"name": "FeeJuicePortal",
"isVerified": true,
"address": "eth:0xaf73Dd51D1eb8a079BB097f39c832cDD00ac691c",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "One-way gas bridge: Escrows the fee asset (AZTEC) used to pay for L2 mana (gas). Users deposit tokens here, which are minted on L2 via the Inbox. The Rollup contract holds exclusive rights to withdraw tokens from this portal to distribute them as rewards to L1 sequencers and provers. Apart from that, this escrow does NOT afford a way to withdraw tokens.\n* Roles:\n * **rollup**: Rollup",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0xaf73Dd51D1eb8a079BB097f39c832cDD00ac691c#code"
}
]
},
"escrows": [
{
"address": "0xaf73Dd51D1eb8a079BB097f39c832cDD00ac691c",
"sinceTimestamp": 1782803327,
"tokens": [
"AZTEC"
],
"contract": {
"isVerified": true,
"address": "eth:0xaf73Dd51D1eb8a079BB097f39c832cDD00ac691c",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"url": "https://etherscan.io/address/0xaf73Dd51D1eb8a079BB097f39c832cDD00ac691c#code"
},
"chain": "ethereum",
"includeInTotal": true,
"chainId": 1
},
{
"address": "0xdf410ad448A0f7165181FBdB32f8896f4a0d9449",
"sinceTimestamp": 1790298635,
"tokens": [
"DAI"
],
"contract": {
"isVerified": true,
"address": "eth:0xdf410ad448A0f7165181FBdB32f8896f4a0d9449",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "zk.money escrow. Withdrawals need a proven Aztec L2->L1 message and a signature from a TEE signer (AWS Nitro enclave) registered on the portal, so exits depend on a live enclave running the approved image.",
"url": "https://etherscan.io/address/0xdf410ad448A0f7165181FBdB32f8896f4a0d9449#code"
},
"chain": "ethereum",
"includeInTotal": true,
"source": "custom-canonical",
"bridgedUsing": {
"bridges": [
{
"name": "Canonical + additional trust assumptions"
}
]
},
"chainId": 1
}
],
"risks": [],
"zkVerifiers": [
"eth:0x098f47c00F4df22a8030746Eb11378236C24b4bC"
]
}+1 -1
{
"baseTimestamp": 1789471807,
"baseTimestamp": 1790759557,
"contractsDiscoDriven": true,
"hasDiscoUi": true,
"isDiscoDriven": true,
"permissionsDiscoDriven": true
}+14 -0
[
{
"id": "32c985ef",
"date": "Wed, 30 Sep 2026 09:13:57 GMT",
"timestamp": 1790759557,
"description": "Config: Add the zk.money escrow (ZkMoneyPortal), which uses the Aztec canonical messaging bridge. The full discovery is in the zkmoney config and not shown here for clarity.",
"isHighSeverity": false,
"changeCount": 14,
"sections": [
{
"kind": "watched-changes",
"body": "```diff\n contract ZkMoneyPortal (eth:0xdf410ad448A0f7165181FBdB32f8896f4a0d9449) [zkmoney/ZkMoneyPortal] {\n +++ description: Escrow of zk.money on the Aztec Network. A withdrawal needs both a proven Aztec L2->L1 message from the zk.money L2 contract and a signature from a registered TEE signer. Anyone can register a TEE signer with a fresh AWS Nitro attestation of an approved enclave image. Once the Aztec Registry's canonical rollup is no longer ROLLUP, anyone can permanently freeze the portal, stopping deposits and fixing the refund snapshot at the last proven checkpoint. Withdrawals within the frozen checkpoint and epoch bounds remain available alongside refunds that need a zk proof and a TEE signature. L2 transfers are not disabled but do not change refundable ownership.\n type:\n- \"EOA\"\n+ \"Contract\"\n proxyType:\n- \"EOA\"\n+ \"immutable\"\n name:\n+ \"ZkMoneyPortal\"\n template:\n+ \"zkmoney/ZkMoneyPortal\"\n sourceHashes:\n+ [\"0x4abb439f2218670904cdae29f2663f412a1ca4d63284a05120c764dc8eed141e\"]\n description:\n+ \"Escrow of zk.money on the Aztec Network. A withdrawal needs both a proven Aztec L2->L1 message from the zk.money L2 contract and a signature from a registered TEE signer. Anyone can register a TEE signer with a fresh AWS Nitro attestation of an approved enclave image. Once the Aztec Registry's canonical rollup is no longer ROLLUP, anyone can permanently freeze the portal, stopping deposits and fixing the refund snapshot at the last proven checkpoint. Withdrawals within the frozen checkpoint and epoch bounds remain available alongside refunds that need a zk proof and a TEE signature. L2 transfers are not disabled but do not change refundable ownership.\"\n critical:\n+ true\n deployerAddress:\n+ \"eth:0x8c5EE3f90cA6D24eD2e2c1817f0caEE89e521601\"\n sinceTimestamp:\n+ 1790298635\n sinceBlock:\n+ 26051097\n values:\n+ {\"_$cachedAvailable\":\"49994487527849187076802\",\"_$freezeArchive\":\"0x0000000000000000000000000000000000000000000000000000000000000000\",\"_$freezeCheckpointCount\":0,\"_$freezeCheckpointNumber\":0,\"_$freezeEpochNumber\":0,\"_$frozen\":false,\"_$initialized\":true,\"_$l2Portal\":\"0x015ca4a43f83d08a038c36c06ca92527f120dc1f9176ea85d1ea347decaf444d\",\"_$lastUpdatedTime\":1790759147,\"$immutable\":true,\"approvedPcr0Hashes\":[\"0x9c846102f8ac909695f7176cec0f60380ac770286bb9eec459d6152f6e676988\"],\"FPC_FUNDER\":\"eth:0x37cD81C39Bf276ea7e1c6a416A254f688c70eAFb\",\"FPC_FUNDING_CUT\":\"100000000000000000\",\"FROZEN_DEPOSIT_REFUND_VERIFIER\":\"eth:0xa2fd594dCA2d598aF231d615E5D34903154C3cCe\",\"FROZEN_NOTES_REFUND_VERIFIER\":\"eth:0x0694fF404DDA586C73EfCe21f34fe084541BB877\",\"getCurrentAvailable\":\"50000000000000000000000\",\"GLOBAL_LIMIT\":\"50000000000000000000000\",\"INBOX\":\"eth:0x7d4Ef0676c2032bbCC09227501D34d86641ab8cA\",\"L2_PORTAL\":\"0x015ca4a43f83d08a038c36c06ca92527f120dc1f9176ea85d1ea347decaf444d\",\"OUTBOX\":\"eth:0x5B062aB5fD3A66BC7e73b04CeD38587673b6A2D7\",\"owner\":\"eth:0x0000000000000000000000000000000000000000\",\"RATE\":\"578703703703703703\",\"REGISTRY\":\"eth:0x35b22e09Ee0390539439E24f06Da43D83f90e298\",\"ROLLUP\":\"eth:0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34\",\"ROLLUP_VERSION\":4248422647,\"TEE_ATTESTATION_MAX_AGE\":3600,\"TEE_CERT_MANAGER\":\"eth:0xdfe52FD98aa0Cc8Ce7778a2b00ac7B7Dc9595875\",\"TEE_NITRO_VALIDATOR\":\"eth:0x0119bC52a09Ac6e7998378BadC16D0e9A866Be56\",\"teeSigners\":[\"eth:0xdFd008642F54aCD44A2a03438A86A25f55c4D3Bc\",\"eth:0xefc45B71e9432a6149a7d52f11a125A19E3A11DC\"],\"UNDERLYING\":\"eth:0x6B175474E89094C44Da98b954EedeAC495271d0F\",\"UNPROCESSED_DEPOSIT_REFUND_VERIFIER\":\"eth:0x5C487AEb500BD0fE65fe52Be7e55a150c3220FA5\"}\n fieldMeta:\n+ {\"owner\":{\"severity\":\"HIGH\"},\"approvedPcr0Hashes\":{\"severity\":\"HIGH\",\"description\":\"Hashes of the AWS Nitro enclave images (PCR0) whose attestations can register TEE signers.\"},\"teeSigners\":{\"description\":\"Registered TEE signers. Registrations are permanent.\"},\"_$l2Portal\":{\"severity\":\"HIGH\",\"description\":\"zk.money token contract on Aztec whose L2->L1 messages can release funds.\"},\"_$frozen\":{\"severity\":\"HIGH\",\"description\":\"Whether the portal is permanently frozen. A frozen portal accepts no deposits. Withdrawals within the frozen checkpoint and epoch bounds remain available alongside refunds against the frozen state. L2 transfers are not disabled but do not change refundable ownership.\"},\"REGISTRY\":{\"description\":\"Aztec Registry. If its canonical rollup is no longer ROLLUP, anyone can freeze this portal.\"},\"FPC_FUNDER\":{\"description\":\"Receives FPC_FUNDING_CUT from every deposit and withdrawal to fund Aztec fees for zk.money users.\"},\"GLOBAL_LIMIT\":{\"description\":\"Deposit capacity (wei), refilling at RATE per second. Withdrawals are only limited by a hardcoded per-transaction cap.\",\"type\":\"RISK_PARAMETER\"}}\n implementationNames:\n+ {\"eth:0xdf410ad448A0f7165181FBdB32f8896f4a0d9449\":\"OxidePortal\"}\n category:\n+ {\"name\":\"Local Infrastructure\",\"priority\":5}\n }\n```"
}
]
},
{
"id": "4fc80441",
"date": "Tue, 15 Sep 2026 11:31:40 GMT",
"timestamp": 1789471807,
"description": "Revoker changed: This is used to revoke vesting token positions.",
"isHighSeverity": false,
"changeCount": 1,
"sections": [
{
"kind": "watched-changes",
"body": "```diff\n contract AztecTokenPositionRegistry_ProtocolTreasury (eth:0xD938bE4A2cB41105Bc2FbE707dca124A2e5d0c80) [aztecnetwork/AztecTokenPositionRegistry] {\n +++ description: AZTEC token-position Registry referenced by the ProtocolTreasury for its activation cutoff and by other ecosystem vesting contracts.\n+++ description: Address used by ATP positions as the revocation authority.\n values.getRevoker:\n- \"eth:0xA70D1A21b251eE5F15C4aD77179114d70917F0Bf\"\n+ \"eth:0x92Ba0FD39658105FaC4dF2B9BADE998B5816b350\"\n }\n```"
}
]
},
{
"id": "0eea7b7f",
"date": "Wed, 19 Aug 2026 14:30:13 GMT",
"timestamp": 1787149104,
"description": "The Registry owner (EOA) appointed a one-shot revocation payload, which then marked 29 milestone ATPs with a total allocation of 35,579,336 AZTEC as revoked. The ATPs are token vaults that vest over time to a given beneficiary address. This is Aztec Labs internal accounting, not DAO related.",
"isHighSeverity": false,
"changeCount": 1,
"sections": [
{
"kind": "watched-changes",
"body": "```diff\n contract AztecTokenPositionRegistry_ProtocolTreasury (eth:0xD938bE4A2cB41105Bc2FbE707dca124A2e5d0c80) [aztecnetwork/AztecTokenPositionRegistry] {\n +++ description: AZTEC token-position Registry referenced by the ProtocolTreasury for its activation cutoff and by other ecosystem vesting contracts.\n+++ description: Address used by ATP positions as the revocation authority.\n values.getRevoker:\n- \"eth:0x92Ba0FD39658105FaC4dF2B9BADE998B5816b350\"\n+ \"eth:0xA70D1A21b251eE5F15C4aD77179114d70917F0Bf\"\n }\n```"
}
]
},
{
"id": "574909e3",
"date": "Wed, 29 Jul 2026 11:40:44 GMT",
"timestamp": 1785325171,
"description": "The existing three-day slashing pause expired (the `slashingDisabledUntil` value did not change), so slash payload execution is enabled again.",
"isHighSeverity": false,
"changeCount": 1,
"sections": [
{
"kind": "watched-changes",
"body": "```diff\n contract Slasher (eth:0xCD6855470A01aBcd989126A1183Fb50673952548) [aztecnetwork/Slasher] {\n +++ description: Executes payload actions submitted by the authorized slashing proposer or Governance. Execution is blocked while slashing is disabled or when the vetoer has vetoed the payload; voting and execution-delay rules are enforced by the proposer, while Governance can bypass the proposer.\n+++ description: Whether slash payload execution is currently enabled.\n values.isSlashingEnabled:\n- false\n+ true\n }\n```"
}
]
},
{
"id": "04037c02",
"date": "Thu, 23 Jul 2026 13:54:50 GMT",
"timestamp": 1784814808,
"description": "Slashing was disabled for ~ three more days, until July 26.",
"isHighSeverity": false,
"changeCount": 1,
"sections": [
{
"kind": "watched-changes",
"body": "```diff\n contract Slasher (eth:0xCD6855470A01aBcd989126A1183Fb50673952548) [aztecnetwork/Slasher] {\n +++ description: Executes payload actions submitted by the authorized slashing proposer or Governance. Execution is blocked while slashing is disabled or when the vetoer has vetoed the payload; voting and execution-delay rules are enforced by the proposer, while Governance can bypass the proposer.\n+++ description: Timestamp until which slash payload execution is disabled.\n values.slashingDisabledUntil:\n- 1784800907\n+ 1785056291\n }\n```"
}
]
},
{
"id": "6c8519bf",
"date": "Tue, 21 Jul 2026 08:50:05 GMT",
"timestamp": 1784623722,
"description": "Slashing vetoed for 3d (will be extended to cover payloads targeting epochs until incl. july 21 10pm).\n\nReason: The grace period after the v5 upgrade was miscommunicated to be 1 week while it was actually 1 day only.",
"isHighSeverity": false,
"changeCount": 2,
"sections": [
{
"kind": "watched-changes",
"body": "```diff\n contract Slasher (eth:0xCD6855470A01aBcd989126A1183Fb50673952548) [aztecnetwork/Slasher] {\n +++ description: Executes payload actions submitted by the authorized slashing proposer or Governance. Execution is blocked while slashing is disabled or when the vetoer has vetoed the payload; voting and execution-delay rules are enforced by the proposer, while Governance can bypass the proposer.\n+++ description: Whether slash payload execution is currently enabled.\n values.isSlashingEnabled:\n- true\n+ false\n+++ description: Timestamp until which slash payload execution is disabled.\n values.slashingDisabledUntil:\n- 0\n+ 1784800907\n }\n```"
}
]
},
{
"id": "36d3cfc7",
"date": "Wed, 15 Jul 2026 14:36:45 GMT",
"timestamp": 1784111155,
"description": "Aztec v5 is canonical with its current verifier, messaging, reward, and slashing stack; The immutable escape patch via Escape Hatch remains and the Rollup config is hardened against malicious governance.",
"isHighSeverity": false,
"changeCount": 42,
"sections": [
{
"kind": "watched-changes",
"body": "```diff\n contract GovernanceProposer (eth:0x06Ef1DcF87E419C48B94a331B252819FADbD63ef) [aztecnetwork/GovernanceProposer] {\n +++ description: Intermediary contract through which the designated proposer for each L2 slot can signal support for an L1 payload. A signalling round comprises 1000 slots. A payload that receives at least 600 signals can be submitted to the L1 Governance contract within the configured lifetime.\n+++ description: Rollup instance whose checkpoint proposers can signal proposals.\n values.getInstance:\n- \"eth:0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962\"\n+ \"eth:0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34\"\n }\n```\n\n```diff\n contract Governance (eth:0x1102471Eb3378FEE427121c9EfcEa452E4B6B75e) [aztecnetwork/Governance] {\n +++ description: DAO contract used for proposals and token voting. Heavily interdependent with the GSE for voting power snapshots.\n receivedPermissions.2:\n- {\"permission\":\"interact\",\"from\":\"eth:0x3D6A1B00C830C5f278FC5dFb3f6Ff0b74Db6dfe0\",\"description\":\"recover AZTEC from any implicit or earmarked accounting bucket and recover any non-AZTEC token held by the distributor.\",\"role\":\".registryOwner\"}\n receivedPermissions.3.condition:\n- \"slashing is enabled and the payload has not been vetoed.\"\n receivedPermissions.3.role:\n- \".GOVERNANCE\"\n+ \".registryOwner\"\n receivedPermissions.3.description:\n- \"execute arbitrary payload actions through the Slasher, bypassing all proposer validation including ballots, quorum, target construction, delay, and lifetime.\"\n+ \"recover AZTEC from any implicit or earmarked accounting bucket and recover any non-AZTEC token held by the distributor.\"\n receivedPermissions.3.from:\n- \"eth:0x64E6e9Bb9f1E33D319578B9f8a9C719Ca6D46eBb\"\n+ \"eth:0x555bAAc4757A89f1CE0c84fA35afE9dD7aa8E1d3\"\n receivedPermissions.4:\n+ {\"permission\":\"interact\",\"from\":\"eth:0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34\",\"description\":\"change the sequencer reward share and checkpoint reward, only increase the mana target, update proving cost within its step and cooldown bounds, update validator entry-queue limits subject to nonzero normal-phase limits and bounded bootstrap settings, queue or cancel a Slasher replacement subject to the replacement delay, set the EscapeHatch once if still unset, and transfer or renounce ownership.\",\"role\":\".owner\"}\n receivedPermissions.5:\n+ {\"permission\":\"interact\",\"from\":\"eth:0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34\",\"description\":\"slash and eject validators while this contract is configured as the active Slasher.\",\"role\":\".getSlasher\",\"condition\":\"the active Slasher authorizes the call under its own execution rules.\",\"via\":[{\"address\":\"eth:0xCD6855470A01aBcd989126A1183Fb50673952548\",\"condition\":\"slashing is enabled and the payload has not been vetoed.\"}]}\n receivedPermissions.7:\n+ {\"permission\":\"interact\",\"from\":\"eth:0xCD6855470A01aBcd989126A1183Fb50673952548\",\"description\":\"execute arbitrary payload actions through the Slasher, bypassing all proposer validation including ballots, quorum, target construction, delay, and lifetime.\",\"role\":\".GOVERNANCE\",\"condition\":\"slashing is enabled and the payload has not been vetoed.\"}\n directlyReceivedPermissions.0:\n- {\"permission\":\"act\",\"from\":\"eth:0x64E6e9Bb9f1E33D319578B9f8a9C719Ca6D46eBb\",\"description\":\"execute arbitrary payload actions through the Slasher, bypassing all proposer validation including ballots, quorum, target construction, delay, and lifetime.\",\"role\":\".GOVERNANCE\",\"condition\":\"slashing is enabled and the payload has not been vetoed.\"}\n directlyReceivedPermissions.1:\n+ {\"permission\":\"act\",\"from\":\"eth:0xCD6855470A01aBcd989126A1183Fb50673952548\",\"description\":\"execute arbitrary payload actions through the Slasher, bypassing all proposer validation including ballots, quorum, target construction, delay, and lifetime.\",\"role\":\".GOVERNANCE\",\"condition\":\"slashing is enabled and the payload has not been vetoed.\"}\n }\n```\n\n```diff\n- Status: DELETED\n contract RewardBooster (eth:0x1CbB707Bd7b4Fd2BcED6D96d84372fb428e93D80) [aztecnetwork/RewardBooster]\n +++ description: Calculates boosted reward shares for active provers based on a configured curve, incentivizing consistent participation.\n```\n\n```diff\n- Status: DELETED\n contract FeeJuicePortal (eth:0x2891F8b941067F8B5a3F34545A30Cf71E3E23617) [aztecnetwork/FeeJuicePortal]\n +++ description: One-way gas bridge: Escrows the fee asset (AZTEC) used to pay for L2 mana (gas). Users deposit tokens here, which are minted on L2 via the Inbox. The Rollup contract holds exclusive rights to withdraw tokens from this portal to distribute them as rewards to L1 sequencers and provers. Apart from that, this escrow does NOT afford a way to withdraw tokens.\n```\n\n```diff\n contract Registry (eth:0x35b22e09Ee0390539439E24f06Da43D83f90e298) [aztecnetwork/Registry] {\n +++ description: Central directory that tracks the current 'canonical' (active) Rollup contract address and key system contracts like the Reward Distributor.\n+++ description: The latest registered rollup instance, treated as canonical by the Aztec contracts.\n values.getCanonicalRollup:\n- \"eth:0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962\"\n+ \"eth:0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34\"\n+++ description: The Registry-selected reward distributor. An existing Rollup keeps the distributor fixed at its deployment and is not retargeted when this pointer changes.\n values.getRewardDistributor:\n- \"eth:0x3D6A1B00C830C5f278FC5dFb3f6Ff0b74Db6dfe0\"\n+ \"eth:0x555bAAc4757A89f1CE0c84fA35afE9dD7aa8E1d3\"\n+++ description: Registered rollup version identifiers in insertion order.\n values.getVersion.2:\n+ 4248422647\n+++ description: Number of rollup versions registered in the registry.\n values.numberOfVersions:\n- 2\n+ 3\n }\n```\n\n```diff\n- Status: DELETED\n contract RewardDistributor (eth:0x3D6A1B00C830C5f278FC5dFb3f6Ff0b74Db6dfe0) [aztecnetwork/RewardDistributor]\n +++ description: Holds tokens allocated for protocol rewards. The canonical Rollup contract, as defined by the Registry, can draw from the implicit reward pool while any address can claim only funds explicitly earmarked to it.\n```\n\n```diff\n- Status: DELETED\n contract Slasher (eth:0x64E6e9Bb9f1E33D319578B9f8a9C719Ca6D46eBb) [aztecnetwork/Slasher]\n +++ description: Executes payload actions submitted by the authorized slashing proposer or Governance. Execution is blocked while slashing is disabled or when the vetoer has vetoed the payload; voting and execution-delay rules are enforced by the proposer, while Governance can bypass the proposer.\n```\n\n```diff\n- Status: DELETED\n contract EscapeHatch (eth:0x8c189ead28D5987A48e522162f9225124D50AD1B) [aztecnetwork/EscapeHatch]\n +++ description: Provides a fallback mechanism for block production if the primary sequencer committee fails or censors. Candidates post a bond of 332,000,000 AZTEC and enter the candidate set. For each hatch, the contract snapshots the eligible set and uses RANDAO to select one designated proposer; posting a bond does not grant immediate proposal rights. If the designated proposer fails to propose and prove, their bond is slashed by 9,600,000 AZTEC. The minimum tax deducted from their bond is 1,660,000 AZTEC, even if the proposal is successful. The escape hatch regularly opens every 112 epochs, given there are any eligible bonded candidates.\n```\n\n```diff\n- Status: DELETED\n contract Inbox (eth:0x8Dbf0b6ed495baAb6062f5D5365aF3C1B2ed4578) [aztecnetwork/Inbox]\n +++ description: Facilitates canonical L1 to L2 communication. It accepts messages (including fee asset deposits) from L1, accumulates them in an append-only frontier tree per checkpoint, and forces the Sequencers and the Rollup contract to sequentially consume the roots of these message trees, ensuring message inclusion.\n```\n\n```diff\n- Status: DELETED\n contract TallySlashingProposer (eth:0xa4a38fD0108C00983E75616b638Ff3321FD26958) [N/A]\n +++ description: None\n```\n\n```diff\n contract GSE (eth:0xa92ecFD0E70c9cd5E5cd76c50Af0F7Da93567a4f) [aztecnetwork/GSE] {\n +++ description: Central staking manager independent of Rollup implementations. Sequencers deposit stake here through their chosen Rollup contract. Their stake is then transferred to the Governance contract and activated for voting. The GSE tracks which rollup instance validators are securing, and gives them an option to automatically move to the latest Rollup version.\n+++ description: Latest rollup registered in the GSE. Validators assigned to the bonus instance follow this address.\n values.getLatestRollup:\n- \"eth:0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962\"\n+ \"eth:0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34\"\n }\n```\n\n```diff\n- Status: DELETED\n contract SlashPayloadCloneable (eth:0xAA43220b7eb7c8Ffe75bc9C483f3C07b0a55B445) [aztecnetwork/SlashPayloadCloneable]\n +++ description: A template for specific slashing payload contracts deployed deterministically to encode one or more slashing actions (validators and amounts) that the Slasher executes.\n```\n\n```diff\n- Status: DELETED\n contract Rollup (eth:0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962) [N/A]\n +++ description: None\n```\n\n```diff\n contract SlashVeto Council (eth:0xBbB4aF368d02827945748b28CD4b2D42e4A37480) [GnosisSafe] {\n +++ description: None\n receivedPermissions.0.from:\n- \"eth:0x64E6e9Bb9f1E33D319578B9f8a9C719Ca6D46eBb\"\n+ \"eth:0xCD6855470A01aBcd989126A1183Fb50673952548\"\n }\n```\n\n```diff\n- Status: DELETED\n contract Outbox (eth:0xc9698B7AdEf9ee63F3Bf5cFF38086e4E836579f0) [aztecnetwork/Outbox]\n +++ description: Facilitates L2 to L1 communication. It stores the roots of L2 to L1 message trees per epoch, which are inserted by the Rollup contract. Users and portals can consume these messages on L1 by providing a Merkle proof against the stored root. A nullifier bitmap prevents double consumption.\n```\n\n```diff\n+ Status: CREATED\n contract HonkVerifier (eth:0x098f47c00F4df22a8030746Eb11378236C24b4bC) [aztecnetwork/HonkVerifier]\n +++ description: ZK proof verification contract.\n```\n\n```diff\n+ Status: CREATED\n contract RewardBooster (eth:0x4490cAb7Ce3499353E1b0090b9e530c1AD03B551) [aztecnetwork/RewardBooster]\n +++ description: Calculates boosted reward shares for active provers based on a configured curve, incentivizing consistent participation.\n```\n\n```diff\n+ Status: CREATED\n contract RollupOperationsExtLib (eth:0x516f010C9AB452d70E0c6f78b9E698249a66d2AC) [aztecnetwork/RollupOperationsExtLib]\n +++ description: Library immutably linked into the Rollup for checkpoint proposal, proof verification, pruning, and chain-tip operations. Its functions operate on the calling Rollup's storage through DELEGATECALL, so direct getter calls on the library are ignored.\n```\n\n```diff\n+ Status: CREATED\n contract RewardDistributor (eth:0x555bAAc4757A89f1CE0c84fA35afE9dD7aa8E1d3) [aztecnetwork/RewardDistributor]\n +++ description: Holds tokens allocated for protocol rewards. The canonical Rollup contract, as defined by the Registry, can draw from the implicit reward pool while any address can claim only funds explicitly earmarked to it.\n```\n\n```diff\n+ Status: CREATED\n contract SlashPayloadCloneable (eth:0x57576AbA1932df7Cc30F971ACC9d4Fc6E86B6e87) [aztecnetwork/SlashPayloadCloneable]\n +++ description: A template for specific slashing payload contracts deployed deterministically to encode one or more slashing actions (validators and amounts) that the Slasher executes.\n```\n\n```diff\n+ Status: CREATED\n contract Outbox (eth:0x5B062aB5fD3A66BC7e73b04CeD38587673b6A2D7) [aztecnetwork/Outbox]\n +++ description: Facilitates L2 to L1 communication. It stores the roots of L2 to L1 message trees per epoch, which are inserted by the Rollup contract. Users and portals can consume these messages on L1 by providing a Merkle proof against the stored root. A nullifier bitmap prevents double consumption.\n```\n\n```diff\n+ Status: CREATED\n contract Inbox (eth:0x7d4Ef0676c2032bbCC09227501D34d86641ab8cA) [aztecnetwork/Inbox]\n +++ description: Facilitates canonical L1 to L2 communication. It accepts messages (including fee asset deposits) from L1, accumulates them in an append-only frontier tree per checkpoint, and forces the Sequencers and the Rollup contract to sequentially consume the roots of these message trees, ensuring message inclusion.\n```\n\n```diff\n+ Status: CREATED\n contract SlashingProposer (eth:0x8A36b8F2Ca71D8d8Bd98e03Ebf8B4D0939Daf0bA) [aztecnetwork/SlashingProposer]\n +++ description: Collects one signed slashing ballot from the designated proposer in each slot. After the execution delay, anyone can tally the ballots per validator and penalty level, deploy the resulting payload, and ask the Slasher to execute it before the round expires.\n```\n\n```diff\n+ Status: CREATED\n contract Rollup (eth:0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34) [aztecnetwork/Rollup]\n +++ description: Core rollup logic contract. It processes checkpoint proposals, verifies ZK proofs for state transitions, manages data availability, and coordinates validator selection and chain tip updates.\n```\n\n```diff\n+ Status: CREATED\n contract FeeJuicePortal (eth:0xaf73Dd51D1eb8a079BB097f39c832cDD00ac691c) [aztecnetwork/FeeJuicePortal]\n +++ description: One-way gas bridge: Escrows the fee asset (AZTEC) used to pay for L2 mana (gas). Users deposit tokens here, which are minted on L2 via the Inbox. The Rollup contract holds exclusive rights to withdraw tokens from this portal to distribute them as rewards to L1 sequencers and provers. Apart from that, this escrow does NOT afford a way to withdraw tokens.\n```\n\n```diff\n+ Status: CREATED\n contract Slasher (eth:0xCD6855470A01aBcd989126A1183Fb50673952548) [aztecnetwork/Slasher]\n +++ description: Executes payload actions submitted by the authorized slashing proposer or Governance. Execution is blocked while slashing is disabled or when the vetoer has vetoed the payload; voting and execution-delay rules are enforced by the proposer, while Governance can bypass the proposer.\n```\n\n```diff\n+ Status: CREATED\n contract RewardExtLib (eth:0xD6E890c615d6f99681a00771C20ed04516288898) [aztecnetwork/RewardExtLib]\n +++ description: Library immutably linked into the Rollup for sequencer and prover reward accounting. Its functions operate on the calling Rollup's storage through DELEGATECALL, so direct getter calls on the library are ignored.\n```\n\n```diff\n+ Status: CREATED\n contract ValidatorOperationsExtLib (eth:0xe4F0b9769Ca04a6E3d93b5BA732b5aD80797D411) [aztecnetwork/ValidatorOperationsExtLib]\n +++ description: Library immutably linked into the Rollup for validator entry, exits, slashing, and Slasher rotation. Its functions operate on the calling Rollup's storage through DELEGATECALL, so direct getter calls on the library are ignored.\n```\n\n```diff\n+ Status: CREATED\n contract EscapeHatch (eth:0xF459348962F5eA3A9A101826B03A2CE1F459E51A) [aztecnetwork/EscapeHatch]\n +++ description: Provides a fallback mechanism for block production if the primary sequencer committee fails or censors. Candidates post a bond of 332,000,000 AZTEC and enter the candidate set. For each hatch, the contract snapshots the eligible set and uses RANDAO to select one designated proposer; posting a bond does not grant immediate proposal rights. If the designated proposer fails to propose and prove, their bond is slashed by 9,600,000 AZTEC. The minimum tax deducted from their bond is 1,660,000 AZTEC, even if the proposal is successful. The escape hatch regularly opens every 112 epochs, given there are any eligible bonded candidates.\n```"
},
{
"kind": "config-related-changes",
"body": "```diff\n+ Status: CREATED\n contract BaseStaker (eth:0x79075C8E314Ab4A84d54F90b1c7032Dc5469082d) [aztecnetwork/BaseStaker]\n +++ description: Implementation registered by the ATP Registry for upgradeable staker proxies that manage locked AZTEC positions.\n```"
}
]
},
{
"id": "c47b6119",
"date": "Wed, 08 Jul 2026 12:23:27 GMT",
"timestamp": 1783513321,
"description": "[v5 upgrade payload](https://aztecgov.nethermind.io/4) passes signaling and is proposed to the Governance contract.",
"isHighSeverity": false,
"changeCount": 1,
"sections": [
{
"kind": "watched-changes",
"body": "```diff\n contract Governance (eth:0x1102471Eb3378FEE427121c9EfcEa452E4B6B75e) [aztecnetwork/Governance] {\n +++ description: DAO contract used for proposals and token voting. Heavily interdependent with the GSE for voting power snapshots.\n values.proposalCount:\n- 4\n+ 5\n }\n```"
}
]
},
{
"id": "a96de870",
"date": "Mon, 22 Jun 2026 13:58:36 GMT",
"timestamp": 1782131482,
"description": "Execute 'cut the leash' upgrade. This revokes ownership of the current rollup contract. Gov execution delay is reduced to 2d (from 30d). Since gov cannot change the escape hatch or critical configs on the current rollup, Aztec Network is now Stage 2. At the same time, there are known vulnerabilities, which places all escrowed funds at risk.",
"isHighSeverity": false,
"changeCount": 3,
"sections": [
{
"kind": "watched-changes",
"body": "```diff\n contract Governance (eth:0x1102471Eb3378FEE427121c9EfcEa452E4B6B75e) [aztecnetwork/Governance] {\n +++ description: DAO contract used for proposals and token voting. Heavily interdependent with the GSE for voting power snapshots.\n values.getConfiguration.executionDelay:\n- 2592000\n+ 172800\n receivedPermissions.3:\n- {\"permission\":\"interact\",\"from\":\"eth:0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962\",\"description\":\"change the escape hatch address and disable the escape hatch, change the slasher address which can slash arbitrary sequencers, change the sequencer queue config and disallow new sequencers joining, set the ejection threshold that exits sequencers from the active set, change various critical fee and reward configurations.\",\"role\":\".owner\"}\n }\n```\n\n```diff\n contract Rollup (eth:0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962) [aztecnetwork/Rollup] {\n +++ description: Core rollup logic contract. It processes checkpoint proposals, verifies ZK proofs for state transitions, manages data availability, and coordinates validator selection and chain tip updates.\n values.owner:\n- \"eth:0x1102471Eb3378FEE427121c9EfcEa452E4B6B75e\"\n+ \"eth:0x0000000000000000000000000000000000000000\"\n }\n```"
}
]
},
{
"id": "90de911d",
"date": "Tue, 16 Jun 2026 09:58:16 GMT",
"timestamp": 1781603826,
"description": "Revoker switched back to EOA (see below).",
"isHighSeverity": false,
"changeCount": 1,
"sections": [
{
"kind": "watched-changes",
"body": "```diff\n contract AztecTokenPositionRegistry_ProtocolTreasury (eth:0xD938bE4A2cB41105Bc2FbE707dca124A2e5d0c80) [aztecnetwork/AztecTokenPositionRegistry] {\n +++ description: Used to set the time at which AZTEC tokens owned by the ProtocolTreasury are unlocked. Is also used as source of truth for other vesting contracts in the Aztec ecosystem.\n values.getRevoker:\n- \"eth:0x79E5BD3BD5cfc52C718Fe0f83fEaab31691683cA\"\n+ \"eth:0x92Ba0FD39658105FaC4dF2B9BADE998B5816b350\"\n }\n```"
}
]
},
{
"id": "b3046f7e",
"date": "Tue, 02 Jun 2026 13:18:04 GMT",
"timestamp": 1780405492,
"description": "Revoker of the vesting contracts registry switched from EOA to a revocation payload. This does not affect the ProtocolTreasury but rather the external vesting contracts, which are not in disco.",
"isHighSeverity": false,
"changeCount": 1,
"sections": [
{
"kind": "watched-changes",
"body": "```diff\n contract AztecTokenPositionRegistry_ProtocolTreasury (eth:0xD938bE4A2cB41105Bc2FbE707dca124A2e5d0c80) [aztecnetwork/AztecTokenPositionRegistry] {\n +++ description: Used to set the time at which AZTEC tokens owned by the ProtocolTreasury are unlocked. Is also used as source of truth for other vesting contracts in the Aztec ecosystem.\n values.getRevoker:\n- \"eth:0x92Ba0FD39658105FaC4dF2B9BADE998B5816b350\"\n+ \"eth:0x79E5BD3BD5cfc52C718Fe0f83fEaab31691683cA\"\n }\n```"
}
]
},
{
"id": "4cf6ec20",
"date": "Wed, 13 May 2026 13:08:09 GMT",
"timestamp": 1778677605,
"description": "AZUP-1: Cut the Leash is queued after a successful sequencer signaling round. The proposal aims to make the escape hatch of the current rollup immutable and get it to Stage 2. Details here: https://aztecgov.nethermind.io/3. The executable payload address is https://etherscan.io/address/0xa156E3a14f45099ecdF9C6A393a118809C5d06e6#code and is simple:\n- revoke ownership of the rollup\n- gov execution delay 30d -> 2d",
"isHighSeverity": false,
"changeCount": 1,
"sections": [
{
"kind": "watched-changes",
"body": "```diff\n contract Governance (eth:0x1102471Eb3378FEE427121c9EfcEa452E4B6B75e) [aztecnetwork/Governance] {\n +++ description: DAO contract used for proposals and token voting. Heavily interdependent with the GSE for voting power snapshots.\n values.proposalCount:\n- 3\n+ 4\n }\n```"
}
]
},
{
"id": "9f35a88f",
"date": "Wed, 22 Apr 2026 13:53:02 GMT",
"timestamp": 1776865911,
"description": "slashing is back after a slashveto council pause.",
"isHighSeverity": false,
"changeCount": 1,
"sections": [
{
"kind": "watched-changes",
"body": "```diff\n contract Slasher (eth:0x64E6e9Bb9f1E33D319578B9f8a9C719Ca6D46eBb) {\n +++ description: The executor contract for penalties. It receives authorization to slash validator stakes, subject to an execution delay and a vetoer.\n values.isSlashingEnabled:\n- false\n+ true\n }\n```"
}
]
},
{
"id": "bb632c3e",
"date": "Mon, 13 Apr 2026 09:17:59 GMT",
"timestamp": 1776071799,
"description": "the slashVeto council vetoes slashing for 3d because of [this request](https://github.com/aztec-slash-veto/council/issues/7). Affected payloads can be seen on https://slashveto.me. The argument is that v4.1.3 was a bugfix release on a friday and the wave of slashing can be attributed to people not having updated in time.\n\none slashVeto council member is replaced (https://forum.aztec.network/t/join-the-slashveto-council/8521).",
"isHighSeverity": false,
"changeCount": 3,
"sections": [
{
"kind": "watched-changes",
"body": "```diff\n contract Slasher (eth:0x64E6e9Bb9f1E33D319578B9f8a9C719Ca6D46eBb) {\n +++ description: The executor contract for penalties. It receives authorization to slash validator stakes, subject to an execution delay and a vetoer.\n values.isSlashingEnabled:\n- true\n+ false\n values.slashingDisabledUntil:\n- 0\n+ 1776137255\n }\n```\n\n```diff\n contract SlashVeto Council (eth:0xBbB4aF368d02827945748b28CD4b2D42e4A37480) {\n +++ description: None\n values.$members.6:\n- \"eth:0xb31e6d9661720A93d54AF7D1815d9bb399280629\"\n+ \"eth:0x8138c46A572D989E54837d5e5dEB506889edFb5D\"\n }\n```"
}
]
},
{
"id": "2b94fb12",
"date": "Tue, 07 Apr 2026 11:42:01 GMT",
"timestamp": 1775561692,
"description": "Rollup contract has reached enough validators, so isBootstrapped is set to true.\nNow the rate of adding new validators is limited by the `getEntryQueueFlushSize` function (max 0.25% of the validator set growth per epoch, at least 1, at most 4).",
"isHighSeverity": false,
"changeCount": 1,
"sections": [
{
"kind": "watched-changes",
"body": "```diff\n contract Rollup (eth:0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962) {\n +++ description: Core rollup logic contract. It processes checkpoint proposals, verifies ZK proofs for state transitions, manages data availability, and coordinates validator selection and chain tip updates.\n values.getIsBootstrapped:\n- false\n+ true\n }\n```"
}
]
},
{
"id": "37b1d883",
"date": "Tue, 31 Mar 2026 10:55:10 GMT",
"timestamp": 1774847186,
"description": "config: forcibly register post-alpha contracts. remove from config.jsonc as soon as the payload is executed.",
"isHighSeverity": true,
"changeCount": 56,
"sections": [
{
"kind": "watched-changes",
"body": "```diff\n contract GovernanceProposer (eth:0x06Ef1DcF87E419C48B94a331B252819FADbD63ef) {\n +++ description: Intermediary contract that allows the L2 Sequencers operating the canonical rollup (as defined by the Registry) to submit formal proposals to the L1 Governance contract by signalling their support of any smart contract payload on L1 with each checkpoint proposal. A signalling round comprises 1000 checkpoints. 600 signals or more during one round allow submitting the payload as a governance proposal.\n values.getInstance:\n- \"eth:0x603bb2c05D474794ea97805e8De69bCcFb3bCA12\"\n+ \"eth:0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962\"\n }\n```\n\n```diff\n contract Governance (eth:0x1102471Eb3378FEE427121c9EfcEa452E4B6B75e) {\n +++ description: DAO contract used for proposals and token voting. Heavily interdependent with the GSE for voting power snapshots.\n values.getConfiguration.executionDelay:\n- 604800\n+ 2592000\n values.proposalCount:\n- 2\n+ 3\n receivedPermissions.1.from:\n- \"eth:0x91A3745c685c220595B997E53311EbF660144889\"\n+ \"eth:0x64E6e9Bb9f1E33D319578B9f8a9C719Ca6D46eBb\"\n receivedPermissions.3:\n+ {\"permission\":\"interact\",\"from\":\"eth:0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962\",\"description\":\"change the escape hatch address and disable the escape hatch, change the slasher address which can slash arbitrary sequencers, change the sequencer queue config and disallow new sequencers joining, set the ejection threshold that exits sequencers from the active set, change various critical fee and reward configurations.\",\"role\":\".owner\"}\n }\n```\n\n```diff\n- Status: DELETED\n contract Inbox (eth:0x15c718C05B8c0dbec4D648b6711d6Ce8793969Ee)\n +++ description: Handles L1-to-L2 messaging. Users deposit funds or send messages here, which are organized into a Merkle tree for the sequencer to include in an L2 block.\n```\n\n```diff\n contract Registry (eth:0x35b22e09Ee0390539439E24f06Da43D83f90e298) {\n +++ description: Central directory that tracks the current 'canonical' (active) Rollup contract address and key system contracts like the Reward Distributor.\n values.getCanonicalRollup:\n- \"eth:0x603bb2c05D474794ea97805e8De69bCcFb3bCA12\"\n+ \"eth:0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962\"\n values.getVersion.1:\n+ 2934756905\n values.numberOfVersions:\n- 1\n+ 2\n }\n```\n\n```diff\n contract RewardDistributor (eth:0x3D6A1B00C830C5f278FC5dFb3f6Ff0b74Db6dfe0) {\n +++ description: Holds tokens allocated for protocol rewards. The canonical Rollup contract (as defined by the Registry) calls this to distribute payments to sequencers and provers.\n values.canonicalRollup:\n- \"eth:0x603bb2c05D474794ea97805e8De69bCcFb3bCA12\"\n+ \"eth:0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962\"\n }\n```\n\n```diff\n- Status: DELETED\n contract Rollup (eth:0x603bb2c05D474794ea97805e8De69bCcFb3bCA12)\n +++ description: Core rollup logic contract. It processes block proposals, verifies ZK proofs for state transitions, manages data availability, and coordinates validator selection and chain tip updates.\n```\n\n```diff\n contract ProtocolTreasury (eth:0x662De311f94bdbB571D95B5909e9cC6A25a6802a) {\n +++ description: Holds the protocol's funds controlled by Governance. It acts as a timelocked executor for spending or relaying transactions approved by the DAO.\n values.getActivationTimestamp:\n- 1799366400\n+ 1795150800\n }\n```\n\n```diff\n- Status: DELETED\n contract RewardBooster (eth:0x7101a6703491A4D808aeAbE9F62bC1Dc6a20bdf4)\n +++ description: Calculates 'boosted' reward shares for active provers based on a configured curve, incentivizing consistent participation.\n```\n\n```diff\n- Status: DELETED\n contract HonkVerifier (eth:0x77e3bA096355510e0E9f60D292010B42d662d2B5)\n +++ description: ZK proof verification contract.\n```\n\n```diff\n- Status: DELETED\n contract TallySlashingProposer (eth:0x7a318c3DaA9f21f8fc8238c65755eB0394Fbf189)\n +++ description: Allows the validator committee to vote on slashing a specific peer. Once a quorum is reached, it proposes a slash action to the Slasher.\n```\n\n```diff\n- Status: DELETED\n contract SlashPayloadCloneable (eth:0x82c592b4Bb7E1f50f68E75d86743c3330beAaba4)\n +++ description: A template for specific slashing payload contracts deployed deterministically to encode a slashing action (who to slash and how much) that the Slasher executes.\n```\n\n```diff\n contract EscapeHatch (eth:0x8c189ead28D5987A48e522162f9225124D50AD1B) {\n +++ description: Provides a fallback mechanism for block production if the primary sequencer committee fails or censors. The committee is circumvented by allowing proposals by anyone who is able to post a large bond of 332,000,000 AZTEC. It maintains a set of bonded candidates and deterministically selects a designated proposer for a given 'hatch' period using RANDAO. If the designated proposer fails to propose and prove, their bond is slashed by 9,600,000 AZTEC. The minimum tax deducted from their bond is 1,660,000 AZTEC, even if the proposal is successful. The escape hatch regularly opens every 112 epochs, given there are any bonded candidates.\n type:\n- \"EOA\"\n+ \"Contract\"\n proxyType:\n- \"EOA\"\n+ \"immutable\"\n name:\n+ \"EscapeHatch\"\n template:\n+ \"aztecnetwork/EscapeHatch\"\n sourceHashes:\n+ [\"0x075ee4b441a07410b5aa3c5fc868789251bc02707bc5ba28a174648dafad785d\"]\n description:\n+ \"Provides a fallback mechanism for block production if the primary sequencer committee fails or censors. The committee is circumvented by allowing proposals by anyone who is able to post a large bond of 332,000,000 AZTEC. It maintains a set of bonded candidates and deterministically selects a designated proposer for a given 'hatch' period using RANDAO. If the designated proposer fails to propose and prove, their bond is slashed by 9,600,000 AZTEC. The minimum tax deducted from their bond is 1,660,000 AZTEC, even if the proposal is successful. The escape hatch regularly opens every 112 epochs, given there are any bonded candidates.\"\n sinceTimestamp:\n+ 1772654171\n sinceBlock:\n+ 24586323\n values:\n+ {\"$immutable\":true,\"getActiveDuration\":2,\"getBondSize\":\"332000000000000000000000000\",\"getBondSizeFmt\":\"332,000,000\",\"getBondToken\":\"eth:0xA27EC0006e59f245217Ff08CD52A7E8b169E62D2\",\"getCandidateCount\":0,\"getCurrentHatch\":8,\"getFailedHatchPunishment\":\"9600000000000000000000000\",\"getFailedHatchPunishmentFmt\":\"9,600,000\",\"getFrequency\":112,\"getLagInHatches\":1,\"getProposingExitDelay\":2592000,\"getRollup\":\"eth:0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962\",\"getWithdrawalTax\":\"1660000000000000000000000\",\"getWithdrawalTaxFmt\":\"1,660,000\",\"LAG_IN_EPOCHS_FOR_RANDAO\":1,\"LAG_IN_EPOCHS_FOR_SET_SIZE\":2}\n fieldMeta:\n+ {\"getBondSizeFmt\":{\"description\":\"The amount of tokens required to join the candidate set.\"},\"getWithdrawalTaxFmt\":{\"description\":\"The amount deducted from the bond when a candidate exits the candidate set. This is the minimum that a candidate loses of their bond by becoming a candidate and cannot be circumvented.\"},\"getCandidateCount\":{\"severity\":\"HIGH\",\"description\":\"Hatch proposer candidates who posted the bond.\"},\"getBondToken\":{\"description\":\"The ERC20 token used for candidate bonds.\"},\"getFailedHatchPunishmentFmt\":{\"description\":\"The amount deducted from the bond if the designated proposer fails to fulfill their duties.\"},\"getFrequency\":{\"description\":\"The number of epochs between escape hatch windows.\"},\"getActiveDuration\":{\"description\":\"The number of epochs an escape hatch remains open.\"},\"getLagInHatches\":{\"description\":\"The number of hatches ahead for which candidates are deterministically selected.\"},\"getProposingExitDelay\":{\"description\":\"The additional time (in seconds) a proposer must wait after their hatch ends before they can exit.\"},\"LAG_IN_EPOCHS_FOR_RANDAO\":{\"description\":\"The number of epochs to look back from the start of the hatch for a stable RANDAO seed.\"},\"LAG_IN_EPOCHS_FOR_SET_SIZE\":{\"description\":\"The number of epochs to look back from the start of the hatch to snapshot the stable candidate set.\"},\"getRollup\":{\"description\":\"The address of the core Rollup contract.\"}}\n implementationNames:\n+ {\"eth:0x8c189ead28D5987A48e522162f9225124D50AD1B\":\"EscapeHatch\"}\n usedTypes:\n+ [{\"typeCaster\":\"Undecimal\",\"arg\":{\"decimals\":18}}]\n category:\n+ {\"name\":\"Local Infrastructure\",\"priority\":5}\n }\n```\n\n```diff\n- Status: DELETED\n contract Slasher (eth:0x91A3745c685c220595B997E53311EbF660144889)\n +++ description: The executor contract for penalties. It receives authorization to slash validator stakes, subject to an execution delay and a vetoer.\n```\n\n```diff\n contract TallySlashingProposer (eth:0xa4a38fD0108C00983E75616b638Ff3321FD26958) {\n +++ description: Allows the validator committee to vote on slashing a specific peer. Once a quorum is reached, it proposes a slash action to the Slasher.\n type:\n- \"EOA\"\n+ \"Contract\"\n proxyType:\n- \"EOA\"\n+ \"immutable\"\n name:\n+ \"TallySlashingProposer\"\n template:\n+ \"aztecnetwork/TallySlashingProposer\"\n sourceHashes:\n+ [\"0x0b4f1c707812b207e031a78710120f6962597aca1d9bfa47b0aa4c940fadbbdb\"]\n description:\n+ \"Allows the validator committee to vote on slashing a specific peer. Once a quorum is reached, it proposes a slash action to the Slasher.\"\n sinceTimestamp:\n+ 1772654159\n sinceBlock:\n+ 24586322\n values:\n+ {\"$immutable\":true,\"COMMITTEE_SIZE\":48,\"eip712Domain\":{\"fields\":\"0x0f\",\"name\":\"TallySlashingProposer\",\"version\":\"1\",\"chainId\":1,\"verifyingContract\":\"eth:0xa4a38fD0108C00983E75616b638Ff3321FD26958\",\"salt\":\"0x0000000000000000000000000000000000000000000000000000000000000000\",\"extensions\":[]},\"EXECUTION_DELAY_IN_ROUNDS\":28,\"getCurrentRound\":237,\"INSTANCE\":\"eth:0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962\",\"LIFETIME_IN_ROUNDS\":34,\"MAX_ROUND_SIZE\":1024,\"QUORUM\":65,\"ROUND_SIZE\":128,\"ROUND_SIZE_IN_EPOCHS\":4,\"ROUNDABOUT_SIZE\":128,\"SLASH_AMOUNT_LARGE\":\"2000000000000000000000\",\"SLASH_AMOUNT_MEDIUM\":\"2000000000000000000000\",\"SLASH_AMOUNT_SMALL\":\"2000000000000000000000\",\"SLASH_OFFSET_IN_ROUNDS\":2,\"SLASH_PAYLOAD_IMPLEMENTATION\":\"eth:0xAA43220b7eb7c8Ffe75bc9C483f3C07b0a55B445\",\"SLASHER\":\"eth:0x64E6e9Bb9f1E33D319578B9f8a9C719Ca6D46eBb\",\"SLASHING_PROPOSER_TYPE\":1,\"VOTE_TYPEHASH\":\"0x18b6b90f234e6d028d4c9800043cedef34624eedddd14e60eba01934728014fe\"}\n implementationNames:\n+ {\"eth:0xa4a38fD0108C00983E75616b638Ff3321FD26958\":\"TallySlashingProposer\"}\n }\n```\n\n```diff\n contract GSE (eth:0xa92ecFD0E70c9cd5E5cd76c50Af0F7Da93567a4f) {\n +++ description: Central staking manager independent of Rollup implementations. Sequencers deposit stake here through their chosen Rollup contract. Their stake is then transfered to the Governance contract and activated for voting. The GSE tracks which rollup instance validators are securing, and gives them an option to automatically move to the latest Rollup version.\n values.getLatestRollup:\n- \"eth:0x603bb2c05D474794ea97805e8De69bCcFb3bCA12\"\n+ \"eth:0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962\"\n }\n```\n\n```diff\n contract SlashVeto Council (eth:0xBbB4aF368d02827945748b28CD4b2D42e4A37480) {\n +++ description: None\n receivedPermissions.0.from:\n- \"eth:0x91A3745c685c220595B997E53311EbF660144889\"\n+ \"eth:0x64E6e9Bb9f1E33D319578B9f8a9C719Ca6D46eBb\"\n }\n```\n\n```diff\n contract AztecTokenPositionRegistry_ProtocolTreasury (eth:0xD938bE4A2cB41105Bc2FbE707dca124A2e5d0c80) {\n +++ description: Used to set the time at which AZTEC tokens owned by the ProtocolTreasury are unlocked.\n values.getExecuteAllowedAt:\n- 1798761600\n+ 1794546000\n values.getGlobalLockParams.startTime:\n- 1798761600\n+ 1794546000\n values.getRevoker:\n- \"eth:0x0000000000000000000000000000000000000000\"\n+ \"eth:0x92Ba0FD39658105FaC4dF2B9BADE998B5816b350\"\n+++ severity: HIGH\n values.getUnlockStartTime:\n- 1798761600\n+ 1794546000\n }\n```\n\n```diff\n- Status: DELETED\n contract FeeJuicePortal (eth:0xe05dc9D5969272831757181fFf1532B066254bf1)\n +++ description: A one-way public bridge to deposit AZTEC tokens to the Rollup.\n```\n\n```diff\n- Status: DELETED\n contract Outbox (eth:0xf006c41097861AFeb18b05e586B921c081411Ee9)\n +++ description: Handles L2-to-L1 messaging. It stores Merkle roots of messages exiting the rollup, allowing users to prove inclusion and finalize withdrawals or actions on L1.\n```\n\n```diff\n+ Status: CREATED\n contract RewardBooster (eth:0x1CbB707Bd7b4Fd2BcED6D96d84372fb428e93D80)\n +++ description: Calculates 'boosted' reward shares for active provers based on a configured curve, incentivizing consistent participation.\n```\n\n```diff\n+ Status: CREATED\n contract FeeJuicePortal (eth:0x2891F8b941067F8B5a3F34545A30Cf71E3E23617)\n +++ description: One-way gas bridge: Escrows the fee asset (AZTEC) used to pay for L2 mana (gas). Users deposit tokens here, which are minted on L2 via the Inbox. The Rollup contract holds exclusive rights to withdraw tokens from this portal to distribute them as rewards to L1 sequencers and provers. Apart from that, this escrow does NOT afford a way to withdraw tokens.\n```\n\n```diff\n+ Status: CREATED\n contract Slasher (eth:0x64E6e9Bb9f1E33D319578B9f8a9C719Ca6D46eBb)\n +++ description: The executor contract for penalties. It receives authorization to slash validator stakes, subject to an execution delay and a vetoer.\n```\n\n```diff\n+ Status: CREATED\n contract HonkVerifier (eth:0x70aEDda427f26480D240bc0f4308ceDec8d31348)\n +++ description: ZK proof verification contract.\n```\n\n```diff\n+ Status: CREATED\n contract Inbox (eth:0x8Dbf0b6ed495baAb6062f5D5365aF3C1B2ed4578)\n +++ description: Facilitates canonical L1 to L2 communication. It accepts messages (including fee asset deposits) from L1, accumulates them in an append-only frontier tree per checkpoint, and forces the Sequencers and the Rollup contract to sequentially consume the roots of these message trees, ensuring message inclusion.\n```\n\n```diff\n+ Status: CREATED\n contract SlashPayloadCloneable (eth:0xAA43220b7eb7c8Ffe75bc9C483f3C07b0a55B445)\n +++ description: A template for specific slashing payload contracts deployed deterministically to encode a slashing action (who to slash and how much) that the Slasher executes.\n```\n\n```diff\n+ Status: CREATED\n contract Rollup (eth:0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962)\n +++ description: Core rollup logic contract. It processes checkpoint proposals, verifies ZK proofs for state transitions, manages data availability, and coordinates validator selection and chain tip updates.\n```\n\n```diff\n+ Status: CREATED\n contract Outbox (eth:0xc9698B7AdEf9ee63F3Bf5cFF38086e4E836579f0)\n +++ description: Facilitates L2 to L1 communication. It stores the roots of L2 to L1 message trees per epoch, which are inserted by the Rollup contract. Users and portals can consume these messages on L1 by providing a Merkle proof against the stored root. A nullifier bitmap prevents double consumption.\n```"
}
]
},
{
"id": "d8113437",
"date": "Mon, 16 Feb 2026 15:13:21 GMT",
"timestamp": 1771254730,
"description": "TGE happened. Sequencers can claim block production rewards, AZTEC is transferable and tradable on uniswap. Token governance is launched.",
"isHighSeverity": false,
"changeCount": 1,
"sections": [
{
"kind": "watched-changes",
"body": "```diff\n contract Rollup (eth:0x603bb2c05D474794ea97805e8De69bCcFb3bCA12) {\n +++ description: Core rollup logic contract. It processes block proposals, verifies ZK proofs for state transitions, manages data availability, and coordinates validator selection and chain tip updates.\n values.isRewardsClaimable:\n- false\n+ true\n }\n```"
}
]
},
{
"id": "0c33a716",
"date": "Mon, 26 Jan 2026 13:07:34 GMT",
"timestamp": 1769432788,
"description": "TGE proposal active after passing signaling by sequencers. voting will start soon, proposal will become executable on 9.2 and cause TGE on 11.2. as [explained here](https://forum.aztec.network/t/reference-for-triggering-the-aztec-token-generation-event-tge/8366).",
"isHighSeverity": false,
"changeCount": 1,
"sections": [
{
"kind": "watched-changes",
"body": "```diff\n contract Governance (eth:0x1102471Eb3378FEE427121c9EfcEa452E4B6B75e) {\n +++ description: DAO contract used for proposals and token voting. Heavily interdependent with the GSE for voting power snapshots.\n values.proposalCount:\n- 1\n+ 2\n }\n```"
}
]
},
{
"id": "66e1cfe0",
"date": "Wed, 21 Jan 2026 12:58:30 GMT",
"timestamp": 1769000209,
"description": "add TGEPayload for verification by governance.\n\nentry queue flush increase payload was executed.",
"isHighSeverity": false,
"changeCount": 14,
"sections": [
{
"kind": "watched-changes",
"body": "```diff\n contract Rollup (eth:0x603bb2c05D474794ea97805e8De69bCcFb3bCA12) {\n +++ description: Core rollup logic contract. It processes block proposals, verifies ZK proofs for state transitions, manages data availability, and coordinates validator selection and chain tip updates.\n+++ description: number of sequencers flushable per epoch: will move from the entry queue to the active validator set if flushed\n values.getEntryQueueFlushSize:\n- 1\n+ 4\n }\n```\n\n```diff\n contract TGEPayload (eth:0x77A5EEF319E23615B848a09Ebd151744547b959C) {\n +++ description: None\n type:\n- \"EOA\"\n+ \"Contract\"\n proxyType:\n- \"EOA\"\n+ \"immutable\"\n name:\n+ \"TGEPayload\"\n template:\n+ \"aztecnetwork/TGEPayload\"\n sourceHashes:\n+ [\"0xc2410dd48add80f68a5d7e354ca701a42d52f1a651c686a180e524179a08ed12\"]\n sinceTimestamp:\n+ 1768592243\n sinceBlock:\n+ 24249428\n values:\n+ {\"$immutable\":true,\"ATP_REGISTRY\":\"eth:0x63841bAD6B35b6419e15cA9bBBbDf446D4dC3dde\",\"AZTEC_TOKEN\":\"eth:0xA27EC0006e59f245217Ff08CD52A7E8b169E62D2\",\"DATE_GATED_RELAYER_SHORT\":\"eth:0x7d6DECF157E1329A20c4596eAf78D387E896aa4e\",\"END_DAY\":3,\"END_OF_WORKDAY\":54000,\"getURI\":\"https://github.com/AztecProtocol/ignition-contracts/\",\"JAN_1_2026_CET\":1767222000,\"ROLLUP\":\"eth:0x603bb2c05D474794ea97805e8De69bCcFb3bCA12\",\"ROLLUP_REGISTRY\":\"eth:0x35b22e09Ee0390539439E24f06Da43D83f90e298\",\"STAKER\":\"eth:0x11ED6b4a9D44cf8bC4e1763D08304eF20c998c95\",\"STAKING_REGISTRY\":\"eth:0x042dF8f42790d6943F41C25C2132400fd727f452\",\"START_DAY\":1,\"START_OF_WORKDAY\":28800,\"VIRTUAL_LBP_STRATEGY\":\"eth:0xd53006d1e3110fD319a79AEEc4c527a0d265E080\"}\n implementationNames:\n+ {\"eth:0x77A5EEF319E23615B848a09Ebd151744547b959C\":\"TGEPayload\"}\n }\n```\n\n```diff\n+ Status: CREATED\n contract ATPWithdrawableAndClaimableStakerV2 (eth:0x11ED6b4a9D44cf8bC4e1763D08304eF20c998c95)\n +++ description: Standard escrow implementation used to simplify and manage staking with locked AZTEC tokens.\n```\n\n```diff\n+ Status: CREATED\n contract BaseStaker (eth:0x6131D4900CD8dC328FB3CF6DFFEfbC628F02e7d9)\n +++ description: A template contract used for staker proxies within the StakingRegistry.\n```\n\n```diff\n+ Status: CREATED\n contract AztecTokenPositionRegistry_Sequencers (eth:0x63841bAD6B35b6419e15cA9bBBbDf446D4dC3dde)\n +++ description: A registry for contracts related to Sequencer staking and token unlock parameters.\n```\n\n```diff\n+ Status: CREATED\n contract GovernanceAcceleratedLock (eth:0x7d6DECF157E1329A20c4596eAf78D387E896aa4e)\n +++ description: None\n```"
}
]
},
{
"id": "c9a53a8f",
"date": "Wed, 07 Jan 2026 14:30:47 GMT",
"timestamp": 1767796183,
"description": "First gov proposal passed signalling phase:\n\n[Increase Ignition Queue Throughput](https://forum.aztec.network/t/increase-ignition-queue-throughput/8211)\n- does what it says, goal is to flush the entire queue until TGE and especially before the first upgrade of the rollup contract.",
"isHighSeverity": false,
"changeCount": 1,
"sections": [
{
"kind": "watched-changes",
"body": "```diff\n contract Governance (eth:0x1102471Eb3378FEE427121c9EfcEa452E4B6B75e) {\n +++ description: DAO contract used for proposals and token voting. Heavily interdependent with the GSE for voting power snapshots.\n values.proposalCount:\n- 0\n+ 1\n }\n```"
}
]
},
{
"id": "6ec23382",
"date": "Mon, 01 Dec 2025 15:07:20 GMT",
"timestamp": 1764601178,
"description": "config: add zk verifier from constructor vars.",
"isHighSeverity": false,
"changeCount": 1,
"sections": [
{
"kind": "config-related-changes",
"body": "```diff\n+ Status: CREATED\n contract HonkVerifier (eth:0x77e3bA096355510e0E9f60D292010B42d662d2B5)\n +++ description: ZK proof verification contract.\n```"
}
]
},
{
"id": "57137267",
"date": "Mon, 24 Nov 2025 14:16:59 GMT",
"timestamp": 1763978160,
"description": "config: yeeted flushrewarder (not core contract), ignored more noisy vars, cleaned up the disco",
"isHighSeverity": false,
"changeCount": 4,
"sections": [
{
"kind": "config-related-changes",
"body": "```diff\n+ Status: CREATED\n contract StakingRegistry (eth:0x042dF8f42790d6943F41C25C2132400fd727f452)\n +++ description: Manages staking providers for delegation.\n```\n\n```diff\n+ Status: CREATED\n contract BaseStaker (eth:0x0Cb8fe28D35fD4763C4f3E3761904bAcF829BbF8)\n +++ description: A template contract used for staker proxies within the StakingRegistry.\n```\n\n```diff\n+ Status: CREATED\n contract ATPWithdrawableAndClaimableStaker (eth:0x7C009AE557234d094D798A03D21E3c1C1CAD3b42)\n +++ description: Standard escrow implementation used to simplify and manage staking with locked AZTEC tokens.\n```\n\n```diff\n+ Status: CREATED\n contract AztecTokenPositionRegistry_Sequencers (eth:0x8F778768aDed86AB778a47cd81b3b42B4b3F655B)\n +++ description: A registry for contracts related to Sequencer staking and token unlock parameters.\n```"
}
]
},
{
"id": "60e547bd",
"date": "Thu, 20 Nov 2025 14:51:30 GMT",
"timestamp": 1763649088,
"description": "config: silence disco.",
"isHighSeverity": false,
"changeCount": 2,
"sections": [
{
"kind": "watched-changes",
"body": "```diff\n contract FlushRewarder (eth:0x7C9a7130379F1B5dd6e7A53AF84fC0fE32267B65) {\n +++ description: None\n values.rewardsAvailable:\n- \"1000000000000000000000000\"\n+ \"998300000000000000000000\"\n }\n```"
},
{
"kind": "config-related-changes",
"body": "```diff\n+ Status: CREATED\n contract FlushRewarder (eth:0x7C9a7130379F1B5dd6e7A53AF84fC0fE32267B65)\n +++ description: None\n```"
}
]
},
{
"id": "784bc3d2",
"date": "Wed, 19 Nov 2025 16:23:21 GMT",
"timestamp": 1763566766,
"description": "initial disco: aztec is in 'ignition' phase, network will launch with empty blocks for 3 months: https://aztec.network/aztec-roadmap.",
"isHighSeverity": false,
"changeCount": 19,
"sections": [
{
"kind": "initial-discovery",
"body": "```diff\n+ Status: CREATED\n contract CoinIssuer (eth:0x02FAdF157d551aa6d761b2A2237D03Af68E41CA6)\n +++ description: Manages the inflation and minting schedule of the Aztec token. It enforces an annual percentage cap and mints new tokens for the budget.\n```\n\n```diff\n+ Status: CREATED\n contract GovernanceProposer (eth:0x06Ef1DcF87E419C48B94a331B252819FADbD63ef)\n +++ description: Intermediary contract that allows the L2 system (or specific L2 signals) to submit formal proposals to the L1 Governance contract.\n```\n\n```diff\n+ Status: CREATED\n contract Governance (eth:0x1102471Eb3378FEE427121c9EfcEa452E4B6B75e)\n +++ description: DAO contract used for proposals and token voting\n```\n\n```diff\n+ Status: CREATED\n contract Inbox (eth:0x15c718C05B8c0dbec4D648b6711d6Ce8793969Ee)\n +++ description: Handles L1-to-L2 messaging. Users deposit funds or send messages here, which are organized into a Merkle tree for the sequencer to include in an L2 block.\n```\n\n```diff\n+ Status: CREATED\n contract Registry (eth:0x35b22e09Ee0390539439E24f06Da43D83f90e298)\n +++ description: Central directory that tracks the current 'canonical' (active) Rollup contract address and key system contracts like the Reward Distributor.\n```\n\n```diff\n+ Status: CREATED\n contract RewardDistributor (eth:0x3D6A1B00C830C5f278FC5dFb3f6Ff0b74Db6dfe0)\n +++ description: Holds tokens allocated for protocol rewards. The canonical Rollup contract calls this to distribute payments to sequencers and provers.\n```\n\n```diff\n+ Status: CREATED\n contract Rollup (eth:0x603bb2c05D474794ea97805e8De69bCcFb3bCA12)\n +++ description: Core rollup logic contract. It processes block proposals, verifies ZK proofs for state transitions, manages data availability, and coordinates validator selection and chain tip updates.\n```\n\n```diff\n+ Status: CREATED\n contract ProtocolTreasury (eth:0x662De311f94bdbB571D95B5909e9cC6A25a6802a)\n +++ description: Holds the protocol's funds controlled by Governance. It acts as a timelocked executor for spending or relaying transactions approved by the DAO.\n```\n\n```diff\n+ Status: CREATED\n contract RewardBooster (eth:0x7101a6703491A4D808aeAbE9F62bC1Dc6a20bdf4)\n +++ description: Calculates 'boosted' reward shares for active provers based on a configured curve, incentivizing consistent participation.\n```\n\n```diff\n+ Status: CREATED\n contract BaseStaker (eth:0x79075C8E314Ab4A84d54F90b1c7032Dc5469082d)\n +++ description: An template contract used for staker proxies within the StakingRegistry.\n```\n\n```diff\n+ Status: CREATED\n contract TallySlashingProposer (eth:0x7a318c3DaA9f21f8fc8238c65755eB0394Fbf189)\n +++ description: Allows the validator committee to vote on slashing a specific peer. Once a quorum is reached, it proposes a slash action to the Slasher.\n```\n\n```diff\n+ Status: CREATED\n contract SlashPayloadCloneable (eth:0x82c592b4Bb7E1f50f68E75d86743c3330beAaba4)\n +++ description: A template for specific slashing payload contracts deployed deterministically to encode a slashing action (who to slash and how much) that the Slasher executes.\n```\n\n```diff\n+ Status: CREATED\n contract Slasher (eth:0x91A3745c685c220595B997E53311EbF660144889)\n +++ description: The executor contract for penalties. It receives authorization to slash validator stakes, subject to an execution delay and a vetoer.\n```\n\n```diff\n+ Status: CREATED\n contract Aztec (eth:0xA27EC0006e59f245217Ff08CD52A7E8b169E62D2)\n +++ description: AZTEC token contract\n```\n\n```diff\n+ Status: CREATED\n contract GSE (eth:0xa92ecFD0E70c9cd5E5cd76c50Af0F7Da93567a4f)\n +++ description: Central staking hub. Validators (attesters) deposit stake here to register. It manages delegation of voting power and tracks which rollup instance validators are securing.\n```\n\n```diff\n+ Status: CREATED\n contract Safe (eth:0xBbB4aF368d02827945748b28CD4b2D42e4A37480)\n +++ description: None\n```\n\n```diff\n+ Status: CREATED\n contract StakingRegistry (eth:0xD938bE4A2cB41105Bc2FbE707dca124A2e5d0c80)\n +++ description: None\n```\n\n```diff\n+ Status: CREATED\n contract FeeJuicePortal (eth:0xe05dc9D5969272831757181fFf1532B066254bf1)\n +++ description: A specific bridge allowing the Aztec token ('Fee Juice') to be deposited into L2 specifically for paying gas fees. AZTEC tokens accruing in this escrow can only be used as fees for sequencers.\n```\n\n```diff\n+ Status: CREATED\n contract Outbox (eth:0xf006c41097861AFeb18b05e586B921c081411Ee9)\n +++ description: Handles L2-to-L1 messaging. It stores Merkle roots of messages exiting the rollup, allowing users to prove inclusion and finalize withdrawals or actions on L1.\n```"
}
]
}
]+108 -0
+108 -0
{
"creator": "Aztec",
"projectsForTvs": [
{
"projectId": "aztecnetwork",
"sinceTimestamp": 1774821600
},
{
"projectId": "payy",
"sinceTimestamp": 1771324355
},
{
"projectId": "zkmoney",
"sinceTimestamp": 1790298635
}
],
"proofSystemInfo": "## Description\n\nBarretenberg is a C++ library that implements several Plonk-based proof systems, developed by Aztec. It notably includes UltraHonk SNARK as an optimized version of previous Plonk implementation, and CHONK (Client-side Highly Optimized ploNK) SNARK for client-side proving on weaker devices. Barretenberg implements actual zero-knowledge SNARK modifications that allow proving over private data, and provides tools to generate UltraHonk smart contract verifiers. It also contains circuits to prove private and public transactions on Aztec L2.\n\n## Proof system\n\nThe main application of Barretenberg is proving Aztec L2 state transition, which includes users locally proving private transactions with true ZK CHONK and more powerful nodes proving public transactions using UltraHonk. CHONK proofs must be verified within UltraHonk, so Barretenberg also includes tools for recursive proving. Both proving systems operate on arithmetic circuits that could be compiled from [Noir](https://github.com/noir-lang/noir) programs into ACIR, which is a [native circuit representation for Barretenberg](https://barretenberg.aztec.network/docs/#relationship-with-noir). \n\n### UltraHonk\n\nUltraHonk is built on top of [Plonk](https://eprint.iacr.org/archive/2019/953/1624533038.pdf) proof system, with several optimizations for performance. It also serves as a basis for CHONK. The main optimization comes from using sumcheck protocol over the boolean hypercube as described in the [HyperPlonk paper](https://eprint.iacr.org/2022/1355). This trick allows reducing prover time and memory requirements at the expense of larger proofs. Barretenberg also contains code for circuits [verifying Honk proofs within UltraHonk verifier](https://github.com/AztecProtocol/aztec-packages/tree/next/barretenberg/cpp/src/barretenberg/stdlib/honk_verifier), allowing prover recursion. For more technical details on UltraHonk see [here](https://github.com/AztecProtocol/aztec-packages/tree/99c1647e91c83a3b1b3e040fce481fb4c7265522/barretenberg/cpp/src/barretenberg/ultra_honk#readme).\n\n### CHONK\n\nCHONK is the proof system that is most optimized for client side proving in memory-restricted environments like mobile and browsers. In addition, CHONK has zero-knowledge property to protect prover private inputs, which is achieved by adding random masking polynomials at several stages of the pipeline and some other measures. For the full description of ZK-related modifications see [here](https://github.com/AztecProtocol/aztec-packages/tree/99c1647e91c83a3b1b3e040fce481fb4c7265522/barretenberg/cpp/src/barretenberg/ultra_honk#zero-knowledge).\n\nOne of CHONK’s key innovations is Goblin architecture that efficiently manages elliptic curve operations over BN254 used e.g. in signatures. Elliptic curve operations are collected in a queue during the circuit proving, but the proof of their correctness is deferred to the very end of the proving process. The final step of the proving is done over a different curve called Grumpkin, which is chosen to make these EC operations native (i.e. extremely efficient). The correctness of translation between BN254 and Grumpkin is handled by the [Translator VM](https://github.com/AztecProtocol/aztec-packages/blob/7d03c441df4935ec5b08069446f3e8d59966532e/barretenberg/cpp/src/barretenberg/translator_vm/README.md) and the correctness of EC operations is proven by the [ECCVM](https://github.com/AztecProtocol/aztec-packages/blob/7d03c441df4935ec5b08069446f3e8d59966532e/barretenberg/cpp/src/barretenberg/eccvm/README.md).\n\nCHONK also introduces a folding scheme inspired by [HyperNova](https://eprint.iacr.org/2023/573) for more memory-efficient proving of recursive smart contract calls. In this case different smart contract are represented by different circuits, which are proven separately and then aggregated. The folding scheme allows efficient aggregation of these proofs that results in only one expensive polynomial commitment check in the end, instead of having to check it for each smart contract call.\n\nFor more technical details on CHONK see [here](https://github.com/AztecProtocol/aztec-packages/tree/7d03c441df4935ec5b08069446f3e8d59966532e/barretenberg/cpp/src/barretenberg/chonk#readme).\n\n### Noir and trusted setups\n\nAlthough not technically a part of Barretenberg proving repo, [Noir language](https://noir-lang.org) represents the most developer-friendly way to create circuits to be proven with UltraHonk or CHONK. It’s a domain-specific language inspired by Rust.\n\nAll Barretenberg proving systems extend Plonk, which is based on KZG commitment schemes. That requires a trusted setup, which is chosen to be Aztec Ignition trusted setup. Some internal proofs, like ECCVM proof, are based on IPA (inner product argument) and thus they require no trusted setup.",
"techStack": {
"zkVM": [
{
"id": "UltraHonk",
"type": "Plonk",
"name": "UltraHonk",
"description": "A KZG-based PLONKish proving system featuring many optimizations, including a sumcheck argument over a boolean hypercube. Developed by Aztec as a part of Barretenberg library."
},
{
"id": "CHONK",
"type": "Plonk",
"name": "CHONK",
"description": "PLONKish proving system, designed for client-side proving. Includes sumcheck argument over a hypercube, HyperNova-like folding schemes and GoblinPlonk EC operation optimization over Grumpkin curve. Developed by Aztec as a part of Barretenberg library."
},
{
"id": "BN254",
"type": "curve",
"name": "BN254",
"description": "BN254, aka BN256, aka alt_bn128 pairing-friendly 254-bit prime field Weierstrass elliptic curve."
},
{
"id": "Grumpkin",
"type": "curve",
"name": "Grumpkin",
"description": "Curve that forms a curve cycle together with BN254, which allows highly efficient recursive proof composition by switching between these two curves."
},
{
"id": "AVM",
"type": "ISA",
"name": "AVM",
"description": "VM that executes the public part of Aztec L2 transactions, conceptually similar to EVM."
}
]
},
"trustedSetups": [
{
"proofSystem": {
"id": "UltraHonk",
"type": "Plonk",
"name": "UltraHonk",
"description": "A KZG-based PLONKish proving system featuring many optimizations, including a sumcheck argument over a boolean hypercube. Developed by Aztec as a part of Barretenberg library."
},
"id": "AztecIgnition",
"name": "Aztec Ignition",
"participantCount": 176,
"risk": "green",
"shortDescription": "Aztec Ignition is a trusted setup ceremony that was run by Aztec for KZG commitment over BN254 curve in 2019. It included 176 participants and was publicly open for participation.",
"longDescription": "Aztec Ignition is a trusted setup ceremony for KZG commitments over BN254 curve that was run by Aztec for KZG commitment over BN254 curve in 2019. \nIt included 176 participants and was publicly open for participation.\n\n- Github repo to download and verify the ceremony artifacts: [https://github.com/AztecProtocol/ignition-verification](https://github.com/AztecProtocol/ignition-verification).\n- Github repo with instructions for ceremony participants: [https://github.com/AztecProtocol/Setup](https://github.com/AztecProtocol/Setup).\n- Ceremony announcement with a call to participate: [https://aztec.network/blog/announcing-ignition](https://aztec.network/blog/announcing-ignition)."
}
],
"verifierHashes": [
{
"hash": "0x0f8581a994b714ef6fcffeaea9777e69e6bc7c0140a039a23afc764d8e863328",
"name": "Payy aggregate verifier",
"sourceLink": "https://github.com/polybase/payy/tree/dcd5d96ee15664a59bc24ed0dc2bb78b73ac5e36/noir/agg_final",
"proofSystem": {
"id": "UltraHonk",
"type": "Plonk",
"name": "UltraHonk",
"description": "A KZG-based PLONKish proving system featuring many optimizations, including a sumcheck argument over a boolean hypercube. Developed by Aztec as a part of Barretenberg library."
},
"knownDeployments": [
{
"address": "eth:0x14DACD534ddc676601B27f41Eb541a7951524a2F"
}
],
"verificationStatus": "successful",
"attesters": [
{
"id": "l2beat",
"name": "L2BEAT",
"link": "https://l2beat.com"
}
],
"verificationSteps": "The verifier was regenerated on Linux. VK generation peaked at approximately 1.7 GiB of memory.\n\nPrepare:\n\n1. Install Nargo 1.0.0-beta.14, e.g. with `noirup -v 1.0.0-beta.14`. `nargo --version` should report noirc git version hash `60ccd48e18ad8ce50d5ecda9baf813b712145051`.\n2. Install the Barretenberg CLI release `v3.0.0-nightly.20251030-2`, the version pinned to Nargo 1.0.0-beta.14 in the official [bb-versions.json](https://github.com/AztecProtocol/aztec-packages/blob/next/barretenberg/bbup/bb-versions.json) mapping, e.g. by downloading `barretenberg-amd64-linux.tar.gz` from the [aztec-packages release](https://github.com/AztecProtocol/aztec-packages/releases/tag/v3.0.0-nightly.20251030-2). Note that the Payy repository README refers to this bb version as `3.0.0-manual.20251030`, for which no release artifact exists.\n\nVerify:\n\n1. Clone [polybase/payy](https://github.com/polybase/payy), then check out commit `dcd5d96ee15664a59bc24ed0dc2bb78b73ac5e36`.\n2. Compile the `agg_final` circuit from source:\n ```bash\n cd noir\n nargo compile --package agg_final\n ```\n3. Generate the UltraHonk verification key with the keccak oracle hash from the newly compiled bytecode:\n ```bash\n mkdir -p /tmp/payy-repro\n bb write_vk --scheme ultra_honk --oracle_hash keccak \\\n -b target/agg_final.json -o /tmp/payy-repro\n xxd -p -c 0 /tmp/payy-repro/vk_hash\n ```\n The final command should print `0f8581a994b714ef6fcffeaea9777e69e6bc7c0140a039a23afc764d8e863328`.",
"description": "UltraHonk verifier generated with Barretenberg from the final proof aggregation Noir circuit (agg_final) of Payy. The hash is the verification key hash hardcoded in the deployed verifier contract."
},
{
"hash": "0x2f0ca3e610369fc41f7fb8a69995a96428fbf69d7dffd2b576e63ba4d9511ee1",
"name": "Barretenberg Aztec verifier v5",
"sourceLink": "https://github.com/AztecProtocol/aztec-packages/tree/v5.0.0/noir-projects/noir-protocol-circuits",
"proofSystem": {
"id": "UltraHonk",
"type": "Plonk",
"name": "UltraHonk",
"description": "A KZG-based PLONKish proving system featuring many optimizations, including a sumcheck argument over a boolean hypercube. Developed by Aztec as a part of Barretenberg library."
},
"knownDeployments": [
{
"address": "eth:0x098f47c00F4df22a8030746Eb11378236C24b4bC"
}
],
"verificationStatus": "successful",
"attesters": [
{
"id": "l2beat",
"name": "L2BEAT",
"link": "https://l2beat.com"
}
],
"verificationSteps": "The verifier was regenerated on Linux. VK generation peaked at approximately 11.3 GiB of memory.\n\nPrepare:\n\n1. Install the toolchain expected by the repository: Node.js 24.12.0 or newer, Yarn 4.13.0, Rust 1.89.0, CMake 3.24 or newer, Clang 20, Zig 0.15.1, Ninja, `jq`, `xxd`, `base64`, and `gzip`.\n2. Ensure at least 16 GiB of combined memory and swap is available.\n\nVerify:\n\n1. Clone [AztecProtocol/aztec-packages](https://github.com/AztecProtocol/aztec-packages), then check out tag `v5.0.0`. It should resolve to commit `7aa2bd616d632801fe65d97ee8a4434f26886b40`.\n2. Initialize the Noir source pinned by the tag: `git submodule update --init --depth 1 noir/noir-repo`. It should resolve to commit `c57152f91260ecdb9faad4efc20abb14b6d2ece7`.\n3. Build Nargo from the pinned source:\n ```bash\n cd noir/noir-repo\n cargo +1.89.0 build --locked --release --target-dir target --bin nargo\n cd ../..\n ```\n4. Build the Barretenberg CLI from source without AVM components:\n ```bash\n cd barretenberg/cpp\n cmake --fresh --preset clang20-no-avm -DAVM_TRANSPILER_LIB=\n cmake --build --preset clang20-no-avm --target bb --parallel 4\n cd ../..\n ```\n5. Generate the ignored Noir workspace files. Do not run the protocol-circuits bootstrap because it consumes the tracked `pinned-build.tar.gz` instead of compiling the circuit source.\n ```bash\n cd noir-projects/noir-protocol-circuits\n corepack [email protected] install\n corepack [email protected] generate_variants\n ```\n6. Compile `rollup_root` from source:\n ```bash\n ../../noir/noir-repo/target/release/nargo check \\\n --package rollup_root --silence-warnings --show-program-hash\n ../../noir/noir-repo/target/release/nargo compile \\\n --package rollup_root --skip-brillig-constraints-check\n ```\n The monomorphized Noir program hash printed by the first command should be `62fd003ca75d0cd7`.\n7. Generate the UltraHonk verification key from the newly compiled bytecode:\n ```bash\n mkdir -p /tmp/aztec-v5-repro\n jq -r '.bytecode' target/rollup_root.json \\\n | base64 -d \\\n | gunzip \\\n | ../../barretenberg/cpp/build/bin/bb write_vk \\\n --scheme ultra_honk --oracle_hash keccak \\\n -b - -o /tmp/aztec-v5-repro\n xxd -p -c 0 /tmp/aztec-v5-repro/vk_hash\n ```\n The final command should print `2f0ca3e610369fc41f7fb8a69995a96428fbf69d7dffd2b576e63ba4d9511ee1`.\n8. Regenerate the Solidity verifier:\n ```bash\n ../../barretenberg/cpp/build/bin/bb write_solidity_verifier \\\n --scheme ultra_honk --disable_zk \\\n -k /tmp/aztec-v5-repro/vk \\\n -o /tmp/aztec-v5-repro/HonkVerifier.sol \\\n --optimized\n diff -u \\\n /tmp/aztec-v5-repro/HonkVerifier.sol \\\n ../../l1-contracts/script/deploy/HonkVerifier.sol\n ```\n The generated verifier should be identical to the repository copy except for the latter's provenance comment after the Solidity pragma."
},
{
"hash": "0x05ea6d9d0a0b1b837f081862dd77aae6bc047fb822b9cf7055ef68719b04198e",
"name": "zk.money frozen notes refund verifier",
"description": "Verifies refunds of notes that were unspent when the zk.money portal was frozen. Generated without the zero-knowledge option.",
"sourceLink": "https://github.com/aztec-labs-eng/zkmoney-public/tree/68425f9cf408ac803eade04d10318fcf345444a0/vendor/oxide/noir-projects/frozen_notes_refund",
"proofSystem": {
"id": "UltraHonk",
"type": "Plonk",
"name": "UltraHonk",
"description": "A KZG-based PLONKish proving system featuring many optimizations, including a sumcheck argument over a boolean hypercube. Developed by Aztec as a part of Barretenberg library."
},
"knownDeployments": [
{
"address": "eth:0x0694fF404DDA586C73EfCe21f34fe084541BB877"
}
],
"verificationStatus": "successful",
"attesters": [
{
"id": "l2beat",
"name": "L2BEAT",
"link": "https://l2beat.com"
}
],
"verificationSteps": "The four zk.money verifiers are regenerated from the same source with the same commands. The Noir circuits compile in under a minute on a standard Linux machine.\n\nPrepare:\n\n1. Install Noir `1.0.0-beta.25`, the version pinned by the Aztec `5.2.0` toolchain, for example with `noirup -v 1.0.0-beta.25`.\n2. Download `barretenberg-amd64-linux.tar.gz` from the [Aztec `v5.2.0` release](https://github.com/AztecProtocol/aztec-packages/releases/tag/v5.2.0) and put the `bb` binary on your `PATH`. `bb --version` should print `5.2.0`.\n3. Install `git`, `jq`, `xxd`, `base64` and `gzip`.\n\nVerify:\n\n1. Clone [aztec-labs-eng/zkmoney-public](https://github.com/aztec-labs-eng/zkmoney-public) and check out commit `68425f9cf408ac803eade04d10318fcf345444a0`.\n2. Compile each circuit, write its UltraHonk verification key and print the key hash. `nargo` fetches the pinned `aztec-nr`, `bignum` and `bigcurve` dependencies on the first run.\n ```bash\n cd vendor/oxide/noir-projects\n for c in frozen_notes_refund frozen_deposit_refund unprocessed_deposit_refund resolver_circuit; do\n (cd $c \\\n && nargo compile --silence-warnings --package $c \\\n && jq -r '.bytecode' target/$c.json | base64 -d | gunzip \\\n | bb write_vk --scheme ultra_honk --oracle_hash keccak -b - -o target/keys \\\n && echo \"$c $(xxd -p -c 0 target/keys/vk_hash)\")\n done\n ```\n The printed hashes should be:\n - `frozen_notes_refund`: `05ea6d9d0a0b1b837f081862dd77aae6bc047fb822b9cf7055ef68719b04198e`\n - `frozen_deposit_refund`: `2290cfb58dea33c485e0ac33581c1c8d358ac3dd9f434470b6cf87da12b5fd43`\n - `unprocessed_deposit_refund`: `080b44509f327b7b0ee935247a069be5def58e0edf1b52721d9c42f5918c390c`\n - `resolver_circuit`: `279d6dad93155d6c03ddd050359fb4675a66c08812b5306f6dfc9754e42827b7`\n3. Regenerate each Solidity verifier and compare it with the verifier committed in the repository. The refund verifiers are generated without the zero-knowledge option, the resolver verifier with it:\n ```bash\n for v in frozen_notes_refund:generated/FrozenNotesRefundVerifier:--disable_zk \\\n frozen_deposit_refund:generated/FrozenDepositRefundVerifier:--disable_zk \\\n unprocessed_deposit_refund:generated/UnprocessedDepositRefundVerifier:--disable_zk \\\n resolver_circuit:pinned/PinnedResolverVerifier:; do\n IFS=: read -r c path flags <<<\"$v\"\n bb write_solidity_verifier --scheme ultra_honk $flags \\\n -k $c/target/keys/vk -o $c/target/verifier.sol\n cmp $c/target/verifier.sol ../l1-contracts/src/$path.sol && echo \"$c matches\"\n done\n ```\n Each circuit should print `matches`.\n4. Optionally, run `nargo test` in `resolver_circuit`. The `comb_table_matches_curve_library` test re-derives every precomputed secp256k1 point in `src/comb_table.nr`, which the circuit uses to check the resolver operator's key.\n5. Compare each regenerated verifier's **full executable source** with the deployed, verified source, including `loadVerificationKey`, the proof decoder, transcript, relations and pairing checks. A matching `VK_HASH` constant alone does not establish that the contract uses that key or verifies proofs correctly. Each verifier calls separately deployed libraries, whose verified source must be the same file.\n\n | Circuit | Ethereum verifier | Linked libraries |\n | --- | --- | --- |\n | Frozen notes | [0x0694…B877](https://etherscan.io/address/0x0694fF404DDA586C73EfCe21f34fe084541BB877#code) | [RelationsLib](https://etherscan.io/address/0x41F721e09a9C8027165C6Bf1B3771848f6a43D29#code) |\n | Frozen deposit | [0xa2fd…3cCe](https://etherscan.io/address/0xa2fd594dCA2d598aF231d615E5D34903154C3cCe#code) | [RelationsLib](https://etherscan.io/address/0xb66C441BbeFe703E423dbcAa515d32F50e507C2b#code) |\n | Unprocessed deposit | [0x5C48…0FA5](https://etherscan.io/address/0x5C487AEb500BD0fE65fe52Be7e55a150c3220FA5#code) | [RelationsLib](https://etherscan.io/address/0x9e2131C7B89D070a6b27f29c2b8e066399ECA5b7#code) |\n | Resolver | [0xbF05…E451](https://etherscan.io/address/0xbF058D54c5033F4cB45c6E1Eba103CaeF232E451#code) | [RelationsLib](https://etherscan.io/address/0x02353dB283087CD51b13eE088A615Dad03949070#code), [ZKTranscriptLib](https://etherscan.io/address/0xf3E445E6E292dE756bD66011c23717DAb9e12DBD#code) |"
},
{
"hash": "0x2290cfb58dea33c485e0ac33581c1c8d358ac3dd9f434470b6cf87da12b5fd43",
"name": "zk.money frozen deposit refund verifier",
"description": "Verifies refunds of deposits that reached Aztec but were unspent when the zk.money portal was frozen. Generated without the zero-knowledge option.",
"sourceLink": "https://github.com/aztec-labs-eng/zkmoney-public/tree/68425f9cf408ac803eade04d10318fcf345444a0/vendor/oxide/noir-projects/frozen_deposit_refund",
"proofSystem": {
"id": "UltraHonk",
"type": "Plonk",
"name": "UltraHonk",
"description": "A KZG-based PLONKish proving system featuring many optimizations, including a sumcheck argument over a boolean hypercube. Developed by Aztec as a part of Barretenberg library."
},
"knownDeployments": [
{
"address": "eth:0xa2fd594dCA2d598aF231d615E5D34903154C3cCe"
}
],
"verificationStatus": "successful",
"attesters": [
{
"id": "l2beat",
"name": "L2BEAT",
"link": "https://l2beat.com"
}
],
"verificationSteps": "The four zk.money verifiers are regenerated from the same source with the same commands. The Noir circuits compile in under a minute on a standard Linux machine.\n\nPrepare:\n\n1. Install Noir `1.0.0-beta.25`, the version pinned by the Aztec `5.2.0` toolchain, for example with `noirup -v 1.0.0-beta.25`.\n2. Download `barretenberg-amd64-linux.tar.gz` from the [Aztec `v5.2.0` release](https://github.com/AztecProtocol/aztec-packages/releases/tag/v5.2.0) and put the `bb` binary on your `PATH`. `bb --version` should print `5.2.0`.\n3. Install `git`, `jq`, `xxd`, `base64` and `gzip`.\n\nVerify:\n\n1. Clone [aztec-labs-eng/zkmoney-public](https://github.com/aztec-labs-eng/zkmoney-public) and check out commit `68425f9cf408ac803eade04d10318fcf345444a0`.\n2. Compile each circuit, write its UltraHonk verification key and print the key hash. `nargo` fetches the pinned `aztec-nr`, `bignum` and `bigcurve` dependencies on the first run.\n ```bash\n cd vendor/oxide/noir-projects\n for c in frozen_notes_refund frozen_deposit_refund unprocessed_deposit_refund resolver_circuit; do\n (cd $c \\\n && nargo compile --silence-warnings --package $c \\\n && jq -r '.bytecode' target/$c.json | base64 -d | gunzip \\\n | bb write_vk --scheme ultra_honk --oracle_hash keccak -b - -o target/keys \\\n && echo \"$c $(xxd -p -c 0 target/keys/vk_hash)\")\n done\n ```\n The printed hashes should be:\n - `frozen_notes_refund`: `05ea6d9d0a0b1b837f081862dd77aae6bc047fb822b9cf7055ef68719b04198e`\n - `frozen_deposit_refund`: `2290cfb58dea33c485e0ac33581c1c8d358ac3dd9f434470b6cf87da12b5fd43`\n - `unprocessed_deposit_refund`: `080b44509f327b7b0ee935247a069be5def58e0edf1b52721d9c42f5918c390c`\n - `resolver_circuit`: `279d6dad93155d6c03ddd050359fb4675a66c08812b5306f6dfc9754e42827b7`\n3. Regenerate each Solidity verifier and compare it with the verifier committed in the repository. The refund verifiers are generated without the zero-knowledge option, the resolver verifier with it:\n ```bash\n for v in frozen_notes_refund:generated/FrozenNotesRefundVerifier:--disable_zk \\\n frozen_deposit_refund:generated/FrozenDepositRefundVerifier:--disable_zk \\\n unprocessed_deposit_refund:generated/UnprocessedDepositRefundVerifier:--disable_zk \\\n resolver_circuit:pinned/PinnedResolverVerifier:; do\n IFS=: read -r c path flags <<<\"$v\"\n bb write_solidity_verifier --scheme ultra_honk $flags \\\n -k $c/target/keys/vk -o $c/target/verifier.sol\n cmp $c/target/verifier.sol ../l1-contracts/src/$path.sol && echo \"$c matches\"\n done\n ```\n Each circuit should print `matches`.\n4. Optionally, run `nargo test` in `resolver_circuit`. The `comb_table_matches_curve_library` test re-derives every precomputed secp256k1 point in `src/comb_table.nr`, which the circuit uses to check the resolver operator's key.\n5. Compare each regenerated verifier's **full executable source** with the deployed, verified source, including `loadVerificationKey`, the proof decoder, transcript, relations and pairing checks. A matching `VK_HASH` constant alone does not establish that the contract uses that key or verifies proofs correctly. Each verifier calls separately deployed libraries, whose verified source must be the same file.\n\n | Circuit | Ethereum verifier | Linked libraries |\n | --- | --- | --- |\n | Frozen notes | [0x0694…B877](https://etherscan.io/address/0x0694fF404DDA586C73EfCe21f34fe084541BB877#code) | [RelationsLib](https://etherscan.io/address/0x41F721e09a9C8027165C6Bf1B3771848f6a43D29#code) |\n | Frozen deposit | [0xa2fd…3cCe](https://etherscan.io/address/0xa2fd594dCA2d598aF231d615E5D34903154C3cCe#code) | [RelationsLib](https://etherscan.io/address/0xb66C441BbeFe703E423dbcAa515d32F50e507C2b#code) |\n | Unprocessed deposit | [0x5C48…0FA5](https://etherscan.io/address/0x5C487AEb500BD0fE65fe52Be7e55a150c3220FA5#code) | [RelationsLib](https://etherscan.io/address/0x9e2131C7B89D070a6b27f29c2b8e066399ECA5b7#code) |\n | Resolver | [0xbF05…E451](https://etherscan.io/address/0xbF058D54c5033F4cB45c6E1Eba103CaeF232E451#code) | [RelationsLib](https://etherscan.io/address/0x02353dB283087CD51b13eE088A615Dad03949070#code), [ZKTranscriptLib](https://etherscan.io/address/0xf3E445E6E292dE756bD66011c23717DAb9e12DBD#code) |"
},
{
"hash": "0x080b44509f327b7b0ee935247a069be5def58e0edf1b52721d9c42f5918c390c",
"name": "zk.money unprocessed deposit refund verifier",
"description": "Verifies refunds of deposits that had not reached Aztec when the zk.money portal was frozen. Generated without the zero-knowledge option.",
"sourceLink": "https://github.com/aztec-labs-eng/zkmoney-public/tree/68425f9cf408ac803eade04d10318fcf345444a0/vendor/oxide/noir-projects/unprocessed_deposit_refund",
"proofSystem": {
"id": "UltraHonk",
"type": "Plonk",
"name": "UltraHonk",
"description": "A KZG-based PLONKish proving system featuring many optimizations, including a sumcheck argument over a boolean hypercube. Developed by Aztec as a part of Barretenberg library."
},
"knownDeployments": [
{
"address": "eth:0x5C487AEb500BD0fE65fe52Be7e55a150c3220FA5"
}
],
"verificationStatus": "successful",
"attesters": [
{
"id": "l2beat",
"name": "L2BEAT",
"link": "https://l2beat.com"
}
],
"verificationSteps": "The four zk.money verifiers are regenerated from the same source with the same commands. The Noir circuits compile in under a minute on a standard Linux machine.\n\nPrepare:\n\n1. Install Noir `1.0.0-beta.25`, the version pinned by the Aztec `5.2.0` toolchain, for example with `noirup -v 1.0.0-beta.25`.\n2. Download `barretenberg-amd64-linux.tar.gz` from the [Aztec `v5.2.0` release](https://github.com/AztecProtocol/aztec-packages/releases/tag/v5.2.0) and put the `bb` binary on your `PATH`. `bb --version` should print `5.2.0`.\n3. Install `git`, `jq`, `xxd`, `base64` and `gzip`.\n\nVerify:\n\n1. Clone [aztec-labs-eng/zkmoney-public](https://github.com/aztec-labs-eng/zkmoney-public) and check out commit `68425f9cf408ac803eade04d10318fcf345444a0`.\n2. Compile each circuit, write its UltraHonk verification key and print the key hash. `nargo` fetches the pinned `aztec-nr`, `bignum` and `bigcurve` dependencies on the first run.\n ```bash\n cd vendor/oxide/noir-projects\n for c in frozen_notes_refund frozen_deposit_refund unprocessed_deposit_refund resolver_circuit; do\n (cd $c \\\n && nargo compile --silence-warnings --package $c \\\n && jq -r '.bytecode' target/$c.json | base64 -d | gunzip \\\n | bb write_vk --scheme ultra_honk --oracle_hash keccak -b - -o target/keys \\\n && echo \"$c $(xxd -p -c 0 target/keys/vk_hash)\")\n done\n ```\n The printed hashes should be:\n - `frozen_notes_refund`: `05ea6d9d0a0b1b837f081862dd77aae6bc047fb822b9cf7055ef68719b04198e`\n - `frozen_deposit_refund`: `2290cfb58dea33c485e0ac33581c1c8d358ac3dd9f434470b6cf87da12b5fd43`\n - `unprocessed_deposit_refund`: `080b44509f327b7b0ee935247a069be5def58e0edf1b52721d9c42f5918c390c`\n - `resolver_circuit`: `279d6dad93155d6c03ddd050359fb4675a66c08812b5306f6dfc9754e42827b7`\n3. Regenerate each Solidity verifier and compare it with the verifier committed in the repository. The refund verifiers are generated without the zero-knowledge option, the resolver verifier with it:\n ```bash\n for v in frozen_notes_refund:generated/FrozenNotesRefundVerifier:--disable_zk \\\n frozen_deposit_refund:generated/FrozenDepositRefundVerifier:--disable_zk \\\n unprocessed_deposit_refund:generated/UnprocessedDepositRefundVerifier:--disable_zk \\\n resolver_circuit:pinned/PinnedResolverVerifier:; do\n IFS=: read -r c path flags <<<\"$v\"\n bb write_solidity_verifier --scheme ultra_honk $flags \\\n -k $c/target/keys/vk -o $c/target/verifier.sol\n cmp $c/target/verifier.sol ../l1-contracts/src/$path.sol && echo \"$c matches\"\n done\n ```\n Each circuit should print `matches`.\n4. Optionally, run `nargo test` in `resolver_circuit`. The `comb_table_matches_curve_library` test re-derives every precomputed secp256k1 point in `src/comb_table.nr`, which the circuit uses to check the resolver operator's key.\n5. Compare each regenerated verifier's **full executable source** with the deployed, verified source, including `loadVerificationKey`, the proof decoder, transcript, relations and pairing checks. A matching `VK_HASH` constant alone does not establish that the contract uses that key or verifies proofs correctly. Each verifier calls separately deployed libraries, whose verified source must be the same file.\n\n | Circuit | Ethereum verifier | Linked libraries |\n | --- | --- | --- |\n | Frozen notes | [0x0694…B877](https://etherscan.io/address/0x0694fF404DDA586C73EfCe21f34fe084541BB877#code) | [RelationsLib](https://etherscan.io/address/0x41F721e09a9C8027165C6Bf1B3771848f6a43D29#code) |\n | Frozen deposit | [0xa2fd…3cCe](https://etherscan.io/address/0xa2fd594dCA2d598aF231d615E5D34903154C3cCe#code) | [RelationsLib](https://etherscan.io/address/0xb66C441BbeFe703E423dbcAa515d32F50e507C2b#code) |\n | Unprocessed deposit | [0x5C48…0FA5](https://etherscan.io/address/0x5C487AEb500BD0fE65fe52Be7e55a150c3220FA5#code) | [RelationsLib](https://etherscan.io/address/0x9e2131C7B89D070a6b27f29c2b8e066399ECA5b7#code) |\n | Resolver | [0xbF05…E451](https://etherscan.io/address/0xbF058D54c5033F4cB45c6E1Eba103CaeF232E451#code) | [RelationsLib](https://etherscan.io/address/0x02353dB283087CD51b13eE088A615Dad03949070#code), [ZKTranscriptLib](https://etherscan.io/address/0xf3E445E6E292dE756bD66011c23717DAb9e12DBD#code) |"
},
{
"hash": "0x279d6dad93155d6c03ddd050359fb4675a66c08812b5306f6dfc9754e42827b7",
"name": "zk.money resolver verifier",
"description": "Verifies that the secret behind a deposit address returned for a zk.money name was derived from the registered user and resolver operator keys, and binds the address to the registered Aztec address. Generated with the zero-knowledge option.",
"sourceLink": "https://github.com/aztec-labs-eng/zkmoney-public/tree/68425f9cf408ac803eade04d10318fcf345444a0/vendor/oxide/noir-projects/resolver_circuit",
"proofSystem": {
"id": "UltraHonk",
"type": "Plonk",
"name": "UltraHonk",
"description": "A KZG-based PLONKish proving system featuring many optimizations, including a sumcheck argument over a boolean hypercube. Developed by Aztec as a part of Barretenberg library."
},
"knownDeployments": [
{
"address": "eth:0xbF058D54c5033F4cB45c6E1Eba103CaeF232E451"
}
],
"verificationStatus": "successful",
"attesters": [
{
"id": "l2beat",
"name": "L2BEAT",
"link": "https://l2beat.com"
}
],
"verificationSteps": "The four zk.money verifiers are regenerated from the same source with the same commands. The Noir circuits compile in under a minute on a standard Linux machine.\n\nPrepare:\n\n1. Install Noir `1.0.0-beta.25`, the version pinned by the Aztec `5.2.0` toolchain, for example with `noirup -v 1.0.0-beta.25`.\n2. Download `barretenberg-amd64-linux.tar.gz` from the [Aztec `v5.2.0` release](https://github.com/AztecProtocol/aztec-packages/releases/tag/v5.2.0) and put the `bb` binary on your `PATH`. `bb --version` should print `5.2.0`.\n3. Install `git`, `jq`, `xxd`, `base64` and `gzip`.\n\nVerify:\n\n1. Clone [aztec-labs-eng/zkmoney-public](https://github.com/aztec-labs-eng/zkmoney-public) and check out commit `68425f9cf408ac803eade04d10318fcf345444a0`.\n2. Compile each circuit, write its UltraHonk verification key and print the key hash. `nargo` fetches the pinned `aztec-nr`, `bignum` and `bigcurve` dependencies on the first run.\n ```bash\n cd vendor/oxide/noir-projects\n for c in frozen_notes_refund frozen_deposit_refund unprocessed_deposit_refund resolver_circuit; do\n (cd $c \\\n && nargo compile --silence-warnings --package $c \\\n && jq -r '.bytecode' target/$c.json | base64 -d | gunzip \\\n | bb write_vk --scheme ultra_honk --oracle_hash keccak -b - -o target/keys \\\n && echo \"$c $(xxd -p -c 0 target/keys/vk_hash)\")\n done\n ```\n The printed hashes should be:\n - `frozen_notes_refund`: `05ea6d9d0a0b1b837f081862dd77aae6bc047fb822b9cf7055ef68719b04198e`\n - `frozen_deposit_refund`: `2290cfb58dea33c485e0ac33581c1c8d358ac3dd9f434470b6cf87da12b5fd43`\n - `unprocessed_deposit_refund`: `080b44509f327b7b0ee935247a069be5def58e0edf1b52721d9c42f5918c390c`\n - `resolver_circuit`: `279d6dad93155d6c03ddd050359fb4675a66c08812b5306f6dfc9754e42827b7`\n3. Regenerate each Solidity verifier and compare it with the verifier committed in the repository. The refund verifiers are generated without the zero-knowledge option, the resolver verifier with it:\n ```bash\n for v in frozen_notes_refund:generated/FrozenNotesRefundVerifier:--disable_zk \\\n frozen_deposit_refund:generated/FrozenDepositRefundVerifier:--disable_zk \\\n unprocessed_deposit_refund:generated/UnprocessedDepositRefundVerifier:--disable_zk \\\n resolver_circuit:pinned/PinnedResolverVerifier:; do\n IFS=: read -r c path flags <<<\"$v\"\n bb write_solidity_verifier --scheme ultra_honk $flags \\\n -k $c/target/keys/vk -o $c/target/verifier.sol\n cmp $c/target/verifier.sol ../l1-contracts/src/$path.sol && echo \"$c matches\"\n done\n ```\n Each circuit should print `matches`.\n4. Optionally, run `nargo test` in `resolver_circuit`. The `comb_table_matches_curve_library` test re-derives every precomputed secp256k1 point in `src/comb_table.nr`, which the circuit uses to check the resolver operator's key.\n5. Compare each regenerated verifier's **full executable source** with the deployed, verified source, including `loadVerificationKey`, the proof decoder, transcript, relations and pairing checks. A matching `VK_HASH` constant alone does not establish that the contract uses that key or verifies proofs correctly. Each verifier calls separately deployed libraries, whose verified source must be the same file.\n\n | Circuit | Ethereum verifier | Linked libraries |\n | --- | --- | --- |\n | Frozen notes | [0x0694…B877](https://etherscan.io/address/0x0694fF404DDA586C73EfCe21f34fe084541BB877#code) | [RelationsLib](https://etherscan.io/address/0x41F721e09a9C8027165C6Bf1B3771848f6a43D29#code) |\n | Frozen deposit | [0xa2fd…3cCe](https://etherscan.io/address/0xa2fd594dCA2d598aF231d615E5D34903154C3cCe#code) | [RelationsLib](https://etherscan.io/address/0xb66C441BbeFe703E423dbcAa515d32F50e507C2b#code) |\n | Unprocessed deposit | [0x5C48…0FA5](https://etherscan.io/address/0x5C487AEb500BD0fE65fe52Be7e55a150c3220FA5#code) | [RelationsLib](https://etherscan.io/address/0x9e2131C7B89D070a6b27f29c2b8e066399ECA5b7#code) |\n | Resolver | [0xbF05…E451](https://etherscan.io/address/0xbF058D54c5033F4cB45c6E1Eba103CaeF232E451#code) | [RelationsLib](https://etherscan.io/address/0x02353dB283087CD51b13eE088A615Dad03949070#code), [ZKTranscriptLib](https://etherscan.io/address/0xf3E445E6E292dE756bD66011c23717DAb9e12DBD#code) |"
}
]
}[ADDED]
zkapi
+656 -0
+1 -0
"zkapi"+1 -0
"zkapi"+1 -0
"zkAPI"+1 -0
null+1 -0
null+1 -0
1790899200+7 -0
{
"redWarning": {
"text": "The vault owner can block withdrawals until deposits expire and become sweepable to the treasury. The proofs rely on a single-party trusted setup.",
"detailAnchor": "permissions"
},
"unverifiedContracts": []
}+16 -0
{
"badges": [],
"description": "An ETH-funded API payment system that hides the deposit behind an API authorization proof.",
"detailedDescription": "zkAPI escrows ETH on Ethereum and uses zero-knowledge proofs to authorize API usage without revealing which deposit pays for it. The deployed integration issues bounded OpenRouter credentials through Open Anonymity. Prompts go to the inference provider, which can read them. **The deposit and its withdrawal are publicly linked by note id.** This is privacy for service authorization, rather than private transfers between Ethereum addresses.\n\n### Funding and API usage\n\nA deposit publishes its funding address, commitment, amount, sequential note id and expiry. The wallet generates a random note secret locally and proves membership in the active-note Merkle tree. The [request circuit](https://github.com/ethereum/zkapi/blob/045b444ea1b52538d1b40273c7cb6ed09468a052/protocol/rust/crates/zkapi-proof/src/groth16.rs#L368-L485) proves that the note has enough balance for a public spending bound. The note id, exact balance, expiry, secret and operator signature are private witnesses. A fresh note uses its deposited balance without needing an operator signature.\n\nAfter usage, the operator signs a new balance commitment. The commitment binds the balance to the same note, while blinding hides its contents. The operator knows the charge and credential it issued. Proof validity establishes authorization and balance accounting, but does not establish that an API service was delivered or that its reported bill is correct. The client checks settlement against its authorized budget and pinned ETH/USD quote. The deployment's request cap is 0.00005 ETH in whole-gwei units. It is a client/service pin, rather than an onchain comparison of every request's spending bound. [Billing implementation](https://github.com/ethereum/zkapi/blob/045b444ea1b52538d1b40273c7cb6ed09468a052/crates/zkapi-serverd/src/processor_v2.rs).\n\nThe live deployment uses Open Anonymity's credential issuer and production verifier, with inference sent to OpenRouter. The verifier receives the issued API key. Verifier approval does not prove that the inference provider refrains from logging prompts, responses or credentials. The local desktop client shares a credential across compatible requests within its default reuse window, including across chats and local clients. Disabling reuse requests fresh access for each inference request. [Client credential reuse and content boundaries](https://github.com/ethereum/zkapi/blob/045b444ea1b52538d1b40273c7cb6ed09468a052/zkapi-clientd/docs/PRIVACY.md).\n\n### Withdrawals, disputes and expiry\n\nA cooperative close requires a withdrawal proof and clearance signed by the pinned operator key. It reveals the original deposit's note id, remaining balance, payout address and nullifier. The vault sends the remaining balance to the destination and the difference from the original deposit to the treasury. Thus total consumption becomes public, even though individual API requests stay offchain.\n\nAn escape withdrawal requires a proof of the user's state and waits 1 day. Anyone holding a valid request proof with the same nullifier can challenge it before the deadline. The contract checks proof validity and deployment bindings, but does not check whether the operator accepted the request or delivered service. The challenge restores the note to the active tree and leaves that nullifier consumed. A user who submitted a request proof without receiving a successor state therefore depends on the operator's signature to resume ordinary spending or withdraw from the updated state if that proof is used to challenge. The escape path bypasses withdrawal clearance, but does not replace missing settlement evidence. [Vault exit and challenge logic](https://etherscan.io/address/0x4386FDbdA35D995beB3BF8625118Ec5982ec81fe#code).\n\nDeposits expire after 1 month, rounded up to a 1 day boundary. Anyone can then sweep the **entire active note** to the treasury, including its unused balance. Expiry is a competing sweep, rather than an automatic refund or an immediate prohibition on withdrawals. Starting an escape moves a note out of active status, protecting that pending withdrawal from the expiry sweep.\n\nThe owner can immediately pause deposits, cooperative closes and the initiation of new escapes. Challenges, already pending escape finalizations and expiry sweeps remain available. A malicious owner can keep the vault paused through expiry and redirect the sweep proceeds by changing the treasury. This is a confiscation path despite the fixed vault code and proof keys. A rejecting destination or treasury can also revert a payout because both ETH transfers must succeed.\n\n### Privacy boundaries and client choices\n\nThe browser wallet stores note secrets and recovery journals on the device and generates proofs locally. It downloads the same [complete tree snapshot](https://github.com/ethereum/zkapi/blob/045b444ea1b52538d1b40273c7cb6ed09468a052/sdk/services/browserWalletRuntime.js#L829-L845) as other clients and derives its note's path locally. It does not send the note id to obtain that path. Direct service connections still expose IPs and timing. The hosted app's zkapi entrypoint disables its ordinary pageview analytics call, but the host and its deployment proxy can still observe requests. A frontend update can read the wallet's local secrets.\n\nThe desktop client's pinned Rust companion instead queries the [indexer by note id](https://github.com/ethereum/zkapi/blob/20aa542ae98e767c0507133fd34b12a56f5ccd3d/crates/zkapi-clientd/src/indexer.rs#L69-L104), including before authorizations. The operator running both indexer and API service can correlate these queries with API activity. The desktop offers a loopback SOCKS5/Tor or Wisp route for its Go transport, but its [Rust protocol transport](https://github.com/ethereum/zkapi/blob/045b444ea1b52538d1b40273c7cb6ed09468a052/zkapi-clientd/internal/zkapi/protocol-transport.patch#L23-L80) builds a separate HTTP client. Selecting the relay alone does not route every wallet request.\n\nAn inspected browser build using common snapshots and separate network identities for funding and API use avoids the desktop's direct note-path disclosure. Routing all application traffic through Tor addresses IP exposure. It does not enlarge the set of eligible notes, conceal identifying prompts or remove the provider's access to its API credential and content. A custom Ethereum RPC requires a reviewed profile and matching deployment manifest because the browser checks the RPC against a packaged pin. These are integration changes, rather than a hosted wallet settings switch.\n\nAn observer who receives an authorization proof can use its request time and spending bound alongside public deposit amounts and expiries to narrow the eligible notes. These inputs remain offchain during ordinary API use. A small or unique eligible set can defeat authorization anonymity even with a correct proof. Publishing a challenge reveals a submitted authorization and associates its nullifier with the public note. The project's anonymity-set chart is therefore disabled: a count of funding addresses would imply deposit-to-withdrawal protection that the contract does not provide.\n\n### Cryptography and availability\n\nThe protocol uses Groth16 over BN254, Poseidon hashing and note-bound Baby-JubJub commitments and Schnorr signatures. The published keys were generated in a [single-party setup](https://github.com/ethereum/zkapi/blob/045b444ea1b52538d1b40273c7cb6ed09468a052/protocol/setup/v2/README.md). Retained setup secrets can permit forged proofs. Matching public artifacts and deployed source cannot establish that these secrets were destroyed.\n\nWithdrawal clearance and non-genesis settlement depend on fixed signing keys. The holder cannot be replaced within this vault. The indexer can be reconstructed from Ethereum events, but substituting a new operator cannot manufacture signatures under the pinned keys. API usage additionally depends on the credential issuer, verifier and inference provider. Losing local secrets or unresolved recovery journals can make funds unrecoverable.\n\nThe signature and proof systems are not post-quantum. A future attacker breaking elliptic-curve cryptography can forge signatures and compromise soundness. This does not automatically recover every historical secret from the randomized commitments. Chain-visible deposit and withdrawal links are already permanent, while service logs and retained prompts create their own future disclosure path.\n\nFlow statistics count deposits and actual user payouts from cooperative and finalized escape withdrawals. They exclude escape initiation, cancelled escapes, treasury consumption shares and expiry sweeps. TVS measures the vault's whole ETH balance, which also contains operator revenue awaiting note closure.",
"links": {
"websites": [
"https://chat.openanonymity.ai"
],
"documentation": [
"https://zkapi.openanonymity.ai"
],
"repositories": [
"https://github.com/ethereum/zkapi"
]
}
}+1 -0
null+1 -0
null+1 -0
null+1 -0
null+11 -0
[
{
"address": "0x4386FDbdA35D995beB3BF8625118Ec5982ec81fe",
"chain": "ethereum",
"sinceTimestamp": 1790783879,
"tokens": [
"ETH"
],
"chainId": 1
}
]+1 -0
null+1 -0
null+1 -0
null+1 -0
null+1 -0
null+1 -0
null+1 -0
null+1 -0
null+1 -0
null+1 -0
null+1 -0
null+62 -0
{
"creator": "Open Anonymity",
"projectsForTvs": [
{
"projectId": "zkapi",
"sinceTimestamp": 1790783879
}
],
"proofSystemInfo": "Application-specific request and withdrawal Groth16 circuits over BN254. Poseidon Merkle membership and note-bound Baby-JubJub balance commitments hide the note and balance during authorization. Withdrawals expose the note id and remaining balance.",
"techStack": {
"snark": [
{
"id": "Arkworks",
"type": "Groth16",
"name": "Arkworks",
"description": "Arkworks implementation of Groth16 written in Rust."
},
{
"id": "BN254",
"type": "curve",
"name": "BN254",
"description": "BN254, aka BN256, aka alt_bn128 pairing-friendly 254-bit prime field Weierstrass elliptic curve."
}
]
},
"trustedSetups": [
{
"id": "ZkApiNoteBoundV1",
"name": "zkapi-v2-note-bound-v1 single-party setup",
"proofSystem": {
"id": "Arkworks",
"type": "Groth16",
"name": "Arkworks",
"description": "Arkworks implementation of Groth16 written in Rust."
},
"participantCount": 1,
"risk": "red",
"shortDescription": "The published request and withdrawal keys were generated by one party. Retained setup secrets can allow forged proofs.",
"longDescription": "The request and withdrawal circuits use separate circuit-specific Groth16 keys over BN254. The published circuit id is `zkapi-v2-note-bound-v1`. The [setup source](https://github.com/ethereum/zkapi/blob/045b444ea1b52538d1b40273c7cb6ed09468a052/protocol/rust/crates/zkapi-proof/src/compact.rs#L288-L383) generates these keys using one process and operating-system randomness. The [provenance note](https://github.com/ethereum/zkapi/blob/045b444ea1b52538d1b40273c7cb6ed09468a052/protocol/setup/v2/README.md) explicitly states that no multi-party ceremony has been conducted.\n\nSecurity requires that the setup party destroyed the trapdoor material. A party retaining it can forge proofs accepted by the verifier and defeat withdrawal authorization. Public proving keys, verifier keys and matching hashes establish artifact identity, but do not prove that setup secrets were erased."
}
],
"verifierHashes": [
{
"name": "zkapi note-bound request and withdrawal verifier",
"hash": "0xd31acf861825869e6a84b6b0025cb6940077f5981a10e73d2e4e8e5d7417c853",
"sourceLink": "https://github.com/ethereum/zkapi/blob/045b444ea1b52538d1b40273c7cb6ed09468a052/protocol/rust/crates/zkapi-proof/src/groth16.rs",
"proofSystem": {
"id": "Arkworks",
"type": "Groth16",
"name": "Arkworks",
"description": "Arkworks implementation of Groth16 written in Rust."
},
"knownDeployments": [
{
"address": "eth:0x8e92013Dd7cc86f75b539DBD3814B2e603e0F9C1"
}
],
"verificationStatus": "notVerified",
"verificationSteps": "### Contract reproduction\n\nReviewed source: [ethereum/zkapi at 045b444](https://github.com/ethereum/zkapi/tree/045b444ea1b52538d1b40273c7cb6ed09468a052). The live manifest reports `95b022fd339a391321481d31dffa4b947954b0a6` as its deployment source. The vault, adapter and circuit source are unchanged between those revisions.\n\nCompile the deployment workspace, which uses solc `0.8.28+commit.7893614a`, optimizer runs `200`, `viaIR: true` and EVM version `prague`:\n\n```bash\ngit clone https://github.com/ethereum/zkapi.git\ncd zkapi\ngit checkout 045b444ea1b52538d1b40273c7cb6ed09468a052\ncd demo/contracts\nforge build --skip test --build-info\n```\n\nRead the creation transactions from an Ethereum RPC:\n\n```bash\ncast tx 0xf753fd93c7e672f7b851f261f600e06930e502bdfd73be29ce8a065643df6985 --json --rpc-url \"$ZKAPI_RESEARCH_RPC_URL\" > vault-tx.json\ncast tx 0x45f2f5259476afd5f64a6a62a36c9012c3a26efcdd35b048a7fac5ae1ba43780 --json --rpc-url \"$ZKAPI_RESEARCH_RPC_URL\" > verifier-tx.json\n```\n\nThe adapter's compiled creation bytecode matches its entire transaction input exactly, including metadata. The vault's compiled creation bytecode matches after replacing every `Bn254Poseidon` link reference with `0xc6B55e86668d8c446B3D81273AAb9CBb20F28c7f`. The remaining transaction bytes decode as its ten constructor arguments. Decode rather than assuming the treasury, signing keys or deployment parameters.\n\nThe vault has 9,598 bytes of creation code plus 320 bytes of constructor arguments, and 8,535 bytes of runtime code. The adapter has 6,527 bytes of creation code and 6,501 bytes of runtime code. Runtime hashes observed for this deployment:\n\n| Contract | Runtime keccak256 |\n| --- | --- |\n| ZkApiVault | `0x0ccfe907122037eef6220c8e9f4792b82a6a23a80b908eaeb8a7fd27c759a5a0` |\n| Groth16ProofAdapter | `0x5cfce41ec9f29c8e23cb6a30c8d4bc328f7d98032ccd7683a888b88d73766ab9` |\n\nBoth initially unverified contracts and the linked Poseidon library were successfully verified on Etherscan using the public sources. For the standard JSON submission, remove Foundry's top-level `version`, `allowPaths`, `basePath` and `includePaths`, omit the unrelated deployment script and forge-std, and resolve dependency source keys consistently with the published remappings. Set the vault's library address and use the constructor bytes from its creation transaction. [Vault](https://etherscan.io/address/0x4386FDbdA35D995beB3BF8625118Ec5982ec81fe#code), [adapter](https://etherscan.io/address/0x8e92013Dd7cc86f75b539DBD3814B2e603e0F9C1#code), [library](https://etherscan.io/address/0xc6B55e86668d8c446B3D81273AAb9CBb20F28c7f#code).\n\n### Circuit and artifact boundary\n\nThe deployed adapter hardcodes the request and withdrawal keys. Its 12 request public inputs and 14 withdrawal public inputs match the published circuit interfaces. The public setup directory contains the verifying keys, proving keys, manifest and generated Solidity adapter. The generated and deployed adapter sources differ in formatting, so compare their structure and key coordinates rather than whole-file hashes.\n\nPublished proving-key SHA-256 pins:\n\n| Key | SHA-256 |\n| --- | --- |\n| request.pk | `c894b261a13f571d0df36be29734aabf2a8cd7162baddc5e08a50341aa076584` |\n| withdrawal.pk | `8e41398092fdd02b9ff86c6ccbecbd7ce2402e6f22ec162e6124d1d04fe0a668` |\n\nThese match the checked-in SDK artifacts and production deployment profiles. Source and bytecode matching do not establish that the published setup was generated honestly from the reviewed circuit or that its secrets were destroyed. The zk catalog entry therefore retains `notVerified` for circuit reproduction. Do not run the `setup` command to reproduce the deployed keys: it generates a fresh incompatible single-party setup."
}
]
}+1 -0
null+372 -0
{
"adversaries": {
"promise": {
"protects": "sender",
"text": "Hides which Ethereum deposit authorizes an API request. Each deposit and its eventual withdrawal are publicly linked by note id. The credential issuer and inference provider receive the API credential, and the provider receives prompts and responses."
},
"adversaries": [
{
"id": "publicObserver",
"label": "Public observer",
"description": "Everyone with a block explorer and some basic tools. Sees every public onchain event, but does no correlation beyond following links.",
"examples": "A curious counterparty, an employer, a journalist."
},
{
"id": "chainAnalyst",
"label": "Chain analyst",
"description": "Scrapes all public data and correlates it: timing, amounts, gas and wallet fingerprints, address clusters.",
"examples": "Chain analytics firms, ZachXBT, data brokers."
},
{
"id": "networkObserver",
"label": "Network observer",
"description": "Sits between the user and the chain and sees web2 traffic only: RPC providers, relayers and broadcasters, indexers, ISPs. Learns IP addresses, timing, browser fingerprints, ciphertext and what becomes public. Assumes Tor to send transactions and, where the client has an RPC setting, an own node to read the blockchain.",
"examples": "Infura or Alchemy, a Tornado relayer, a wallet vendor selling telemetry, Google captcha or analytics in the dapp frontend."
},
{
"id": "privilegedInsider",
"label": "Privileged insider",
"description": "Holds a protocol operator role or receives keys or plaintext by design: upgrade admin, sequencer, decryption or view key holder, TEE vendor, association set provider, hosted prover, note registry.",
"examples": "A compliance backdoor key, a DAO with an upgrade key, a KMS committee, an ASP operator."
},
{
"id": "futureAdversary",
"label": "Future adversary",
"description": "Harvest now, decrypt later. Holds every byte ever written onchain plus any retained logs, and future cryptanalysis such as a large quantum computer that breaks elliptic-curve key exchange and pairings, but not hashes, symmetric ciphers or lattices.",
"examples": "First well-funded insiders, then everyone in a potential post-quantum future."
}
],
"fields": [
{
"id": "sender",
"label": "Sender",
"subject": "Sender",
"promiseLabel": "Sender privacy",
"description": "The Ethereum address that funds entered from, or that initiated a transfer."
},
{
"id": "recipient",
"label": "Recipient",
"subject": "Recipient",
"promiseLabel": "Recipient privacy",
"description": "The Ethereum address that funds exit to, or that receives a transfer."
},
{
"id": "amount",
"label": "Amount",
"subject": "Amounts",
"promiseLabel": "Amount privacy",
"description": "The value moved."
},
{
"id": "asset",
"label": "Asset",
"subject": "Asset",
"promiseLabel": "Asset privacy",
"description": "Which token is moved."
},
{
"id": "linkage",
"label": "Link",
"subject": "Link",
"promiseLabel": "Link privacy",
"description": "Whether the entry and exit of the same funds, or sender and recipient of the same transfer, can be tied together."
}
],
"cells": {
"publicObserver": {
"sentiment": "good",
"exposure": "API authorizations stay offchain. Their proofs hide the deposit note and exact remaining balance. Ethereum publishes deposit sender, commitment, amount and expiry, then the same note id, payout address and remaining balance on closure. The difference reveals total consumption for that note. Publishing a challenge exposes a request proof and its nullifier alongside the note being withdrawn.",
"advice": "Treat funding, payouts and total consumption as public. Use a funding wallet and payout address that you accept being linked. An escape dispute reveals additional authorization metadata.",
"interior": {
"sender": "private",
"recipient": {
"verdict": "exposed",
"note": "Payments are for the configured service operator."
},
"amount": {
"verdict": "private",
"note": "Individual request charges stay offchain. A closed note reveals its total consumed amount."
},
"asset": "exposed",
"linkage": {
"verdict": "exposed",
"note": "Every closure identifies the original deposit by note id."
}
},
"sources": [
{
"contract": "ZkApiVault"
},
{
"contract": "Groth16ProofAdapter"
},
{
"title": "Request circuit hides note id, balance and state signature",
"url": "https://github.com/ethereum/zkapi/blob/045b444ea1b52538d1b40273c7cb6ed09468a052/protocol/rust/crates/zkapi-proof/src/groth16.rs#L368-L485"
}
],
"id": "publicObserver",
"value": "Sender private",
"alsoExposed": []
},
"chainAnalyst": {
"sentiment": "warning",
"exposure": "Ordinary authorizations and their spending bounds stay offchain. If an analyst obtains a request proof, its time and spending bound narrow the eligible notes using public deposit amounts and rounded expiries. A unique eligible note can identify the funding account. A published withdrawal challenge directly identifies the note behind its request proof. There is no pool anonymity between deposit and withdrawal.",
"advice": "Check that other active notes can cover your request budget. Avoid authorizing immediately after funding. Choosing a fresh payout address does not remove the published note-id link.",
"interior": {
"sender": {
"verdict": "atRisk",
"note": "The eligible set may contain only one plausible note."
},
"recipient": "exposed",
"amount": "atRisk",
"asset": "exposed",
"linkage": "exposed"
},
"sources": [
{
"contract": "ZkApiVault"
},
{
"title": "Authorization checks expiry, balance bound and active-note membership",
"url": "https://github.com/ethereum/zkapi/blob/045b444ea1b52538d1b40273c7cb6ed09468a052/protocol/rust/crates/zkapi-proof/src/groth16.rs#L388-L437"
}
],
"id": "chainAnalyst",
"value": "Sender at risk",
"alsoExposed": [
{
"field": "amount",
"exposure": "atRisk"
}
]
},
"networkObserver": {
"sentiment": "good",
"exposure": "Direct connections reveal IPs and timing to the protocol service, indexer, credential verifier and inference provider. RPCs see funding accounts and withdrawal transactions. The browser fetches a common tree snapshot and derives note paths locally. The desktop companion instead requests paths containing its note id, identifying the deposit to the indexer. Its Go Tor/Wisp transport is separate from the Rust companion HTTP client. Prompts can identify the user independently of funding.",
"advice": "Use an inspected browser SDK build with a reviewed production profile, route all traffic and wallet broadcasts through Tor, and read Ethereum through your own node. Changing the pinned RPC requires a reviewed profile and matching manifest. For the desktop client, disable credential reuse and route the whole application, including its Rust companion. The relay setting alone does not cover companion requests.",
"interior": {
"sender": {
"verdict": "atRisk",
"note": "Direct traffic or desktop note-path queries can identify the funding account. A browser using common snapshots and separately isolated network identities avoids this direct link."
},
"recipient": "exposed",
"amount": {
"verdict": "atRisk",
"note": "Request budgets, settlement responses and provider usage reach their respective services over TLS."
},
"asset": "exposed",
"linkage": "exposed"
},
"sources": [
{
"title": "Browser derives note paths from the common snapshot",
"url": "https://github.com/ethereum/zkapi/blob/045b444ea1b52538d1b40273c7cb6ed09468a052/sdk/services/browserWalletRuntime.js#L829-L845"
},
{
"title": "Desktop companion queries the indexer by note id",
"url": "https://github.com/ethereum/zkapi/blob/20aa542ae98e767c0507133fd34b12a56f5ccd3d/crates/zkapi-clientd/src/indexer.rs#L69-L104"
},
{
"title": "Companion patch preserves a separate HTTP client",
"url": "https://github.com/ethereum/zkapi/blob/045b444ea1b52538d1b40273c7cb6ed09468a052/zkapi-clientd/internal/zkapi/companion.patch#L271-L321"
},
{
"title": "Protocol requests construct their own Rust HTTP client",
"url": "https://github.com/ethereum/zkapi/blob/045b444ea1b52538d1b40273c7cb6ed09468a052/zkapi-clientd/internal/zkapi/protocol-transport.patch#L23-L80"
},
{
"title": "Tor route and credential-reuse settings",
"url": "https://github.com/ethereum/zkapi/blob/045b444ea1b52538d1b40273c7cb6ed09468a052/zkapi-clientd/cmd/zkapi-clientd/configure.go#L26-L39"
}
],
"id": "networkObserver",
"value": "Sender private",
"alsoExposed": [
{
"field": "amount",
"exposure": "atRisk"
}
]
},
"privilegedInsider": {
"sentiment": "warning",
"exposure": "The protocol operator receives the proof, spending bound, timing, lease metadata and billed cost. Randomized commitments hide the exact balance and note, but an operator sharing indexer logs can correlate desktop note-path queries with authorization requests. The credential issuer knows the provider key it issues, and the inference provider sees that key and all content sent with it. The desktop reuses keys across compatible requests by default. Hosted wallet code can read local secrets or substitute future payment instructions. A challenge explicitly associates a submitted authorization with a public note.",
"advice": "Run inspected local code, use the browser snapshot path, isolate funding and API network identities, and send no identifying content. Disable desktop key reuse with --key-reuse-window-seconds 0. The issuer and provider still learn the credential and content needed to deliver the service.",
"interior": {
"sender": {
"verdict": "atRisk",
"note": "Operator-held metadata and the desktop indexer path can identify the funding wallet. The proof alone does not reveal it."
},
"recipient": "exposed",
"amount": {
"verdict": "exposed",
"note": "The operator and provider know individual billed usage even though the remaining note balance is hidden."
},
"asset": "exposed",
"linkage": "exposed"
},
"sources": [
{
"title": "Operator signs balance updates and persists request transcripts",
"url": "https://github.com/ethereum/zkapi/blob/045b444ea1b52538d1b40273c7cb6ed09468a052/crates/zkapi-serverd/src/processor_v2.rs#L1267-L1381"
},
{
"title": "Desktop request authorizations fetch the active note path",
"url": "https://github.com/ethereum/zkapi/blob/20aa542ae98e767c0507133fd34b12a56f5ccd3d/crates/zkapi-clientd/src/service.rs#L1668-L1685"
},
{
"title": "Provider access reuse and plaintext boundaries",
"url": "https://github.com/ethereum/zkapi/blob/045b444ea1b52538d1b40273c7cb6ed09468a052/zkapi-clientd/docs/PRIVACY.md"
},
{
"title": "Wallet secrets and recovery state are stored locally",
"url": "https://github.com/ethereum/zkapi/blob/045b444ea1b52538d1b40273c7cb6ed09468a052/sdk/services/browserWalletStore.js"
},
{
"contract": "ZkApiVault",
"title": "Challenge calldata links a submitted authorization to its note"
},
{
"section": "permissions"
}
],
"id": "privilegedInsider",
"value": "Sender at risk",
"alsoExposed": [
{
"field": "amount",
"exposure": "exposed"
}
]
},
"futureAdversary": {
"sentiment": "warning",
"exposure": "Deposit and payout links, note totals and published challenges are permanent. Retained service logs can preserve note-path queries, credentials, prompts, timestamps and usage for later correlation. A quantum computer breaks the elliptic-curve signatures and proof soundness used by this protocol. This does not by itself uniquely open uniformly blinded balance commitments or reveal every historical note secret, which is hashed with Poseidon.",
"advice": "Treat chain data and information given to providers as permanently available. Preserve local secrets carefully and avoid identifiable prompts. The protocol has no post-quantum proof or signature protection.",
"interior": {
"sender": {
"verdict": "atRisk",
"note": "Retained indexer and service logs can connect authorizations to public deposits."
},
"recipient": "exposed",
"amount": {
"verdict": "atRisk",
"note": "Per-request charges require retained offchain records. Note-level totals are already public."
},
"asset": "exposed",
"linkage": "exposed"
},
"sources": [
{
"contract": "ZkApiVault"
},
{
"title": "Blinded note-bound commitments and cryptographic assumptions",
"url": "https://github.com/ethereum/zkapi/blob/045b444ea1b52538d1b40273c7cb6ed09468a052/docs/note-bound-commitments.md"
},
{
"title": "Durable operator transcripts",
"url": "https://github.com/ethereum/zkapi/blob/045b444ea1b52538d1b40273c7cb6ed09468a052/crates/zkapi-serverd/src/nullifier_store.rs"
}
],
"id": "futureAdversary",
"value": "Sender at risk",
"alsoExposed": [
{
"field": "amount",
"exposure": "atRisk"
}
]
}
}
},
"anonymitySet": {
"type": "not-applicable",
"description": "API authorization proofs hide their note among eligible active deposits. Each withdrawal identifies its original deposit by note id, so there is no deposit-to-withdrawal anonymity set."
},
"attributes": [
{
"id": "zk",
"label": "ZK",
"description": "Uses zero-knowledge proofs to prove private actions without revealing private data."
},
{
"id": "anyAmount",
"label": "Any amount",
"description": "Deposits and withdrawals can have any size."
}
],
"category": {
"id": "anonymousAuthorization",
"label": "Anonymous authorization",
"description": "Proves eligibility to use a service without identifying the funding account. Deposits and withdrawals can remain public and linked."
},
"exitWindow": {
"value": "None",
"sentiment": "bad",
"orderHint": 0,
"description": "The owner can immediately pause cooperative withdrawals and new escapes. An already pending escape can be finalized after 1 day, including during a pause. An active note becomes sweepable after its deposit expiry.",
"walkawayTest": {
"passed": false,
"reason": "An unpaused vault and the latest usable local note state are needed to start an escape. A submitted request proof can cancel an escape from the same state, even without evidence of service acceptance or delivery. The operator must return a signed successor state to recover normal use. API access itself requires the operator, credential issuer and inference provider."
}
},
"reproducibility": {
"value": "Partially reproducible",
"sentiment": "warning",
"description": "Vault and verifier creation bytecode match public source, and all three contracts are verified on Etherscan. Circuits, setup artifacts, browser SDK, local client and protocol services are public. The single-party setup has no public ceremony, and the deployed hosted app, credential issuer and production services have not been independently reproduced."
},
"riskSummary": "## Funds can be stolen if\n\n1. the owner pauses new withdrawals until notes expire and directs the permissionless sweep proceeds to a treasury it controls.\n2. someone uses retained single-party setup secrets or a circuit/verifier flaw to forge a withdrawal proof.\n3. malicious wallet code obtains note secrets or redirects future deposits and payout instructions.\n\n
\n\n## Funds can be lost or frozen if\n\n1. the user loses the note secret, signed state or pending-request recovery journal.\n2. a submitted request proof prevents recovery from the same state while the operator withholds a successor signature. The challenge needs no evidence that service was accepted or delivered.\n3. an active note expires and anyone sweeps its entire remaining deposit to the treasury.\n4. the owner pauses cooperative closes and new escapes, or a payout destination or treasury rejects ETH transfers.\n5. the operator loses a pinned signing key. This vault has no key-rotation mechanism.\n\n
\n\n## Privacy can be lost if\n\n1. the indexer correlates the desktop companion's note-id path queries with API authorization traffic.\n2. direct connections, timing, request budgets or a unique eligible deposit identify the funding account.\n3. the provider or credential issuer links requests through the issued API key, which the desktop can reuse across chats by default.\n4. identifying prompts, responses or retained service logs expose the user.\n5. a withdrawal challenge publishes a request proof and links its nullifier to the original note.\n6. hosted wallet code or another process obtains locally stored note secrets and recovery data.",
"tokens": [
{
"token": {
"address": "0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE",
"iconUrl": "https://assets.coingecko.com/coins/images/279/large/ethereum.png?1595348880",
"symbol": "ETH",
"decimals": 18,
"priceId": "ethereum",
"sinceTimestamp": 1790783879
},
"buckets": [
{
"id": "zkapi-ETH",
"type": "pool",
"label": "ETH API balances",
"address": "eth:0x4386FDbdA35D995beB3BF8625118Ec5982ec81fe",
"sinceTimestamp": 1790783879,
"deposit": {
"event": "0x7c83dba8534bea9e30d6444f9ca6462dc906897f9938d220dbbe4358c1f7a063",
"extractor": "zkApiDeposit",
"params": {
"weiPerUnit": "1000000000"
}
},
"withdrawal": {
"event": "0x1f43fa4711ca18e1d26398f26bf598bd3a62992cdd0e84f055f2bb506e9d7031",
"extractor": "zkApiWithdrawal",
"params": {
"weiPerUnit": "1000000000"
}
},
"additionalWithdrawals": [
{
"event": "0x163f2e46c4004f0ed9682e2db8c84efac31310720266b17ea9904ba348c26504",
"extractor": "zkApiWithdrawal",
"params": {
"weiPerUnit": "1000000000"
}
}
]
}
]
}
],
"trackedOn": [
"ethereum"
],
"upgradesAndGovernance": {
"content": "The vault's verifier, signing keys, note lifetime, expiry bucket and escape delay are fixed by its code and constructor. The linked Poseidon library is also fixed. The request and withdrawal verification keys cannot be replaced within this deployment.\n\nThe discovered vault owner can change the treasury, pause and unpause deposits and user-initiated withdrawal routes, transfer ownership or renounce it. Ownership changes are resolved through discovery. There is no enforced notice period before a pause. Already pending escapes, challenges and expired-note sweeps continue during a pause. Keeping the vault paused until an active note expires allows its full balance to be swept to the treasury, which the owner can redirect. [Verified vault source](https://etherscan.io/address/0x4386FDbdA35D995beB3BF8625118Ec5982ec81fe#code).\n\nThe operator holds the offchain state and clearance signing keys pinned in the vault. It controls API lease issuance, settlement signatures and immediate withdrawal clearance. State signatures bind commitments and deployment context. They do not give the key holder an ordinary onchain call permission or reveal note secrets. There is no public onchain evidence mapping these Baby-JubJub keys to an Ethereum account, so the discovered owner is not assumed to hold them.\n\nThe service operator, credential issuer, key verifier and inference provider control availability beyond Ethereum. The operator needs retained request proofs and a functioning challenger to reject stale-state escapes before their deadlines. API cost and service delivery are offchain trust assumptions. A lost signing key or missing settlement transcript cannot be remedied by rotating keys in this vault.\n\nOpen Anonymity controls the hosted application and its packaged endpoint, deployment and artifact pins. A browser update can change future instructions and access locally stored note state. An inspected local build preserves reviewed pins, but still needs compatible operator signatures, credential issuance and inference services. The mainnet profile in the public SDK currently pins a different verifier endpoint from the hosted mainnet app. Review the production profile before using that SDK build. [Public profile](https://github.com/ethereum/zkapi/blob/045b444ea1b52538d1b40273c7cb6ed09468a052/sdk/assets/config/mainnet.json), [hosted profile](https://chat.openanonymity.ai/zkapi/browser-config.json)."
}
}+1 -0
null+1 -0
null+1 -0
null+4 -0
{
"associatedTokens": [],
"warnings": []
}+21 -0
[
{
"mode": "auto",
"id": "zkapi-ETH",
"priceId": "ethereum",
"symbol": "ETH",
"name": "Ether",
"iconUrl": "https://assets.coingecko.com/coins/images/279/large/ethereum.png?1696501628",
"amount": {
"type": "balanceOfEscrow",
"chain": "ethereum",
"sinceTimestamp": 1790783879,
"address": "native",
"decimals": 18,
"escrowAddress": "0x4386FDbdA35D995beB3BF8625118Ec5982ec81fe"
},
"category": "ether",
"source": "canonical",
"isAssociated": false
}
]+1 -0
null+1 -0
null+1 -0
null+1 -0
null+1 -0
null+1 -0
null+1 -0
null+1 -0
null+24 -0
{
"ethereum": {
"roles": [],
"actors": [
{
"id": "EOA-1",
"name": "EOA 1",
"accounts": [
{
"address": "eth:0x83f7eA47811A288f2052Bc31aaAE0803c761D156",
"type": "EOA",
"isVerified": true,
"name": "0x83f7…D156",
"url": "https://etherscan.io/address/0x83f7eA47811A288f2052Bc31aaAE0803c761D156",
"displayName": "EOA 1"
}
],
"chain": "ethereum",
"description": "* Can interact with ZkApiVault\n * pause and unpause deposits, cooperative withdrawals and new escape withdrawals, and change the treasury receiving consumed balances and expired notes. Pausing can prevent users from exiting before their notes become sweepable ",
"discoveryDrivenData": true
}
]
}
}+55 -0
{
"addresses": {
"ethereum": [
{
"name": "ZkApiVault",
"isVerified": true,
"address": "eth:0x4386FDbdA35D995beB3BF8625118Ec5982ec81fe",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Escrows native ETH for anonymous API authorizations. Each deposit creates a publicly identified note. A Groth16 proof closes it with operator clearance or starts a delayed escape withdrawal that can be challenged with a valid request proof sharing its nullifier. The challenge does not prove service acceptance or delivery. Closures reveal the original note id, payout address and remaining balance, and send the consumed balance to the treasury. Anyone can sweep an expired active note entirely to the treasury. Pausing blocks deposits, cooperative closes and new escapes, while challenges, escape finalization and expiry sweeps remain available.\n* Roles:\n * **owner**: EOA 1",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x4386FDbdA35D995beB3BF8625118Ec5982ec81fe#code"
},
{
"name": "Groth16ProofAdapter",
"isVerified": true,
"address": "eth:0x8e92013Dd7cc86f75b539DBD3814B2e603e0F9C1",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "BN254 Groth16 verifier containing the request and withdrawal verification keys for zkapi-v2-note-bound-v1. Request proofs hide the note identity, exact balance and state signature. Withdrawal proofs expose the note id, destination, final balance and nullifier. The published circuit-specific keys were generated in a single-party setup. Retained setup secrets can allow forged proofs.\n",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x8e92013Dd7cc86f75b539DBD3814B2e603e0F9C1#code"
},
{
"name": "Bn254Poseidon",
"isVerified": true,
"address": "eth:0xc6B55e86668d8c446B3D81273AAb9CBb20F28c7f",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Linked Poseidon hash library used by the vault for active-note leaves and Merkle updates. Its BN254 parameters must agree with the request and withdrawal circuits.\n",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0xc6B55e86668d8c446B3D81273AAb9CBb20F28c7f#code"
}
]
},
"risks": [],
"zkVerifiers": [
"eth:0x8e92013Dd7cc86f75b539DBD3814B2e603e0F9C1"
]
}+7 -0
{
"baseTimestamp": 1790944823,
"contractsDiscoDriven": false,
"hasDiscoUi": false,
"isDiscoDriven": false,
"permissionsDiscoDriven": false
}+16 -0
[
{
"id": "193c1624",
"date": "Fri, 02 Oct 2026 12:42:14 GMT",
"timestamp": 1790944823,
"description": "Initial discovery of the active native ETH vault, its Groth16 proof adapter and linked Poseidon library. All three contracts were verified from public source. The owner can pause new exits and change the treasury.",
"isHighSeverity": false,
"changeCount": 3,
"sections": [
{
"kind": "initial-discovery",
"body": "```diff\n+ Status: CREATED\n contract ZkApiVault (eth:0x4386FDbdA35D995beB3BF8625118Ec5982ec81fe) [zkapi/ZkApiVault]\n +++ description: Escrows native ETH for anonymous API authorizations. Each deposit creates a publicly identified note. A Groth16 proof closes it with operator clearance or starts a delayed escape withdrawal that can be challenged with a valid request proof sharing its nullifier. The challenge does not prove service acceptance or delivery. Closures reveal the original note id, payout address and remaining balance, and send the consumed balance to the treasury. Anyone can sweep an expired active note entirely to the treasury. Pausing blocks deposits, cooperative closes and new escapes, while challenges, escape finalization and expiry sweeps remain available.\n```\n\n```diff\n+ Status: CREATED\n contract Groth16ProofAdapter (eth:0x8e92013Dd7cc86f75b539DBD3814B2e603e0F9C1) [zkapi/Groth16ProofAdapter]\n +++ description: BN254 Groth16 verifier containing the request and withdrawal verification keys for zkapi-v2-note-bound-v1. Request proofs hide the note identity, exact balance and state signature. Withdrawal proofs expose the note id, destination, final balance and nullifier. The published circuit-specific keys were generated in a single-party setup. Retained setup secrets can allow forged proofs.\n```\n\n```diff\n+ Status: CREATED\n contract Bn254Poseidon (eth:0xc6B55e86668d8c446B3D81273AAb9CBb20F28c7f) [zkapi/Bn254Poseidon]\n +++ description: Linked Poseidon hash library used by the vault for active-note leaves and Merkle updates. Its BN254 parameters must agree with the request and withdrawal circuits.\n```"
}
]
}
]+26 -0
{
"changes": [],
"contracts": [
{
"name": "ZkApiVault",
"address": "eth:0x4386FDbdA35D995beB3BF8625118Ec5982ec81fe",
"isVerified": true,
"ossifyingSince": 1790783879,
"codeChangeCount": 0,
"stateChangeCount": 0
},
{
"name": "Groth16ProofAdapter",
"address": "eth:0x8e92013Dd7cc86f75b539DBD3814B2e603e0F9C1",
"isVerified": true,
"ossifyingSince": 1790782859,
"codeChangeCount": 0,
"stateChangeCount": 0
}
],
"observedSince": 1790782859,
"resets": [
1790782859,
1790783879
]
}+1 -0
null+1 -0
null[ADDED]
zkmoney
+1093 -0
+1 -0
"zkmoney"+1 -0
"zkmoney"+1 -0
"zk.money"+1 -0
null+1 -0
null+1 -0
1790640000+3 -0
{
"unverifiedContracts": []
}+19 -0
{
"badges": [],
"description": "A private DAI wallet on Aztec Network, with funds escrowed on Ethereum.",
"detailedDescription": "Internal payments are hidden, but names, deposits and withdrawals are public. The first payment to a new contact reveals the recipient. The first sponsored transaction after registration reveals the sender's account.\n\nEvery withdrawal and refund needs a proof and a live AWS Nitro enclave. Operations are encrypted to the enclave (TEE), which decrypts and reads them. Its approved binary has not been reproduced from the published source. Aztec Labs controls zk.money names and the released wallets' contract configuration.\n\n### Multiproofs and exits\nThe portal releases funds only after Aztec proves the withdrawal message (zk proof of validity) and any one registered enclave signer co-signs it (TEE signature). Stealing escrowed funds requires both layers to fail while privacy leaks depend on either. Anyone can register an enclave running the approved image with a fresh AWS attestation.\n\nIf Aztec governance changes its canonical rollup, anyone can freeze the portal. Deposits stop and refundable ownership is fixed at the last proven checkpoint. Later L2 transfers do not change it. Withdrawals and refunds still need an enclave. Refunds expose note or deposit amounts on Ethereum and use proofs without zero knowledge.\n\n### Wallet\n- **Hosted:** loads code from zk.money on every visit. Whoever controls deployment can read viewing keys and request harmful passkey signatures. Passkey prompts do not show the operation.\n- **Desktop:** runs local code but fetches contract addresses from two unsigned Aztec Labs lists. Substituting them can redirect future deposits and payments.\n- **Independent operation:** requires modifying the desktop build to pin verified addresses, remove screening and serve it under auth.zk.money. Users can submit Ethereum transactions themselves and run the approved enclave on AWS. New names still require Aztec Labs' signature. L2BEAT has not run this setup.\n\nBoth released wallets allow custom Aztec, Ethereum and enclave endpoints. Their passkeys belong to auth.zk.money, which must authorize wallet.zk.money on every use. Onchain contracts do not check the signature's origin. A modified wallet served under auth.zk.money would bypass this dependency.\n\nWallets use XMTP, an end-to-end encrypted messaging network, to confirm contacts added by QR code or link and to send payment requests. Messages are encrypted, but each inbox is publicly tied to a name, so XMTP's servers can see which names talk to each other.\n\nThe browser stores the master key unencrypted until sign-out, and viewing keys and decrypted notes until local data is cleared. All keys except the spending key derive from the master key (privacy is lost if the master key is leaked).\n\n### Deposits and fees\nUsers fund deposit addresses called SIPAs. Anyone can sweep them into the Ethereum portal. USDC and USDT are swapped to DAI through Curve. After fees, DAI stays in escrow and an Inbox message credits private notes on Aztec L2. SIPAs can be reused, at the expense of user privacy.\n\nA sweep pays 0.25 DAI, or 0.5 DAI when claiming a name. Registration costs 5 DAI by default, including its sweep fee. The domain owner (onchain role in NameRegistry) can sign custom prices and add fee beneficiaries. Users select a beneficiary in their registration intent.\n\nThe portal takes 0.1 DAI from each deposit and ordinary withdrawal to sponsor Aztec fees. Sponsorship requires a registered name or a voucher from a registered account. An empty fee-paying contract or fees above its allowance stall the released wallet. Modified code can pay with the account's own Fee Juice (potential privacy implications). Deposits share a 50,000 DAI capacity, refilling over 1 day. Deposit, payment and withdrawal transaction amounts are capped at 2,583 DAI each.\n\n### Names and Compliance\nNames (tags) publicly map to Aztec addresses and keys on Ethereum. Claims require the domain owner's signature from a closed-source server with a name blocklist. The released wallet requires a registered name to access an account on a new device.\n\nExternal name payments use a resolver operator to derive and announce deposit addresses. Internal payments skip it (reading from the onchain contract), but wallet-created deposit addresses still derive from Aztec Labs' operator key. The onchain Resolver checks a zk proof on every lookup, binding each address to the recipient's registered keys, Aztec address and L1 account, so the operator cannot redirect payments. It can still re-derive every deposit address of its users. Users can choose another operator for name payments. The only registered operator is Aztec Labs, and its service is unpublished.\n\nThe wallet sends Ethereum addresses to Predicate through zk.money for screening, which can be bypassed by funding a deposit SIPA directly. The relayer also screens token movements against OFAC and optionally Predicate. Self-submitting sweeps and proven withdrawals bypasses relayer screening.\n\nThe name resolver screens deposit addresses and funders against OFAC before notifying the recipient on L2. A blocked payment leaves funds at an address the wallet never learns. Recovery requires the recipient's own tooling to re-derive it and authorization from their L1 account. Onchain contracts and the enclave do not check compliance lists.\n\n### Source verification\nThe [token verification steps](https://github.com/l2beat/l2beat/blob/main/packages/config/src/projects/zkmoney/verificationSteps-token.md) compare a fresh source build with the Aztec instance (L2 contract) pinned by the Ethereum portal. The [verifier steps](/zk-catalog/barretenberg#verifiers) regenerate the keys and Solidity verifiers of the refund and resolver circuits and compare them with the deployed contracts.",
"links": {
"websites": [
"https://zk.money"
],
"documentation": [
"https://docs.zk.money/docs"
],
"repositories": [
"https://github.com/aztec-labs-eng/zkmoney-public"
],
"explorers": [
"https://aztecscan.xyz/contracts/instances/0x015ca4a43f83d08a038c36c06ca92527f120dc1f9176ea85d1ea347decaf444d"
]
}
}+1 -0
null+1 -0
null+1 -0
null+1 -0
null+11 -0
[
{
"address": "0xdf410ad448A0f7165181FBdB32f8896f4a0d9449",
"chain": "ethereum",
"sinceTimestamp": 1790298635,
"tokens": [
"DAI"
],
"chainId": 1
}
]+1 -0
null+1 -0
null+1 -0
null+1 -0
null+1 -0
null+1 -0
null+1 -0
null+1 -0
null+1 -0
null+1 -0
null+1 -0
null+1 -0
null+1 -0
null+475 -0
{
"adversaries": {
"promise": {
"protects": "linkage",
"text": "Hides senders, amounts and links between deposits and withdrawals within the ledger. Tags, deposits and withdrawals are public. The first payment to a new contact reveals the recipient, and the first sponsored transaction after registration reveals the sender’s account."
},
"adversaries": [
{
"id": "publicObserver",
"label": "Public observer",
"description": "Everyone with a block explorer and some basic tools. Sees every public onchain event, but does no correlation beyond following links.",
"examples": "A curious counterparty, an employer, a journalist."
},
{
"id": "chainAnalyst",
"label": "Chain analyst",
"description": "Scrapes all public data and correlates it: timing, amounts, gas and wallet fingerprints, address clusters.",
"examples": "Chain analytics firms, ZachXBT, data brokers."
},
{
"id": "networkObserver",
"label": "Network observer",
"description": "Sits between the user and the chain and sees web2 traffic only: RPC providers, relayers and broadcasters, indexers, ISPs. Learns IP addresses, timing, browser fingerprints, ciphertext and what becomes public. Assumes Tor to send transactions and, where the client has an RPC setting, an own node to read the blockchain.",
"examples": "Infura or Alchemy, a Tornado relayer, a wallet vendor selling telemetry, Google captcha or analytics in the dapp frontend."
},
{
"id": "privilegedInsider",
"label": "Privileged insider",
"description": "Holds a protocol operator role or receives keys or plaintext by design: upgrade admin, sequencer, decryption or view key holder, TEE vendor, association set provider, hosted prover, note registry.",
"examples": "A compliance backdoor key, a DAO with an upgrade key, a KMS committee, an ASP operator."
},
{
"id": "futureAdversary",
"label": "Future adversary",
"description": "Harvest now, decrypt later. Holds every byte ever written onchain plus any retained logs, and future cryptanalysis such as a large quantum computer that breaks elliptic-curve key exchange and pairings, but not hashes, symmetric ciphers or lattices.",
"examples": "First well-funded insiders, then everyone in a potential post-quantum future."
}
],
"fields": [
{
"id": "sender",
"label": "Sender",
"subject": "Sender",
"promiseLabel": "Sender privacy",
"description": "The Ethereum address that funds entered from, or that initiated a transfer."
},
{
"id": "recipient",
"label": "Recipient",
"subject": "Recipient",
"promiseLabel": "Recipient privacy",
"description": "The Ethereum address that funds exit to, or that receives a transfer."
},
{
"id": "amount",
"label": "Amount",
"subject": "Amounts",
"promiseLabel": "Amount privacy",
"description": "The value moved."
},
{
"id": "asset",
"label": "Asset",
"subject": "Asset",
"promiseLabel": "Asset privacy",
"description": "Which token is moved."
},
{
"id": "linkage",
"label": "Link",
"subject": "Link",
"promiseLabel": "Link privacy",
"description": "Whether the entry and exit of the same funds, or sender and recipient of the same transfer, can be tied together."
}
],
"cells": {
"publicObserver": {
"sentiment": "good",
"exposure": "Private payments publish encrypted notes. Fixed log tags identify zk.money transactions on Aztec, and the first payment to a new contact reveals the recipient's Aztec address through a handshake. The Ethereum registry maps that address to a tag. The first sponsored transaction after registration also identifies the sender's account. Deposits and withdrawals show address, token and amount. Claiming a tag links it and the Aztec address to the funding L1 wallet.",
"advice": "Claim your tag from a wallet with no public link to you and fund each deposit address once. Wait for deposits to be swept. Recovering them reveals the link to your account.",
"interior": {
"sender": {
"verdict": "atRisk",
"note": "Your first sponsored transaction after registration is publicly tied to your account."
},
"recipient": {
"verdict": "exposed",
"note": "The first payment to a new contact reveals the recipient's Aztec address."
},
"amount": "private",
"asset": {
"verdict": "exposed",
"note": "zk.money only holds DAI."
},
"linkage": {
"verdict": "atRisk",
"note": "If your first sponsored transaction after registration is a payment to a new contact, it shows both ends."
}
},
"sources": [
{
"title": "Fixed log tags on every zk.money transaction",
"url": "https://github.com/aztec-labs-eng/zkmoney-public/blob/fc37a3e25440bc4bd7a9de81a7f4830ec753a4d4/vendor/oxide/noir-projects/oxide_lib/src/constants.nr#L77-L81"
},
{
"title": "First delivery to a new contact opens a handshake",
"url": "https://github.com/aztec-labs-eng/zkmoney-public/blob/fc37a3e25440bc4bd7a9de81a7f4830ec753a4d4/packages/sdk/src/feePaymentMethod/claimFpcGasModel.ts#L232-L237"
},
{
"title": "First sponsored transaction nullifies the L1 account",
"url": "https://github.com/aztec-labs-eng/zkmoney-public/blob/fc37a3e25440bc4bd7a9de81a7f4830ec753a4d4/packages/contracts/contracts/fee_paying/claim_fpc/src/main.nr#L205-L217"
},
{
"title": "Withdrawals publish their L1 payload",
"url": "https://github.com/aztec-labs-eng/zkmoney-public/blob/fc37a3e25440bc4bd7a9de81a7f4830ec753a4d4/vendor/oxide/noir-projects/oxide_token_contract/src/withdrawal.nr#L32-L42"
},
{
"contract": "RegistrationController"
},
{
"contract": "AccountMetadataRegistry"
},
{
"contract": "DepositSIPA"
}
],
"id": "publicObserver",
"value": "Link private",
"alsoExposed": []
},
"chainAnalyst": {
"sentiment": "warning",
"exposure": "The anonymity set is limited to zk.money users. The first payment to a tag from outside zk.money is publicly tied to that tag. Anyone who records Aztec transactions can also tie the first deposit address your wallet creates after registration to your account.",
"advice": "Watch the anonymity set in this early stage. Give outside payers a deposit address your wallet created instead of your tag. Fund your first deposit address after registration from the wallet that claimed your tag. Withdraw common amounts rather than everything at once. Wait before exiting and pick a different time of day than the deposit. Exit to a fresh address every time and spend from it with a different wallet than the one that deposited.",
"interior": {
"sender": "atRisk",
"recipient": "exposed",
"amount": {
"verdict": "atRisk",
"note": "Inferable when a payment sits between a matching public deposit and withdrawal."
},
"asset": "exposed",
"linkage": {
"verdict": "atRisk",
"note": "Registration deposits are publicly tied to their tag."
}
},
"sources": [
{
"contract": "ZkMoneyPortal"
},
{
"contract": "RegistrationSIPA"
},
{
"contract": "PlainWithdrawalExecutor"
},
{
"title": "Private transfers credit the recipient with new notes",
"url": "https://github.com/aztec-labs-eng/zkmoney-public/blob/fc37a3e25440bc4bd7a9de81a7f4830ec753a4d4/vendor/oxide/noir-projects/oxide_token_contract/src/main.nr#L133-L167"
},
{
"title": "Resolver notifies the recipient of each deposit address",
"url": "https://github.com/aztec-labs-eng/zkmoney-public/blob/fc37a3e25440bc4bd7a9de81a7f4830ec753a4d4/vendor/oxide/noir-projects/oxide_token_contract/src/main.nr#L236-L251"
},
{
"title": "The notification and the sweep request share one Aztec transaction",
"url": "https://github.com/aztec-labs-eng/zkmoney-public/blob/fc37a3e25440bc4bd7a9de81a7f4830ec753a4d4/packages/sdk/src/services/sipaIntents.ts#L171-L186"
},
{
"title": "Handshake announcements are tagged with the recipient address",
"url": "https://github.com/AztecProtocol/aztec-packages/blob/v5.2.0/noir-projects/noir-contracts/contracts/standard/handshake_registry_contract/src/main.nr#L82-L96"
}
],
"id": "chainAnalyst",
"value": "Link at risk",
"alsoExposed": [
{
"field": "amount",
"exposure": "atRisk"
}
]
},
"networkObserver": {
"sentiment": "good",
"exposure": "Keys and proving stay on your device. Note discovery reveals your account address to the Aztec node. Ethereum RPC requests reveal funding wallets, deposit addresses and L1 transaction senders. XMTP carries payment requests and contact links under public account addresses, exposing who asks whom for money. Both wallets support custom Aztec, Ethereum and enclave endpoints.",
"advice": "Use zk.money Desktop with your own Aztec and Ethereum nodes. Send L1 transactions from your Ethereum wallet over a public RPC. Route all computer traffic through a VPN or Tor. Avoid payment requests and contact links with counterparties that must stay private.",
"interior": {
"sender": {
"verdict": "atRisk",
"note": "Payment requests over XMTP show who asks whom."
},
"recipient": "exposed",
"amount": "private",
"asset": "exposed",
"linkage": "atRisk"
},
"sources": [
{
"title": "Desktop endpoint overrides",
"url": "https://github.com/aztec-labs-eng/zkmoney-public/blob/fc37a3e25440bc4bd7a9de81a7f4830ec753a4d4/packages/web-wallet-desktop/src/config.js#L36-L47"
},
{
"title": "Handshakes are found by a tag derived from your address",
"url": "https://github.com/AztecProtocol/aztec-packages/blob/v5.2.0/noir-projects/noir-contracts/contracts/standard/handshake_registry_contract/src/main.nr#L82-L96"
},
{
"title": "L1 gas estimates over the wallet RPC carry your address",
"url": "https://github.com/aztec-labs-eng/zkmoney-public/blob/fc37a3e25440bc4bd7a9de81a7f4830ec753a4d4/packages/web-wallet/src/features/deposit/sipaRecovery.ts#L166-L193"
},
{
"title": "Desktop sends screening to zk.money from its own process",
"url": "https://github.com/aztec-labs-eng/zkmoney-public/blob/fc37a3e25440bc4bd7a9de81a7f4830ec753a4d4/packages/web-wallet-desktop/scripts/compose-config.js#L15-L20"
},
{
"title": "XMTP identity is the account bootstrap address",
"url": "https://github.com/aztec-labs-eng/zkmoney-public/blob/fc37a3e25440bc4bd7a9de81a7f4830ec753a4d4/packages/web-wallet/src/platform/xmtp/WebXmtpClient.ts#L95-L109"
},
{
"title": "Pointing the wallet at a different service",
"url": "https://docs.zk.money/docs/desktop"
}
],
"id": "networkObserver",
"value": "Link private",
"alsoExposed": []
},
"privilegedInsider": {
"sentiment": "bad",
"exposure": "Wallets encrypt payments, withdrawals and deposit claims to an enclave key registered in the portal. The approved code decrypts them inside the enclave. Privacy against the operator depends on AWS Nitro and that code, whose binary has not been reproduced. The resolver operator can re-derive all deposit addresses, including those created by your wallet, linking L1 deposits to L2 recipients.",
"advice": "Run your own enclave, which is permissionless onchain but still depends on AWS. Running your own resolver operator is also permissionless, but its service is unpublished and the released wallets only use Aztec Labs' operator.",
"interior": {
"sender": "exposed",
"recipient": "exposed",
"amount": "exposed",
"asset": "exposed",
"linkage": "exposed"
},
"sources": [
{
"title": "Enclave requests carry notes and the nullifier hiding key",
"url": "https://github.com/aztec-labs-eng/zkmoney-public/blob/fc37a3e25440bc4bd7a9de81a7f4830ec753a4d4/vendor/oxide/yarn-project/oxide-lib/src/types.ts#L336-L392"
},
{
"title": "Wallets encrypt to the enclave key registered in the portal",
"url": "https://github.com/aztec-labs-eng/zkmoney-public/blob/fc37a3e25440bc4bd7a9de81a7f4830ec753a4d4/vendor/oxide/yarn-project/oxide-client/src/fleet_signer.ts#L172-L202"
},
{
"title": "Deposit address secrets derive from the resolver key",
"url": "https://github.com/aztec-labs-eng/zkmoney-public/blob/fc37a3e25440bc4bd7a9de81a7f4830ec753a4d4/packages/sdk/src/services/sipaStealth.ts#L80-L100"
},
{
"title": "The resolver circuit derives each secret from the operator key",
"url": "https://github.com/aztec-labs-eng/zkmoney-public/blob/68425f9cf408ac803eade04d10318fcf345444a0/vendor/oxide/noir-projects/resolver_circuit/src/main.nr#L23-L79"
},
{
"title": "Self-made deposit addresses use predictable nonces",
"url": "https://github.com/aztec-labs-eng/zkmoney-public/blob/fc37a3e25440bc4bd7a9de81a7f4830ec753a4d4/packages/sdk/src/services/sipaSelfResolve.ts#L47-L53"
},
{
"title": "Addresses are sent to Predicate for screening",
"url": "https://github.com/aztec-labs-eng/zkmoney-public/blob/fc37a3e25440bc4bd7a9de81a7f4830ec753a4d4/packages/front-core/src/core/services/screening/PredicateScreeningService.ts#L86-L97"
},
{
"contract": "ZkMoneyPortal",
"title": "Registered TEE signers"
},
{
"contract": "Resolver"
},
{
"contract": "AccountMetadataRegistry",
"title": "Resolver operators"
},
{
"section": "permissions"
}
],
"id": "privilegedInsider",
"value": "Link exposed",
"alsoExposed": [
{
"field": "sender",
"exposure": "exposed"
},
{
"field": "amount",
"exposure": "exposed"
}
]
},
"futureAdversary": {
"sentiment": "bad",
"exposure": "A quantum computer that breaks elliptic-curve key exchange can decrypt historical notes and payment events published to Ethereum. Registered Aztec addresses identify the accounts. Deposit address secrets and enclave communication use the same class of cryptography.",
"advice": "Treat every payment and every deposit link as permanently disclosed.",
"interior": {
"sender": "exposed",
"recipient": "exposed",
"amount": "exposed",
"asset": "exposed",
"linkage": "exposed"
},
"sources": [
{
"contract": "AccountMetadataRegistry",
"title": "Registered Aztec addresses"
},
{
"title": "Deposit address secrets use secp256k1 key exchange",
"url": "https://github.com/aztec-labs-eng/zkmoney-public/blob/fc37a3e25440bc4bd7a9de81a7f4830ec753a4d4/packages/sdk/src/services/sipaStealth.ts#L80-L100"
},
{
"title": "Enclave channel uses P-256 HPKE",
"url": "https://github.com/aztec-labs-eng/zkmoney-public/blob/fc37a3e25440bc4bd7a9de81a7f4830ec753a4d4/vendor/oxide/yarn-project/oxide-lib/src/encryption.ts#L1-L5"
}
],
"id": "futureAdversary",
"value": "Link exposed",
"alsoExposed": [
{
"field": "sender",
"exposure": "exposed"
},
{
"field": "amount",
"exposure": "exposed"
}
]
}
}
},
"anonymitySet": {
"type": "partially-attributed"
},
"attributes": [
{
"id": "zk",
"label": "ZK",
"description": "Uses zero-knowledge proofs to prove private actions without revealing private data."
},
{
"id": "tee",
"label": "TEE",
"description": "Privacy assumptions of this project are secured by trusted hardware."
},
{
"id": "transfers",
"label": "Transfers",
"description": "Private transfers within the shielded pool."
},
{
"id": "anyAmount",
"label": "Any amount",
"description": "Deposits and withdrawals can have any size."
}
],
"category": {
"id": "shieldedLedger",
"label": "Shielded ledger",
"description": "A pool with transfers or DeFi inside. Hides who pays whom and which deposit funds which withdrawal."
},
"exitWindow": {
"value": "Infinite",
"sentiment": "good",
"orderHint": 9007199254740991,
"description": "The escrow and approved enclave image cannot be upgraded. Every withdrawal and refund still needs a proof and a live approved enclave. If Aztec changes its canonical rollup, anyone can freeze deposits and fix refundable ownership at the last proven checkpoint. Later L2 transfers do not change it.",
"walkawayTest": {
"passed": false,
"reason": "Withdrawals and refunds require a live enclave running the approved image published by Aztec Labs. Running one requires AWS Nitro infrastructure. Both released wallets also depend on zk.money services, so independent operation requires a modified desktop build."
}
},
"relayerTracking": {
"type": "onchainEvents",
"metric": "paidFinalizers",
"sources": [
{
"address": "eth:0xdf410ad448A0f7165181FBdB32f8896f4a0d9449",
"sinceTimestamp": 1790298635,
"extractor": "zkMoneyDepositPayout",
"params": {
"tokenAddress": "0x6B175474E89094C44Da98b954EedeAC495271d0F",
"factoryAddress": "0xc357E34D4C7520a83C9Ec0a242Ba52b4ecABa1Fc",
"depositImplementation": "0xF714D8Cf287F4A410b018514074A9371BC45461b",
"registrationImplementation": "0x0934F010d59b552949DBe44AcBE5AFf0e32C8C34",
"fundingTokens": [
"0x6B175474E89094C44Da98b954EedeAC495271d0F",
"0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48",
"0xdAC17F958D2ee523a2206206994597C13D831ec7"
],
"exchangeAddress": "0xbEbc44782C7dB0a1A60Cb6fe97d0b483032FF1C7",
"historyFromBlock": 26051085,
"fundingCut": "100000000000000000",
"depositFee": "250000000000000000",
"registrationSweepFee": "500000000000000000",
"operationExecutor": "0xe883686d9EC4E0430f2233A6BF12B2D226a39e19"
}
},
{
"address": "eth:0xdf410ad448A0f7165181FBdB32f8896f4a0d9449",
"sinceTimestamp": 1790298635,
"extractor": "zkMoneyWithdrawalPayout",
"params": {
"tokenAddress": "0x6B175474E89094C44Da98b954EedeAC495271d0F",
"executorAddress": "0xC2363b7155EE8391C5395B72C46a6d22BF49151c",
"operationExecutor": "0xe883686d9EC4E0430f2233A6BF12B2D226a39e19"
}
}
]
},
"reproducibility": {
"value": "Partially reproducible",
"sentiment": "warning",
"description": "The contract, desktop wallet, enclave and circuit sources are public. The deployed refund and resolver verifiers match the published circuits. The approved enclave binary has not been reproduced. The resolver service, frozen-chain snapshot service and hosted wallet release source are unpublished. Verification instructions cover the refund and resolver circuits and the Aztec token pinned by the Ethereum portal."
},
"riskSummary": "## Funds can be stolen if\n\n1. Aztec's private execution or refund proof is unsound and the enclave layer also fails.\n2. malicious wallet code obtains a harmful signature, or substituted unsigned contract lists redirect future deposits and payments.\n3. the NameRegistry owner or owner of zk.money in ENS redirects future payments to names.\n\n
\n\n## Funds can be lost if\n\n1. a user loses their passkey.\n2. no AWS-attested enclave is running.\n3. resolver screening blocks an external payment. Funds remain recoverable, but the recipient needs their own tooling to re-derive the unannounced deposit address.\n\n
\n\n## Privacy can be lost if\n\n1. a user pays a new contact. The handshake reveals the recipient's Aztec address, publicly linked to their name. The first sponsored transaction after registration also reveals the sender's account.\n2. an enclave or AWS Nitro attestation is compromised.\n3. the resolver operator re-derives deposit addresses and links deposits to recipients.\n4. public deposits, withdrawals, registration and deposit-address reuse allow amount or timing correlation.\n5. an external Aztec RPC learns the account from note requests, or zk.money and Predicate correlate screened addresses by IP.\n6. someone reads keys and decrypted notes stored unencrypted on the device.\n7. a freeze forces refunds, which expose note and deposit amounts on Ethereum and use proofs without zero knowledge.\n8. a quantum computer breaks the elliptic-curve encryption of notes published to Ethereum.",
"tokens": [
{
"token": {
"address": "0x6B175474E89094C44Da98b954EedeAC495271d0F",
"iconUrl": "https://assets.coingecko.com/coins/images/9956/large/Badge_Dai.png?1696509996",
"symbol": "DAI",
"decimals": 18,
"priceId": "dai",
"sinceTimestamp": 1790298635
},
"buckets": [
{
"id": "zkmoney-DAI",
"type": "pool",
"label": "DAI",
"address": "eth:0xdf410ad448A0f7165181FBdB32f8896f4a0d9449",
"sinceTimestamp": 1790298635,
"anonymitySet": {
"minimumAmounts": [
"200000000000000000000"
]
},
"deposit": {
"event": "0x8154af7b1b360f500640de68c82af19c52c4ad4189d7a7c7a41506e19a1fdd6c",
"extractor": "zkMoneyDeposit",
"params": {
"tokenAddress": "0x6B175474E89094C44Da98b954EedeAC495271d0F",
"factoryAddress": "0xc357E34D4C7520a83C9Ec0a242Ba52b4ecABa1Fc",
"depositImplementation": "0xF714D8Cf287F4A410b018514074A9371BC45461b",
"registrationImplementation": "0x0934F010d59b552949DBe44AcBE5AFf0e32C8C34",
"fundingTokens": [
"0x6B175474E89094C44Da98b954EedeAC495271d0F",
"0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48",
"0xdAC17F958D2ee523a2206206994597C13D831ec7"
],
"exchangeAddress": "0xbEbc44782C7dB0a1A60Cb6fe97d0b483032FF1C7",
"historyFromBlock": 26051085,
"fundingCut": "100000000000000000",
"depositFee": "250000000000000000",
"registrationSweepFee": "500000000000000000",
"operationExecutor": "0xe883686d9EC4E0430f2233A6BF12B2D226a39e19"
}
},
"withdrawal": {
"event": "0x0ef2e2e9f18042ca214d1bee833209f28326ffa8f4a6b0dc92172caf71bc5433",
"extractor": "zkMoneyWithdrawal",
"params": {}
}
}
]
}
],
"trackedOn": [
"ethereum"
],
"upgradesAndGovernance": {
"content": "### Immutable escrow and accounts\n\nThe portal, Aztec token, fee-paying contract, verifiers, withdrawal executors and current SIPA implementations cannot be upgraded.\n\nThe approved enclave image is fixed. Anyone can permanently register a signer with an AWS Nitro attestation at most 1 hour old. 2 signers are registered. A withdrawal or refund needs only one of them, alongside its proof. Registrations do not expire and cannot be revoked.\n\nIf Aztec governance changes the canonical rollup, anyone can permanently freeze the portal. Deposits stop and refundable ownership is fixed at the last proven checkpoint. Later L2 transfers do not change it. Withdrawals and refunds still require a live enclave.\n\n### Name administration\n\nTwo Aztec Labs EOAs control *.zk.money names:\n\n- The deployer owns the NameRegistry and can replace its RegistrationController, AccountMetadataRegistry and Resolver, allowing it to reassign names, rewrite records and redirect future payments. It also owns zk.money in ENS, which the DNS domain holder can reclaim.\n- The domain owner can refuse name claims, sign custom registration fees and add fee beneficiaries. Users select a beneficiary from the allowlist in their signed registration intent. Existing beneficiaries cannot be removed.\n\n### Wallet and services\n\nAztec Labs controls hosted wallet code, desktop releases and two unsigned contract lists consumed by both wallets. These are security dependencies: wallet code handles keys and signatures, and the lists determine where future funds go. The wallet checks the [profile](https://github.com/aztec-labs-eng/zkmoney-public/blob/fc37a3e25440bc4bd7a9de81a7f4830ec753a4d4/packages/config-client/src/toContractServiceConfig.ts#L41-L68) and [manifest](https://github.com/aztec-labs-eng/zkmoney-public/blob/fc37a3e25440bc4bd7a9de81a7f4830ec753a4d4/packages/core/src/oxide/index.ts#L108-L170) for consistency, but both come from Aztec Labs. A local build with custom nodes still trusts those lists until their addresses are independently verified and pinned.\n\nThe relayer, resolver, claim server, enclave hosts and passkey domain also control availability and censorship. Self-submission bypasses the relayer, but exits still need an enclave and the released wallets still depend on zk.money services."
},
"zkCatalogId": "barretenberg"
}+1 -0
null+1 -0
null+1 -0
null+4 -0
{
"associatedTokens": [],
"warnings": []
}+21 -0
[
{
"mode": "auto",
"id": "zkmoney-DAI",
"priceId": "dai",
"symbol": "DAI",
"name": "Dai Stablecoin",
"iconUrl": "https://assets.coingecko.com/coins/images/9956/large/Badge_Dai.png?1696509996",
"amount": {
"type": "balanceOfEscrow",
"chain": "ethereum",
"sinceTimestamp": 1790298635,
"address": "0x6B175474E89094C44Da98b954EedeAC495271d0F",
"decimals": 18,
"escrowAddress": "0xdf410ad448A0f7165181FBdB32f8896f4a0d9449"
},
"category": "stablecoin",
"source": "canonical",
"isAssociated": false
}
]+1 -0
null+1 -0
null+1 -0
null+1 -0
null+1 -0
null+1 -0
null+1 -0
null+1 -0
null+66 -0
{
"ethereum": {
"roles": [],
"actors": [
{
"id": "EOA-1",
"name": "EOA 1",
"accounts": [
{
"address": "eth:0x8c5EE3f90cA6D24eD2e2c1817f0caEE89e521601",
"type": "EOA",
"isVerified": true,
"name": "0x8c5E…1601",
"url": "https://etherscan.io/address/0x8c5EE3f90cA6D24eD2e2c1817f0caEE89e521601",
"displayName": "EOA 1"
}
],
"chain": "ethereum",
"description": "* Can interact with Resolver\n * replace this Resolver as the ENS resolver of zk.money names, which decides the addresses that payments to these names resolve to \n* Can interact with NameRegistry\n * replace the RegistrationController and the AccountMetadataRegistry, and change the domainOwner. A new RegistrationController can reassign names and rewrite any user record, and a new AccountMetadataRegistry decides where future payments to zk.money names resolve to \n* Can interact with SIPAFactory\n * bless the deposit address implementation for any portal and intent that has none yet. This decides the code of all deposit addresses for that portal and intent ",
"discoveryDrivenData": true
},
{
"id": "EOA-2",
"name": "EOA 2",
"accounts": [
{
"address": "eth:0x768001056E4d89fd45Bf74Df3d91809F9BEb1ee1",
"type": "EOA",
"isVerified": true,
"name": "0x7680…1ee1",
"url": "https://etherscan.io/address/0x768001056E4d89fd45Bf74Df3d91809F9BEb1ee1",
"displayName": "EOA 2"
}
],
"chain": "ethereum",
"description": "* Can interact with NameRegistry\n * authorize or refuse every name claim and sign custom registration fees ",
"discoveryDrivenData": true
},
{
"id": "EOA-3-and-EOA-4",
"name": "EOA 3 and EOA 4",
"accounts": [
{
"address": "eth:0xdFd008642F54aCD44A2a03438A86A25f55c4D3Bc",
"type": "EOA",
"isVerified": true,
"name": "0xdFd0…D3Bc",
"url": "https://etherscan.io/address/0xdFd008642F54aCD44A2a03438A86A25f55c4D3Bc",
"displayName": "EOA 3"
},
{
"address": "eth:0xefc45B71e9432a6149a7d52f11a125A19E3A11DC",
"type": "EOA",
"isVerified": true,
"name": "0xefc4…11DC",
"url": "https://etherscan.io/address/0xefc45B71e9432a6149a7d52f11a125A19E3A11DC",
"displayName": "EOA 4"
}
],
"chain": "ethereum",
"description": "* Can interact with ZkMoneyPortal\n * co-sign withdrawals and refunds. Without a signature from a registered TEE signer, no funds can leave the portal ",
"discoveryDrivenData": true
}
]
}
}+328 -0
{
"addresses": {
"ethereum": [
{
"name": "NitroValidator",
"isVerified": true,
"address": "eth:0x0119bC52a09Ac6e7998378BadC16D0e9A866Be56",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Validates AWS Nitro enclave attestations against the certificate chain verified by the CertManager.\n",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x0119bC52a09Ac6e7998378BadC16D0e9A866Be56#code"
},
{
"name": "SwapEscrowFactory",
"isVerified": true,
"address": "eth:0x03b21BBa8e75A1BD0354c5ECbEC078cF59C85343",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Swap-on-withdraw: a withdrawal can pay DAI to a SwapEscrow clone whose route, recipient and tip are fixed in its address. Anyone can deploy and execute a funded clone to swap the DAI for USDC, USDT or ETH to the recipient.\n",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x03b21BBa8e75A1BD0354c5ECbEC078cF59C85343#code"
},
{
"name": "FrozenNotesRefundVerifier",
"isVerified": true,
"address": "eth:0x0694fF404DDA586C73EfCe21f34fe084541BB877",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "UltraHonk verifier for a zk.money circuit with a hardcoded verification key.\n",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x0694fF404DDA586C73EfCe21f34fe084541BB877#code"
},
{
"name": "RegistrationSIPA",
"isVerified": true,
"address": "eth:0x0934F010d59b552949DBe44AcBE5AFf0e32C8C34",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Implementation of zk.money registration addresses. Sweeping a funded clone registers the name through the current RegistrationController of the NameRegistry, pays the committed fees and deposits the rest into the PORTAL. The recipient's account can recover any funds from the clone.\n",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x0934F010d59b552949DBe44AcBE5AFf0e32C8C34#code"
},
{
"name": "RegistrationController",
"isVerified": true,
"address": "eth:0x10EB6fecD2DCE6DA55d25C355374c970D5D11E23",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Completes paid name registrations: deploys the user's L1 account, claims the name and writes the user record. Fees above the relayer fee go to an allowlisted beneficiary.\n",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x10EB6fecD2DCE6DA55d25C355374c970D5D11E23#code"
},
{
"name": "OxideAccountFactory",
"isVerified": true,
"address": "eth:0x187d19EccBf2909AD3d71B798A8704D950b9C3ee",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Permissionless factory for deterministic L1 accounts. The implementation is immutable and there is no administrator.\n",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x187d19EccBf2909AD3d71B798A8704D950b9C3ee#code"
},
{
"name": "Resolver",
"isVerified": true,
"address": "eth:0x3e9BcF7cCA4b94885aBEB9Bbf0005aA99DC6307F",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "ENS resolver for zk.money names. It returns a deposit address derived from a resolver operator's answer, which must come with a zk proof that it matches the user's registered keys and L2 address in the AccountMetadataRegistry.\n* Roles:\n * **ensNodeOwner**: EOA 1",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x3e9BcF7cCA4b94885aBEB9Bbf0005aA99DC6307F#code"
},
{
"name": "UnprocessedDepositRefundVerifier",
"isVerified": true,
"address": "eth:0x5C487AEb500BD0fE65fe52Be7e55a150c3220FA5",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "UltraHonk verifier for a zk.money circuit with a hardcoded verification key.\n",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x5C487AEb500BD0fE65fe52Be7e55a150c3220FA5#code"
},
{
"name": "FrozenDepositRefundVerifier",
"isVerified": true,
"address": "eth:0xa2fd594dCA2d598aF231d615E5D34903154C3cCe",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "UltraHonk verifier for a zk.money circuit with a hardcoded verification key.\n",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0xa2fd594dCA2d598aF231d615E5D34903154C3cCe#code"
},
{
"name": "NameRegistry",
"isVerified": true,
"address": "eth:0xa9863B8F573D62377d987ccb9AF6e0000f99D14a",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Registry of zk.money names. It points to the RegistrationController and the AccountMetadataRegistry, which together decide where payments to a zk.money name resolve to.\n* Roles:\n * **domainOwner**: EOA 2\n * **owner**: EOA 1",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0xa9863B8F573D62377d987ccb9AF6e0000f99D14a#code"
},
{
"name": "ResolverVerifier",
"isVerified": true,
"address": "eth:0xbF058D54c5033F4cB45c6E1Eba103CaeF232E451",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "UltraHonk verifier for a zk.money circuit with a hardcoded verification key.\n",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0xbF058D54c5033F4cB45c6E1Eba103CaeF232E451#code"
},
{
"name": "PlainWithdrawalExecutor",
"isVerified": true,
"address": "eth:0xC2363b7155EE8391C5395B72C46a6d22BF49151c",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Default payout contract for withdrawals and refunds. Only the PORTAL can call it. It pays the recipient and relayer tip committed on Aztec.\n",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0xC2363b7155EE8391C5395B72C46a6d22BF49151c#code"
},
{
"name": "SIPAFactory",
"isVerified": true,
"address": "eth:0xc357E34D4C7520a83C9Ec0a242Ba52b4ecABa1Fc",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Deploys zk.money deposit addresses (SIPAs) as deterministic clones. The implementation per portal and intent is blessed once by the owner and cannot be changed afterwards.\n* Roles:\n * **owner**: EOA 1",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0xc357E34D4C7520a83C9Ec0a242Ba52b4ecABa1Fc#code"
},
{
"name": "OxideAccount",
"isVerified": true,
"address": "eth:0xdA0D7cD0f49cE7b1D04bf03eE56374a8981c2844",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Immutable implementation of users' L1 accounts. The bootstrap key authorizes the first passkey. Once a passkey is installed, only the user's passkeys can authorize operations and manage keys. The last passkey cannot be removed. Deposit recovery checks signatures against this account.\n",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0xdA0D7cD0f49cE7b1D04bf03eE56374a8981c2844#code"
},
{
"name": "AccountMetadataRegistry",
"isVerified": true,
"address": "eth:0xDA79Bae4485c40291363D885Aae5B543d2D0Efa9",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Stores user records (Aztec L2 address, keys, chosen resolver operator) and resolver operator entries. User records can be written by the user or by the RegistrationController. Anyone can register as a resolver operator.\n",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0xDA79Bae4485c40291363D885Aae5B543d2D0Efa9#code"
},
{
"name": "ZkMoneyPortal",
"isVerified": true,
"address": "eth:0xdf410ad448A0f7165181FBdB32f8896f4a0d9449",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Escrow of zk.money on the Aztec Network. A withdrawal needs both a proven Aztec L2->L1 message from the zk.money L2 contract and a signature from a registered TEE signer. Anyone can register a TEE signer with a fresh AWS Nitro attestation of an approved enclave image. Once the Aztec Registry's canonical rollup is no longer ROLLUP, anyone can permanently freeze the portal, stopping deposits and fixing the refund snapshot at the last proven checkpoint. Withdrawals within the frozen checkpoint and epoch bounds remain available alongside refunds that need a zk proof and a TEE signature. L2 transfers are not disabled but do not change refundable ownership.\n* Roles:\n * **teeSigners**: EOA 3, EOA 4",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0xdf410ad448A0f7165181FBdB32f8896f4a0d9449#code"
},
{
"name": "CertManager",
"isVerified": true,
"address": "eth:0xdfe52FD98aa0Cc8Ce7778a2b00ac7B7Dc9595875",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Verifies and caches AWS Nitro attestation certificates. The only trust anchor is the hardcoded AWS Nitro root certificate.\n",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0xdfe52FD98aa0Cc8Ce7778a2b00ac7B7Dc9595875#code"
},
{
"name": "OperationExecutor",
"isVerified": true,
"address": "eth:0xe883686d9EC4E0430f2233A6BF12B2D226a39e19",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Permissionless helper that executes a call and forwards the resulting token payout to the caller. Used by finalizers to collect fees and subsidies.\n",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0xe883686d9EC4E0430f2233A6BF12B2D226a39e19#code"
},
{
"name": "SwapEscrow",
"isVerified": true,
"address": "eth:0xf16Fd140036925e3a0630d0F743204a4c7d8ccaf",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "SwapEscrow implementation. A clone swaps via the Curve 3pool (and Uniswap for ETH) with a slippage bound of 100 bps for stablecoins and 200 bps against the Chainlink ETH/USD price for ETH. If the swap cannot execute, only the recovery key committed in the clone's address can move the funds.\n",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0xf16Fd140036925e3a0630d0F743204a4c7d8ccaf#code"
},
{
"name": "DepositSIPA",
"isVerified": true,
"address": "eth:0xF714D8Cf287F4A410b018514074A9371BC45461b",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Implementation of zk.money deposit addresses. Anyone can sweep a funded clone, which swaps USDC or USDT to DAI, pays DEPOSIT_FEE to the relayer and deposits the rest into the PORTAL for the recipient fixed in the clone's address. The recipient's account can recover any funds from the clone.\n",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0xF714D8Cf287F4A410b018514074A9371BC45461b#code"
},
{
"name": "FPCFunderDAI",
"isVerified": true,
"address": "eth:0x37cD81C39Bf276ea7e1c6a416A254f688c70eAFb",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Collects the portal's funding cut. Anyone can swap it to AZTEC and bridge it as Fee Juice to the zk.money fee-paying contract on Aztec (L2_BENEFICIARY), which pays L2 fees for users.\n",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x37cD81C39Bf276ea7e1c6a416A254f688c70eAFb#code"
}
]
},
"risks": [],
"zkVerifiers": [
"eth:0x0694fF404DDA586C73EfCe21f34fe084541BB877",
"eth:0xa2fd594dCA2d598aF231d615E5D34903154C3cCe",
"eth:0x5C487AEb500BD0fE65fe52Be7e55a150c3220FA5",
"eth:0xbF058D54c5033F4cB45c6E1Eba103CaeF232E451"
]
}+7 -0
{
"baseTimestamp": 1790840907,
"contractsDiscoDriven": false,
"hasDiscoUi": false,
"isDiscoDriven": false,
"permissionsDiscoDriven": false
}+16 -0
[
{
"id": "1225e8f9",
"date": "Thu, 01 Oct 2026 07:49:42 GMT",
"timestamp": 1790840907,
"description": "Initial full discovery of zk.money.",
"isHighSeverity": false,
"changeCount": 21,
"sections": [
{
"kind": "initial-discovery",
"body": "```diff\n+ Status: CREATED\n contract NitroValidator (eth:0x0119bC52a09Ac6e7998378BadC16D0e9A866Be56) [zkmoney/NitroValidator]\n +++ description: Validates AWS Nitro enclave attestations against the certificate chain verified by the CertManager.\n```\n\n```diff\n+ Status: CREATED\n contract SwapEscrowFactory (eth:0x03b21BBa8e75A1BD0354c5ECbEC078cF59C85343) [zkmoney/SwapEscrowFactory]\n +++ description: Swap-on-withdraw: a withdrawal can pay DAI to a SwapEscrow clone whose route, recipient and tip are fixed in its address. Anyone can deploy and execute a funded clone to swap the DAI for USDC, USDT or ETH to the recipient.\n```\n\n```diff\n+ Status: CREATED\n contract FrozenNotesRefundVerifier (eth:0x0694fF404DDA586C73EfCe21f34fe084541BB877) [zkmoney/HonkVerifier]\n +++ description: UltraHonk verifier for a zk.money circuit with a hardcoded verification key.\n```\n\n```diff\n+ Status: CREATED\n contract RegistrationSIPA (eth:0x0934F010d59b552949DBe44AcBE5AFf0e32C8C34) [zkmoney/RegistrationSIPA]\n +++ description: Implementation of zk.money registration addresses. Sweeping a funded clone registers the name through the current RegistrationController of the NameRegistry, pays the committed fees and deposits the rest into the PORTAL. The recipient's account can recover any funds from the clone.\n```\n\n```diff\n+ Status: CREATED\n contract RegistrationController (eth:0x10EB6fecD2DCE6DA55d25C355374c970D5D11E23) [zkmoney/RegistrationController]\n +++ description: Completes paid name registrations: deploys the user's L1 account, claims the name and writes the user record. Fees above the relayer fee go to an allowlisted beneficiary.\n```\n\n```diff\n+ Status: CREATED\n contract OxideAccountFactory (eth:0x187d19EccBf2909AD3d71B798A8704D950b9C3ee) [zkmoney/OxideAccountFactory]\n +++ description: Permissionless factory for deterministic L1 accounts. The implementation is immutable and there is no administrator.\n```\n\n```diff\n+ Status: CREATED\n contract FPCFunderDAI (eth:0x37cD81C39Bf276ea7e1c6a416A254f688c70eAFb) [zkmoney/FPCFunderDAI]\n +++ description: Collects the portal's funding cut. Anyone can swap it to AZTEC and bridge it as Fee Juice to the zk.money fee-paying contract on Aztec (L2_BENEFICIARY), which pays L2 fees for users.\n```\n\n```diff\n+ Status: CREATED\n contract Resolver (eth:0x3e9BcF7cCA4b94885aBEB9Bbf0005aA99DC6307F) [zkmoney/Resolver]\n +++ description: ENS resolver for zk.money names. It returns a deposit address derived from a resolver operator's answer, which must come with a zk proof that it matches the user's registered keys and L2 address in the AccountMetadataRegistry.\n```\n\n```diff\n+ Status: CREATED\n contract UnprocessedDepositRefundVerifier (eth:0x5C487AEb500BD0fE65fe52Be7e55a150c3220FA5) [zkmoney/HonkVerifier]\n +++ description: UltraHonk verifier for a zk.money circuit with a hardcoded verification key.\n```\n\n```diff\n+ Status: CREATED\n contract FrozenDepositRefundVerifier (eth:0xa2fd594dCA2d598aF231d615E5D34903154C3cCe) [zkmoney/HonkVerifier]\n +++ description: UltraHonk verifier for a zk.money circuit with a hardcoded verification key.\n```\n\n```diff\n+ Status: CREATED\n contract NameRegistry (eth:0xa9863B8F573D62377d987ccb9AF6e0000f99D14a) [zkmoney/NameRegistry]\n +++ description: Registry of zk.money names. It points to the RegistrationController and the AccountMetadataRegistry, which together decide where payments to a zk.money name resolve to.\n```\n\n```diff\n+ Status: CREATED\n contract ResolverVerifier (eth:0xbF058D54c5033F4cB45c6E1Eba103CaeF232E451) [zkmoney/HonkVerifier]\n +++ description: UltraHonk verifier for a zk.money circuit with a hardcoded verification key.\n```\n\n```diff\n+ Status: CREATED\n contract PlainWithdrawalExecutor (eth:0xC2363b7155EE8391C5395B72C46a6d22BF49151c) [zkmoney/PlainWithdrawalExecutor]\n +++ description: Default payout contract for withdrawals and refunds. Only the PORTAL can call it. It pays the recipient and relayer tip committed on Aztec.\n```\n\n```diff\n+ Status: CREATED\n contract SIPAFactory (eth:0xc357E34D4C7520a83C9Ec0a242Ba52b4ecABa1Fc) [zkmoney/SIPAFactory]\n +++ description: Deploys zk.money deposit addresses (SIPAs) as deterministic clones. The implementation per portal and intent is blessed once by the owner and cannot be changed afterwards.\n```\n\n```diff\n+ Status: CREATED\n contract OxideAccount (eth:0xdA0D7cD0f49cE7b1D04bf03eE56374a8981c2844) [zkmoney/OxideAccount]\n +++ description: Immutable implementation of users' L1 accounts. The bootstrap key authorizes the first passkey. Once a passkey is installed, only the user's passkeys can authorize operations and manage keys. The last passkey cannot be removed. Deposit recovery checks signatures against this account.\n```\n\n```diff\n+ Status: CREATED\n contract AccountMetadataRegistry (eth:0xDA79Bae4485c40291363D885Aae5B543d2D0Efa9) [zkmoney/AccountMetadataRegistry]\n +++ description: Stores user records (Aztec L2 address, keys, chosen resolver operator) and resolver operator entries. User records can be written by the user or by the RegistrationController. Anyone can register as a resolver operator.\n```\n\n```diff\n+ Status: CREATED\n contract ZkMoneyPortal (eth:0xdf410ad448A0f7165181FBdB32f8896f4a0d9449) [zkmoney/ZkMoneyPortal]\n +++ description: Escrow of zk.money on the Aztec Network. A withdrawal needs both a proven Aztec L2->L1 message from the zk.money L2 contract and a signature from a registered TEE signer. Anyone can register a TEE signer with a fresh AWS Nitro attestation of an approved enclave image. Once the Aztec Registry's canonical rollup is no longer ROLLUP, anyone can permanently freeze the portal, stopping deposits and fixing the refund snapshot at the last proven checkpoint. Withdrawals within the frozen checkpoint and epoch bounds remain available alongside refunds that need a zk proof and a TEE signature. L2 transfers are not disabled but do not change refundable ownership.\n```\n\n```diff\n+ Status: CREATED\n contract CertManager (eth:0xdfe52FD98aa0Cc8Ce7778a2b00ac7B7Dc9595875) [zkmoney/CertManager]\n +++ description: Verifies and caches AWS Nitro attestation certificates. The only trust anchor is the hardcoded AWS Nitro root certificate.\n```\n\n```diff\n+ Status: CREATED\n contract OperationExecutor (eth:0xe883686d9EC4E0430f2233A6BF12B2D226a39e19) [zkmoney/OperationExecutor]\n +++ description: Permissionless helper that executes a call and forwards the resulting token payout to the caller. Used by finalizers to collect fees and subsidies.\n```\n\n```diff\n+ Status: CREATED\n contract SwapEscrow (eth:0xf16Fd140036925e3a0630d0F743204a4c7d8ccaf) [zkmoney/SwapEscrow]\n +++ description: SwapEscrow implementation. A clone swaps via the Curve 3pool (and Uniswap for ETH) with a slippage bound of 100 bps for stablecoins and 200 bps against the Chainlink ETH/USD price for ETH. If the swap cannot execute, only the recovery key committed in the clone's address can move the funds.\n```\n\n```diff\n+ Status: CREATED\n contract DepositSIPA (eth:0xF714D8Cf287F4A410b018514074A9371BC45461b) [zkmoney/DepositSIPA]\n +++ description: Implementation of zk.money deposit addresses. Anyone can sweep a funded clone, which swaps USDC or USDT to DAI, pays DEPOSIT_FEE to the relayer and deposits the rest into the PORTAL for the recipient fixed in the clone's address. The recipient's account can recover any funds from the clone.\n```"
}
]
}
]+107 -0
{
"changes": [],
"contracts": [
{
"name": "RegistrationSIPA",
"address": "eth:0x0934F010d59b552949DBe44AcBE5AFf0e32C8C34",
"isVerified": true,
"ossifyingSince": 1790298731,
"codeChangeCount": 0,
"stateChangeCount": 0
},
{
"name": "PlainWithdrawalExecutor",
"address": "eth:0xC2363b7155EE8391C5395B72C46a6d22BF49151c",
"isVerified": true,
"ossifyingSince": 1790298707,
"codeChangeCount": 0,
"stateChangeCount": 0
},
{
"name": "DepositSIPA",
"address": "eth:0xF714D8Cf287F4A410b018514074A9371BC45461b",
"isVerified": true,
"ossifyingSince": 1790298659,
"codeChangeCount": 0,
"stateChangeCount": 0
},
{
"name": "ZkMoneyPortal",
"address": "eth:0xdf410ad448A0f7165181FBdB32f8896f4a0d9449",
"isVerified": true,
"ossifyingSince": 1790298635,
"codeChangeCount": 0,
"stateChangeCount": 0
},
{
"name": "UnprocessedDepositRefundVerifier",
"address": "eth:0x5C487AEb500BD0fE65fe52Be7e55a150c3220FA5",
"isVerified": true,
"ossifyingSince": 1790298623,
"codeChangeCount": 0,
"stateChangeCount": 0
},
{
"name": "FrozenNotesRefundVerifier",
"address": "eth:0x0694fF404DDA586C73EfCe21f34fe084541BB877",
"isVerified": true,
"ossifyingSince": 1790298599,
"codeChangeCount": 0,
"stateChangeCount": 0
},
{
"name": "FrozenDepositRefundVerifier",
"address": "eth:0xa2fd594dCA2d598aF231d615E5D34903154C3cCe",
"isVerified": true,
"ossifyingSince": 1790298575,
"codeChangeCount": 0,
"stateChangeCount": 0
},
{
"name": "SIPAFactory",
"address": "eth:0xc357E34D4C7520a83C9Ec0a242Ba52b4ecABa1Fc",
"isVerified": true,
"ossifyingSince": 1790298491,
"codeChangeCount": 0,
"stateChangeCount": 0
},
{
"name": "ResolverVerifier",
"address": "eth:0xbF058D54c5033F4cB45c6E1Eba103CaeF232E451",
"isVerified": true,
"ossifyingSince": 1789423367,
"codeChangeCount": 0,
"stateChangeCount": 0
},
{
"name": "NitroValidator",
"address": "eth:0x0119bC52a09Ac6e7998378BadC16D0e9A866Be56",
"isVerified": true,
"ossifyingSince": 1787140391,
"codeChangeCount": 0,
"stateChangeCount": 0
},
{
"name": "CertManager",
"address": "eth:0xdfe52FD98aa0Cc8Ce7778a2b00ac7B7Dc9595875",
"isVerified": true,
"ossifyingSince": 1787140391,
"codeChangeCount": 0,
"stateChangeCount": 0
}
],
"observedSince": 1787140391,
"resets": [
1787140391,
1787140391,
1789423367,
1790298491,
1790298575,
1790298599,
1790298623,
1790298635,
1790298659,
1790298707,
1790298731
]
}+1 -0
null+1 -0
null