Search

Search for projects and tokens by name or address

Privacy

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.

About

A shielded ledger on Aztec Network for DAI payments and sUSDS savings, with funds escrowed on Ethereum.


  • Total Value Locked
    $52.30 K0.59%
    across 1 assets and 1 buckets
  • TVL
    $52.30 K0.59%
  • Assets tracked
    1
  • Buckets tracked
    1
  • Deposits 7D
    8934.0%
  • Deposits 30D
    1.11 K
  • Deposits Total
    1.12 K
  • Active Relayers 30D
    9

  • Privacy
    Link privacy
  • Trusted setup
  • Exit window
  • Reproducibility

  • Tracked on
    Ethereum logo
  • Attributes
    ZKTEETransfersAny amount
  • Public observerChain analystNetwork observerPrivileged insiderFuture adversary

    About

    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.

    Flow

    1. Deposit. You fund an 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. deposit address called a SIPA, and anyone can sweep it into the portal. USDC and USDT are swapped to DAI through Curve. After fees, an Inbox message credits private notes on Aztec. Reusing a SIPA links its deposits.
    2. Pay. You add a name as a contact, and the wallet reads its Aztec address from the onchain registry and sends a private transfer.
    3. Withdraw. Aztec proves the withdrawal message, an enclave co-signs it and the portal pays out DAI on Ethereum. A swap escrow can instead pay out USDC, USDT or ETH, and give a fresh recipient ETH for 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..

    Keys

    Accounts sign with a passkey. The released wallet requires a registered name to access an account on a new device.

    App

    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

    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.

    Names

    Tags such as l2beat.zk.money publish Aztec addresses and keys on Ethereum.

    • L1 deposits: ENS-compatible wallets resolve a tag to a deposit address through the recipient’s 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.. The default is a centralized resolver who can link deposits to their tag.
    • L2 transfers: wallets read the registered Aztec address when a tag is added as a contact.

    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.

    Resolver

    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.

    Exits

    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.

    Compliance

    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.

    Fees and limits

    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.

    Source verification

    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.

    Public observerChain analystNetwork observerPrivileged insiderFuture adversary
    Public observer
    Private

    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.

    InsideSenderat riskRecipientexposedAmountprivateAssetexposedLinkat risk
    Chain analyst
    At risk

    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.

    Compared with a public observer
    InsideAmountat riskLinkat risk
    Network observer
    At risk

    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.

    Compared with a public observer
    InsideSenderat riskLinkat risk
    Privileged insider
    At risk

    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.

    Compared with a public observer
    InsideSenderat riskAmountat riskLinkat risk
    Future adversary
    Exposed

    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.

    Compared with a public observer
    InsideSenderexposedRecipientexposedAmountexposedAssetexposedLinkexposed

    30 day historic anonymity set

    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.

    Estimated anonymity set by holding duration

    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
    DAIDAI
    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..

    Learn more

    Funds can be stolen if

    1. Aztec’s private execution or refund proof is unsound and the enclave layer also fails.
    2. malicious wallet code obtains a harmful signature, or substituted unsigned contract lists redirect future deposits and payments.
    3. the NameRegistry owner or owner of zk.money in ENS redirects future payments to names.
    4. a malicious sUSDS token upgrade confiscates escrowed shares (see upgrades and governance).

    Funds can be lost if

    1. a user loses their passkey.
    2. all registered signers stop serving and users cannot obtain or run the portal’s approved enclave image, which for sUSDS is unpublished.
    3. resolver screening blocksAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over. an external payment and the recipient lacks the tooling to re-derive its deposit address.

    Privacy can be lost if

    1. a user pays a new contact, whose handshake reveals the recipient (see public observer).
    2. a user’s payments hide only among zk.money’s users on Aztec (see chain analyst).
    3. 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. links deposits paid through a name to their recipients, or an enclave or AWS Nitro is compromised (see privileged insider).
    4. the unpublished sUSDS enclave image is malicious (see privileged insider).
    5. the default endpoints, Alchemy and Aztec Labs’ Aztec nodeA software client that participates in the network., see deposit addresses and withdrawals in one session (see networkA constellation of nodes (peers) that communicate via a peer-to-peer protocol, for example, in propagating transactions and blocks to other nodes. observer and privileged insider).
    6. the portal freezes, and refunds publish note or deposit amounts on Ethereum.
    7. elliptic-curve cryptography is broken, which decrypts data published to Ethereum (see future adversary).

    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.

    Enclave signers and freeze

    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.

    Names and services

    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.

    Savings asset

    Sky governance can upgrade sUSDS, changing balances and transfer rules. Its authorized rate controller can change the savings rate.

    Aztec Ignition

    UltraHonk

    Detailed description

    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.

    Ossification

    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.

    Ossification %
    49since 2026 Sep 25
    TVS & changes (1Y)
    Battle-tested exposure
    $2.56 K·years
    Critical changes / year
    0across 21 contracts
    Exit window

    Discovery updates

    2026 October 26, 10:53 UTC
    8changes

    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
    }
    2026 October 23, 09:33 UTC
    2changes

    Add SwapEscrowFactoryV2 and its SwapEscrowV2 implementation, which zk.money Desktop v0.5.0 uses for swap and fresh-address withdrawals.

    New and verified contracts

    + 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.
    2026 October 13, 09:10 UTC
    High severity
    38changes

    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.

    New and verified contracts

    + 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.
    2026 October 01, 07:48 UTC
    21changes

    Initial full discovery of zk.money.

    Initial discovery

    + 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.
    A dashboard to explore contracts and permissions
    Go to Disco
    Disco UI Banner

    Ethereum

    Actors:

    • Can interact with Resolver
      • replace this Resolver as the ENS resolver of zk.money names, which decides the addresses that payments to these names resolve to
    • Can interact with NameRegistry
      • 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
    • Can interact with SIPAFactory
      • 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
    • Can interact with ZkMoneyPortal_sUSDS
      • co-sign withdrawals and refunds. Without a signature from a registered TEE signer, no funds can leave the portal
    • Can interact with NameRegistry
      • authorize or refuse every name claim and sign custom registration fees
    • Can interact with ZkMoneyPortal
      • co-sign withdrawals and refunds. Without a signature from a registered TEE signer, no funds can leave the portal
    A dashboard to explore contracts and permissions
    Go to Disco
    Disco UI Banner

    Ethereum

    NitroValidator0x0119…Be56

    Validates AWS Nitro enclave attestations against the certificate chain verified by the CertManager.

    RelationsLib0x0235…9070

    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.

    SwapEscrowFactory0x03b2…5343

    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.

    FrozenNotesRefundVerifier0x0694…B877

    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.

    RegistrationSIPA0x0934…8C34

    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.

    RegistrationController0x10EB…1E23

    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.

    OxideAccountFactory0x187d…C3ee

    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.

    FrozenDepositRefundVerifier_sUSDS0x2E0C…4522

    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.

    SwapEscrowFactoryV20x3B5D…5952

    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.

    • Roles:
      • ensNodeOwner: EOA 1
    SkyEscrow0x5C41…6b8a

    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.

    1. Source Code
    UnprocessedDepositRefundVerifier0x5C48…0FA5

    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.

    SkyWithdrawalExecutor0x63e6…5475

    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.

    UnprocessedDepositRefundVerifier_sUSDS0x8ACc…b787

    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.

    SkyEscrowFactory0x9c4A…9054

    Deploys deterministic escrows for moving funds between the DAI and sUSDS portals. Anyone can execute a funded escrow. Its implementation and routes are immutable.

    FrozenDepositRefundVerifier0xa2fd…3cCe

    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.

    NameRegistry0xa986…D14a

    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.

    • Roles:
      • domainOwner: EOA 5
      • owner: EOA 1
    ResolverVerifier0xbF05…E451

    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.

    PlainWithdrawalExecutor0xC236…151c

    Default payout contract for withdrawals and refunds. Only the PORTAL can call it. It pays the recipient and relayer tip committed on Aztec.

    SIPAFactory0xc357…a1Fc

    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.

    • Roles:
      • owner: EOA 1
    SwapEscrowV20xcfAf…FB95

    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.

    FrozenNotesRefundVerifier_sUSDS0xd24a…abf2

    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.

    ZkMoneyPortal_sUSDS0xD7Ae…260f

    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.

    • Roles:
      • teeSigners: EOA 2, EOA 3, EOA 4
    OxideAccount0xdA0D…2844

    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.

    AccountMetadataRegistry0xDA79…Efa9

    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.

    ZkMoneyPortal0xdf41…9449

    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.

    • Roles:
      • teeSigners: EOA 6, EOA 7
    CertManager0xdfe5…5875

    Verifies and caches AWS Nitro attestation certificates. The only trust anchor is the hardcoded AWS Nitro root certificate.

    OperationExecutor0xe883…9e19

    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.

    SwapEscrow0xf16F…ccaf

    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.

    ZKTranscriptLib0xf3E4…2DBD

    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.

    DepositSIPA0xF714…461b

    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.

    FPCFunderDAI0x37cD…eAFb

    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.