Search for projects and tokens by name or address
Both portals are frozen since Aztec made its v6 rollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign rollup. canonical, and deposits revert. Balances leave only through refunds. The released wallet refunds into a zk.money deployment on Aztec v6.
A shielded ledger on Aztec Network for DAI payments and sUSDS savings, with funds escrowed on Ethereum.
A shielded ledger on Aztec Network for DAI payments and sUSDS savings, with funds escrowed on Ethereum.
zk.money lets users send DAI privately on Aztec and move it into sUSDS savings. Funds are escrowed on Ethereum. Names, deposits and withdrawals are public.
Every withdrawal and refund needs a zk proof and a signature from a live AWS Nitro enclave (TEE). Each pool’s enclave decrypts and reads the operations it handles. Aztec Labs controls names and the contract lists the released wallets use.
The portal releases funds only after Aztec proves the withdrawal message and one registered enclave signer co-signs it. Stealing escrowed funds requires both layers to fail, while a failure of either breaks privacy.
Accounts sign with a passkey. The released wallet requires a registered name to access an account on a new device.
The privacy ratings cover DAI payments and sUSDS savings in zk.money Desktop v0.5.0.
The Desktop release runs local code. Its endpoint settings accept the user’s own Aztec nodeA software client that participates in the network., Ethereum endpoint and DAI enclave. The sUSDS enclave address is always fetched from Aztec Labs among other addresses in two unsigned contract lists. Replacing them can redirect future deposits and payments.
The hosted wallet reloads code on every visit. Its owner can read viewing keys and request harmful passkey signatures through misleading prompts.
Independent operation remains untested. It requires a modified Desktop build without screening, pointed at self-hosted contract lists. Users would submit Ethereum transactions themselves and register an approved enclave on AWS. New names still require Aztec Labs’ signature. The enclave guide describes image downloads and registration.
Savings hold sUSDS in a second portal with its own L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. token and enclave. A move in withdraws DAI to a deterministic SkyEscrow, which converts it through USDS into sUSDS shares and deposits them into the sUSDS portal. A move out reverses both legs into the DAI portal. Each move publishes its DAI and share amounts, tied by the escrow. The wallet moves sUSDS only to and from the user’s own DAI balance.
Tags such as l2beat.zk.money publish Aztec addresses and keys on Ethereum.
Name claims need the domain owner’s signature. XMTP, an encrypted offchain messaging networkA constellation of nodes (peers) that communicate via a peer-to-peer protocol, for example, in propagating transactions and blocks to other nodes., powers QR-code or link contacts and carries payment requests.
For ENS lookups, the resolver operator derives each deposit address from a secret shared with the recipient and announces it to them on L2. The assessed wallet can derive its own deposit addresses privately. The onchain Resolver checks a zk proof on every lookup, which stops the operator from redirecting payments. Users can choose a custom operator for name payments.
Refund. If Aztec Network governance changes its canonical rollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign rollup., anyone can freeze the portal, see upgrades and governance. Refunds then publish note or deposit amounts on Ethereum and use proofs without zero knowledge.
The assessed wallet sends Ethereum addresses to Predicate through zk.money for screening, which funding a deposit SIPA directly avoids. The relayer screens token movements against OFAC and optionally Predicate, and self-submitted sweeps and withdrawals skip it.
The name resolver screens deposit addresses and funders against OFAC before notifying the recipient on L2. A blocked payment leaves funds at an address unknown to the wallet. Recovery requires the recipient’s own tooling to re-derive it and authorization from their L1 account. Screening happens only in these offchain services.
A DAI sweep pays 0.25 DAI, or 0.5 DAI when claiming a name. Registration costs 5 DAI by default, including its sweep fee.
The DAI portal takes 0.1 DAI from deposits and ordinary withdrawals to sponsor Aztec fees. The sUSDS portal takes 0 sUSDS.
Gas sponsorship needs a registered name or a voucher from a registered account. An empty fee-paying contract, or fees above its allowance, stall the assessed wallet. Modified code can pay with the account’s own Fee Juice.
DAI deposits share 50,000 DAI of capacity, refilling over 1 day. sUSDS deposits share 50,000 sUSDS, refilling over 1 day.
DAI deposits, payments and withdrawals are capped at 2,583 DAI each. sUSDS deposits and withdrawals are capped at 2,583 sUSDS each.
The token verification steps compare a fresh source build with the DAI and sUSDS L2 contracts pinned by their Ethereum portals. The verifier steps regenerate the keys and Solidity verifiers of the refund and resolver circuits.
What the protocol promises: Hides senders, amounts and the link between deposits and withdrawals inside the ledger. Names, deposits and withdrawals are public.
Ethereum is public by default. Each protocol is rated on its main privacy promise, like hiding who paid, who received, how much, or which deposit became which withdrawal. Against each adversary, the colour says whether it holds for a careful user with the app's own settings: green yes, yellow only with significant extra work, red no. Fields marked at risk stay private only under the condition in their note.
Private payments publish encrypted notes. Claiming a name ties it and its Aztec address to the wallet that funds the registration. The first payment to a new contact reveals the recipient through a handshake, and L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. logs mark every transaction of the shared token smart contract. The user’s first sponsored transaction after registration is tied to their account, with the payment, deposit address or withdrawal it carries.
Advice: Claim the user's name from a wallet without a public link to them, then make the first transaction after registration a deposit from that wallet. Fund each deposit address once and let it be swept/relayed.
In practice the anonymity setIn privacy protocols, anonymity set denotes all users, to which a particular withdrawal could be plausibly attributed. Anonymity set depends on a particular withdrawal, the size of the anonymity set is a metric for level of user's privacy. is zk.money’s users on Aztec, although the L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. contract is permissionlessAnyone willing should be able to join and leave the network at any time, without causing significant disturbance to the network or being detrimental to the party in question. No single entity should have the power to allowlist or blocklist participants.. The first payment to a name from outside zk.money is publicly tied to that name. A payee can tell which payments come from the same payer, since each pair shares one secret for tagging notes. Moving a whole savings position out republishes the share amount it went in with.
Advice: Give outside payers a deposit address the user's wallet created. 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.
Alchemy, called under Aztec Labs’ key, sees an account’s deposit addresses and withdrawals in one session unless the user sets their own Ethereum nodeA software client that participates in the network.. Desktop has no Tor setting. Routing all of the computer’s traffic through Tor works, but Chrome’s QUIC traffic to WalletConnect bypasses Tor unless UDP is blocked.
Advice: Set your own Ethereum node as the L1 endpoint, and run Desktop on a system that sends all traffic through Tor and blocks UDP, such as Whonix.
An AWS Nitro enclave reads payments, withdrawals and deposit claims inside. The portal admits only enclaves whose attestation it verifies onchain and approved enclave images are immutable. The sUSDS portal’s approved image is unpublished, as is its source. Aztec Labs’ default Aztec nodeA software client that participates in the network., like Alchemy under its key, sees an account’s deposit addresses and withdrawals in one session. The resolver operatorAn operator is the entity charged with managing a rollup and progressing its state. A rollup operator can be a centralized sequencer, proposer, prover, challenger, pauser of admin that is able to perform upgrades., Aztec Labs today, derives each deposit address paid through a name, so it knows the recipient.
Advice: Set your own Aztec node and Ethereum node in the endpoint settings, and keep funds out of savings.
Whoever breaks elliptic-curve cryptography can decrypt historical notes and payment events published to Ethereum. Registered Aztec addresses identify the accounts. Deposit addresses paid through a name and enclave communication use the same class of cryptography.
How many unique depositors you could have blended in with if you withdrew on a particular day after depositing during the previous 30 days. This metric is a proxy for the historic anonymity set and shows how it developed over time.
The metric looks backwards: it counts deposits that already happened, including from addresses that have since withdrawn. Your real anonymity also depends on deposits made after yours, which cannot be known in advance.
An estimate of how many unique depositors you blend in with, depending on how long you leave your deposit in the pool. It is based on historic data of past deposits: each point counts depositors from the preceding period, so holding for up to 30 days effectively means blending in with everyone who deposited during the last 30 days.
Asset | Deposits 7D | Deposits 30D | Deposits Total | Value Locked |
|---|---|---|---|---|
DAI | 89 $32.04 K | 1.11 K $188.83 K | 1.12 K $188.88 K | $44.05 K |
| Total | 89 $32.04 K | 1.11 K $188.83 K | 1.12 K $188.88 K | $44.05 K |
zk.money relaunches on Aztec
2026 Sep 29th
Aztec Labs relaunches zk.money as a private DAI wallet on the Aztec networkA constellation of nodes (peers) that communicate via a peer-to-peer protocol, for example, in propagating transactions and blocks to other nodes..
Aztec NetworkA constellation of nodes (peers) that communicate via a peer-to-peer protocol, for example, in propagating transactions and blocks to other nodes.’s rollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign rollup. and zk.money’s portals and payout contracts are immutable.
Anyone can register a signer with an AWS Nitro attestation up to 1 hour old. DAI has 2 registered signers, and sUSDS has 3. Both portals are frozen permanently, and no party can undo the freeze.
Two Aztec Labs EOAs control *.zk.money names. The deployer owns the NameRegistry and can replace its registration, metadata and resolver contracts, which lets it reassign names and redirect future payments. It also owns zk.money in ENS, which the DNS holder can reclaim. The domain owner can refuse claims, sign custom fees and add permanent fee beneficiaries, which users pick from in their registration intent. Aztec Labs also controls the hosted wallet, the desktop releases and the two unsigned contract lists both wallets currently use.
Sky governance can upgrade sUSDS, changing balances and transfer rules. Its authorized rate controller can change the savings rate.
Aztec Ignition is a trusted setupGeneration of a piece of data that must then be used for some cryptographic protocol to run. Generating this data requires some secret information. The "trust" comes from the fact the secret must be destroyed after the ceremony, otherwise cryptographic properties of the protocol could be broken. Once the data is generated, and the secrets are forgotten, no further participation from the creators of the ceremony is required. There are two types of trusted setups for SNARKs: (i) trusted setup per circuit where it is generated from scratch for each circuit, (ii) trusted universal setup per proving system where it can be used for several circuits. ceremony for KZG commitmentsA polynomial commitment scheme that allows a prover to compute a commitment to a polynomial, with the properties that this commitment can later be opened at any position: the prover shows that the value of the polynomial at a certain position is equal to a claimed value. KZG is widely used as it’s applicable both for univariate and k-variate polynomials, is efficient for batch proofs, and is able to generate many proofs at once relatively fast. It is also proof generation time efficient: the time for prover to commit to a polynomial is linear on the degree of the polynomial. over BN254 curve that was run by Aztec for KZG commitment over BN254 curve in 2019. It included 176 participants and was publicly open for participation.
Contracts our research team classifies as critical form the project's critical perimeter. Its clock starts at the ossification genesis, and every critical change resets it (changes within 24 hours count as one). The ossification score is the share of recorded code-bug exploits whose exploited code was younger than this perimeter is today. Battle-tested exposure is the value secured, summed over that unchanged period.
Both portals were frozen right after Aztec made its v6 rollup canonical, at proven v5 checkpoint 118925. Deposits revert, and only withdrawals proven by then still pay out. Funds leave through refunds that prove notes or deposits against the frozen state, need a registered enclave signature and publish their total. Payments on Aztec v5 after the freeze do not change who can refund a note. No zk.money deployment on Aztec v6 exists yet.
Both portals were frozen right after Aztec made its v6 rollup canonical, at proven v5 checkpoint 118925. Deposits revert, and only withdrawals proven by then still pay out. Funds leave through refunds that prove notes or deposits against the frozen state, need a registered enclave signature and publish their total. Payments on Aztec v5 after the freeze do not change who can refund a note. No zk.money deployment on Aztec v6 exists yet.
| contract ZkMoneyPortal_sUSDS (eth:0xD7Ae00b91ba0B8e0240B22Cd75fE447d177C260f) [zkmoney/ZkMoneyPortal] { | |
| +++ 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. | |
| values._$freezeArchive: | |
| - | "0x0000000000000000000000000000000000000000000000000000000000000000" |
| + | "0x103a50a830507b89a1c34cafa4060a839d437f85df3c63e0e8e6b3f832c545d7" |
| values._$freezeCheckpointNumber: | |
| - | 0 |
| + | 118925 |
| values._$freezeEpochNumber: | |
| - | 0 |
| + | 4426 |
| +++ 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. | |
| +++ severity: MEDIUM | |
| values._$frozen: | |
| - | false |
| + | true |
| } | |
| contract ZkMoneyPortal (eth:0xdf410ad448A0f7165181FBdB32f8896f4a0d9449) [zkmoney/ZkMoneyPortal] { | |
| +++ 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. | |
| values._$freezeArchive: | |
| - | "0x0000000000000000000000000000000000000000000000000000000000000000" |
| + | "0x103a50a830507b89a1c34cafa4060a839d437f85df3c63e0e8e6b3f832c545d7" |
| values._$freezeCheckpointNumber: | |
| - | 0 |
| + | 118925 |
| values._$freezeEpochNumber: | |
| - | 0 |
| + | 4426 |
| +++ 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. | |
| +++ severity: MEDIUM | |
| values._$frozen: | |
| - | false |
| + | true |
| } | |
Add SwapEscrowFactoryV2 and its SwapEscrowV2 implementation, which zk.money Desktop v0.5.0 uses for swap and fresh-address withdrawals.
Add SwapEscrowFactoryV2 and its SwapEscrowV2 implementation, which zk.money Desktop v0.5.0 uses for swap and fresh-address withdrawals.
| + | Status: CREATED |
| contract SwapEscrowFactoryV2 (eth:0x3B5D8c731364902eAFa46Be327AFB044C10c5952) [zkmoney/SwapEscrowFactoryV2] | |
| +++ description: Swap-on-withdraw: a withdrawal can pay DAI to a SwapEscrowV2 clone whose route, recipient, gas share and tip are fixed in its address. Anyone can deploy and execute a funded clone to pay USDC, USDT, ETH or DAI to the recipient. | |
| + | Status: CREATED |
| contract SwapEscrowV2 (eth:0xcfAf1DFc22CE92cf3F2b534b3b5C1F116028FB95) [zkmoney/SwapEscrowV2] | |
| +++ description: SwapEscrowV2 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. It can first swap a capped share of the DAI to ETH for the recipient's gas. If the swap cannot execute, only the recovery key committed in the clone's address can move the funds. | |
Track verifier key hashes and linked proof-verification libraries, add sUSDS escrow. Move ENS handlers and refund-library criticality into templates.
Track verifier key hashes and linked proof-verification libraries, add sUSDS escrow. Move ENS handlers and refund-library criticality into templates.
| contract SkyEscrowFactory (eth:0x9c4A7d65AFDC2b4eF1164264D9585ED64c869054) [zkmoney/SkyEscrowFactory] { | |
| +++ description: Deploys deterministic escrows for moving funds between the DAI and sUSDS portals. Anyone can execute a funded escrow. Its implementation and routes are immutable. | |
| type: | |
| - | "EOA" |
| + | "Contract" |
| proxyType: | |
| - | "EOA" |
| + | "immutable" |
| name: | |
| + | "SkyEscrowFactory" |
| template: | |
| + | "zkmoney/SkyEscrowFactory" |
| sourceHashes: | |
| + | ["0x186505f8f56ecd35908cef522d33f5658860e763137cb5c6d3bb0e206ac03742"] |
| description: | |
| + | "Deploys deterministic escrows for moving funds between the DAI and sUSDS portals. Anyone can execute a funded escrow. Its implementation and routes are immutable." |
| deployerAddress: | |
| + | "eth:0xa3533FD3dAC685D54df722B970772b54128a717C" |
| sinceTimestamp: | |
| + | 1791329267 |
| sinceBlock: | |
| + | 26136622 |
| values: | |
| + | {"$immutable":true,"DAI":"eth:0x6B175474E89094C44Da98b954EedeAC495271d0F","DAI_PORTAL":"eth:0xdf410ad448A0f7165181FBdB32f8896f4a0d9449","IMPLEMENTATION":"eth:0x5C412Ba5B338F3e5E2a1332069bdd3Aae6ae6b8a","SKY_EXECUTOR":"eth:0x63e6cD9Ff886cFF198Eaaab01CeC2b707E7F5475","SUSDS":"eth:0xa3931d71877C0E7a3148CB7Eb4463524FEc27fbD","SUSDS_PORTAL":"eth:0xD7Ae00b91ba0B8e0240B22Cd75fE447d177C260f"} |
| implementationNames: | |
| + | {"eth:0x9c4A7d65AFDC2b4eF1164264D9585ED64c869054":"SkyEscrowFactory"} |
| category: | |
| + | {"name":"Local Infrastructure","priority":5} |
| } | |
| contract ZkMoneyPortal_sUSDS (eth:0xD7Ae00b91ba0B8e0240B22Cd75fE447d177C260f) [zkmoney/ZkMoneyPortal] { | |
| +++ 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. | |
| type: | |
| - | "EOA" |
| + | "Contract" |
| proxyType: | |
| - | "EOA" |
| + | "immutable" |
| template: | |
| + | "zkmoney/ZkMoneyPortal" |
| sourceHashes: | |
| + | ["0x7020e3729f66f6c8ddada17eeb82b33ae8b7f623c0ffb3bb6c921bf966a7f6a8"] |
| 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." |
| critical: | |
| + | true |
| deployerAddress: | |
| + | "eth:0xa3533FD3dAC685D54df722B970772b54128a717C" |
| sinceTimestamp: | |
| + | 1791316739 |
| sinceBlock: | |
| + | 26135579 |
| values: | |
| + | {"_$cachedAvailable":"49997504449688617568427","_$freezeArchive":"0x0000000000000000000000000000000000000000000000000000000000000000","_$freezeCheckpointCount":0,"_$freezeCheckpointNumber":0,"_$freezeEpochNumber":0,"_$frozen":false,"_$initialized":true,"_$l2Portal":"0x2bb708cb67bbda3ec2c79b842ef5d3b3d55897663d29cac5b5518c2e9af7171b","_$lastUpdatedTime":1791874367,"$immutable":true,"approvedPcr0Hashes":["0xbfdd552587f517a9f18ef6ed588e3bd57a21ac2070fda39ac4612558df3e72c8"],"FPC_FUNDER":"eth:0x37cD81C39Bf276ea7e1c6a416A254f688c70eAFb","FPC_FUNDING_CUT":0,"FROZEN_DEPOSIT_REFUND_VERIFIER":"eth:0x2E0C30821b9fcCf1CDB47F4e3a3A993593344522","FROZEN_NOTES_REFUND_VERIFIER":"eth:0xd24a49321878AB82E46992ab853A11903882abf2","getCurrentAvailable":"50000000000000000000000","GLOBAL_LIMIT":"50000000000000000000000","INBOX":"eth:0x7d4Ef0676c2032bbCC09227501D34d86641ab8cA","L2_PORTAL":"0x2bb708cb67bbda3ec2c79b842ef5d3b3d55897663d29cac5b5518c2e9af7171b","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:0x367eD02480809f5020234181B61D9069a08974dD","eth:0x5F03984126AdFDb72B2823b553988Ccebe1F781e","eth:0x05406F53174EC1bFE5C94aF253CdD62A4adF2F29"],"UNDERLYING":"eth:0xa3931d71877C0E7a3148CB7Eb4463524FEc27fbD","UNPROCESSED_DEPOSIT_REFUND_VERIFIER":"eth:0x8ACcBa3958cEF8E30b255c70A4C16CD2D14fb787"} |
| fieldMeta: | |
| + | {"owner":{"severity":"MEDIUM"},"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":{"description":"zk.money token contract on Aztec whose L2->L1 messages can release funds."},"_$frozen":{"severity":"MEDIUM","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"}} |
| implementationNames: | |
| + | {"eth:0xD7Ae00b91ba0B8e0240B22Cd75fE447d177C260f":"OxidePortal"} |
| category: | |
| + | {"name":"Local Infrastructure","priority":5} |
| } | |
| + | Status: CREATED |
| contract RelationsLib (eth:0x1ab8c7439B47B474d72963076aB1C8C944750241) [zkmoney/RefundRelationsLib] | |
| +++ description: Library immutably linked into a zk.money refund verifier. It evaluates the UltraHonk circuit constraints during proof verification. | |
| + | Status: CREATED |
| contract FrozenDepositRefundVerifier_sUSDS (eth:0x2E0C30821b9fcCf1CDB47F4e3a3A993593344522) [zkmoney/FrozenDepositRefundVerifier] | |
| +++ description: UltraHonk verifier for refunds of deposits included in Aztec's frozen message tree but still unclaimed. Its verification key is immutable. | |
| + | Status: CREATED |
| contract RelationsLib (eth:0x567771A39903323B81E18b388372897FdAd6338C) [zkmoney/RefundRelationsLib] | |
| +++ description: Library immutably linked into a zk.money refund verifier. It evaluates the UltraHonk circuit constraints during proof verification. | |
| + | Status: CREATED |
| contract SkyEscrow (eth:0x5C412Ba5B338F3e5E2a1332069bdd3Aae6ae6b8a) [zkmoney/SkyEscrow] | |
| +++ description: Implementation for savings conversion escrows. Each clone fixes the route, deposit commitment, relayer tip and recovery commitment in its address. It converts DAI into sUSDS or redeposits DAI after a savings withdrawal. The recovery account can reclaim stranded tokens, including shares taken without redemption. | |
| + | Status: CREATED |
| contract SkyWithdrawalExecutor (eth:0x63e6cD9Ff886cFF198Eaaab01CeC2b707E7F5475) [zkmoney/SkyWithdrawalExecutor] | |
| +++ description: Payout contract for sUSDS withdrawals and refunds. Only the PORTAL can execute a payout. It normally redeems sUSDS into USDS and converts USDS to DAI before paying the committed recipient and relayer tip. The recipient can complete an ordinary withdrawal in sUSDS shares through withdrawInShares, bypassing redemption. | |
| + | Status: CREATED |
| contract RelationsLib (eth:0x871Af018DeD698d9753766D41Dbc80B777944263) [zkmoney/RefundRelationsLib] | |
| +++ description: Library immutably linked into a zk.money refund verifier. It evaluates the UltraHonk circuit constraints during proof verification. | |
| + | Status: CREATED |
| contract UnprocessedDepositRefundVerifier_sUSDS (eth:0x8ACcBa3958cEF8E30b255c70A4C16CD2D14fb787) [zkmoney/UnprocessedDepositRefundVerifier] | |
| +++ description: UltraHonk verifier for refunds of deposits not absorbed into Aztec before the zk.money portal froze. Its verification key is immutable. | |
| + | Status: CREATED |
| contract FrozenNotesRefundVerifier_sUSDS (eth:0xd24a49321878AB82E46992ab853A11903882abf2) [zkmoney/FrozenNotesRefundVerifier] | |
| +++ description: UltraHonk verifier for refunds of notes that were unspent when the zk.money portal froze. Its verification key is immutable. | |
| + | Status: CREATED |
| contract RelationsLib (eth:0x02353dB283087CD51b13eE088A615Dad03949070) [zkmoney/ResolverVerifierLibrary] | |
| +++ description: Runtime library immutably linked into the zk.money resolver verifier. It evaluates circuit constraints or derives Fiat-Shamir challenges for zero-knowledge UltraHonk proofs. | |
| + | Status: CREATED |
| contract RelationsLib (eth:0x41F721e09a9C8027165C6Bf1B3771848f6a43D29) [zkmoney/RefundRelationsLib] | |
| +++ description: Library immutably linked into a zk.money refund verifier. It evaluates the UltraHonk circuit constraints during proof verification. | |
| + | Status: CREATED |
| contract RelationsLib (eth:0x9e2131C7B89D070a6b27f29c2b8e066399ECA5b7) [zkmoney/RefundRelationsLib] | |
| +++ description: Library immutably linked into a zk.money refund verifier. It evaluates the UltraHonk circuit constraints during proof verification. | |
| + | Status: CREATED |
| contract RelationsLib (eth:0xb66C441BbeFe703E423dbcAa515d32F50e507C2b) [zkmoney/RefundRelationsLib] | |
| +++ description: Library immutably linked into a zk.money refund verifier. It evaluates the UltraHonk circuit constraints during proof verification. | |
| + | Status: CREATED |
| contract ZKTranscriptLib (eth:0xf3E445E6E292dE756bD66011c23717DAb9e12DBD) [zkmoney/ResolverVerifierLibrary] | |
| +++ description: Runtime library immutably linked into the zk.money resolver verifier. It evaluates circuit constraints or derives Fiat-Shamir challenges for zero-knowledge UltraHonk proofs. | |
Initial full discovery of zk.money.
Initial full discovery of zk.money.
| + | Status: CREATED |
| contract NitroValidator (eth:0x0119bC52a09Ac6e7998378BadC16D0e9A866Be56) [zkmoney/NitroValidator] | |
| +++ description: Validates AWS Nitro enclave attestations against the certificate chain verified by the CertManager. | |
| + | Status: CREATED |
| contract SwapEscrowFactory (eth:0x03b21BBa8e75A1BD0354c5ECbEC078cF59C85343) [zkmoney/SwapEscrowFactory] | |
| +++ 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. | |
| + | Status: CREATED |
| contract FrozenNotesRefundVerifier (eth:0x0694fF404DDA586C73EfCe21f34fe084541BB877) [zkmoney/HonkVerifier] | |
| +++ description: UltraHonk verifier for a zk.money circuit with a hardcoded verification key. | |
| + | Status: CREATED |
| contract RegistrationSIPA (eth:0x0934F010d59b552949DBe44AcBE5AFf0e32C8C34) [zkmoney/RegistrationSIPA] | |
| +++ 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. | |
| + | Status: CREATED |
| contract RegistrationController (eth:0x10EB6fecD2DCE6DA55d25C355374c970D5D11E23) [zkmoney/RegistrationController] | |
| +++ 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. | |
| + | Status: CREATED |
| contract OxideAccountFactory (eth:0x187d19EccBf2909AD3d71B798A8704D950b9C3ee) [zkmoney/OxideAccountFactory] | |
| +++ description: Permissionless factory for deterministic L1 accounts. The implementation is immutable and there is no administrator. | |
| + | Status: CREATED |
| contract FPCFunderDAI (eth:0x37cD81C39Bf276ea7e1c6a416A254f688c70eAFb) [zkmoney/FPCFunderDAI] | |
| +++ 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. | |
| + | Status: CREATED |
| contract Resolver (eth:0x3e9BcF7cCA4b94885aBEB9Bbf0005aA99DC6307F) [zkmoney/Resolver] | |
| +++ 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. | |
| + | Status: CREATED |
| contract UnprocessedDepositRefundVerifier (eth:0x5C487AEb500BD0fE65fe52Be7e55a150c3220FA5) [zkmoney/HonkVerifier] | |
| +++ description: UltraHonk verifier for a zk.money circuit with a hardcoded verification key. | |
| + | Status: CREATED |
| contract FrozenDepositRefundVerifier (eth:0xa2fd594dCA2d598aF231d615E5D34903154C3cCe) [zkmoney/HonkVerifier] | |
| +++ description: UltraHonk verifier for a zk.money circuit with a hardcoded verification key. | |
| + | Status: CREATED |
| contract NameRegistry (eth:0xa9863B8F573D62377d987ccb9AF6e0000f99D14a) [zkmoney/NameRegistry] | |
| +++ 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. | |
| + | Status: CREATED |
| contract ResolverVerifier (eth:0xbF058D54c5033F4cB45c6E1Eba103CaeF232E451) [zkmoney/HonkVerifier] | |
| +++ description: UltraHonk verifier for a zk.money circuit with a hardcoded verification key. | |
| + | Status: CREATED |
| contract PlainWithdrawalExecutor (eth:0xC2363b7155EE8391C5395B72C46a6d22BF49151c) [zkmoney/PlainWithdrawalExecutor] | |
| +++ description: Default payout contract for withdrawals and refunds. Only the PORTAL can call it. It pays the recipient and relayer tip committed on Aztec. | |
| + | Status: CREATED |
| contract SIPAFactory (eth:0xc357E34D4C7520a83C9Ec0a242Ba52b4ecABa1Fc) [zkmoney/SIPAFactory] | |
| +++ 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. | |
| + | Status: CREATED |
| contract OxideAccount (eth:0xdA0D7cD0f49cE7b1D04bf03eE56374a8981c2844) [zkmoney/OxideAccount] | |
| +++ 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. | |
| + | Status: CREATED |
| contract AccountMetadataRegistry (eth:0xDA79Bae4485c40291363D885Aae5B543d2D0Efa9) [zkmoney/AccountMetadataRegistry] | |
| +++ 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. | |
| + | Status: CREATED |
| contract ZkMoneyPortal (eth:0xdf410ad448A0f7165181FBdB32f8896f4a0d9449) [zkmoney/ZkMoneyPortal] | |
| +++ 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. | |
| + | Status: CREATED |
| contract CertManager (eth:0xdfe52FD98aa0Cc8Ce7778a2b00ac7B7Dc9595875) [zkmoney/CertManager] | |
| +++ description: Verifies and caches AWS Nitro attestation certificates. The only trust anchor is the hardcoded AWS Nitro root certificate. | |
| + | Status: CREATED |
| contract OperationExecutor (eth:0xe883686d9EC4E0430f2233A6BF12B2D226a39e19) [zkmoney/OperationExecutor] | |
| +++ description: Permissionless helper that executes a call and forwards the resulting token payout to the caller. Used by finalizers to collect fees and subsidies. | |
| + | Status: CREATED |
| contract SwapEscrow (eth:0xf16Fd140036925e3a0630d0F743204a4c7d8ccaf) [zkmoney/SwapEscrow] | |
| +++ 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. | |
| + | Status: CREATED |
| contract DepositSIPA (eth:0xF714D8Cf287F4A410b018514074A9371BC45461b) [zkmoney/DepositSIPA] | |
| +++ 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. | |


Validates AWS Nitro enclave attestations against the certificate chain verified by the CertManager.
Runtime library immutably linked into the zk.money resolver verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover.. It evaluates circuitA program written for the purpose of being proven within a proving system. A circuit is a mathematical representation of the computation to be executed, arithmetic circuits and zkVM execution trace are examples of circuits. Circuits can be written in different languages, ranging from low-level to high-level. constraints or derives Fiat-Shamir challenges for zero-knowledgeA cryptographic technology and sub-discipline of cryptography that allows an individual to prove that a statement or computation is true without revealing any additional information. UltraHonk proofs.
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.
UltraHonk verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. for refunds of notes that were unspent when the zk.money portal froze. Its verification key is immutable.
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.
Completes paid name registrations: deploys the user’s L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. account, claims the name and writes the user record. Fees above the relayer fee go to an allowlisted beneficiary.
PermissionlessAnyone willing should be able to join and leave the network at any time, without causing significant disturbance to the network or being detrimental to the party in question. No single entity should have the power to allowlist or blocklist participants. factory for deterministic L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. accounts. The implementation is immutable and there is no administrator.
Library immutably linked into a zk.money refund verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover.. It evaluates the UltraHonk circuitA program written for the purpose of being proven within a proving system. A circuit is a mathematical representation of the computation to be executed, arithmetic circuits and zkVM execution trace are examples of circuits. Circuits can be written in different languages, ranging from low-level to high-level. constraints during proof verification.
UltraHonk verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. for refunds of deposits included in Aztec’s frozen message tree but still unclaimed. Its verification key is immutable.
Swap-on-withdraw: a withdrawal can pay DAI to a SwapEscrowV2 clone whose route, recipient, gasA virtual fuel used to execute smart contracts on a rollup. The EVM (or other VM within the rollup) uses an accounting mechanism to correspond the consumption of gas to the consumption of computing resources, and to limit the consumption of computing resources. share and tip are fixed in its address. Anyone can deploy and execute a funded clone to pay USDC, USDT, ETH or DAI to the recipient.
ENS resolver for zk.money names. It returns a deposit address derived from a resolver operatorAn operator is the entity charged with managing a rollup and progressing its state. A rollup operator can be a centralized sequencer, proposer, prover, challenger, pauser of admin that is able to perform upgrades.’s answer, which must come with a zk proof that it matches the user’s registered keys and L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. address in the AccountMetadataRegistry.
Implementation for savings conversion escrows. Each clone fixes the route, deposit commitment, relayer tip and recovery commitment in its address. It converts DAI into sUSDS or redeposits DAI after a savings withdrawal. The recovery account can reclaim stranded tokens, including shares taken without redemption.
UltraHonk verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. for refunds of deposits not absorbed into Aztec before the zk.money portal froze. Its verification key is immutable.
Payout contract for sUSDS withdrawals and refunds. Only the PORTAL can execute a payout. It normally redeems sUSDS into USDS and converts USDS to DAI before paying the committed recipient and relayer tip. The recipient can complete an ordinary withdrawal in sUSDS shares through withdrawInShares, bypassing redemption.
UltraHonk verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. for refunds of deposits not absorbed into Aztec before the zk.money portal froze. Its verification key is immutable.
Deploys deterministic escrows for moving funds between the DAI and sUSDS portals. Anyone can execute a funded escrow. Its implementation and routes are immutable.
UltraHonk verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. for refunds of deposits included in Aztec’s frozen message tree but still unclaimed. Its verification key is immutable.
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.
UltraHonk verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. for the zk.money resolver circuitA program written for the purpose of being proven within a proving system. A circuit is a mathematical representation of the computation to be executed, arithmetic circuits and zkVM execution trace are examples of circuits. Circuits can be written in different languages, ranging from low-level to high-level. with a hardcoded verification key. The Resolver uses it to check that a resolver operatorAn operator is the entity charged with managing a rollup and progressing its state. A rollup operator can be a centralized sequencer, proposer, prover, challenger, pauser of admin that is able to perform upgrades.’s answer matches the user’s registered keys and L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. address.
Default payout contract for withdrawals and refunds. Only the PORTAL can call it. It pays the recipient and relayer tip committed on Aztec.
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.
SwapEscrowV2 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. It can first swap a capped share of the DAI to ETH for the recipient’s gasA virtual fuel used to execute smart contracts on a rollup. The EVM (or other VM within the rollup) uses an accounting mechanism to correspond the consumption of gas to the consumption of computing resources, and to limit the consumption of computing resources.. If the swap cannot execute, only the recovery key committed in the clone’s address can move the funds.
UltraHonk verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. for refunds of notes that were unspent when the zk.money portal froze. Its verification key is immutable.
Escrow of zk.money on the Aztec NetworkA constellation of nodes (peers) that communicate via a peer-to-peer protocol, for example, in propagating transactions and blocks to other nodes.. A withdrawal needs both a proven Aztec L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups.->L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. 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 rollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign rollup. is no longer ROLLUP, anyone can permanently freeze the portal, stopping deposits and fixing the refund snapshot at the last proven checkpoint.
Immutable implementation of users’ L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. 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.
Stores user records (Aztec L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. address, keys, chosen resolver operatorAn operator is the entity charged with managing a rollup and progressing its state. A rollup operator can be a centralized sequencer, proposer, prover, challenger, pauser of admin that is able to perform upgrades.) and resolver operator entries. User records can be written by the user or by the RegistrationController. Anyone can register as a resolver operator.
Escrow of zk.money on the Aztec NetworkA constellation of nodes (peers) that communicate via a peer-to-peer protocol, for example, in propagating transactions and blocks to other nodes.. A withdrawal needs both a proven Aztec L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups.->L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. 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 rollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign rollup. is no longer ROLLUP, anyone can permanently freeze the portal, stopping deposits and fixing the refund snapshot at the last proven checkpoint.
Verifies and caches AWS Nitro attestation certificates. The only trust anchor is the hardcoded AWS Nitro root certificate.
PermissionlessAnyone willing should be able to join and leave the network at any time, without causing significant disturbance to the network or being detrimental to the party in question. No single entity should have the power to allowlist or blocklist participants. helper that executes a call and forwards the resulting token payout to the caller. Used by finalizers to collect fees and subsidies.
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.
Runtime library immutably linked into the zk.money resolver verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover.. It evaluates circuitA program written for the purpose of being proven within a proving system. A circuit is a mathematical representation of the computation to be executed, arithmetic circuits and zkVM execution trace are examples of circuits. Circuits can be written in different languages, ranging from low-level to high-level. constraints or derives Fiat-Shamir challenges for zero-knowledgeA cryptographic technology and sub-discipline of cryptography that allows an individual to prove that a statement or computation is true without revealing any additional information. UltraHonk proofs.
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.
Collects the portal’s funding cut. Anyone can swap it to AZTEC and bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. it as Fee Juice to the zk.money fee-paying contract on Aztec (L2_BENEFICIARY), which pays L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. fees for users.