Search

Search for projects by name or address

Privacy

About

A private DAI wallet on Aztec Network, with funds escrowed on Ethereum.


  • Total Value Locked
    $17.27 K>1K%
    across 1 assets and 1 buckets
  • TVL
    $17.27 K>1K%
  • Assets tracked
    1
  • Buckets tracked
    1
  • Deposits 7D
    718>1K%
  • Deposits 30D
    724
  • Deposits Total
    752
  • Active Relayers 30D
    7

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

  • Tracked on
    Ethereum logo
  • Attributes
    ZKTEETransfersAny amount

  • About

    A private DAI wallet on Aztec Network, with funds escrowed on Ethereum.

    Internal payments are hidden, but names, deposits and withdrawals are public. The first payment to a new contact reveals the recipient. The first sponsored transaction after registration reveals the sender’s account.

    Every withdrawal and refund needs a proof and a live AWS Nitro enclave. Operations are encrypted to the enclave (TEE), which decrypts and reads them. Its approved binary has not been reproduced from the published source. Aztec Labs controls zk.money names and the released wallets’ contract configuration.

    Multiproofs and exits

    The portal releases funds only after Aztec proves the withdrawal message (zk proof of validity) and any one registered enclave signer co-signs it (TEE signature). Stealing escrowed funds requires both layers to fail while privacy leaks depend on either. Anyone can register an enclave running the approved image with a fresh AWS attestation.

    If Aztec 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. Deposits stop and refundable ownership is fixed at the last proven checkpoint. Later 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. transfers do not change it. Withdrawals and refunds still need an enclave. Refunds expose note or deposit amounts on Ethereum and use proofs without zero knowledge.

    Wallet

    • Hosted: loads code from zk.money on every visit. Whoever controls deployment can read viewing keys and request harmful passkey signatures. Passkey prompts do not show the operation.
    • Desktop: runs local code but fetches contract addresses from two unsigned Aztec Labs lists. Substituting them can redirect future deposits and payments.
    • Independent operation: requires modifying the desktop build to pin verified addresses, remove screening and serve it under auth.zk.money. Users can submit Ethereum transactions themselves and run the approved enclave on AWS. New names still require Aztec Labs’ signature. L2BEAT has not run this setup.

    Both released wallets allow custom Aztec, Ethereum and enclave endpoints. Their passkeys belong to auth.zk.money, which must authorize wallet.zk.money on every use. Onchain contracts do not check the signature’s origin. A modified wallet served under auth.zk.money would bypass this dependency.

    Wallets use XMTP, an end-to-end encrypted messaging networkA constellation of nodes (peers) that communicate via a peer-to-peer protocol, for example, in propagating transactions and blocks to other nodes., to confirm contacts added by QR code or link and to send payment requests. Messages are encrypted, but each inbox is publicly tied to a name, so XMTP’s servers can see which names talk to each other.

    The browser stores the master key unencrypted until sign-out, and viewing keys and decrypted notes until local data is cleared. All keys except the spending key derive from the master key (privacy is lost if the master key is leaked).

    Deposits and fees

    Users fund deposit addresses called SIPAs. Anyone can sweep them into the Ethereum portal. USDC and USDT are swapped to DAI through Curve. After fees, DAI stays in escrow and an Inbox message credits private notes on Aztec L2. SIPAs can be reused, at the expense of user privacy.

    A sweep pays 0.25 DAI, or 0.5 DAI when claiming a name. Registration costs 5 DAI by default, including its sweep fee. The domain owner (onchain role in NameRegistry) can sign custom prices and add fee beneficiaries. Users select a beneficiary in their registration intent.

    The portal takes 0.1 DAI from each deposit and ordinary withdrawal to sponsor Aztec fees. Sponsorship requires a registered name or a voucher from a registered account. An empty fee-paying contract or fees above its allowance stall the released wallet. Modified code can pay with the account’s own Fee Juice (potential privacy implications). Deposits share a 50,000 DAI capacity, refilling over 1 day. Deposit, payment and withdrawal transaction amounts are capped at 2,583 DAI each.

    Names and Compliance

    Names (tags) publicly map to Aztec addresses and keys on Ethereum. Claims require the domain owner’s signature from a closed-source server with a name blocklist. The released wallet requires a registered name to access an account on a new device.

    External name payments use 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. to derive and announce deposit addresses. Internal payments skip it (reading from the onchain contract), but wallet-created deposit addresses still derive from Aztec Labs’ operator key. The onchain Resolver checks a zk proof on every lookup, binding each address to the recipient’s registered keys, Aztec address and 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, so the operator cannot redirect payments. It can still re-derive every deposit address of its users. Users can choose another operator for name payments. The only registered operator is Aztec Labs, and its service is unpublished.

    The wallet sends Ethereum addresses to Predicate through zk.money for screening, which can be bypassed by funding a deposit SIPA directly. The relayer also screens token movements against OFAC and optionally Predicate. Self-submitting sweeps and proven withdrawals bypasses relayer screening.

    The name resolver screens deposit addresses and funders against OFAC before notifying the recipient on L2. A blocked payment leaves funds at an address the wallet never learns. Recovery requires the recipient’s own tooling to re-derive it and authorization from their L1 account. Onchain contracts and the enclave do not check compliance lists.

    Source verification

    The token verification steps compare a fresh source build with the Aztec instance (L2 contract) pinned by the Ethereum portal. The verifier steps regenerate the keys and Solidity verifiers of the refund and resolver circuits and compare them with the deployed contracts.

    What the protocol promises: Hides senders, amounts and links between deposits and withdrawals within the ledger. Tags, deposits and withdrawals are public. The first payment to a new contact reveals the recipient, and the first sponsored transaction after registration reveals the sender’s account.

    On public blockchains like Ethereum, all actions transparent by default. A privacy protocol can at best cut the link between addresses or offer privacy while deposited. The colour says whether a careful user can keep the link, amount or recipient private against that adversary: green yes, yellow only outside supported options or by accepting another leak, red no. Fields marked at risk stay private only under the condition in their note.

    Link private

    Private payments publish encrypted notes. Fixed log tags identify zk.money transactions on Aztec, and the first payment to a new contact reveals the recipient's Aztec address through a handshake. The Ethereum registry maps that address to a tag. The first sponsored transaction after registration also identifies the sender's account. Deposits and withdrawals show address, token and amount. Claiming a tag links it and the Aztec address to the funding L1 wallet.

    Advice: Claim your tag from a wallet with no public link to you and fund each deposit address once. Wait for deposits to be swept. Recovering them reveals the link to your account.

    InsideSenderat riskRecipientexposedAmountprivateAssetexposedLinkat risk
    Link at risk

    The anonymity set is limited to zk.money users. The first payment to a tag from outside zk.money is publicly tied to that tag. Anyone who records Aztec transactions can also tie the first deposit address your wallet creates after registration to your account.

    Advice: Watch the anonymity set in this early stage. Give outside payers a deposit address your wallet created instead of your tag. Fund your first deposit address after registration from the wallet that claimed your tag. Withdraw common amounts rather than everything at once. Wait before exiting and pick a different time of day than the deposit. Exit to a fresh address every time and spend from it with a different wallet than the one that deposited.

    Compared with a public observer
    InsideSenderat riskRecipientexposedAmountat riskAssetexposedLinkat risk
    Link private

    Keys and proving stay on your device. Note discovery reveals your account address to the Aztec node. Ethereum RPC requests reveal funding wallets, deposit addresses and L1 transaction senders. XMTP carries payment requests and contact links under public account addresses, exposing who asks whom for money. Both wallets support custom Aztec, Ethereum and enclave endpoints.

    Advice: Use zk.money Desktop with your own Aztec and Ethereum nodes. Send L1 transactions from your Ethereum wallet over a public RPC. Route all computer traffic through a VPN or Tor. Avoid payment requests and contact links with counterparties that must stay private.

    Compared with a public observer
    InsideSenderat riskRecipientexposedAssetexposedLinkat risk
    Link exposed

    Wallets encrypt payments, withdrawals and deposit claims to an enclave key registered in the portal. The approved code decrypts them inside the enclave. Privacy against the operator depends on AWS Nitro and that code, whose binary has not been reproduced. The resolver operator can re-derive all deposit addresses, including those created by your wallet, linking L1 deposits to L2 recipients.

    Advice: Run your own enclave, which is permissionless onchain but still depends on AWS. Running your own resolver operator is also permissionless, but its service is unpublished and the released wallets only use Aztec Labs' operator.

    Compared with a public observer
    InsideSenderexposedRecipientexposedAmountexposedAssetexposedLinkexposed
    Link exposed

    A quantum computer that breaks elliptic-curve key exchange can decrypt historical notes and payment events published to Ethereum. Registered Aztec addresses identify the accounts. Deposit address secrets and enclave communication use the same class of cryptography.

    Advice: Treat every payment and every deposit link as permanently disclosed.

    Compared with a public observer
    InsideSenderexposedRecipientexposedAmountexposedAssetexposedLinkexposed

    30 day historic anonymity set

    How many unique addresses 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 addresses 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
    718
    $47.32 K
    724
    $47.37 K
    752
    $47.99 K
    $17.27 K
    Total
    718
    $47.32 K
    724
    $47.37 K
    752
    $47.99 K
    $17.27 K

    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.

    Funds can be lost if

    1. a user loses their passkey.
    2. no AWS-attested enclave is running.
    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. Funds remain recoverable, but the recipient needs their own tooling to re-derive the unannounced deposit address.

    Privacy can be lost if

    1. a user pays a new contact. The handshake reveals the recipient’s Aztec address, publicly linked to their name. The first sponsored transaction after registration also reveals the sender’s account.
    2. an enclave or AWS Nitro attestation is compromised.
    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. re-derives deposit addresses and links deposits to recipients.
    4. public deposits, withdrawals, registration and deposit-address reuse allow amount or timing correlation.
    5. an external Aztec RPC learns the account from note requests, or zk.money and Predicate correlate screened addresses by IP.
    6. someone reads keys and decrypted notes stored unencrypted on the device.
    7. a freeze forces refunds, which expose note and deposit amounts on Ethereum and use proofs without zero knowledge.
    8. a quantum computer breaks the elliptic-curve encryption of notes published to Ethereum.

    Immutable escrow and accounts

    The portal, Aztec token, fee-paying contract, verifiers, withdrawal executors and current SIPA implementations cannot be upgraded.

    The approved enclave image is fixed. Anyone can permanently register a signer with an AWS Nitro attestation at most 1 hour old. 2 signers are registered. A withdrawal or refund needs only one of them, alongside its proof. Registrations do not expire and cannot be revoked.

    If Aztec governance changes the 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 permanently freeze the portal. Deposits stop and refundable ownership is fixed at the last proven checkpoint. Later 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. transfers do not change it. Withdrawals and refunds still require a live enclave.

    Name administration

    Two Aztec Labs EOAs control *.zk.money names:

    • The deployer owns the NameRegistry and can replace its RegistrationController, AccountMetadataRegistry and Resolver, allowing it to reassign names, rewrite records and redirect future payments. It also owns zk.money in ENS, which the DNS domain holder can reclaim.
    • The domain owner can refuse name claims, sign custom registration fees and add fee beneficiaries. Users select a beneficiary from the allowlist in their signed registration intent. Existing beneficiaries cannot be removed.

    Wallet and services

    Aztec Labs controls hosted wallet code, desktop releases and two unsigned contract lists consumed by both wallets. These are security dependencies: wallet code handles keys and signatures, and the lists determine where future funds go. The wallet checks the profile and manifest for consistency, but both come from Aztec Labs. A local build with custom nodes still trusts those lists until their addresses are independently verified and pinned.

    The relayer, resolver, claim server, enclave hosts and passkey domain also control availability and censorship. Self-submission bypasses the relayer, but exits still need an enclave and the released wallets still depend on zk.money services.

    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.

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

    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 a zk.money refund 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.

    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.

    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
    UnprocessedDepositRefundVerifier0x5C48…0FA5

    UltraHonk verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. for a zk.money refund 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.

    FrozenDepositRefundVerifier0xa2fd…3cCe

    UltraHonk verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. for a zk.money refund 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.

    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 2
      • 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
    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. 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.

    • Roles:
      • teeSigners: EOA 3, EOA 4
    Implementation used in:
    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.

    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.