0x-shashi/skills/aztec-scanner

Aztec Network Security Scanner

Security scanner for Aztec Network smart contracts written in Noir. Aztec is a privacy-focused L2 on Ethereum with a unique dual public/private state model.

---

Language & Runtime

| Attribute | Value | |-----------|-------| | Chain | Aztec Network (Ethereum L2) | | Language | Noir (Rust-inspired, ZK-circuit language) | | Proof System | Ultra-PLONK (client-side proving) | | State Model | Dual: Private (UTXO/notes) + Public (storage slots) | | Privacy | Private functions hide inputs, outputs, and who called them | | Execution | Private: client-side → Public: sequencer-side | | Token Standard | Private tokens via note encryption |

---

Architecture: Public vs Private

┌─────────────────────────────────────────────────────────┐
│  Aztec Contract                                         │
├──────────────────────────┬──────────────────────────────┤
│  Private Functions          │  Public Functions               │
│  (Client-side execution)    │  (Sequencer-side execution)     │
│  - Hidden inputs/outputs    │  - Visible state changes        │
│  - Note creation/nullifying │  - Storage slot reads/writes    │
│  - ZK proof generation      │  - Similar to Solidity          │
├──────────────────────────┴──────────────────────────────┤
│  Private State: Notes (UTXO-like, encrypted)             │
│  Public State: Storage slots (like Solidity)             │
│  Shared: Nullifier tree, note hash tree, L1-L2 messages  │
└─────────────────────────────────────────────────────────┘

Private State: Notes

Aztec uses a UTXO-like model for private state:

1. Notes are encrypted data stored in the note hash tree
2. To "read" a note, the owner decrypts it client-side
3. To "spend" a note, a nullifier is emitted (marks the note as consumed)
4. To "create" a note, a new note hash is added to the tree
5. Notes are immutable — to update, nullify the old note and create a new one

Execution Order

Private functions execute FIRST (client-side), then public functions execute SECOND (sequencer-side). This ordering has security implications:

• Private can enqueue calls to public, but not vice versa
• Private computations can't read current public state (stale reads)
• Public functions see the effects of private functions

---

Detection Capabilities

| Category | Detection | Severity | |----------|-----------|----------| | Privacy | Private data exposed via public state or function args | Critical | | Privacy | Note content leaked through observable behavior (timing, gas) | High | | Privacy | Encryption key mismanagement (wrong recipient) | Critical | | Nullifier | Nullifier collision (two notes produce same nullifier) | Critical | | Nullifier | Nullifier not emitted when note consumed (double-spend) | Critical | | Nullifier | Nullifier predictable (allows front-running) | High | | State Sync | Public/private state inconsistency | High | | State Sync | Private function reads stale public state | Medium | | Circuit | Under-constrained circuit (invalid proofs accepted) | Critical | | Circuit | Over-constrained circuit (valid transactions rejected) | Medium | | Oracle | Untrusted oracle data used in circuit constraints | High | | Access | Private function callable without proper auth | High | | Notes | Note not encrypted for correct recipient | Critical | | Notes | Note discovery failure (recipient can't find their notes) | High |

---

Privacy Threat Model

| Threat | Attack Vector | Mitigation | |--------|--------------|-------------| | Transaction graph analysis | Linking sender/receiver via timing | Add delay, use shield/unshield | | Amount leakage | Fixed denomination reveals nothing | Use uniform note sizes | | Metadata leakage | Public function calls reveal intent | Minimize public function usage | | Sequencer censorship | Sequencer refuses to include tx | Forced inclusion via L1 | | Nullifier linking | Linking nullifiers to note creation | Nullifier derived from note secret + position |

---

Resources

• Aztec Patterns

Workflows

• Aztec Audit

Overview

Aztec is a privacy-focused L2 with:

• Private and public state separation
• UTXO-like note model for private data
• Noir language for circuit programming
• Encrypted function arguments
• Client-side proof generation

Error Code Reference

Common Aztec/Noir errors encountered during audits. Noir circuits fail at proof generation time, making errors harder to debug than runtime reverts.

Noir Language Errors

| Error Type | Error Pattern | Meaning | |-----------|--------------|----------| | Assertion failure | assert(condition) failed | Constraint not satisfied — proof cannot be generated | | Array bounds | index out of bounds | Array access exceeds declared length | | Integer overflow | Overflow on arithmetic | Operation exceeds field/integer bounds | | Type mismatch | Expected type X, found Y | Incorrect type in circuit computation | | Unresolved variable | Variable not found | Reference to undefined variable in circuit | | Division by zero | Division by zero | Denominator is zero in integer division |

Aztec Protocol Errors

| Error Pattern | Source | Meaning | |--------------|--------|----------| | 'NOTE_NOT_FOUND' | Note management | Note does not exist or was nullified | | 'NULLIFIER_ALREADY_EXISTS' | Nullifier tree | Double-spend attempt — note already consumed | | 'INVALID_CALLER' | Access control | Unauthorized function caller | | 'INVALID_CONTEXT' | Context check | Wrong execution context (private vs public) | | 'INVALID_NOTE_TYPE' | Note deserialization | Note type does not match expected schema | | 'PUBLIC_CALL_FAILED' | Public function | Public portion of transaction reverted | | 'PRIVATE_CALL_FAILED' | Private function | Private proof verification failed | | 'ENCRYPTION_FAILED' | Note encryption | Failed to encrypt note for recipient | | 'INVALID_SELECTOR' | Function dispatch | Function selector not found on contract |

Privacy-Specific Audit Errors

| Issue | Error Pattern | Audit Significance | |-------|--------------|--------------------| | Note viewing key leak | No error — silent | If viewing keys are shared incorrectly, privacy is broken without any on-chain error | | Nullifier predictability | No error — logical | Predictable nullifiers allow note existence tracking — check nullifier derivation | | Public/private boundary leak | Transaction appears normal | Data flowing from private to public context may leak information — audit cross-context calls | | Incomplete nullification | No error | Note consumed but nullifier not published — allows double-spend | | Proof witness leakage | No on-chain error | Witness data in proof reveals private inputs — verify proof contains only public signals |

Troubleshooting

| Issue | Likely Cause | Solution | |-------|-------------|----------| | Privacy leakage not detected | Scanner audits logic without modeling information flow | Trace all data paths between private and public contexts; flag any private state exposed via public functions | | Nullifier collision risks missed | Scanner doesn't model nullifier tree | Verify nullifier derivation includes unique components (note hash, secret, index) | | Note encryption issues not caught | Scanner doesn't analyze encryption correctness | Verify notes are encrypted to correct recipient keys; check key rotation handling | | Cross-context reentrancy missed | Scanner treats private/public as isolated | Trace private → public → private call chains for state manipulation opportunities | | Proof circuit constraint gaps | Scanner checks Noir syntax, not constraint completeness | Verify every private input is constrained; unconstrained inputs allow proof forgery | | Client-side proof manipulation ignored | Scanner only checks on-chain contracts | Audit client-side proof generation logic for witness injection or tampering vectors |