Summary
In response to the Cross-Chain RFGP, the Wormhole Foundation and Nethermind propose implementing the Wormhole messaging protocol on Aztec.
Wormhole encompasses message passing, cross-chain queries, fungible and non-fungible token bridging, intent-based bridging, and native token transfers. For this grant, we will focus on implementing core message passing, off-chain guardian and relaying functionality, and a PoC token bridge with privacy features.
If a production-grade Wormhole token bridge is deployed on the imminent Aztec mainnet, the Aztec network would have access to up to $2B+ in liquidity (source). This also benefits solvers serving intent-based bridges on Aztec by allowing them to efficiently rebalance across chains.
With Wormhole messaging and token bridging in place, future work can include implementing NFT bridging and intent-based bridging through Wormhole Settlement.
Start: 1 April 2025
End: 27 May 2025 (8 weeks from start)
Budget: $50,000
Budget Rationale: see the breakdown in the Milestones table below. The budget covers costs arising from smart contract engineering, off-chain infrastructure development, front-end development, and devops.
Contact: josh[at]nethermind[dot]io, ossie[at]wormhole[dot]foundation
Trust Assumptions: Wormhole relies on a Guardian set of 19 reputable infrastructure providers. Thirteen of those Guardians must sign a message before it can be consumed on the destination. Risks associated with these trust assumptions are transparently documented here.
Milestones
| Milestone | Start | End | Weeks | Budget |
|---|---|---|---|---|
| Core Contract Implementation | April 1 | April 15 | 2 | $12,500 |
| Relayer+Guardian Implementation | April 15 | April 22 | 1 | $6,250 |
| Token Bridge PoC | April 22 | May 13 | 3 | $18,750 |
| Minimal UI | May 13 | May 20 | 1 | $6,250 |
| Testing + Buffer | May 20 | May 27 | 1 | $6,250 |
Core Contract Implementation. The IWormhole.sol interface summarizes the Core Contract functionality. The top-level Solidity contracts here are a rough benchmark for the implementation complexity (0.5kLOC). We do not expect to make significant changes to the Solidity Core architecture to conceal a sender’s or recipient’s identity (see the User Flows below for more details).
Relayer+Guardian Implementation. The primary code changes in the Guardian will involve adding a watcher here. We intend to develop an example relayer for demonstration purposes, such as this Aptos example.
Token Bridge PoC. After porting Wormhole Core, we plan to port the Wormhole Token Bridge. See the Solidity implementation here. Notably, we intend for our implementation to be fully compatible with the existing Wormhole Token Bridge deployments. We will need to slightly extend the Noir implementation to support private transfers. This is described in the User Flows below.
Minimal UI. Allow sending public and private messages to and from Base.
Testing + Buffer. The buffer will allow us to conduct additional testing, address unanticipated technical challenges, add documentation, and/or optimize the implementation.
User Flows
Our north star design goal is to remain backward compatible with existing Wormhole deployments while supporting public and private flows with Aztec. For the token bridge PoC, we plan to sponsor fees.
Wormhole Background: Public Flows
We summarize the standard public flows in this section. For a comprehensive overview of the Wormhole protocol, see the docs here.
Source. The Wormhole user flow for non-EVM chains.
- A source contract or EOA sends a payload to the Wormhole Contract on the source chain.
- Guardians observe the payload, which is typically emitted as a log.
- Each guardian wraps the message payload in a VAA. The VAA is the standard Wormhole message format that adds metadata to the payload (
timestamp,sequence, etc.). The VAA metadata does not include the destination chain or recipient’s address. The payload may include recipient’s chain and address, but it is not required. - Guardians sign and broadcast the VAA, and persist it when a quorum of signatures has been observed.
- The relayer retrieves the signed VAA via p2p, a guardian’s RPC endpoint, or a third-party API and submits it to a target contract on the destination chain.
- The target contract should generally verify the VAA using the Wormhole Core contract to ensure the signatures are valid.
- The target contract will typically extract the payload from the VAA, perform additional verification (e.g., ensuring the payload’s destination chain ID is correct), and execute the corresponding action (e.g., minting tokens to a recipient).
Adding Privacy
Note: We are focused on allowing the Aztec user to conceal his or her identity. We do not attempt to hide token amounts across chains.
Aztec to EVM. When sending funds from Aztec to a destination chain, the message must simply be initiated as a private transaction.
EVM to Aztec. When sending funds from an EVM chain to Aztec using our token bridge PoC, we require the recipient to be specified as a byte string that fits in a native Aztec field element. When the message is consumed in public, our token bridge implementation will interpret the recipient as an Aztec address. When the message is consumed in private, our implementation will interpret the recipient as the hash of a secret preimage: to privately bridge tokens, a user must also provide the preimage.
More specifically: a recipient in Wormhole’s token bridge is a byte array of length 32. Aztec addresses are outputs from the poseidon2 hash (field elements, ~254 bits). We can use poseidon2 for the hash lock as well; we could use any hash as long as it’s truncated to fit into a field element, but the poseidon2 verification will be most efficient on Aztec.
Roughly speaking, we can have claim_public(vaa_bytes) and claim_private(vaa_bytes) on Aztec:
claim_public: interpret the recipient as an addressclaim_private: interpret the recipient as a hash lock
By the collision resistance and preimage resistance of poseidon2, we don’t need to fragment liquidity on the source token bridge.
Future Work
The future work primarily revolves around implementing other features in the Wormhole stack on top of the Core messaging primitives:
- Tooling Integrations: SDK and Dashboard
- Non-Fungible Token Bridge
- Native Token Transfers (NTT): eliminate the need for wrapped tokens.
- Settlement: Wormhole’s intent-based bridging solution.
- Alternative fee management options: such as Fee Payment Contracts, moving beyond the app-sponsored fees in the PoC.
- Compliance hooks (as required): private bridging may introduce compliance concerns for some applications and users. Once the initial version(s) are implemented and deployed to testnet, we will review relevant compliance concerns and evaluate whether changes are required to support compliant bridging.
- Trust Minimization: Wormhole is committed to pragmatic, progressive decentralization of its Guardian set. By remaining compatible with existing implementations, the Aztec implementation could benefit from those advancements.
About Us
The Wormhole Foundation is dedicated to advancing interoperability in the blockchain ecosystem. We support research, development, and adoption of cross-chain technologies that enable seamless communication between decentralized networks. Our work spans core protocol advancements, developer tools, and community initiatives to drive the future of an open, interconnected web.
Nethermind is a blockchain research and development company. We empower enterprises and developers worldwide to access and build on the decentralized web. Our work touches every part of the blockchain ecosystem: from fundamental cryptography research to application-layer protocol development.
Disclaimer
This proposal does not create a contractual relationship between Wormhole Foundation, Nethermind, Aztec Labs, and the Aztec Foundation - the service engagement requires a separate written agreement setting out the specific terms and conditions. The parties make no express or implied representations or warranties regarding the accuracy or completeness of information or opinions contained herein. All data and figures are based on information available at the time of writing (22/03/2025). Performance dates, price estimates, and timeframes are estimates only and may change depending on the final agreed scope of work.
