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

**URL:** <https://forum.aztec.network/t/request-for-grant-proposals-application-state-migration-using-direct-proof-migration/8403>\
**Category:** Aztec\
**Tags:** rfgp\
**Created:** [January 23, 2026, 4:39pm UTC](https://forum.aztec.network/t/request-for-grant-proposals-application-state-migration-using-direct-proof-migration/8403 "2026-01-23T16:39:23Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![andeebtceth](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.aztec.network/andeebtceth/32/2831_2.png) [@andeebtceth](https://forum.aztec.network/u/andeebtceth)\
**Post date:** [January 23, 2026, 4:39pm UTC](https://forum.aztec.network/t/request-for-grant-proposals-application-state-migration-using-direct-proof-migration/8403/1 "2026-01-23T16:39:23Z")

</div>

## 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](https://github.com/orgs/noir-lang/discussions/8559)). We know Aztec’s architecture (UTXO notes, portal messaging, nullifier system) and have built multiple Noir/Aztec developer tools.

**Proof of Past Work:**

- [Noirlings App](https://github.com/0xandee/noirlings-app) - Interactive Noir learning platform
- [Noir Playground](https://github.com/0xandee/noir-playground) - Browser-based Noir development environment
- [Aztec NFT Playground](https://github.com/0xandee/aztec-nft-playground) - Aztec NFT experimentation toolkit
- Aztec Playground (in development)

**Team Members:**

- **Andee (Lead Developer)**

- **Tea (Core Developer)**

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

```mermaid
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)

```mermaid
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](https://forum.aztec.network/t/request-for-grant-proposals-application-state-migration/8298/2) 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.

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