Request for Grant Proposals: Application State Migration using Direct Proof Migration

Aztec
1

1. Summary

The Direct Proof Migration is a pure on-chain state migration solution that leverages Aztec’s existing key infrastructure. Notes are associated with owners through Aztec’s storage patterns, and users control the corresponding master keys (nsk_m) across all rollup instances. Though addresses differ per rollup, the underlying keys are portable. Direct Proof Migration leverages this emergent property of Aztec’s key architecture for cross-rollup ownership proofs without introducing new cryptographic primitives.

Trust Model: Direct Proof Migration only trusts Ethereum L1 consensus and ZK proof soundness. No foundation attestation, operator trust, or TEE is required.

Our design achieves migration in two transactions: (1) bridge the old rollup’s state root to L1 via portal messaging, then (2) claim on the new rollup with a ZK ownership proof. See §4.2 for full flow.

Key benefits: Direct Proof Migration only trusts Ethereum L1 consensus. No foundation attestation or operator trust is required. Users can claim any note at any time without planning ahead. The design uses only existing Aztec primitives (Grumpkin curve, Poseidon2 hashing), minimizing audit scope. It works for tokens, NFTs, credentials, and any single-owner state, with zero state footprint on the old rollup.

2. Start and End Date

Start Date: February 1, 2026
End Date: February 27, 2026
Total Duration: 31 days (4.5 weeks)

3. About You

Team Name: Andee Labs

Team of 2 developers with deep ZK and blockchain experience. Recipients of past Noir Research Grants (NRG #8559). We know Aztec’s architecture (UTXO notes, portal messaging, nullifier system) and have built multiple Noir/Aztec developer tools.

Proof of Past Work:

Team Members:

  • Andee (Lead Developer)

  • Tea (Core Developer)

    • Embedded software engineer background (Assembly, C++, RH850 CPU cores)
    • Blockchain experience: EOS (C++), EVM/Solidity, CKB RISC-V
    • Deep interest in UTXO-based programming paradigms
    • Built joyDAO prototype (became NERVDAO)
    • Creator of Quantum Purse
    • GitHub: @tea2x

Why We’re Well-Positioned:
Our combined experience spans ZK circuits (Cairo, Noir), UTXO systems (CKB, Aztec), and developer tooling. Andee’s Noir ecosystem contributions and Tea’s low-level systems expertise make us uniquely suited to build Direct Proof Migration, a project requiring deep understanding of both Aztec’s key infrastructure and proof construction patterns.

Post-Grant Commitment: Open-source Noir library (aztec-migrate), AIP proposal for ecosystem adoption, migration SDK for developers, MIT license, and 12-month post-grant support.

4. Details

4.1 The Core Problem

The same private key produces different addresses on different rollup deployments. Address derivation involves contract class IDs, salts, and public key hashes that can all differ. A simple “same address” migration is impossible.

4.2 Solution Architecture

Aztec’s master keys (nsk_m, ivsk_m) are portable by design: derived from user-controlled seeds independent of any rollup, they persist across rollup instances even as addresses differ. Direct Proof Migration exploits this architectural property: users prove ownership of notes by demonstrating knowledge of nsk_m and the derivation chain to the note’s owner address.

flowchart LR
    subgraph OLD["Old Rollup"]
        SSP["StateSnapshotPortal"]
    end
    subgraph L1["Ethereum L1"]
        MR["MigrationRelay"]
    end
    subgraph NEW["New Rollup"]
        DCV["DirectClaimVerifier"]
        APP["App Handlers"]
    end

    SSP -->|"Portal Message"| MR
    MR -->|"Cached Root"| DCV
    DCV -->|"Verified Claim"| APP

Components: StateSnapshotPortal (old rollup) captures state roots and bridges to L1. MigrationRelay (L1) stores snapshots indexed by (rollup_id, block_num). DirectClaimVerifier (new rollup) validates ZK ownership proofs against L1-cached roots and coordinates minting.

4.3 User Flow (2 Transactions)

sequenceDiagram
    participant Anyone
    participant OldRollup
    participant L1
    participant User
    participant NewRollup

    Anyone->>OldRollup: snapshot()
    OldRollup->>L1: Bridge state root via portal
    Note over L1: MigrationRelay stores root
    User->>NewRollup: claim_migration() + ZK proof
    NewRollup->>User: Mint equivalent state

Transaction 1 (Batched): Anyone calls snapshot() periodically. Cost is amortized since one snapshot serves unlimited users.

Transaction 2 (User-Initiated): User’s PXE generates a ZK proof of ownership (nsk_m derivation + Merkle membership) with a migration nullifier. DirectClaimVerifier validates and calls the app handler to mint equivalent state.

Proof Generation (PXE Integration): The user’s PXE (Private eXecution Environment) handles proof generation entirely client-side:

  1. PXE retrieves the Merkle path for the note from the old rollup’s archive node
  2. PXE constructs ownership proof using nsk_m and the full derivation chain to the note’s owner address
  3. Proof submitted to DirectClaimVerifier in a single transaction

No PXE modifications required. The migration circuit uses standard note fetching and Noir proof construction patterns already available in the Aztec SDK.

4.4 Design Highlights

Nullifier formula: poseidon2([note_hash, nsk_m, block_num, DOMAIN]). This uses Aztec’s existing Poseidon2 primitive, with block_num for snapshot-specific uniqueness. All sensitive data remains private as ZK inputs.

Key advantages:

  • No old rollup modifications: Zero state footprint, just needs to be readable
  • No user pre-planning: Migrate any note, any time
  • No new primitives: Uses existing Grumpkin/Poseidon2, minimizing audit scope

This aligns with Mike’s forum discussion on portable identity while requiring zero protocol changes.

4.5 Generalizability

Direct Proof Migration works for any single-owner state: fungible tokens (mint equivalent value), NFTs (preserve token ID), identity credentials (re-issue), and access rights (re-grant permissions). Each application implements a handler that receives verified data and mints equivalent state on the new rollup.

4.6 Bridged vs Native State Classification

Not all assets can be freely re-minted. Assets with L1 collateral require special handling to prevent unbacked token creation.

Native State (e.g., in-rollup tokens, NFTs, credentials):

  • Can be safely re-minted via ZK ownership proof
  • Old rollup’s note becomes dormant; new rollup mints equivalent
  • Examples: governance tokens, in-game items, membership credentials

Bridged State (e.g., L1-backed ETH, DAI, USDC):

  • Cannot be re-minted: L1 collateral backs only one instance
  • Migration flow: User must use escape hatch on old portal → withdraw to L1 → deposit to new portal
  • DirectClaimVerifier detects bridged contracts and routes to escape hatch guidance

Implementation: MigrationRelay maintains a registry of bridged contract addresses (populated during deployment or via governance). When a claim targets a bridged contract, DirectClaimVerifier returns escape hatch instructions rather than minting, preventing double-collateralization.

flowchart TD
    CLAIM["User Claim"] --> CHECK{"Is Bridged?"}
    CHECK -->|No| MINT["DirectClaimVerifier → App Handler → Mint"]
    CHECK -->|Yes| ESCAPE["Return Escape Hatch Instructions"]
    ESCAPE --> L1["User withdraws via old portal"]
    L1 --> DEPOSIT["User deposits to new portal"]

4.7 Security Model

Trust Assumptions: Requires only Ethereum L1 consensus, Aztec Portal messaging, ZK proof soundness, and Grumpkin/Poseidon2 security. No foundation attestation, operator trust, or TEE required.

Privacy: Note data (nsk_m, value, owner) remains hidden as ZK private inputs. Only the migration transaction and destination contract are visible on-chain.

Key Mitigations:

  • Snapshots verified against L1-finalized blocks only
  • Migration nullifier includes block_num to prevent double-claims
  • Bridged/native classification prevents double-collateralization (§4.6)
  • Formal verification + security audit planned (M4)

5. Grant Milestones and Roadmap

Development Milestones

Milestone Date Deliverables
M1: Setup Feb 1 Dual sandbox environment, CI/CD, technical spec
M2: Bridge Feb 7 StateSnapshotPortal + MigrationRelay contracts
M3: Verifier Feb 15 DirectClaimVerifier + ownership proof circuit
M4: Testing Feb 23 E2E tests, basic proof aggregation (≤10 notes), security testing
M5: Demo Feb 27 Working prototype, video demo, SDK, documentation

Success Criteria

Metric Target
Asset type coverage Successfully migrate 3+ types (token, NFT, credential)
Security Zero double-migration vulnerabilities in testing
Documentation Complete SDK docs + integration guide

Future Extensions (Beyond Grant Scope)

Planned extensions to build on the grant deliverables:

  • Advanced Batch Migration: Recursive proof aggregation for 100+ notes
  • Merkle Proof Archive Service: Public archive with decentralized proof generation
  • Multi-Party State Migration: Threshold schemes for AMM pools and shared vaults
  • AuthWit Delegated Migration: Third-party migration services using Aztec’s AuthWit pattern

6. Grant Amount Requested

Total Request: $20,000

Grant Rationale

This budget reflects a focused 4.5-week sprint by a 2-person team delivering production-ready migration infrastructure. The $20,000 request covers end-to-end development of three coordinated smart contracts (StateSnapshotPortal, MigrationRelay, DirectClaimVerifier), a custom ZK ownership proof circuit, and developer tooling. All of these require deep integration with Aztec’s key infrastructure and portal messaging system. Deliverables include the open-source aztec-migrate Noir library and TypeScript SDK, providing long-term ecosystem value beyond this specific migration use case. The MIT-licensed codebase becomes shared infrastructure for future rollup transitions.

Deliverables: Working prototype, core contracts (StateSnapshotPortal, DirectClaimVerifier, MigrationRelay), aztec-migrate Noir library, TypeScript SDK, video demo, and documentation.

7. Questions

None at this time. We are confident in our understanding of the RFGP requirements and Aztec’s architecture.

Request for Grant Proposals: Application State Migration