Search for projects by name or address
A private DAI wallet on Aztec Network, with funds escrowed on Ethereum.
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.
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.
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).
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 (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.
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.
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.
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.
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.
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.
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.
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.
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 |
|---|---|---|---|---|
DAI | 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 |
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.
Two Aztec Labs EOAs control *.zk.money names:
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 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.
Initial full discovery of zk.money.
Initial full discovery of zk.money.
| + | Status: CREATED |
| contract NitroValidator (eth:0x0119bC52a09Ac6e7998378BadC16D0e9A866Be56) [zkmoney/NitroValidator] | |
| +++ description: Validates AWS Nitro enclave attestations against the certificate chain verified by the CertManager. | |
| + | Status: CREATED |
| contract SwapEscrowFactory (eth:0x03b21BBa8e75A1BD0354c5ECbEC078cF59C85343) [zkmoney/SwapEscrowFactory] | |
| +++ description: Swap-on-withdraw: a withdrawal can pay DAI to a SwapEscrow clone whose route, recipient and tip are fixed in its address. Anyone can deploy and execute a funded clone to swap the DAI for USDC, USDT or ETH to the recipient. | |
| + | Status: CREATED |
| contract FrozenNotesRefundVerifier (eth:0x0694fF404DDA586C73EfCe21f34fe084541BB877) [zkmoney/HonkVerifier] | |
| +++ description: UltraHonk verifier for a zk.money circuit with a hardcoded verification key. | |
| + | Status: CREATED |
| contract RegistrationSIPA (eth:0x0934F010d59b552949DBe44AcBE5AFf0e32C8C34) [zkmoney/RegistrationSIPA] | |
| +++ description: Implementation of zk.money registration addresses. Sweeping a funded clone registers the name through the current RegistrationController of the NameRegistry, pays the committed fees and deposits the rest into the PORTAL. The recipient's account can recover any funds from the clone. | |
| + | Status: CREATED |
| contract RegistrationController (eth:0x10EB6fecD2DCE6DA55d25C355374c970D5D11E23) [zkmoney/RegistrationController] | |
| +++ description: Completes paid name registrations: deploys the user's L1 account, claims the name and writes the user record. Fees above the relayer fee go to an allowlisted beneficiary. | |
| + | Status: CREATED |
| contract OxideAccountFactory (eth:0x187d19EccBf2909AD3d71B798A8704D950b9C3ee) [zkmoney/OxideAccountFactory] | |
| +++ description: Permissionless factory for deterministic L1 accounts. The implementation is immutable and there is no administrator. | |
| + | Status: CREATED |
| contract FPCFunderDAI (eth:0x37cD81C39Bf276ea7e1c6a416A254f688c70eAFb) [zkmoney/FPCFunderDAI] | |
| +++ description: Collects the portal's funding cut. Anyone can swap it to AZTEC and bridge it as Fee Juice to the zk.money fee-paying contract on Aztec (L2_BENEFICIARY), which pays L2 fees for users. | |
| + | Status: CREATED |
| contract Resolver (eth:0x3e9BcF7cCA4b94885aBEB9Bbf0005aA99DC6307F) [zkmoney/Resolver] | |
| +++ description: ENS resolver for zk.money names. It returns a deposit address derived from a resolver operator's answer, which must come with a zk proof that it matches the user's registered keys and L2 address in the AccountMetadataRegistry. | |
| + | Status: CREATED |
| contract UnprocessedDepositRefundVerifier (eth:0x5C487AEb500BD0fE65fe52Be7e55a150c3220FA5) [zkmoney/HonkVerifier] | |
| +++ description: UltraHonk verifier for a zk.money circuit with a hardcoded verification key. | |
| + | Status: CREATED |
| contract FrozenDepositRefundVerifier (eth:0xa2fd594dCA2d598aF231d615E5D34903154C3cCe) [zkmoney/HonkVerifier] | |
| +++ description: UltraHonk verifier for a zk.money circuit with a hardcoded verification key. | |
| + | Status: CREATED |
| contract NameRegistry (eth:0xa9863B8F573D62377d987ccb9AF6e0000f99D14a) [zkmoney/NameRegistry] | |
| +++ description: Registry of zk.money names. It points to the RegistrationController and the AccountMetadataRegistry, which together decide where payments to a zk.money name resolve to. | |
| + | Status: CREATED |
| contract ResolverVerifier (eth:0xbF058D54c5033F4cB45c6E1Eba103CaeF232E451) [zkmoney/HonkVerifier] | |
| +++ description: UltraHonk verifier for a zk.money circuit with a hardcoded verification key. | |
| + | Status: CREATED |
| contract PlainWithdrawalExecutor (eth:0xC2363b7155EE8391C5395B72C46a6d22BF49151c) [zkmoney/PlainWithdrawalExecutor] | |
| +++ description: Default payout contract for withdrawals and refunds. Only the PORTAL can call it. It pays the recipient and relayer tip committed on Aztec. | |
| + | Status: CREATED |
| contract SIPAFactory (eth:0xc357E34D4C7520a83C9Ec0a242Ba52b4ecABa1Fc) [zkmoney/SIPAFactory] | |
| +++ description: Deploys zk.money deposit addresses (SIPAs) as deterministic clones. The implementation per portal and intent is blessed once by the owner and cannot be changed afterwards. | |
| + | Status: CREATED |
| contract OxideAccount (eth:0xdA0D7cD0f49cE7b1D04bf03eE56374a8981c2844) [zkmoney/OxideAccount] | |
| +++ description: Immutable implementation of users' L1 accounts. The bootstrap key authorizes the first passkey. Once a passkey is installed, only the user's passkeys can authorize operations and manage keys. The last passkey cannot be removed. Deposit recovery checks signatures against this account. | |
| + | Status: CREATED |
| contract AccountMetadataRegistry (eth:0xDA79Bae4485c40291363D885Aae5B543d2D0Efa9) [zkmoney/AccountMetadataRegistry] | |
| +++ description: Stores user records (Aztec L2 address, keys, chosen resolver operator) and resolver operator entries. User records can be written by the user or by the RegistrationController. Anyone can register as a resolver operator. | |
| + | Status: CREATED |
| contract ZkMoneyPortal (eth:0xdf410ad448A0f7165181FBdB32f8896f4a0d9449) [zkmoney/ZkMoneyPortal] | |
| +++ description: Escrow of zk.money on the Aztec Network. A withdrawal needs both a proven Aztec L2->L1 message from the zk.money L2 contract and a signature from a registered TEE signer. Anyone can register a TEE signer with a fresh AWS Nitro attestation of an approved enclave image. Once the Aztec Registry's canonical rollup is no longer ROLLUP, anyone can permanently freeze the portal, stopping deposits and fixing the refund snapshot at the last proven checkpoint. Withdrawals within the frozen checkpoint and epoch bounds remain available alongside refunds that need a zk proof and a TEE signature. L2 transfers are not disabled but do not change refundable ownership. | |
| + | Status: CREATED |
| contract CertManager (eth:0xdfe52FD98aa0Cc8Ce7778a2b00ac7B7Dc9595875) [zkmoney/CertManager] | |
| +++ description: Verifies and caches AWS Nitro attestation certificates. The only trust anchor is the hardcoded AWS Nitro root certificate. | |
| + | Status: CREATED |
| contract OperationExecutor (eth:0xe883686d9EC4E0430f2233A6BF12B2D226a39e19) [zkmoney/OperationExecutor] | |
| +++ description: Permissionless helper that executes a call and forwards the resulting token payout to the caller. Used by finalizers to collect fees and subsidies. | |
| + | Status: CREATED |
| contract SwapEscrow (eth:0xf16Fd140036925e3a0630d0F743204a4c7d8ccaf) [zkmoney/SwapEscrow] | |
| +++ description: SwapEscrow implementation. A clone swaps via the Curve 3pool (and Uniswap for ETH) with a slippage bound of 100 bps for stablecoins and 200 bps against the Chainlink ETH/USD price for ETH. If the swap cannot execute, only the recovery key committed in the clone's address can move the funds. | |
| + | Status: CREATED |
| contract DepositSIPA (eth:0xF714D8Cf287F4A410b018514074A9371BC45461b) [zkmoney/DepositSIPA] | |
| +++ description: Implementation of zk.money deposit addresses. Anyone can sweep a funded clone, which swaps USDC or USDT to DAI, pays DEPOSIT_FEE to the relayer and deposits the rest into the PORTAL for the recipient fixed in the clone's address. The recipient's account can recover any funds from the clone. | |


Validates AWS Nitro enclave attestations against the certificate chain verified by the CertManager.
Swap-on-withdraw: a withdrawal can pay DAI to a SwapEscrow clone whose route, recipient and tip are fixed in its address. Anyone can deploy and execute a funded clone to swap the DAI for USDC, USDT or ETH to the recipient.
UltraHonk verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. for 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.
Implementation of zk.money registration addresses. Sweeping a funded clone registers the name through the current RegistrationController of the NameRegistry, pays the committed fees and deposits the rest into the PORTAL. The recipient’s account can recover any funds from the clone.
Completes paid name registrations: deploys the user’s L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. account, claims the name and writes the user record. Fees above the relayer fee go to an allowlisted beneficiary.
PermissionlessAnyone willing should be able to join and leave the network at any time, without causing significant disturbance to the network or being detrimental to the party in question. No single entity should have the power to allowlist or blocklist participants. factory for deterministic L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. accounts. The implementation is immutable and there is no administrator.
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.
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.
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.
Registry of zk.money names. It points to the RegistrationController and the AccountMetadataRegistry, which together decide where payments to a zk.money name resolve to.
UltraHonk verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. for the zk.money resolver circuitA program written for the purpose of being proven within a proving system. A circuit is a mathematical representation of the computation to be executed, arithmetic circuits and zkVM execution trace are examples of circuits. Circuits can be written in different languages, ranging from low-level to high-level. with a hardcoded verification key. The Resolver uses it to check that a resolver operatorAn operator is the entity charged with managing a rollup and progressing its state. A rollup operator can be a centralized sequencer, proposer, prover, challenger, pauser of admin that is able to perform upgrades.’s answer matches the user’s registered keys and L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. address.
Default payout contract for withdrawals and refunds. Only the PORTAL can call it. It pays the recipient and relayer tip committed on Aztec.
Deploys zk.money deposit addresses (SIPAs) as deterministic clones. The implementation per portal and intent is blessed once by the owner and cannot be changed afterwards.
Immutable implementation of users’ L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. accounts. The bootstrap key authorizes the first passkey. Once a passkey is installed, only the user’s passkeys can authorize operations and manage keys. The last passkey cannot be removed. Deposit recovery checks signatures against this account.
Stores user records (Aztec L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. address, keys, chosen resolver operatorAn operator is the entity charged with managing a rollup and progressing its state. A rollup operator can be a centralized sequencer, proposer, prover, challenger, pauser of admin that is able to perform upgrades.) and resolver operator entries. User records can be written by the user or by the RegistrationController. Anyone can register as a resolver operator.
Escrow of zk.money on the Aztec NetworkA constellation of nodes (peers) that communicate via a peer-to-peer protocol, for example, in propagating transactions and blocks to other nodes.. A withdrawal needs both a proven Aztec L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups.->L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. message from the zk.money L2 contract and a signature from a registered TEE signer. Anyone can register a TEE signer with a fresh AWS Nitro attestation of an approved enclave image. Once the Aztec Registry’s canonical rollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign rollup. is no longer ROLLUP, anyone can permanently freeze the portal, stopping deposits and fixing the refund snapshot at the last proven checkpoint. 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.
Verifies and caches AWS Nitro attestation certificates. The only trust anchor is the hardcoded AWS Nitro root certificate.
PermissionlessAnyone willing should be able to join and leave the network at any time, without causing significant disturbance to the network or being detrimental to the party in question. No single entity should have the power to allowlist or blocklist participants. helper that executes a call and forwards the resulting token payout to the caller. Used by finalizers to collect fees and subsidies.
SwapEscrow implementation. A clone swaps via the Curve 3pool (and Uniswap for ETH) with a slippage bound of 100 bps for stablecoins and 200 bps against the Chainlink ETH/USD price for ETH. If the swap cannot execute, only the recovery key committed in the clone’s address can move the funds.
Implementation of zk.money deposit addresses. Anyone can sweep a funded clone, which swaps USDC or USDT to DAI, pays DEPOSIT_FEE to the relayer and deposits the rest into the PORTAL for the recipient fixed in the clone’s address. The recipient’s account can recover any funds from the clone.
Collects the portal’s funding cut. Anyone can swap it to AZTEC and bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. it as Fee Juice to the zk.money fee-paying contract on Aztec (L2_BENEFICIARY), which pays L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. fees for users.