Contact Details
Raid Guild
(https://x.com/RaidGuild
Our Discord: Raid Guild)
Point of Contact: George
Discord/Telegram: @georgeh0x
Summary
We propose building an EVM-compatible cross-chain messaging protocol connecting Aztec to Optimism, leveraging the privacy benefits of Aztec while enabling interoperability with the thriving Optimism ecosystem. Our protocol will provide two essential functions:
-
A general-purpose messaging layer allowing any arbitrary data to be securely transmitted between chains, enabling cross-chain dApp coordination while maintaining privacy guarantees.
-
A comprehensive asset bridge facilitating private transfers of multiple token types (ERC-20, ERC-721, ERC-1155) between Aztec and Optimism, using a wrapped token model based on ERC-1155 for maximum flexibility.
The bridge architecture employs trust-minimized relayers utilizing Trusted Execution Environments (TEEs) hosted on decentralized networks to ensure secure message passing without centralized vulnerabilities. Smart contracts on both chains will handle message validation, asset locking/unlocking, and wrapped token minting/burning.
The aim is to create a bridge with minimal governance and trust assumptions while preserving the privacy guarantees through the full cross-chain operation. The design is to be general-purpose and extensible for other applications to build on top of it. The bridge will be deployed on Aztec Testnet and Optimism Testnet initially and then extended to other L2s in the future.
Start and End Date
Our team will commence work on April 1 2025 and commit to delivering a fully functional cross-chain messaging protocol on Aztec Testnet and OP Sepolia by June 2025.
About Us
Raid Guild is Web3’s premier decentralized development collective, delivering high-impact blockchain solutions since 2019. With 154 skilled members and over 200 successful projects completed, we specialize in creating secure, efficient infrastructure for leading protocols across the ecosystem.
Our extensive expertise makes us uniquely qualified to build an Aztec <> EVM messaging protocol:
- Pocket Network Bridge : Engineered a robust cross-chain bridge handling over $7M in bridged assets in 2024 alone, creating a 10x surge in $POKT token value through our wrapped token implementation, liquidity solutions, and seamless staking interface.
- Gnosis Chain Bridge : Built the OG Gnosis Bridge dApp for secure, user-friendly asset transfers between Ethereum and Gnosis Chain, optimizing both technical infrastructure and user experience.
- PORTERS RPC Gateway : Built a scalable decentralized RPC infrastructure on POKT Network handling over 1 billion requests across 40+ blockchain networks, providing crucial cross-chain connectivity.
For this project, we’ve assembled a specialized team:
George (Lead Smart Contract Developer)
- 4+ years in Solidity smart contracts and full-stack development
- Contributed to multiple ZK projects using Circom and Noir, including privacy-preserving cross-chain implementations
- Core developer for Raid Guild’s Pocket Network bridge
EC (Lead Backend Developer)
- 7 years specializing in decentralized infrastructure and TEE implementations
- Head of Product at Rigor, roadmapping core features and architecting technical specifications
- Technical lead for dozens of blockchain projects at RaidGuild
- Deep expertise in relayer networks and cross-chain message validation
Sasquatch (Project Management)
- Senior Account Manager who successfully coordinated the Pocket Network bridge deployment
- Delivered 12+ blockchain infrastructure projects on time and on budget
- Expertise in managing complex cross-chain initiatives with multiple stakeholders
Our team brings proven experience in bridging technologies, privacy-preserving systems, and web3 infra – the exact skillset needed for building a secure, efficient Aztec <> EVM L2 messaging protocol. Having delivered multiple production-ready bridges handling millions in volume, we understand the unique challenges of cross-chain operations, particularly when preserving privacy guarantees.
Specifications
Overview
The protocol will comprise two forms of cross-chain operations:
- Messaging - any arbitrary data
- Asset Transfers - an extended implementation of Messaging (1) specifically for tokens
Relayers
Our protocol uses trust-minimized relayers built on Trusted Execution Environments (TEEs) to securely transmit messages between Aztec and other L2s. These relayers operate on decentralized networks for maximum reliability and censorship resistance. We are currently evaluating the following options for building and hosting them:
For testnet deployment, relayer management will be handled through an owner-controlled whitelist mechanism in the Bridge contract, allowing only authorized relayers to fulfill cross-chain message requests. For mainnet, we’ll implement a DAO-governed permissioning system with additional security safeguards to minimize trust assumptions.
Smart Contracts
Our contract architecture draws inspiration from established cross-chain protocols, incorporating elements from ERC-7683, Hop Protocol, and Chainlink CCIP while adapting them for Aztec’s privacy requirements.
1. Messaging Protocol
The core of our system is a “router” contract that serves as the endpoint for sending and receiving cross-chain messages. Each message contains a standardized struct with:
originChainId: Identifier of the source chaindestinationChainId: Identifier of the target chainnonce: Unique sequential identifier to prevent replay attacksmessageData: Arbitrary payload data (ABI-encoded for structured data)
When a message is sent, the router generates a unique messageId that’s logged on the origin chain and used by relayers for validation and fulfillment on the destination chain. The destination router verifies message authenticity and executes the appropriate actions based on the payload.
2. Asset Transfer Protocol
The asset transfer functionality extends the messaging protocol through a specialized “asset handler” contract. This component:
1.) On origin chain:
- Accepts and validates an Order struct (based on ERC-7683 but modified for multiple asset types)
- Locks tokens from the user in the contract
- Encodes the order details as messageData
- Triggers the router contract to initiate the cross-chain message
2.) On destination chain:
- Receives validated messages from the router
- Decodes the Order struct
- Mints wrapped versions of the tokens as ERC-1155 tokens
We chose to use ERC-1155 for the wrapped token implementation as it allows for a flexible and efficient way to handle multiple token types (ERC-20, ERC-721, ERC-1155) in a single contract. Our ERC-1155 implementation creates a unique id of each wrapped token calculated as keccak256(originChainId, contractAddress, tokenId) , with tokenId defaulting to 0 for ERC-20 tokens. Each wrapped token includes JSON metadata mapping to id for additional context such as token standard and URI of original token.
For popular ERC-20 tokens, we’ll deploy liquidity pools enabling immediate 1:1 swaps between wrapped tokens and native tokens (i.e. Aztec-bridged USDC and native USDC on Optimism), with swap permissions encoded in the original cross-chain message to minimize user transactions.
The redemption process mirrors the deposit flow, with wrapped tokens being burned on the source chain and the asset handler on the destination chain releasing the original locked tokens to the specified recipient.
Grant Milestones and Roadmap
Roadmap
Phase 1: Foundation (April 1-7, 2025)
- Research and finalize architecture choices for TEE relayers (Lit Protocol vs Fleek’s Edge SGX vs Marlin)
- Develop initial prototypes for router contracts on both Aztec and EVM
- Setup testing environment and CI/CD pipeline
- Deliverable: Technical architecture document and contract interfaces
Phase 2: Core Development (April 8 - May 7, 2025)
- Implement router contracts for arbitrary messaging
- Build and deploy initial TEE relayers on decentralized network
- Implement basic security features and validation logic
- Deliverable: Working messaging protocol between Aztec and EVM
Phase 3: Asset Bridge (May 8 - May 21, 2025)
- Develop asset handler contracts for token transfers
- Implement ERC-1155 contract for wrapped token mint/burn
- Develop liquidity pool for 1:1 token swaps with wrapped tokens
- Setup token redemption and withdrawal flows
- Deliverable: Functional asset transfer system between chains
Phase 4: Testing and MVP Launch (May 22 - June 7, 2025)
- Comprehensive security self-auditing and testing
- Resolve bugs and optimize gas usage
- Deploy full solution to Aztec Testnet and OP Sepolia
- Create documentation and user guides
- Deliverable: MVP cross-chain messaging and asset transfer protocol
Phase 5: Post-MVP Improvements (Future Work)
- Implement DAO governance for bridge contract ownership
- Add support for additional L2 networks
Phase 6: Additional Features (Future Work)
- Migrate validation logic to using storage proofs
- Add an escrow mechanism on Aztec for chain abstraction use: users can spend on any chain and let solvers draw from their escrowed balance on Aztec as reimbursement afterwards. This would be used by ERC-4337/7702 accounts (including stealth addresses).
Phase 7: Mainnet Preparation (Future Work)
- Complete formal verification of contracts
- Additional external security audits
- Community testing program and bug bounty
- Mainnet deployment preparation
Grant Amount Requested
$50,000
Grant Budget Rationale
The requested grant amount will be allocated across the four main development phases to deliver the testnet MVP:
- $12,000 - Phase 1: Research, architecture design, and initial prototyping requires specialized knowledge of TEE systems and cross-chain protocols.
- $16,000 - Phase 2: Core contract development and relayer implementation represents the most intensive engineering work.
- $12,000 - Phase 3: Asset bridge implementation involves complex token handling across different standards.
- $10,000 - Phase 4: Security testing, optimization, and documentation to ensure a production-ready testnet MVP.
The timeline allows for focused development with a dedicated team of 2-3 engineers working on the project, prioritizing security and reliability while meeting the June 2025 deadline.
Questions
- Will Aztec provide any technical support during development or for resolving Aztec-specific implementation challenges?