Aztec (Alpha mainnet private token transfers)

transfer Assessed on Aztec mainnet (Alpha) (aztec:mainnet)aztec.network

Ratings apply to this deployment only. Treat them as unverified for other chains. Why this deployment: Aztec is a privacy L2 with its own state, sequencers and provers, settling to Ethereum. Unit: the mainnet the node follows. AztecProtocol/networks network_config.json L21-L32 names Registry 0x35b2…e298 on chain 1, whose canonical rollup is 0x91fF…8E34 (v5, Ethereum block 26,153,545). Scope: private transfers in tokens built on the reference Token contract. Excluded: testnet, older rollup versions, Fee Juice (not transferable). aztec:mainnet is not a registered CAIP-2 namespace.

At a glance

Category: Protocols for privacy-preserving transfers
Chain: Aztec mainnet (Alpha)
CROPS tally: 19 of 23 hold up
Security audits: 14 published
Offered: Everywhere
Last edited: 2026-10-13 · History

Censorship Resistance0 FailsWeakest: Token and chain freeze risks disclosed
Open1 WeakWeakest: Can be self-hosted
Free0 FailsWeakest: Protection against relicensing
Privacy2 PartialWeakest: Tracking and analytics; Payments linkable onchain; Third parties in the payment flow
Security1 WeakWeakest: Audits and bug bounty

Holds up 19

2 PartialAdmin pause or freeze powers
2 PartialSettle without the provider
3 StrongReliance on hosted services
2 PartialNeutral settlement, disclosed filtering
2 PartialContracts verified onchain
3 StrongWhole stack published
2 PartialInterfaces and data export
2 PartialOpen-source licences
2 PartialNo proprietary dependencies
2 PartialTracking and analytics
3 StrongData collected beyond payment
2 PartialPayments linkable onchain
2 PartialThird parties in the payment flow
3 StrongEndpoints can be changed
2 PartialWho holds funds in transit
2 PartialWho can upgrade the code
2 PartialToken approval scope
2 PartialFunds safe if provider disappears
2 PartialSecrets and webhook handling

Falls short 4

0 FailsToken and chain freeze risks disclosed
1 WeakCan be self-hosted
0 FailsProtection against relicensing
1 WeakAudits and bug bounty

Not yet evidenced 0

Every criterion has evidence.

Where it is offered

Offered everywhere, per the provider's code or documents. Checked 2026-10-09. Not scored.

The rollup contracts and reference token have no country rule, and the node, PXE, aztec.js and CLI wallet contain no country or geolocation gate (code search on 2026-10-09; the only country hit is a testnet mock staking handler). Aztec Labs' hosted mainnet RPC (mainnet.rpc.aztec-labs.com) runs behind a Google Cloud Armor policy named in spartan/environments/mainnet.env whose rules are not public, so it may filter by region; users avoid it by running a node. Third-party wallets, bridges and token issuers may impose their own limits, which we did not evidence. Legality of use varies by jurisdiction; that is not an availability restriction by the protocol.

Evidence (2)2 verified

Verified
The hosted mainnet RPC is configured with RPC_CLOUD_ARMOR_POLICY_NAME=mainnet-rpc-policy; the policy's rules are not in the repo.
AztecProtocol/aztec-packages · spartan/environments/mainnet.env
commit 49a592109e · checked 2026-10-09
Verified
The client connects to a node URL of the user's choice (default localhost) with no location check.
AztecProtocol/aztec-packages · yarn-project/cli/src/utils/commands.ts
commit 49a592109e · checked 2026-10-09

Censorship Resistance

Who can block valid use, and can users route around them?

0 FailsPillar rating: weakest of 5
4 of 5 Partial or better

What would raise this pillar

Token and chain freeze risks disclosed reaching Weak: Enumerated in docs only.

Admin pause or freeze powers

Can any privileged role stop, freeze, or block payments through the settlement contracts, and how is that role constrained? C1

2 Partial

Best evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

The rollup contracts have no pause, freeze or blacklist, the Rollup is not a proxy, and the reference Token contract has none either. The committee of staked sequencers can censor by omission, but the escape hatch gives a bonded outsider periodic block-production windows. Any particular token on Aztec is deployed by a third party whose contracts may add controls; the one bridge we sampled (Nyx.money TokenVaultPortal) is Ownable. Judgment call: the substance supports 3 for the protocol layer, but the rollup contracts live on Ethereum while this row's chain is aztec:mainnet, so the dashboard cannot record the onchain reads as onchain evidence (see notes), and third-party token controls are unknown; we take 2.

Evidence (3)3 verified

Verified
The Rollup's owner-only functions set reward config, mana target, proving cost, staking-queue config, a time-delayed slasher swap and a set-once escape hatch; there is no pause, freeze or blacklist. Read on Ethereum at block 26,153,545 (not recordable as onchain evidence here, see notes) with cast, Rollup 0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34 owner() = Governance 0x1102471Eb3378FEE427121c9EfcEa452E4B6B75e, getEscapeHatch() = 0xF459348962F5eA3A9A101826B03A2CE1F459E51A.
AztecProtocol/aztec-packages · l1-contracts/src/core/RollupCore.sol
commit 49a592109e · checked 2026-10-09
Verified
The escape hatch lets a bonded, randomly chosen candidate propose blocks during periodic windows, bypassing the sequencer committee.
AztecProtocol/aztec-packages · l1-contracts/src/core/EscapeHatch.sol
commit 49a592109e · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19
Verified
The reference L2 Token contract's admin can change the admin and minters; it has no pause or blacklist.
AztecProtocol/aztec-packages · noir-projects/noir-contracts/contracts/app/token_contract/src/main.nr
commit 49a592109e · checked 2026-10-09

Settle without the provider

Can a payer or payee complete settlement by calling the public contracts directly, without the provider's API, signer, or relayer? C2

2 Partial

Best evidence: VerifiedChecked 2026-10-09 10 days ago

UnreviewedAssessed by AI research agent (seed), 2026-10-09

A payer proves a private transfer in their own PXE and sends it to any Aztec node, which gossips it to the sequencers; no company API or signature is needed. Judgment call: anchor 3 needs onchain evidence about deployed contracts that this row's chain id cannot carry, and the token contract being paid is third-party, so we take 2.

Evidence (2)2 verified

Verified
transfer_in_private moves a private balance from one account to another, authorised by the sender's account (authorize_once); the user's PXE proves it locally and submits it to any node.
AztecProtocol/aztec-packages · noir-projects/noir-contracts/contracts/app/token_contract/src/main.nr
commit 49a592109e · checked 2026-10-09
Verified
The CLI's node option defaults to http://localhost:8080, the user's own node.
AztecProtocol/aztec-packages · yarn-project/cli/src/utils/commands.ts
commit 49a592109e · checked 2026-10-09

Reliance on hosted services

Does the payment flow require a relayer, paymaster, bundler, or API that only the provider runs? C3

3 Strong

Best evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

No relayer, paymaster or company API is required. Users can run their own node from public code, sequencing and proving are open to stakers and provers, and the escape hatch is a fallback if the committee censors. Fees need Fee Juice bridged from L1, which is a protocol asset rather than a service. Aztec Labs' hosted RPC, network-config and snapshot hosts are conveniences with overrides.

Evidence (2)2 verified

Verified
The repo documents running a full node against the user's own Ethereum execution and beacon endpoints; the CLI defaults to a local node.
AztecProtocol/aztec-packages · docs/docs-operate/operators/full-node/setup.md
commit 49a592109e · checked 2026-10-09
Verified
Block production is by a committee of 48 drawn from 3,085 staked attesters (getTargetCommitteeSize, getActiveAttesterCount on Rollup 0x91fF…8E34 at Ethereum block 26,153,545), with the escape hatch as fallback.
AztecProtocol/aztec-packages · l1-contracts/src/core/EscapeHatch.sol
commit 49a592109e · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

Neutral settlement, disclosed filtering

Is the settlement layer free of address or geographic filtering, and is any filtering at the edge disclosed and avoidable? C4

2 Partial

Best evidence: VerifiedChecked 2026-10-09 10 days ago

UnreviewedAssessed by AI research agent (seed), 2026-10-09

Settlement is neutral: the rollup and the reference token have no address or country checks, and private senders and recipients are not visible to sequencers. The setup-phase allowlist restricts which public functions may run before fees are paid, which shapes fee payment but does not target users. Aztec Labs' hosted RPC sits behind a Cloud Armor policy (spartan/environments/mainnet.env) whose rules are not public. Judgment call: 2, not 3, because 3 needs a distributed-package or trace record and because the hosted RPC's filtering is undisclosed (users can avoid it by running a node).

Evidence (2)2 verified

Verified
Nodes apply a protocol-level allowlist of public functions callable in a transaction's setup phase; it filters functions, not addresses or countries.
AztecProtocol/aztec-packages · docs/docs-developers/docs/aztec-js/how_to_use_private_fee_juice.md
commit 49a592109e · checked 2026-10-09
Verified
The rollup checks proofs and attestations; it has no address or country rule. Code search on 2026-10-09 found no sanctions or geoblocking code (the only country hit is a testnet mock staking handler).
AztecProtocol/aztec-packages · l1-contracts/src/core/RollupCore.sol
commit 49a592109e · checked 2026-10-09

Token and chain freeze risks disclosed

Are the tokens and chains the rail depends on enumerated, with their issuers' freeze powers and sequencer assumptions stated to payees? C5

0 Fails

Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

The rail does not enumerate the tokens a payee might receive: Fee Juice cannot be transferred, and payable assets are app-deployed token contracts bridged through third-party portals with their own owners, which the protocol neither lists nor describes. The sequencer, escape-hatch and upgrade assumptions are stated in the Alpha documentation. Scored 0: tokens not enumerated.

Evidence (2)2 verified

Verified
The protocol's own asset, Fee Juice, can only be bridged in, not withdrawn or transferred, so every payment uses a third-party token.
AztecProtocol/aztec-packages · noir-projects/noir-contracts/contracts/protocol/fee_juice_contract/src/main.nr
commit 49a592109e · checked 2026-10-09
Verified
The mainnet network config lists bootnodes, snapshot hosts, the Registry and the L1 chain, and no token list. Recent L1-to-L2 messages (Ethereum blocks 26,144,545 to 26,153,545) came from an OperationExecutor 0xe883…9e19 and a TokenVaultPortal 0xD0b1…80d0 by Nyx.money, both Sourcify exact matches; the portal is Ownable.
AztecProtocol/networks · network_config.json
commit 7182c14bbb · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

Open

Is the whole stack visible?

1 WeakPillar rating: weakest of 4
3 of 4 Partial or better

What would raise this pillar

Can be self-hosted reaching Partial: Reproducible with minor undocumented steps, recorded.

Contracts verified onchain

Does the deployed bytecode match public source, and can a third party rebuild it? O1

2 Partial

Best evidence: VerifiedChecked 2026-10-09 10 days ago

UnreviewedAssessed by AI research agent (seed), 2026-10-09

All L1 rollup and governance contracts are partial matches on Sourcify. We did not check L2 contract classes (the token contracts users pay with) against source, and attempted no rebuild. Scored 2: partial matches.

Evidence (1)1 verified

Verified
Sourcify on 2026-10-09 returns match (partial) for Registry 0x35b2…e298, Rollup 0x91fF…8E34, Governance 0x1102…B75e, GovernanceProposer 0x06Ef…63ef, GSE 0xa92e…7a4f, Inbox 0x7d4E…b8cA, Outbox 0x5B06…A2D7, FeeJuicePortal 0xaf73…691c, EscapeHatch 0xF459…E51A, Slasher 0xCD68…2548 and the AZTEC token 0xA27E…62D2, all on Ethereum.
AztecProtocol/aztec-packages · l1-contracts/src
commit 49a592109e · checked 2026-10-09

Whole stack published

Are the SDK, frontend, backend or API, indexer, and deploy scripts all public? O2

3 Strong

Best evidence: VerifiedChecked 2026-10-09 10 days ago

UnreviewedAssessed by AI research agent (seed), 2026-10-09

The whole protocol stack is public in one Apache-2.0 monorepo, including node, sequencer, prover, client, contracts and deploy tooling. The hosted RPC's access policy and third-party browser wallets are not public, but neither is needed. Judgment call: we score the stack a user needs, not the hosted conveniences, at 3.

Evidence (1)1 verified

Verified
The monorepo at v5.2.0 contains the node, sequencer, prover, PXE, aztec.js, wallet-sdk and CLI wallet (yarn-project), the L1 contracts (l1-contracts), Noir protocol and app contracts (noir-projects), the proving backend (barretenberg) and network deployment (spartan).
AztecProtocol/aztec-packages · yarn-project
commit 49a592109e · checked 2026-10-09

Can be self-hosted

Can a stranger reach a working deployment from the README? O3

1 Weak

Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-09 10 days ago

UnreviewedAssessed by AI research agent (seed), 2026-10-09

Node setup documentation exists in the repo. Reproduction not attempted, so the score is capped at 1.

Evidence (1)1 verified

Verified
Step-by-step Docker Compose setup for a mainnet full node, with required environment variables.
AztecProtocol/aztec-packages · docs/docs-operate/operators/full-node/setup.md
commit 49a592109e · checked 2026-10-09

Interfaces and data export

Are ABIs, event schemas, an API schema, and a payee data export in a non-proprietary format all in the repo? O4

2 Partial

Best evidence: VerifiedChecked 2026-10-09 10 days ago

UnreviewedAssessed by AI research agent (seed), 2026-10-09

ABIs, events and the node API schema are versioned in the repo. We found no payee export format in the wallet tooling. Scored 2: interfaces present, export absent.

Evidence (1)1 verified

Verified
Contract interfaces (Noir ABIs generated from source, L1 ABIs in l1-artifacts) and the node's typed API schemas (stdlib) are in the repo; a Transfer event is emitted for private transfers.
AztecProtocol/aztec-packages · noir-projects/noir-contracts/contracts/app/token_contract/src/main.nr
commit 49a592109e · checked 2026-10-09

Free

Does the license actually let a third party fork, modify, and run it?

0 FailsPillar rating: weakest of 3
2 of 3 Partial or better

What would raise this pillar

Protection against relicensing reaching Weak: CLA permits relicensing; commitment exists in docs.

Open-source licences

Does every repository needed to run the product carry an OSI-approved license? F1

2 Partial

Best evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

Everything needed to run the protocol is Apache-2.0. The network-config repo the node reads by default has no licence; the same mainnet values are compiled into the CLI (chain_l2_config.ts), so it is not critical. Scored 2: one non-critical repo unlicensed.

Evidence (1)1 verified

Verified
aztec-packages is Apache-2.0; AztecProtocol/networks (the default network config) has no licence file.
AztecProtocol/aztec-packages · LICENSE
commit 49a592109e · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

Protection against relicensing

Can the provider unilaterally relicense future versions, and has it committed not to? F2

0 Fails

Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

There is no CLA and no licence-stability commitment. The monorepo's licence changed from GPL-2.0 to Apache-2.0 days after the repo was created, before any release. Judgment call: anchor 0 names any prior relicense event; this one was early and permissive, but under the take-the-lower-anchor rule we score 0.

Evidence (1)1 verified

Verified
The LICENSE file changed from GPL-2.0 to Apache-2.0 in commit 356db7c7 (2023-02-28), four days after the initial commit, and its copyright holder changed to Aztec Foundation in 82e3c33d (2026-10-06); CONTRIBUTING.md mentions no CLA.
AztecProtocol/aztec-packages · LICENSE
commit 49a592109e · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

No proprietary dependencies

Does a production deployment need a proprietary plugin or hosted-only service? F3

2 Partial

Best evidence: VerifiedChecked 2026-10-09 10 days ago

UnreviewedAssessed by AI research agent (seed), 2026-10-09

A production setup (own node, PXE, wallet) needs no proprietary plugin; hosted RPC, snapshots and third-party wallets are optional. Judgment call: the code supports 3, but with no O3 reproduction we take 2.

Evidence (1)1 verified

Verified
The client defaults to a local node; the node needs only Ethereum endpoints the operator chooses.
AztecProtocol/aztec-packages · yarn-project/cli/src/utils/commands.ts
commit 49a592109e · checked 2026-10-09

Privacy

What can an observer learn, and did the user knowingly choose it?

2 PartialPillar rating: weakest of 5
5 of 5 Partial or better

What would raise this pillar

Tracking and analytics reaching Strong: None in SDK, widget, or frontend manifests and lockfiles, confirmed by trace.
Payments linkable onchain reaching Strong: No payee identifiers, invoice metadata, or payer-payee linkage in calldata or events beyond what settlement needs; fresh addresses or stealth/privacy patterns available.
Third parties in the payment flow reaching Strong: Only the configured RPC; no third-party indexer, risk-scoring, or pricing vendor in the critical path.

Tracking and analytics

Do the SDK, widget, or frontend ship analytics, telemetry, error reporting, or fingerprinting? P1

2 Partial

Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-09 10 days ago

UnreviewedAssessed by AI research agent (seed), 2026-10-09

The client libraries ship no analytics or telemetry. Third-party browser wallets were not inspected. Judgment call: absence shown in code and the published package, without a trace, is capped at 2.

Evidence (1)1 verified

Verified
No analytics, telemetry or error-reporting dependency in the pxe, aztec.js, wallet-sdk or cli-wallet manifests; the node's OpenTelemetry export is operator-side and needs an endpoint configured.
AztecProtocol/aztec-packages · yarn-project/pxe/package.json
commit 49a592109e · checked 2026-10-09

Data collected beyond payment

Does the flow collect anything beyond addresses, amounts, token, and chain? P2

3 Strong

Best evidence: VerifiedChecked 2026-10-09 10 days ago

UnreviewedAssessed by AI research agent (seed), 2026-10-09

The protocol and reference token collect only what settlement needs, and no required component holds identity data. A third-party node, if used, sees the user's IP and queries (P4).

Evidence (1)1 verified

Verified
A private transfer takes sender, recipient, amount and an authorisation nonce; nothing else.
AztecProtocol/aztec-packages · noir-projects/noir-contracts/contracts/app/token_contract/src/main.nr
commit 49a592109e · checked 2026-10-09

Payments linkable onchain

What do calldata and events reveal about who paid whom for what? P3

2 Partial

Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-09 10 days ago

UnreviewedAssessed by AI research agent (seed), 2026-10-09

A private token transfer hides the recipient and amount. Unless the payer uses a private fee payment contract, the payer's own account pays the fee and is recorded publicly as fee payer, so the chain shows who sent a private transaction, though not to whom. Side-effect counts give transaction fingerprints, and the docs warn that the zk property is not yet guaranteed. All of this is documented. Judgment call: minimal, documented linkage is anchor 2.

Evidence (2)2 verified

Verified
Private calldata and identities are hidden, but the transaction's fee payer address is recorded onchain by the protocol.
AztecProtocol/aztec-packages · docs/docs-developers/docs/aztec-js/how_to_use_private_fee_juice.md
commit 49a592109e · checked 2026-10-09
Verified
msg_sender leaks on private-to-public calls by default, and the counts of public calls and L2-to-L1 messages remain visible.
AztecProtocol/aztec-packages · docs/docs-developers/docs/resources/considerations/limitations.md
commit 49a592109e · checked 2026-10-09

Third parties in the payment flow

Which third parties see a request during a payment, and can they be swapped out? P4

2 Partial

Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-09 10 days ago

UnreviewedAssessed by AI research agent (seed), 2026-10-09

With a local node, only the user's Ethereum endpoints see anything. With a remote node (for example Aztec Labs' hosted RPC), that operator sees the user's IP, the transactions they send and the notes and logs they query. The node URL is named in code and swappable. Scored 2.

Evidence (1)1 verified

Verified
The docs state there are no privacy-preserving queries to third-party nodes; a user who queries someone else's node may reveal who they are and their activity.
AztecProtocol/aztec-packages · docs/docs-developers/docs/resources/considerations/limitations.md
commit 49a592109e · checked 2026-10-09

Endpoints can be changed

Can RPC and indexer URLs be changed, and is the indexer code public? P5

3 Strong

Best evidence: VerifiedChecked 2026-10-09 10 days ago

UnreviewedAssessed by AI research agent (seed), 2026-10-09

The data endpoint is configurable in the client, and the node that serves it is public. Scored 3.

Evidence (1)1 verified

Verified
The node URL is a CLI option and AZTEC_NODE_URL environment variable; the node, which also serves as the indexer, is public code.
AztecProtocol/aztec-packages · yarn-project/cli/src/utils/commands.ts
commit 49a592109e · checked 2026-10-09

Security

Who can cause loss, lock users in, or change the rules?

1 WeakPillar rating: weakest of 6
5 of 6 Partial or better

What would raise this pillar

Audits and bug bounty reaching Partial: Audit pinned to a commit, resolutions not individually linked.

Who holds funds in transit

Who holds funds between payer and payee, and can the provider redirect them? S1

2 Partial

Best evidence: VerifiedChecked 2026-10-09 10 days ago

UnreviewedAssessed by AI research agent (seed), 2026-10-09

Funds move directly between users' notes; no one holds them in flight. The L1 backing of a bridged token sits in that token's portal, controlled by its owner, and the rollup's correctness rests on circuits the project itself calls under-constrained. Judgment call: direct transfer is anchor 3 in substance, but 3 needs onchain evidence this row cannot carry, and the soundness caveat argues against the top score; we take 2.

Evidence (2)2 verified

Verified
A private transfer nullifies the sender's notes and creates notes owned by the recipient in the same transaction.
AztecProtocol/aztec-packages · noir-projects/noir-contracts/contracts/app/token_contract/src/main.nr
commit 49a592109e · checked 2026-10-09
Verified
The docs say some complex circuits are still under-constrained, so proof soundness is not guaranteed.
AztecProtocol/aztec-packages · docs/docs-developers/docs/resources/considerations/limitations.md
commit 49a592109e · checked 2026-10-09

Who can upgrade the code

Who can change the contract code, and with how much notice? S2

2 Partial

Best evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

Deployed rollup code cannot be changed in place: upgrades register a new rollup version, which needs sequencer signalling plus an AZTEC token vote, at least 12 days from proposal to execution (3-day delay, 7-day vote, 2-day execution delay), far longer than the roughly one-epoch exit to L1. The old rollup stays usable for exits. But state does not migrate, so users must move funds at each upgrade, and governance execution can call any contract. Judgment call: the timelock exceeds the user exit and the notice channel is the Alpha docs, which supports 3 in substance; we take 2 because 3 needs onchain evidence this row cannot carry and because forced migrations shift work and risk onto users.

Evidence (3)3 verified

Verified
Only the GovernanceProposer (sequencer signalling, 600 of 1,000 slots per round) can propose; execute() (L488-L506) runs arbitrary calls except to the governance asset. Read on Ethereum at block 26,153,545 with cast getConfiguration() on 0x1102…B75e - votingDelay 259200 s, votingDuration 604800 s, executionDelay 172800 s, gracePeriod 604800 s, quorum 20%, yea margin 33%; proposalCount 5.
AztecProtocol/aztec-packages · l1-contracts/src/governance/Governance.sol
commit 49a592109e · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19
Verified
Upgrades add a new rollup version to the Registry (owner-only addRollup); Registry owner() and getGovernance() both return Governance 0x1102…B75e, numberOfVersions() is 3, and the Rollup's EIP-1967 implementation and admin slots are zero (no proxy) at block 26,153,545.
AztecProtocol/aztec-packages · l1-contracts/src/governance/Registry.sol
commit 49a592109e · checked 2026-10-09
Verified
The Alpha page says a new rollup version becomes canonical while the old one stays accessible for bridging out, state does not carry over, and applications must redeploy.
AztecProtocol/aztec-packages · docs/docs-participate/alpha.md
commit 49a592109e · checked 2026-10-09

Token approval scope

How large an allowance does the SDK ask users to grant, and for how long? S3

2 Partial

Best evidence: VerifiedChecked 2026-10-09 10 days ago

UnreviewedAssessed by AI research agent (seed), 2026-10-09

The reference token uses one-time authorisations for an exact action instead of allowances, and a direct transfer needs none. Judgment call: anchor 3 in substance, but 3 needs a distributed-package or trace record for the client, so we take 2; third-party tokens may differ.

Evidence (1)1 verified

Verified
Spending on another's behalf uses authwits (authorize_once) that authorise one exact call with a nonce and can be cancelled (cancel_authwit); the token has no standing allowance.
AztecProtocol/aztec-packages · noir-projects/noir-contracts/contracts/app/token_contract/src/main.nr
commit 49a592109e · checked 2026-10-09

Funds safe if provider disappears Derived

If the provider disappears tomorrow, do payees keep their funds and the ability to keep settling? S4

2 Partial

Best evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

Derived from S1=2, C2=2, C3=3 and O3=1. Funds are notes under the user's keys (S1), any node accepts a transaction (C2), and no company service is required (C3). If Aztec Labs disappeared, users could run a node and exit through the token's portal and the ownerless Outbox. Fee Juice cannot be withdrawn at all, and a bridged token's exit depends on its portal owner. We did not reproduce a self-hosted setup (O3=1). Judgment call: 2.

Evidence (1)1 verified

Verified
If the committee stops including a user's transactions, escape-hatch windows let a bonded candidate produce blocks; Outbox and FeeJuicePortal have no owner.
AztecProtocol/aztec-packages · l1-contracts/src/core/EscapeHatch.sol
commit 49a592109e · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

Secrets and webhook handling

Are secrets kept out of client bundles and are webhooks signed and verified? S5

2 Partial

Best evidence: VerifiedChecked 2026-10-09 10 days ago

UnreviewedAssessed by AI research agent (seed), 2026-10-09

Account keys stay in the user's PXE, and the protocol has no webhooks. The limitations page warns that the PXE does not yet enforce which apps can read a user's private data. Judgment call: 2, since 3 needs a package or trace record and the PXE data-access caveat is documented.

Evidence (1)1 verified

Verified
Keys and API keys come from the user's environment (PRIVATE_KEY, MNEMONIC, API_KEY); nothing is bundled.
AztecProtocol/aztec-packages · yarn-project/cli/src/utils/commands.ts
commit 49a592109e · checked 2026-10-09

Audits and bug bounty

Has the code been audited at a pinned commit, were findings fixed traceably, and is there a live bounty? S6

1 Weak

Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

Audit reports exist for the L1 contracts and parts of the proving library, but we did not read them for pinned commits, and the project's own docs say no part of the stack has been fully audited and some circuits are under-constrained. A bounty page is linked, with scope outside the repo. Scored 1: reports only, nothing pinned.

Evidence (2)2 verified

Verified
Cantina reports on the rollup contracts, governance, escape hatch and staking registry, Veridise on governance, and a governance formal verification are published; Barretenberg primitives have separate reports.
AztecProtocol/audit-reports · l1-contracts
commit b3b60cefe2 · checked 2026-10-09
Verified
SECURITY.md says a limited-scope bug bounty is being prepared and also links a Cantina bounty page for submissions; scope is not in the repo.
AztecProtocol/aztec-packages · SECURITY.md
commit 49a592109e · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

Security audits 14

Published audits and similar reviews of this provider's code, newest first. Context for the Audits and bug bounty rating, which scores them; this list does not change any rating, and an audit of older code says little about what is deployed now.

Date	Auditor	Type	Scope	Covers deployed code	Findings
2026-04-06	Cyfrin	Audit	Barretenberg stdlib logic module (in-circuit AND/XOR constraints), part of the proving system. Shared proving-system code; the report gives no commit, so we could not match it to v5.2.0.	Partly	4 low, 4 informational
2026-03-05	Cantina	Security review	Alpha upgrade payload and deployment (DeployAlpha.s.sol, run_alpha_upgrade.sh, AlphaPayload.sol, AlphaVerifier.sol) plus PR 21066 updating the verification-key tree root. at `ed3f61d6` The file name says 2025.03.05; the report is dated March 5, 2026 (Aztec PR 20865).	Unknown	1 high (fixed), 4 informational (acknowledged)
2026-02-24	Cantina	Audit	L1 EscapeHatch contract (forced exit path when the sequencer set censors). at `0092f9f0` Audited before the v5.2.0 release (49a59210) used for this assessment; we did not diff EscapeHatch.sol.	Partly	1 high, 6 medium, 5 low, 3 gas, 16 informational; 16 fixed, 15 acknowledged
2026-01	Sherlock	Audit	Barretenberg cycle_group (Grumpkin in-circuit curve operations) and RAM/ROM memory modules. at `c58cd76497` Audited January 14 to 28, 2026; fix review at 6b858739.	Partly	1 high, 4 medium, 3 low/info; all resolved or acknowledged
2025-12-16	Cantina	Audit	Barretenberg stdlib field primitive. at `458fb330`	Partly	3 low, 14 informational; all fixed
2025-11-12	Cantina	Audit	L1 rollup contracts at the stated commit (findings span the Rollup, Outbox and related libraries) and the EmpireSlashingProposer change (PR 16357). at `270e2a58ae` The deployed Rollup v5 was built from a later commit (v5.2.0, 49a59210); we did not diff the contracts.	Partly	1 critical, 2 high, 6 medium, 6 low, 1 gas, 7 informational; 15 fixed, 8 acknowledged
2025-11-12	Cantina	Audit	L1 governance contracts (findings span Governance, the EmpireBase signalling used by GovernanceProposer, and GSE). at `6496e59d`	Partly	4 medium, 6 low, 1 gas, 9 informational; 15 fixed, 4 acknowledged
2025-11-10	Cantina	Audit	Barretenberg stdlib bool and byte_array primitives. at `72f52e7b`	Partly	2 critical, 3 medium, 5 low, 5 informational; all fixed
2025-10-13	Veridise	Audit	L1 governance contracts, including GSE and the BN254 library. at `a6eebac`	Partly	10 issues, 1 medium
2025-09-18	Veridise	Audit	Barretenberg bigfield (non-native field arithmetic) in the proving system. at `480f49d`	Partly	9 issues, none high or critical; 3 low
2025-09-15	Igor Konnov and Thomas Pani	Formal verification	Formal verification (Quint/TLA+) of the L1 governance contracts EmpireBase, GovernanceProposer, Governance, GSE and SlashingProposer. at `8b10b2b2` Commit range ffc8af0c to 8b10b2b2.	Partly	0 critical, 0 high, 5 medium, 3 low, 6 informational
2024-10-04	Cantina	Audit	Barretenberg bigfield, one of three parallel reviews of the same commit. at `4ba553ba` Superseded in part by Veridise's 2025 bigfield audit.	Partly	2 critical, 1 high, 2 medium, 2 low, 10 informational
2024-07-25	Zellic	Audit	Barretenberg bigfield proof circuit. at `d9ca76a2`	Partly	5 critical, 2 high, 8 low, 2 informational
2024-07-01	zkSecurity	Audit	Barretenberg bigfield and field modules. at `4ba553ba31`	Partly

Compiled from: github.com/AztecProtocol/audit-reports at b3b60cef (l1-contracts, Barretenberg and TGE folders), SECURITY.md and barretenberg/cpp/scripts/audit (scope files, not reports) in aztec-packages, the noir-lang/noir repo (no audits folder), and the Trail of Bits publications list. Not listed: the TGE reports (Spearbit, zkSecurity), Cantina's Soulbound, Uniswap TWAP, Protocol Treasury, Coinissuer and Ignition staking-registry reviews, which cover token-sale, treasury, reward and staking contracts outside the transfer path; Trail of Bits' 2019 review of the earlier AZTEC Protocol; and Aztec Connect audits (a retired product). No published audit of the protocol circuits, PXE or Noir compiler was found; the docs say the stack is not fully audited. Checked 2026-10-13. Only published reports are listed; private audits a provider mentions without a report are not.

Operational and procurement

Facts an institution's procurement, finance and security functions ask for. Separate from the CROPS ratings and never scored.

Group A: operational facts. Group B: 45 due-diligence controls derived from a UN agency's vendor requirements: 13 evidenced, 0 attested, 4 absent, 27 not applicable, 1 unknown. "Not applicable" means there is no operator to hold the control: it falls to whoever deploys the rail. How to read this.

Group A: operational facts

Fees

Evidenced

Component	Paid by	Amount	Basis
network	payer	Mana used x fee per mana, in Fee Juice; minimum about 2.27e-6 AZTEC per mana on 2026-10-09	Rollup FeeLib minimum = sequencer cost (L1 gas and blobs) + prover cost (provingCostPerMana, set by governance) + congestion cost (burned), converted at an oracle ETH/fee-asset rate. Paid from a non-transferable Fee Juice balance or by a fee-paying contract.
network	payer	Optional priority fee per mana, set by the user in gas settings	EIP-1559-style max and priority fee per mana chosen by the sender. Unburnt fees per epoch go 70% to the block proposer and 30% to provers.

No protocol or Aztec Labs fee. The payer needs Fee Juice bridged from AZTEC on Ethereum through the one-way FeeJuicePortal (an L1 transaction with its own ETH gas), or a third-party fee-paying contract, which may charge in other tokens and whose terms were not reviewed. The Fee Juice per transaction depends on its mana use, which was not sampled.

Verified
getManaMinFeeComponentsAt sums sequencer, prover and congestion cost per mana. Read on Ethereum at block 26,154,934 (2026-10-09) with cast on Rollup 0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34 (chain 1, not recordable as onchain evidence for an aztec:mainnet row) gives getManaMinFeeAt = 2,269,387,395,825; components congestionCost 0, multiplier 1e9 (minimum), sequencerCost 122,988,048,037, proverCost 2,146,399,347,788; manaTarget 75,000,000.
AztecProtocol/aztec-packages · l1-contracts/src/core/libraries/rollup/FeeLib.sol
commit 49a592109e · checked 2026-10-09
Verified
fee = daMana x feePerDaMana + l2Mana x feePerL2Mana; Fee Juice is bridged AZTEC and non-transferable; base and priority fees per mana as in EIP-1559. L141-L143 says collected fees, minus burnt congestion, go to provers and block proposers once an epoch is proven.
AztecProtocol/aztec-packages · docs/docs-developers/docs/foundational-topics/fees.md
commit 49a592109e · checked 2026-10-09
Verified
Congestion cost is burned; of the remainder 70% goes to the sequencer and 30% to provers.
AztecProtocol/aztec-packages · docs/docs-participate/token/economics.md
commit 49a592109e · checked 2026-10-09

UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09

Custody model

Evidenced

Self-custody

Agrees with the S1 finding (anchor 3 in substance, held at 2). A private transfer nullifies the sender's notes and creates notes for the recipient; keys stay in the user's PXE. The L1 backing of a bridged token sits in that token's portal under its owner's control, and the docs call some circuits under-constrained.

Evidence shared with CROPS: S1 item 1, S1 item 2

UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09

Licences and registrations

Absent

Searched: Aztec Labs and Aztec Foundation terms and privacy policies, the Companies House entry. Not searched: the FCA cryptoasset register and Financial Services Register (client-rendered) and FINMA's lists. Neither entity transmits or holds users' funds on the rail, so a licence would be expected only for services outside it.

Documented
Aztec Labs' terms name Spilsbury Holdings Limited as a software developer, disclaim investment advice and brokerage, and cite no licence or regulator.
aztec-labs.com/terms-of-service.html
checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19
Documented
Companies House entry, active, nature of business SIC 62012 (business and domestic software development).
find-and-update.company-information.service.gov.uk/company/11093783
checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19
Documented
Aztec Foundation (Swiss Stiftung, Zug) terms describe stewardship of open-source software and cite no licence or regulator.
aztec.network/terms-of-service
checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09

Cash-out options

N/A: falls to the institution

No fiat leg. The payee receives notes of an app-deployed token on Aztec; leaving means bridging the token out through its third-party L1 portal and converting on Ethereum, outside the protocol.

UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09

First deployment

Evidenced

2025-11-13 (block 23786836): First Aztec mainnet rollup (Registry index 0, 0x603b…CA12) at Ethereum block 23,786,836. The canonical v5 Rollup (0x91fF…8E34) was deployed at block 25,428,902 on 2026-06-30.

Judgment call. The first rollup in the mainnet Registry is recorded. State does not carry over between rollup versions (alpha.md L60-L77), so the deployment that holds today's notes dates from 2026-06-30, and the docs describe the network as Alpha. The block number is an Ethereum L1 block.

Verified
Sourcify records the creation transaction 0x2e76…a254 in Ethereum block 23,786,836 (timestamp 2025-11-13 00:52:35 UTC from the block header). Registry 0x35b2…e298 was created nine blocks earlier (23,786,827). Registry getRollup(0) returns this address; getVersion lists three versions (0, 2934756905, 4248422647).
0x603b…CA12 on sourcify.dev
0x603b…CA12 explorer · Sourcify · block 23786836 · checked 2026-10-09
Verified
Canonical Rollup (Registry getCanonicalRollup) created in Ethereum block 25,428,902, 2026-06-30 07:08:47 UTC; exact Sourcify match.
0x91fF…8E34 on sourcify.dev
0x91fF…8E34 explorer · Sourcify · block 25428902 · checked 2026-10-09

UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09

Operating entity

Evidenced

Spilsbury Holdings Limited (trading as Aztec Labs), GB · 11093783 · register

Judgment call. Aztec Labs is recorded as the maintaining organisation, as directed. Aztec Foundation (Swiss Stiftung, Zug) runs aztec.network, stewards development and since 2026-10-06 is the copyright holder in aztec-packages' LICENSE; its Swiss commercial-register entry was not looked up.

Documented
Aztec Labs terms identify the company behind the Aztec Labs name; Aztec Labs runs the hosted mainnet RPC and the snapshot hosts.
aztec-labs.com/terms-of-service.html
checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19
Documented
Companies House entry, status active, incorporated 2017-12-04.
find-and-update.company-information.service.gov.uk/company/11093783
checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09

Security incidents

Evidenced

2026-05-11: SECURITY.md reports 8 critical and 7 high vulnerabilities found internally and by external audits in Aztec Network v4 (the mainnet version until v5); no details or exploitation statement are given. funds lost: unknown source
2026-07-28: GHSA-778c-2h5c-8r96 (low) - a checkpoint of over 72 blocks pushed through the escape hatch and proven would halt L2 nodes (uncaught validation error in the archiver). funds lost: no source
2026-10-08: GHSA-2hc8-mq24-76v2 (high) - the native UltraHonk verifier in barretenberg accepted recursive proofs with a malformed pairing accumulator; fixed in v5.2.1, which the release notes say does not affect the Aztec network. funds lost: no source

Absence of a found incident is not evidence that none occurred.

The medium advisory (same verifier, abort on a point at infinity) is not listed separately. Release v4.2.1 (2026-05-07) was a mandatory hotfix restoring governance signalling, a liveness bug rather than an incident. No post-mortem of a mainnet halt was found. The docs say no part of the stack is fully audited and halts are expected during Alpha.

Verified
Three published advisories (GHSA-73xc-j27q-wg75 medium, GHSA-2hc8-mq24-76v2 high, GHSA-778c-2h5c-8r96 low) on 2026-10-09.
api.github.com/repos/AztecProtocol/aztec-packages/security-advisories
checked 2026-10-09
Verified
Table of high and critical vulnerabilities discovered in v4 by 2026-05-11.
AztecProtocol/aztec-packages · SECURITY.md
commit 49a592109e · checked 2026-10-09

UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09

Product changes affecting users

Evidenced

2025-11-13: Registry and first rollup deployed on Ethereum (blocks 23,786,827 and 23,786,836). source
2026-03-04: Second rollup version (Registry version 2934756905, 0xAe20…4962) deployed at Ethereum block 24,586,322. source
2026-06-30: Third rollup version (Registry version 4248422647, 0x91fF…8E34), now canonical, deployed at Ethereum block 25,428,902; v5.0.0 (2026-07-11) is the first release supported on mainnet for it. State does not migrate between versions. source

The date each version became canonical (a governance action) was not read; deployment dates are recorded. Governance had 5 proposals at the seed read.

Verified
Registry numberOfVersions() = 3; getRollup for versions 0, 2934756905 and 4248422647 returns 0x603b…CA12, 0xAe20…4962 and 0x91fF…8E34; getCanonicalRollup() = 0x91fF…8E34. Deployment blocks from Sourcify, dates from the block headers.
0x35b2…e298 on sourcify.dev
0x35b2…e298 explorer · Sourcify · block 26154934 · checked 2026-10-09

UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09

Volume transacted (verified only)

Not observable

Private transfers move value between encrypted notes inside the rollup; only nullifiers, note hashes and fee payers reach Ethereum, never amounts or tokens. Public L1 events (portal deposits and withdrawals, checkpoint proposals) are bridging and rollup bookkeeping, not payment settlement. The volume script reads EVM logs over the provider's listed contracts only, and this row lists none because its primary chain is aztec:mainnet.

UnreviewedAssessed by AI research agent (operational), 2026-10-09

Group B: institutional due diligence

Control	State	What was found
Assurance and certifications
B1.1 ISO 27001, developer organisation Is the organisation that develops the product ISO 27001 certified, and does the certificate name that entity?	N/A: falls to the institution implied from the component list
B1.2 ISO 27001, hosting and support organisation Is the organisation that hosts and supports the service ISO 27001 certified in its own name, with a scope covering the service?	N/A: falls to the institution implied from the component list
B1.3 SOC 2 Type II or ISAE 3000/3402 reports Does the provider undergo periodic SOC 2 Type II or ISAE 3402 Type II assessments and make reports available?	N/A: falls to the institution implied from the component list
B1.4 Independent source-code security review before go-live Was the application reviewed by an independent party before launch, and is the report linked?	N/A: falls to the institution implied from the component list
B1.5 Penetration testing Is the service penetration-tested before go-live and at least every three years, with results available?	N/A: falls to the institution implied from the component list
B1.6 Vulnerability scanning cadence Are the platform and the application scanned for vulnerabilities at least every six months?	N/A: falls to the institution implied from the component list
Vulnerability and patch management
B2.1 Security contact and disclosure policy Is there a published way to report a vulnerability (SECURITY.md, security.txt, or a disclosure page)?	Evidenced	some of 2 repo(s): AztecProtocol/aztec-packages ✓ security policy file: SECURITY.md; AztecProtocol/networks ✗ no security policy file source 1 · source 2
B2.2 Patch service levels Does the provider commit to patch timelines for known vulnerabilities (the partner expects 30 days critical, 40 high, 90 medium)?	N/A: falls to the institution implied from the component list
B2.3 Dependency and vulnerability scanning in CI Do the public repositories run dependency or code scanning automatically?	Evidenced	some of 2 repo(s): AztecProtocol/aztec-packages ✓ scanning step in a workflow; AztecProtocol/networks ✗ no scanning config or workflow step found source 1 · source 2
Incident reporting and continuity
B3.1 Incident reporting commitment Does the provider commit to notify customers of security or data incidents within a stated time (the partner expects 24 hours)?	N/A: falls to the institution implied from the component list
B3.2 Backups and restore testing Are customer records backed up daily and restores tested on a schedule?	N/A: no such service implied from the component list
B3.3 Recovery plan Is there an approved and tested recovery plan for the service?	N/A: no such service implied from the component list
B3.4 Status page and post-mortems Does the provider publish service status and post-mortems for incidents?	N/A: falls to the institution implied from the component list
Identity and access (operator side)
B4.1 MFA for end users Can or must end users protect accounts with multi-factor authentication?	N/A: no such service implied from the component list
B4.2 MFA and separate accounts for privileged access Is privileged access protected by MFA and kept on separate accounts?	N/A: falls to the institution implied from the component list
B4.3 Periodic access reviews Are user access rights reviewed at least annually and privileged accounts at least six-monthly?	N/A: falls to the institution implied from the component list
B4.4 Segregation of duties and joiner-mover-leaver controls Is there a documented segregation-of-duties model and a joiner-mover-leaver process?	N/A: falls to the institution implied from the component list
B4.5 Session timeout Are idle interactive sessions terminated after a defined period (the partner expects 60 minutes)?	N/A: no such service implied from the component list
API and integration
B5.1 API authentication, browser to server Which standard (OAuth 2.0, OpenID Connect, SAML, JWT) protects browser-to-server API calls?	N/A: falls to the institution implied from the component list
B5.2 API authentication, server to server Are server-to-server calls authenticated with keys or PKI certificates, and are keys scoped and rotatable?	N/A: falls to the institution implied from the component list
B5.3 Token expiry Do API tokens expire, and within what period (the partner caps it at 120 minutes for public data, 30 otherwise)?	N/A: falls to the institution implied from the component list
B5.4 Export controls If an API exports data, does it limit volumes and log exports?	N/A: falls to the institution implied from the component list
Data protection and privacy governance
B6.1 Data classification and encryption Does the provider state a data classification and enforce encryption at rest and TLS 1.2 or better in transit?	N/A: falls to the institution implied from the component list
B6.2 Production data kept out of test environments Does the provider state that production or real personal data is not used in development and testing?	N/A: falls to the institution implied from the component list
B6.3 Data retention and deletion on termination What is retained, for how long, and is customer data removed on termination?	Evidenced	Aztec Labs' privacy policy keeps contact data, technical usage data and service-use data for 12 months, then may keep it in anonymised form. Its scope is the Aztec Labs website and services; it does not mention the hosted mainnet RPC, whose ingress logs every request (log sample rate 1.0) per the deployment config. Position of a hosted service Aztec Labs runs; the rail does not require it (users can run their own node, see C3). Cross-reference CROPS P2. source 1 · source 2
B6.4 Data protection impact assessment and roles For systems holding personal data, has a DPIA been completed and are controller and processor defined?	N/A: falls to the institution implied from the component list
B6.5 Data processing or sharing agreement available Can a customer obtain a data processing agreement or equivalent?	N/A: falls to the institution implied from the component list
Logging and monitoring
B7.1 Audit logging Are account changes, logins and activity on important records logged and retained?	N/A: falls to the institution implied from the component list
B7.2 Central monitoring and endpoint detection Are logs sent to a managed SIEM and is endpoint detection running on all platforms?	N/A: falls to the institution implied from the component list
Hosting and network
B8.1 Hardened hosting Are hosts hardened to a recognised benchmark, with only essential ports open, IDS/IPS, a WAF for internet-facing applications and tenant isolation?	Evidenced	Partial. The hosted mainnet RPC is deployed on Google Cloud behind a named Cloud Armor (WAF) policy; the policy rules, host hardening benchmark, IDS/IPS and open ports are not published. Applies only to Aztec Labs' optional hosted RPC. No external port scan was run. source 1
B8.2 Deployment configuration and infrastructure as code Does the repository ship reproducible deployment configuration (containers, IaC, Helm) that a self-hoster can harden?	Absent	none of 2 repo(s): AztecProtocol/aztec-packages ✗ no deployment configuration; AztecProtocol/networks ✗ no deployment configuration source 1 · source 2
Engineering practice in public repositories
B9.1 Default branch protected Does the default branch require reviews and passing checks, with no direct pushes?	Evidenced	all of 2 repo(s): AztecProtocol/aztec-packages ✓ rules: deletion, non_fast_forward, pull_request, required_status_checks; AztecProtocol/networks ✓ rules: deletion, non_fast_forward, pull_request source 1 · source 2
B9.2 CI runs on pull requests Does every pull request trigger automated checks?	Evidenced	all of 2 repo(s): AztecProtocol/aztec-packages ✓ 26 workflow file(s); AztecProtocol/networks ✓ 2 workflow file(s) source 1 · source 2
B9.3 Tests run in CI Do the CI workflows run the test suite?	Absent	none of 2 repo(s): AztecProtocol/aztec-packages ✗ test command in a workflow; AztecProtocol/networks ✗ test command in a workflow source 1 · source 2
B9.4 Coverage reported Is test coverage measured and reported (the partner expects 85%)?	Absent	none of 2 repo(s): AztecProtocol/aztec-packages ✗ coverage tooling referenced; AztecProtocol/networks ✗ coverage tooling referenced source 1 · source 2
B9.5 Versioned releases Are releases tagged with immutable semantic versions?	Evidenced	some of 2 repo(s): AztecProtocol/aztec-packages ✓ latest tags: v7.0.0-nightly.20261019, v7.0.0-nightly.20261018, v7.0.0-nightly.20261017; AztecProtocol/networks ✗ no tags source 1 · source 2
B9.6 Signed tags or commits Are release tags or recent commits cryptographically signed?	Evidenced	all of 2 repo(s): AztecProtocol/aztec-packages ✓ 9 of 10 recent commits signed; AztecProtocol/networks ✓ 7 of 10 recent commits signed source 1 · source 2
B9.7 Changelog Is a changelog maintained with the code?	Evidenced	some of 2 repo(s): AztecProtocol/aztec-packages ✓ CHANGELOG file; AztecProtocol/networks ✗ no changelog or release notes source 1 · source 2
B9.8 Contribution and branching model documented Does the README or contribution guide state how changes are proposed, reviewed and released?	Evidenced	some of 2 repo(s): AztecProtocol/aztec-packages ✓ CONTRIBUTING file; AztecProtocol/networks ✗ none found source 1 · source 2
Architecture documentation
B10.1 Architecture documentation Is there a public architecture document covering logical, infrastructure and integration architecture and the components used?	Evidenced	Logical and integration views. The docs describe the client-side PXE, the public AVM on nodes, private and public state, L1-L2 messaging and the L1 contracts; the deployment configs in spartan/ describe Aztec Labs' own infrastructure but there is no prose infrastructure view for self-hosters beyond the node setup guide. source 1
Commercial and financial
B11.1 Contracting entity Which legal entity would an institution contract with, and in which jurisdiction?	Evidenced	No terms cover the hosted mainnet RPC. Aztec Labs' terms (Spilsbury Holdings Limited, England and Wales, English law, London arbitration) cover its website and testnet tools; Aztec Foundation's terms (Swiss Stiftung, Zug) cover aztec.network. The rail itself has no contracting party. source 1 · source 2
B11.2 Funding of ongoing operation How is ongoing operation and maintenance funded (revenue, foundation, grants, fee switch), per a primary source?	Evidenced	Protocol rewards fund operators, not developers. AZTEC is minted in advance to a RewardDistributor and paid at 400 AZTEC per slot (70% sequencer, 30% provers), adjustable by governance; unburnt fees go to the same parties. Development is stewarded by Aztec Foundation and carried out by Aztec Labs, a private company; their funding was not read from a primary source. source 1 · source 2
B11.3 Termination terms What happens to customer funds and data on termination by either side?	N/A: falls to the institution implied from the component list
AI components
B12.1 AI in the payment path Does an AI system take part in payment processing or compliance decisions (for example automated transaction screening)?	Absent	Inclusion depends on proofs, fees and a protocol allowlist of setup-phase public functions (a static list, not a screen of addresses). The seed code search for sanction, country and geoblock found no screening. The Cloud Armor policy on the hosted RPC is unpublished and is not in the payment path when a user runs a node. CROPS C4 · CROPS C4
B12.2 AI controls documented If AI is used, are monitoring, validation, override, decommissioning and bias evaluation documented?	Unknown implied from the component list

Scope of assessment

Components in the payment path

Component	Role	Public	Licence	Operator	Required
Aztec L1 rollup contracts on Ethereum (Registry, Rollup v5, Inbox, Outbox)	contracts	Yes	Apache-2.0	Aztec Governance (Registry owner; Rollup parameter owner)	Yes
Aztec L2 network (staked sequencer committee, provers, escape hatch)	ledger	Yes	Apache-2.0	3,085 staked attesters at Ethereum block 26,153,545; permissionless provers	Yes
Ethereum mainnet (L1 settlement and data availability)	ledger	Yes	LGPL-3.0	Ethereum validators	Yes
Aztec node (own, or someone else's), with an Ethereum execution and beacon RPC	backend	Yes	Apache-2.0	user or node operator	Yes
PXE and wallet (aztec.js, wallet-sdk, aztec-wallet CLI)	wallet	Yes	Apache-2.0	user	Yes
Fee Juice and FeeJuicePortal (non-transferable fee asset bridged from L1)	other	Yes	Apache-2.0	none (portal immutable); fee asset bridged from the AZTEC L1 token	Yes
Token contract and L1 portal of the asset being paid (third-party)	contracts	Yes	Apache-2.0	token and bridge owners (e.g. Nyx.money TokenVaultPortal, Ownable)	Yes
Aztec Governance and GovernanceProposer (sequencer signalling, token vote)	other	Yes	Apache-2.0	AZTEC token holders and sequencers	No
Aztec Labs hosted RPC (mainnet.rpc.aztec-labs.com, Cloud Armor policy)	api	No	proprietary	Aztec Labs	No
Network config and snapshot hosts (networks repo, aztec-labs-snapshots.com)	other	Yes	none	Aztec Labs	No
Third-party browser wallets and fee payment contracts (not reviewed)	wallet	No	proprietary	wallet and FPC developers	No

Repositories

Repository	Role	License
AztecProtocol/aztec-packages	contracts	Apache-2.0
AztecProtocol/networks	deploy	none

Contracts

None listed.

Assessor notes

Unit: Aztec Alpha mainnet private token transfers. Pins: aztec-packages@49a59210 (v5.2.0; v5.2.1 changes only barretenberg), networks@7182c14b, audit-reports@b3b60cef. Ethereum reads at block 26,153,545 via publicnode: Registry 0x35b22e09Ee0390539439E24f06Da43D83f90e298, canonical Rollup 0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34 (proven checkpoint 99,016, pending 99,048), Governance 0x1102471Eb3378FEE427121c9EfcEa452E4B6B75e, GovernanceProposer 0x06Ef1DcF87E419C48B94a331B252819FADbD63ef, EscapeHatch 0xF459348962F5eA3A9A101826B03A2CE1F459E51A. These are Ethereum (chain 1) contracts, but this row's primary chain is aztec:mainnet, and the validator requires onchain evidence to match the primary chain, so the reads are recorded in repo evidence details with cast rechecks and contracts is empty; C1, C2, S1 and S2 are capped at 2 for that reason. No transactions, node runs, builds, traces or self-host attempts were made.