Submitted by: LimeChain
Date: January 23, 2026
Grant Request: $30,000.00
Project Duration: 5 weeks
Delivery Deadline: February 27th, 2026
Contact Details
Primary Contact: Zhivko Todorov
Email: zhivko@limechain.tech
Telegram: zhivkoto
Website: https://limechain.tech
About LimeChain
LimeChain is a blockchain development and consulting company contributing to Ethereum and the broader blockchain ecosystem since 2017, with a proven track record of delivering complex infrastructure, developer tooling and applications for protocols, crypto-native startups, and Fortune 500 companies. Over the years, we have worked with and contributed to industry leading protocols and organizations such as the Ethereum Foundation, Coinbase, Arbitrum, Optimism, Polygon, Scroll, The Graph and many others.
Deep Ethereum L2 & Rollup Expertise
At LimeChain we care deeply about scaling Ethereum and the L2 ecosystem. We worked with the EF on based-sequencing research. In addition, we have contributed to many of the leading rollups with core protocol work such as alternative client implementations. Lastly, We are the creators and maintainers of Rollup.codes—an interactive specification website for the Ethereum Rollup ecosystem that was awarded a RetroPGF grant. As the date of this post, LimeChain has no active commercial relationship with any Ethereum L2.
Zero-Knowledge Proof Experience
Through our work with Polygon zkEVM, Scroll, Taiko and others, we’ve attained practical expertise in ZK proof technologies, such as Circom, Halo2 and plonky2. We believe this will help us with building Noir-based smart contracts.
Commitment to Public Goods & Open Source
LimeChain’s ethos is deeply aligned with Ethereum’s and Aztec core values. We dedicate significant resources to building public goods, open-source software and research. Our vision is to contribute to Aztec long-term through protocol research, infrastructure and tooling
Why Aztec
At LimeChain, we care about Ethereum and we care about privacy. We see this project as the beginning of our long-term contribution to the Aztec ecosystem through apps, and potentially protocol research, infrastructure and tooling.
Summary
Aztec’s privacy-first architecture presents a unique challenge during network upgrades: the state is encrypted, the contracts’ and users’ addresses change, preventing a centralized “copy-paste” migration. To solve this, we propose a Hybrid “User-Pull” Migration Prototype, where users leverage client-side ZK proofs to securely teleport assets from one version to another without revealing their history.
1. The Identity Primitive (The Anchor) Since contract upgrades alter user addresses, we cannot rely on V1 addresses (0x123...) for continuity. Instead, we establish the tagging public key Tpk as the canonical identity anchor. Derived directly from the master seed, the Tpk persists across versions.
-
Discovery: The user’s incoming viewing key
Ivpkis used locally to decrypt V1 notes. -
Proof: The user proves ownership of the seed linked to the
Tpkto authorize the migration.
2. Architecture & Scope The migration is app-centric, not chain-centric. We implement a Hub-and-Spoke model:
-
Migration Hub: A contract that acts as the “Truth Oracle.” It verifies user ZK proofs against the immutable archive root stored on L1.
-
Whitelisted Apps: To prevent spam and security issues, only registered V1 → V2 contract pairs are eligible.
-
App Interface: Whitelisted apps implement a secure
migratehook, accepting state only from the verified Hub. Alternatively, the Apps can bypass the Migration Hub and implement their own ZK verification against the root.
3. The Workflow Users interact with a single “Migration Bridge” UI. The local PXE scans historical V1 logs, filters for whitelisted assets, and generates ZK proofs in batches (aggregating ~10 notes per proof to optimize performance).
4. Security We introduce a Migration Nullifier (Hash(Note_Secret, "MIGRATE_V1_TO_V2")). This cryptographic receipt ensures that while the V1 note remains in the archive, it can only be imported into V2 exactly once, strictly preventing double-migration.
While the migration is private, the architecture preserves the Ovpk (Outgoing Viewing Key) history. This allows DAOs or regulated entities to audit the total migrated supply without breaking individual user privacy.
State types and their migration strategy
Native State
Native state is any asset or data that originates and exists solely within the Aztec Network. Its “Source of Truth” is the Aztec L2 history itself. Since the value is derived from L2 logic, we can safely “re-mint” this state on V2 by cryptographically proving it existed in V1. No external liquidity is required.
Bridged state (L1 Backed Assets)
A bridged state is any asset that represents a claim on L1 liquidity (e.g., ETH, DAI, USDC…) locked in an L1 Portal. Its “Source of Truth” is the Ethereum L1 Portal, not just the L2 note. Also, in those cases, we would have to think about the liquidity on the L1 side.
Escape Hatches
In the Alpha stage, upgrades deploy fresh Rollup instances, effectively abandoning the old chain. If the V1 sequencers go offline, the escape hatch becomes the critical mechanism for bridged state. It ensures users can bypass the dead V1 network to reclaim their L1 liquidity, preventing a total loss of funds during the transition.
Why do state origin and escape hatch matter?
The Alpha stage of the Aztec network will not be moving any state to the upgraded network. It would start from a clean genesis. Every upgrade deploys a completely new Rollup instance.
Double migration risk
Since the Escape Hatch allows users to exit the V1 Aztec network indefinitely, and we also provide a way to migrate the older state, we risk double-minting assets. To prevent this, our Hub enforces a rule: Native State uses ZK Migration, while Bridged State must use the Escape Hatch. The Hub will reject proofs for bridged assets.
State verification
With this flow, the user state should be checked against different “Source of Truth” and different rules should be applied based on the origin. At the same time, the migration should ensure that the checks are executed first on the correct “Source of Truth” and on the correct finalized state of that source.
If a portal chooses to use the same L1 contract despite network upgrades, ensuring the correctness of the block number and root they need to verify is crucial. Some users may be left with no way to withdraw their funds.
Liquidity
For portals migrating through separate L1 instances of the contract, that means the liquidity will stay trapped in the V1 Portal contract. Users will be able to retrieve it through the escape hatch and reinsert it on the new Aztec rollup, but that requires ETH to pay gas, and we are forcing the user to use L1 to submit transactions.
Technical architecture and user flow
1. Local PXE
Role: The client-side privacy engine. The PXE runs entirely within the user’s device (browser or local node) to ensure that V1 keys and secrets never leave the user’s control. It is responsible for discovering and verifying the migration data.
-
V1Scanner: A specialized service that downloads encrypted historical logs from the V1 Archive. It utilizes the user’s Incoming Viewing Key (Ivpk) to trial-decrypt these logs and reconstruct the user’s V1 asset history locally. The output is only list of state related to the whitelisted contracts. -
State_MigrationNoir circuit - executes it inside a WebAssembly (WASM) environment. It takes the discovered V1 Note and the V1 Archive Root as inputs to generate the Zero-Knowledge Proof. -
Securely derives the Tagging Public Key (Tpk) from the master seed to prove identity continuity without exposing the seed itself.
L1 Root Portal
Instead of hardcoding the root in the Migration Hub, we would use the Aztec’s L1 to L2 messaging to read the L1 finalized V1 archive root and bridge it to the L2 Migration Hub.
Migration Hub
The Migration Hub is responsible for recording the whitelisted apps for migration and their new addresses. It would trigger a call to the common migrate interface for the migration of apps that have related state. The Hub checks the Migration Nullifier (derived from V1 secret). The app creates new spending nullifiers later when the user spends the funds.
Demo contracts
Using the https://github.com/defi-wonderland/aztec-standards as a base to demonstrate the migration flow, we would add the migrate function.
User flow from old roll-up to new roll-up
-
User provides their
Tpkto a dedicated migration ui or cli tool -
The tool gets the list of whitelisted/approved apps for migration -
mapping(V1_Contract_Address => V2_Contract_Address) -
The tool scans the V1 state for record for the user in the apps from 2.
-
List of notes is presented to the user for migration
-
When the user approves, proofs are generated
-
Input: V1 Note + V1 Archive Root.
-
Check: Proves the note exists and belongs to the
Tpk. And the state is from the V1 root.
-
-
User signs the transaction. The V2 contract verifies the proof and calls the app to create the new state
Trust assumptions
The Migration Hub is secure
The Migration Hub holds the proper mapping old to new address and is managed by trusted parties - Aztec DAO/Gov. Migration hub is only migrating trusted state and no bugs to the upgraded network. The risk of an insecure Hub can be mitigated by each App implementing its own migration verification and not using the Migration Hub.
Privacy
While the migration proof cryptographically hides the Source (your specific V1 Note) and the Amount (the value being moved), it cannot hide the destination. To route the migration correctly, the Target V2 Application must be a public input to the transaction. An external observer will see that “User X is migrating assets to the V2 App,” even though they cannot see how much was migrated or which specific V1 interaction generated those assets. This is an unavoidable trade-off of the Hub-and-Spoke model. We prioritize preventing spam (via whitelisting) over hiding the asset type being migrated.
Generalization
Decoupled verification and state interpretation
Instead of every application building its own migration circuit, they all plug into a shared infrastructure we call the Migration Hub. Our generic migration circuit is designed to prove ownership of any standard ValueNote.
Consistent contract interface
Each whitelisted app should implement migrate function. On top of that they should handle their own data mapping for state structure changes for newer versions. The migration function should be called only by the Migration Hub.
The applications should implement only the new migrate function following the predefined interface that accepts the proof and the old state. It should verify that the sender is the Migration Hub and will create a new nullifier. All other app functionality would not be affected.
Grant deliverables and Team
State scanner
-
V1 exporter so that we don’t have to scan the whole network again and use the already existing local store. Once connected to the upgraded RPC the store would be wiped.
-
Implement connection to the archive node
-
Scanning for notes related to the current tagging key
-
Present a list of notes for migration for the user
-
Batch submission of the migration data.
Deliverable: PXE extended implementation
Migration Circuits
Following the state verification circuits logic we’ll create a new circuit verifying the ownership and validity of the V1 state. Custom Nullifier Hash(Secret, "MIGRATION_V1")
Deliverable: State_Migration circuit
Migration Hub
Noir smart contract that will verify the truthfulness of the migrated state. It would hold the whitelisted accounts, the last trusted root from V1.
Deliverable: MigrationHub and Registrycontracts, unit tests
V2 Contract Migration Interface
The prototype will use a fork of the smart contracts listed in https://github.com/defi-wonderland/aztec-standards and add a migrate function handling the state migration.
Deliverable: Fork of https://github.com/defi-wonderland/aztec-standards with migration logic
Demo UI
UI which will trigger the user flow for migration and would visualize the states and contracts for migration.
Deliverable: Single page app to facilitate user interaction
Documentation and public repos
Detailed documentation of the user flow, guides for setup. Public Github fork of the Aztec monorepo with the migration code.
Deliverable: README for the project
Team
-
Blockchain architect
-
ZK engineer
-
Blockchain engineer
-
Project Manager
Final remarks
LimeChain is committed to embark on a journey as a long-term contributor to the Aztec network and we would be happy to support app teams to implement this solution. We’re also open to engage and help in research discussions with other teams beyond this RFGP.