Title
Cross-Chain Messaging Infrastructure by WakeUp Labs
Contact Details
milton@wakeuplabs.io
Summary
We propose to develop a Cross-Chain Messaging Infrastructure that facilitates seamless interoperability between Aztec and other Layer 2 networks. Our approach will start with a centralized implementation to accelerate development and establish a solid foundation, followed by a structured transition towards decentralization. The primary objectives are:
- To build a robust framework enabling developers to create cross-chain applications efficiently.
- To develop a showcase application demonstrating the system’s full capabilities.
About Us
WakeUp Labs is a blockchain development firm specializing in EVM-compatible chains, cross-chain interoperability, and privacy-focused architectures. Our team includes experienced blockchain engineers with deep expertise in:
- Zero-knowledge proofs (ZKPs) and privacy-preserving technologies.
- Cross-chain bridge development.
- EVM-compatible smart contract development.
- Optimistic and ZK-Rollup architectures. We are committed to enhancing private and secure interoperability between Aztec and other L2 networks.
Details
Cross-Chain App Demo:
Our cross-chain messaging system enables multiple use cases, we can present at the demo one of these ones:
1. Cross-Chain Bridging (two options):
- Traditional Tokens: Users lock funds on one chain and mint equivalent tokens on the target chain, with potential solver-based solutions for native token swaps.
- Omnichannel NFTs & Fungible Tokens (OFTs): Move assets across chains without wrapping or intermediaries. No need to lock or unlock funds.
2. Confidential payroll systems: Process salaries securely without revealing individual salary details.
Kind of Bridge & Justification
We will create our own Cross-Chain Messaging Infrastructure that facilitates seamless interoperability between Aztec and other Layer 2 networks.
To achieve this, we will leverage ERC-7683 Cross-Chain Intents. The core idea is to deploy contracts and facilitate an SDK in Solidity and in Noir, enabling the creation of cross-chain messaging intents. We will maintain Merkle trees on both chains, recording all generated intents, and use relayers (initially centralized) to propagate these intents and certify their execution at the time of fulfillment.
The main reason for using Merkle trees is to efficiently verify that an intent was created on the source chain without having to transfer all intents individually. By storing only foreign merkle roots, providing the intent’s content upon solving the message intent allows us to run the proper verifications and act appropriately without needing to store the content of all the messages of every chain in every chain. This helps reduce on-chain storage and computational overhead. It’s also compatible with the portal messaging restrictions. That said, we’re open to modifying the design if there’s a more efficient alternative for verifying the existence of intents across chains.
How the design will meet the requirements
Our Solidity and Noir SDK will enable standardized cross-chain messaging:
PortalContract (Aztec & L2): Manages intent creation, verifies Merkle roots, and processes messages.
Merkle Root Relayer: Initially centralized, later decentralized for enhanced security.
Execution Model: Ensures seamless user experience while preserving privacy.
Expected Outcomes
- A functional PoC demonstrating secure and trust-minimized cross-chain interoperability with Aztec.
- Efficient private transactions with minimal latency and cost.
- Enhanced user experience through seamless deposits and withdrawals.
- A foundation for future iterations toward a production-ready solution.
Technical Hurdles
1. On Source Chain: PortalContract logs intents and updates Merkle roots.
2. Relaying: A relayer transmits the updated Merkle root to the target chain.
3. On Target Chain: The PortalContract verifies Merkle root integrity, allowing solvers to fulfill intents securely.
4. Privacy Layer: Users can submit hashed intents for private execution.
User Flow and Journey
1. Source Chain:
- A contract calls the PortalContract with a message.
- The PortalContract creates an intent, hashes it, and updates the Merkle root.
2. Relaying:
- A relayer picks up the updated Merkle root and transmits it to the target chain.
3. Target Chain:
- The PortalContract updates the target chain’s Merkle root.
- A solver verifies the intent in the source chain, confirms the availability of the Merkle root, and submits a fulfillment request.
- The PortalContract verifies the request by checking the intent’s existence in the Merkle tree and forwards the message to the destination contract.
- The destination contract processes the message.
It would work the same way in the opposite direction.
This system could also support private messaging. Instead of storing the full intent on-chain, users could store only a hashed intent, ensuring only they can solve it privately. The system would still verify the intent’s existence via the Merkle root, maintaining privacy while ensuring integrity.
Once the intent is done we just mark it as resolved, we can further inspect this but there should be no exposure by doing this publicly in a simple mapping(intent hash, bool). Solvers would check this mapping before committing to a work. Regarding the Merkle root we have a few, a local one to the chain and one for each foreign chain that we support. The update is as follows:
- Local root: The contract updates the root automatically upon intent creation.
- External roots: The root of different chains is updated through the relayer or decentralized mechanism.
Intents Nullification
We will create a public mapping(intent hash, bool) to nullify spent intents. We are also going to introduce a salt to each intent, to ensure that identical messages do not produce the same hash. This prevents replay attacks and makes it unnecessary to maintain a separate nullifier tree. This works similarly to double-spending prevention mechanisms, where an intent cannot be reused once fulfilled.
Security Considerations
To mitigate brute-force risks:
- We will include a random salt in the intent hash.
- This ensures uniqueness and prevents replay attacks.
- Similar to how Aztec uses randomness in notes or secret hashes in bridges, our design will incorporate a comparable mechanism to enhance security.
Intents Privacy
- Our current focus is not on full privacy like Tornado-style anonymity but rather on controlled disclosure of intents.
- For private messages the intent itself can be hashed before being published, preventing premature exposure while still allowing verification by the user that knows its details. Providing the original intent content as a private function call in Aztec will allow verification against the public root and also the follow up execution of private actions of any kind, for example token minting in the case of a bridge.
- We are considering additional obfuscation techniques in later project iterations to enhance privacy further.
We would allow the insertion of intents hash altogether so that they can be fully disclosed as private transactions in Aztec hiding all information on it and allowing chained private calls to execute any private action desired, whether that’s a bridge or anything the developer is working on.
We are actively exploring these privacy-preserving mechanisms for future improvements.
Example bridge implementation
Assets are locked on one side—Arbitrum, for example—while minting instructions are sent to Aztec.
- For a public transaction, the user calls the bridge contract to lock their assets. The bridge contract then sends a public intent message to the messaging layer: mint(asset, amount, to). This intent is included in the Merkle root, which is later delivered to the Aztec chain. A solver will then call the messaging contract to relay the message to the bridge contract on Aztec, which mints the corresponding tokens.
- The private counterpart follows a similar process but introduces privacy for the recipient. Since asset type and amount must remain public (as the deposit occurs on Arbitrum, where balances are transparent), we instead obscure the recipient’s identity. This is achieved by hashing the recipient’s address with a secret (just particular to this bridge implementation). The message is sent and resolved publicly by any solver. Upon receiving it, the bridge contract on Aztec registers a pending mint for the specified amount, associated with the hashed address. Finally, the recipient submits a private transaction to the bridge contract to claim the tokens, thereby nullifying the pending mint entry.
Further implementations could be explored but we believe any would make use and benefit from the messaging layer in place for public or private messages.
Milestones & Roadmap
We propose a fast centralized prototype
Phase 1 (Week 1): Research & Architecture Design – Define project scope, structures, and obstacles.
Phase 2 (Weeks 2-3): Development & Integration – Build core messaging contracts, relayer, bridge contracts, and UI.
Phase 3 (Week 4): Testing & Deployment – Deploy on testnet, provide documentation, and demonstrate PoC.
Grant Amount Requested:
We request $50,000 to cover initial development, security audits, and infrastructure costs.
Grant Budget Rationale:
Development salaries for the Engineering Team (smart contracts, relayer, UI, integrations, Tech Lead, QA).
Post MVP, potential improvements:
Path to Decentralization
With the core messaging infrastructure in place, the next step is ensuring strong guarantees for users through decentralization. While the relayer plays a crucial role, it introduces a trust assumption: even if it cannot modify or delete existing messages, it could inject new messages without a corresponding counterpart. This is unacceptable in a fully trustless system.
The key solution is a decentralized oracle or any mechanism that allows secure cross-chain communication of Merkle roots.
Proposed Approach
To leverage existing infrastructure while staying within the expected timeframe, we propose:
1. Using existing cross-chain messaging solutions to transmit Merkle roots between any chain and Ethereum. In particular we would be using LayerZero to send these messages, but any other similar tool could be implemented as well.
2. Utilizing the Aztec Portal for the final step between Ethereum and Aztec.
3. Implementing a specific sequencer to optimize gas costs by sponsoring root transmissions between Ethereum and Aztec. In particular this service will be picking up messages coming from aztec into the L1 contract and pushing them forward to the target chain through LayerZero. We’ll reserve these rights to a batcher that can collect a bunch of these messages and send them all in a single transaction to optimize gas costs. But we’ll keep the possibility open for a third party to potentially pay for the gas and send their message in case the batcher were to ignore it. We could also do this inside Aztec for all the messages coming from the outside, at least for the public variants.
This hybrid approach allows us to rapidly achieve decentralization without reinventing cross-chain messaging solutions.
A fully decentralized oracle system purpose-built for Merkle root transmission is another potential direction. However, developing such a system may exceed the scope of this proposal.
This roadmap balances practicality and security, ensuring a decentralized, reliable messaging layer while leveraging existing infrastructure for efficiency.