Request for Grant Proposals: State Migration
We’re allocating US$60,000 to support 2-3 teams in researching and prototyping state migration approaches during upgrades of the network. The deadline for proposal submissions is 23rd January 2026
Overview
The Aztec network can only be upgraded through hard forks. While it is possible for an upgrade to copy the existing state of the network, we expect most (if not all) of the upgrades in the early days of the network not to. Instead, they will start with no state.
However, applications can always choose to migrate their state to new versions even when the network doesn’t do it automatically. This RFPG is a call for teams to research and prototype application-level state migration. The design space is large, with tradeoffs between trustlessness, user experience, and privacy.
Why start with no state
The Aztec network is complex. Independent of the number of audits or the amount of care demonstrated during development, it is very likely issues with the production network will be discovered, especially in the early days.
The impact of bugs can be especially large given Aztec’s privacy. Unlike fully transparent blockchains, a successful exploit may not ever be observable. A sophisticated attacker could maliciously and privately double spend or mint large amounts of an asset, but keep their exploit hidden forever.
Upgrades which do not carry over historical state act as a turnstile. It limits the potential impact historical exploits of bugs, giving stronger assurances to users of the latest version of the network that no bad state created during previous exploits still exists.
With time, we expect Aztec governance to get more confidence in the safety of the underlying code and cryptography, and gradually come to default to upgrades which do carry over state.
Below, we provide more context on Aztec’s roadmap, how governance-driven upgrades work, and what makes state migration an interesting design problem. If you’re already familiar with Aztec’s different phases and roll-up upgrades, skip ahead to 'State Migration During Alpha’.
What is Aztec
Aztec is an Ethereum Layer 2 that uses zero-knowledge proofs for scalability and to enable programmable privacy.
Unlike traditional rollups that operate entirely on public state, Aztec allows smart contracts to mix private and public state within the same application. Private state, such as balances, strategies, identities, or votes, is operated on and stored off-chain, with zero-knowledge proofs submitted on-chain to verify correctness. Public state and interactions, on the other hand, are directly stored and executed on-chain.
The Roadmap
The network will progress through the following phases: Ignition (current), Alpha, and Beta.
The key point is this: during Alpha, roll-up upgrades are expected to be proposed approximately every two months. Crucially, state will not be migrated automatically when these upgrades occur. These upgrades enable the community to exercise governance, build muscle for handling network changes, state migrations, and provide flexibility to ship improvements safely. If governance approves each upgrade, the network moves to new roll-up contracts on Ethereum. For more information on the governance process, please refer to the appendix.
State Migration During Alpha
If governance approves roll-up upgrades during Alpha, applications deployed on one version won’t automatically exist on the next. For stateless, “pass-through” use cases like private cross-chain bridging, this works great. For applications that benefit from persistent state (user positions, balances, app-specific data), migration becomes a design consideration.
How applications handle migration is ultimately up to them. Alpha is an early-stage network, and developers may make different tradeoffs depending on their priorities. For example, an application that prioritizes user experience during Alpha might choose to centralize certain components to simplify migration, while others might accept more friction in exchange for stronger trust assumptions. There’s no single “right” answer; it depends on the application and its users.
We’re allocating US$60,000 to support 2-3 teams in researching and prototyping state migration approaches. The goal is to showcase possible patterns that applications could adopt, not to prescribe how they must work. We’re looking for creative, generalizable solutions that help users and developers carry their state across roll-up upgrades while preserving Aztec’s privacy and security guarantees.
Submit your proposal by January 23rd, 2026 for a chance to receive funding and support.
Grant Details and Submission Format
We’re allocating up to US$60,000 split across 2-3 teams, with funding distributed flexibly based on proposal scope and complexity.
To ensure consistency, please follow this format:
-
Title: Team/product name
-
Contact Details: Signal, email, etc.
-
Summary: In 300 words or fewer, describe your proposed approach to state migration
-
Start and End Date: Recommended start end-of-January 2026, working prototype by February 27th, 2026
-
About You: Team background, relevant experience, and why you’re well-positioned to tackle this
-
Details you should cover:
-
Which migration approach are you pursuing (see categories below)
-
Technical architecture
-
User flow from old roll-up to new roll-up
-
Trust assumptions (be explicit!)
-
How does your solution generalize across multiple applications
-
-
Grant Milestones and Roadmap: 3-5 milestones to get to a working prototype, plus 2-3 items for potential future work
-
Grant Amount Requested: Flexible based on scope. Justify your ask.
-
Questions: Anything unclear?
Submissions should be created as a new post on the Aztec Forum, tagged state-migration and rfgp. Once posted, add the link as a comment on this RFPG.
Submission deadline: January 23rd, 2026
Team selection: January 27th, 2026
Delivery deadline: March 6th, 2026
Design Considerations & Potential Solutions
There is currently no canonically recognised notion of “you” for the purposes of state migration. The same private key, contract code, and salt will result in different public addresses on different rollup instances, meaning a simple “same address” migration approach does not work out of the box. As a result, any migration mechanism must answer a more fundamental question: who does this state belong to, and how can they prove it? Aztec does not currently define a canonical public key or identity primitive that persists across rollup instances, and proposals may need to consider how (or whether) to introduce one.
Private state: Migrating private state requires user interaction, since all private state is ultimately encrypted to a particular address.
Old state remains accessible: Previous roll-up state stays readable on L1. There may be opportunities to leverage the Inbox/Outbox messaging system to pass previous roll-up tree roots into the new roll-up. This is the kind of creative thinking we’d be excited to see.
Forced exits: Aztec plans to be a Stage 2 rollup, which means users can always exit via forced withdrawal mechanisms, even if all sequencers disappear.
Aztec is NOT EVM-compatible. It’s a Turing-complete smart contract environment using Noir as the smart contract programming language, supporting both public and private execution. Solutions should account for this. Don’t assume EVM patterns will translate directly.
Given these considerations, here are some potential solutions. Note that this is not a conclusive list.
Category A: Off-Chain Attestation
Applications may authorize state migration using trusted off-chain mechanisms. Practical approaches include exporting state to off-chain storage with encrypted user backups or through a trusted execution environment (e.g., SGX). While faster to implement, these approaches introduce explicit trust assumptions in off-chain infrastructure.
Category B: Purely Onchain, Self-Migration
Users migrate their own state using on-chain proofs. No external attestation required. Users prove their previous state and claim it on the new roll-up. This maximizes trust minimization but may involve more user friction.
Category C: Hybrid Approaches
A combination of on-chain and off-chain mechanisms. Be explicit about the tradeoffs.
Note: Teams can submit multiple approaches (e.g., “here’s a more centralized version optimized for UX AND here’s a fully on-chain version”). Showing the tradeoffs across different points on the spectrum is valuable.
Requirements
Must-Haves
-
Generalizable patterns: We want reusable patterns, data structures, or standards that applications could adopt, rather than app-specific solutions. The goal is to showcase approaches, not mandate them. Think of: token balances, proven identities, NFTs, etc.
-
Reasonable UX: Aim for no more than 3-4 transactions to complete a migration. Use common sense.
-
Working prototype: Demonstrate on a local network with tests showing migration between two roll-ups.
-
Design documentation: Clear write-up of the approach, trust assumptions, tradeoffs, and recommendations. Help future application developers understand when they might choose this approach.
Out of Scope
-
Shared/multi-party private state: AMM liquidity pools, multi-user vaults, etc. These are tied to other contracts’ states (tokens, etc.) and are too complex for this initial research.
-
Abandoned state handling: Users who never migrate can use forced exits on the old roll-up. We don’t need a solution for them.
-
Foundation as trust anchor: Any solution requiring Aztec Foundation to be a centralized trust party will be rejected.
FAQs
Is Aztec EVM-compatible?
No. Aztec uses Noir for smart contracts and has both public and private execution environments.
Where do I build this?
Start with the local network, Aztec’s local development environment. Your tests should simulate two roll-ups to demonstrate migration.
Can users always withdraw their funds from the old roll-up?
Yes. Aztec is a Stage 2 L2 with forced exit mechanisms. Even if no sequencers remain on the old roll-up, users can withdraw via L1.
Do I need ALL requirements done by the deadline?
We require a working prototype that demonstrates the core mechanism. Design docs and recommendations for future work are also expected. Full production-readiness is not required.
Can one team submit multiple proposals?
Yes! You can propose different approaches (e.g., centralized AND decentralized versions).
How will proposals be evaluated?
We’re looking for feasibility and outside-of-the-box thinking. Creative approaches that address the core constraints will stand out.
What about the address derivation constraint?
This is a key design consideration. Aztec Labs and Wonderland are working on persistent identifier solutions separately, but your proposal should either work around this or propose its own approach.
Disclaimer
The published request for proposal and ideas herein are explicitly published as discussion points to invite community feedback in the community forums. Robust design and developer discussion is the best way for the community to collectively explore state migration patterns during Alpha.
The information set out herein is for discussion purposes only and does not represent any binding indication or commitment by Aztec Foundation and/or affiliates and their employees/consultants to take any action whatsoever, including relating to the structure and/or any potential operation of the Aztec protocol or the protocol roadmap. In particular: (i) nothing in this post (and any response to this post) is intended to create any contractual or other form of legal, investment, financial, tax or advisory relationship between Aztec Foundation or third parties who engage with such posts (including, without limitation, by submitting comments, a proposal and/or responding to posts including any medium such as X, Discord, etc), (ii) by engaging with any post, the relevant persons are consenting to Aztec Foundation’s use and publication of such engagement and related information on an open-source basis (and agree that Aztec Foundation will not treat such engagement and related information as confidential), and (iii) Aztec Foundation is not under any duty to consider any or all engagements, and that consideration of such engagements and any decision to award grants or other rewards for any such engagement is entirely at Aztec Foundation’s sole discretion. Please do not rely on any information on this forum for any purpose - the development, release, and timing of any products, features or functionality remains subject to change and is currently entirely hypothetical. Nothing on this forum post should be treated as an offer to sell any security or any other asset by Aztec Foundation or its affiliates, and you should not rely on any forum posts or content for advice of any kind, including legal, investment, financial, tax or other professional advice.
Appendix
How Governance Drives The Transitions
Every major network change goes through governance. Here’s the flow:
-
Proposal – A payload is submitted proposing new roll-up contracts
-
Signaling – Once 600 out of 1000 sequencers signal support for a payload, we move to the voting stage
-
Prep phase – A 3-day delay where no actions can be taken
-
Voting – Sequencers vote on whether to adopt the change. Voting lasts 7 days.
-
Execution delay – If passed, there’s a 7-day delay before the new rollup becomes the “canonical rollup”
-
Old roll-up winds down – The old rollup may still have leftover $AZTEC balance that it can distribute as inflation rewards, but it won’t be able to request additional tokens from the Reward Distributor. The previous rollup can keep running as long as there are enough sequencers to maintain liveness (at least 24 sequencers for Ignition’s target committee size). Some sequencers may choose stay temporarily to help users exit, or because of other community-driven incentives.
This is governance-driven. The community decides whether and when to upgrade. Our plan is to propose upgrades roughly every two months during Alpha, but ultimately it’s up to the sequencers and the governance process.
