# Aztec Ghost: Run Transactions Anonymously on Optimistic L2s using Privacy Relayers **URL:** \ **Category:** Aztec\ **Tags:** rfgp, bridge\ **Created:** [March 22, 2025, 12:32am UTC](https://forum.aztec.network/t/aztec-ghost-run-transactions-anonymously-on-optimistic-l2s-using-privacy-relayers/7582 "2025-03-22T00:32:03Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![PsychoVirtual](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.aztec.network/psychovirtual/32/2398_2.png) [@PsychoVirtual](https://forum.aztec.network/u/PsychoVirtual)\ **Post date:** [March 22, 2025, 12:32am UTC](https://forum.aztec.network/t/aztec-ghost-run-transactions-anonymously-on-optimistic-l2s-using-privacy-relayers/7582/1 "2025-03-22T00:32:03Z")
# Aztec Ghost: Run Transactions Anonymously on Optimistic L2s using Privacy Relayers ## Contact Details - Email: [dev@johnswu.net](mailto:dev@johnswu.net) - Email: [simon@psychovirtual.io](mailto:simon@psychovirtual.io) - Signal: Available upon request ## Summary We propose a secure and private cross-chain intent bridge connecting Aztec’s privacy-focused L2 with optimistic rollups. Our bridge addresses three critical challenges in the current cross-chain ecosystem: lack of privacy on Layer 2s, absence of bridges between private and public ecosystems, and lengthy finality delays on optimistic rollups. Our solution leverages Espresso’s BFT consensus to bypass the 7-day challenge period, providing near-instant finality while maintaining security through slashable stake. The system implements a cross-chain intent mechanism where users create orders on a single source chain, with assets securely locked and cryptographically proven to the destination chain to prevent value duplication. The bridge incorporates a private relayer architecture that preserves user anonymity across networks and implements a dual-fee incentive structure: a Dutch auction filler fee that decreases over time until execution becomes profitable, and a settlement fee to encourage prompt finalization. This economic model ensures a robust network of nodes is incentivized to execute cross-chain orders efficiently. The atomic execution model guarantees all-or-nothing transactions that either complete fully or revert entirely, preventing partial fills and asset fragmentation. Our two-phase commit process ensures transaction integrity across chains - locking assets on the source chain and only unlocking them on the destination upon cryptographic verification. By unifying Ethereum’s public and private ecosystems, our bridge enables seamless privacy-preserving cross-chain operations, allowing users to leverage Aztec’s privacy features while accessing the liquidity and functionality of optimistic L2s, all without compromising their anonymity or security. ## Start and End Date Start Date: April 1, 2025 End Date: June 30, 2025 (Testnet MVP) ## About You (Team Background) Psycho Virtual accelerates Zero Knowledge Cryptography adoption through interdisciplinary research and rapid development cycles. We partner with leading technology companies, protocols, and investors to build cutting-edge applications leveraging advanced mathematics and algorithms. ## Our Expertise - Zero-knowledge proofs - Account abstraction - Cross-chain interoperability ## Recent Projects GhostPad: Private token launches on Solana Spooky AGI: AI meme coin with self-reinforcing growth loops Sparta(0): SuperSpartan prover (ZK HACK Montreal Chewing Glass Award winner) HackSTIR: Prototype STIR prover in Golang PLONK GPU Hardware Acceleration: Faster PLONK Prover execution Bulletproof: Bulletproof prover implemented in Rust ZK Poker: A zero-knowledge proof based poker game for the Aleo blockchain # Details ## 1. Introduction ### 1.1 Current Challenges in Cross-Chain Transactions #### Privacy Concerns on Layer 2s Currently, all transactions on Optimistic and ZK rollups are fully public. Users seeking privacy have no way to interact with L2 ecosystems without exposing their transaction history, asset holdings, and trading patterns. This fundamentally undermines privacy for DeFi users who need to access L2 liquidity and functionality. #### Bridging Between Private and Public Ecosystems There is a critical need for a secure bridge between privacy-focused L1 solutions like Aztec and public L2 networks. Without such a bridge, users are forced to choose between privacy and scalability, rather than benefiting from both simultaneously. #### L2 Finality Delays Optimistic rollups rely on a challenge period (typically 7 days) before transactions are considered truly final. This creates a fundamental dilemma for cross-chain operations: - Wait 7+ days for secure finality (making cross-chain operations impractically slow) - Accept significant security risks by acknowledging transactions before they’re final (potentially creating duplicate assets) This lengthy dispute window severely impacts cross-chain operations that require transaction finality, creating unacceptable delays for users. ### 1.2 Proposed Solution: Cross-Chain Intent Bridge To address these challenges, we propose a comprehensive bridge system with several key innovations and expected benefits: #### Key Components ##### Fast Bridging with Espresso We propose integrating **Espresso’s BFT consensus layer** to enable near-instant finality for cross-chain transfers, bypassing the lengthy dispute window of Optimistic L2s while maintaining security through slashable stake. ##### Cross-Chain Intent System Users would create **intent orders** on a single “source” chain (Aztec or an L2). To use assets on another chain, they must be **securely locked** on the source and cryptographically proven to the destination, ensuring **no duplication** of value. ##### Private Relayer for L2s The system would incorporate a **private relayer** concept that finalizes instructions quickly, preserving user anonymity on both Aztec and the L2. ##### Filler Incentives A **robust fee-based economic model** would incentivize network participants to execute cross-chain orders: - **Dutch Auction Mechanism** : Order fees would start high and gradually decrease over time until a filler decides it’s profitable to execute. - **Two-Part Fee Structure** : - **Filler Fee** : The main economic incentive paid to whoever completes the cross-chain transaction. - **Settlement Fee** : A separate reward for proving successful execution on the source chain, encouraging prompt finalization. - **Economic Equilibrium** : The system is designed so fillers only execute orders when the fee exceeds their costs, creating a natural market for cross-chain transaction execution. - **Exclusive Window** : Original fillers would have a short time period with exclusive rights to claim their settlement fee before it becomes available to other participants. ##### Atomic Execution Model The system is designed with complete atomicity in mind: - **All-or-Nothing Execution** : Orders are either fully executed or not executed at all. There are **no partial fills** in this system. - **Transaction Integrity** : If any step in the cross-chain execution process fails, the entire transaction reverts to its original state. - **Two-Phase Commit** : The process is designed to function like a **two-phase commit** : If any step fails, the original state would be restored (assets remain locked or become unlocked without duplication). #### Expected Benefits - **Seamless bridging** with minimal user friction, enabling multi-step cross-chain instructions in a single atomic flow. - **Private relayer architecture** that would hide user identity and complete tasks quickly. - **Advanced Composability** : A user could bridge ETH to an L2, purchase an Azuki NFT, and bridge it back to Aztec in one orchestrated flow—while preserving anonymity via private relaying. - **Robust, Incentivized Filler Network** : - An **economic model** designed to ensure a network of nodes is rewarded for both executing orders and finalizing them on the origin chain. - A low probability of inconsistent state, since fill orders would be fully completed or canceled. - **No partial fill risk** : Unlike other cross-chain systems that may leave assets stranded in an intermediate state, this design ensures transactions are atomic—they either succeed completely or fail entirely. - **Vault Contracts on Each Chain** : - Would exist in Aztec and on Optimistic L2(s), ensuring local deposit/withdraw controls and asset locking, preventing duplication of minted assets. - **Cancellable orders** : Users would be able to cancel cross-chain orders at any time as long as the order has not been settled and they can prove ownership of the order. This is useful since users may need to adjust their fees to get a filler to pick up the order. * * * ### 1.3 Technical Approach: Espresso #### Accelerating Optimistic L2 Transaction Finality 1. **The Optimistic L2 Finality Challenge** Optimistic rollups achieve scalability by publishing transaction batches to Ethereum while deferring execution verification. This creates a fundamental challenge: transactions can only be considered truly final after a **challenge period** (typically 7 days) during which fraud proofs can be submitted. This long waiting period severely impacts cross-chain operations that require transaction finality. 2. **Traditional Cross-Chain Bridging Limitations** For bridges connecting to optimistic L2s, this creates an undesirable tradeoff: either wait the full 7 days for secure finality (making cross-chain operations impractically slow) or accept the significant risk of accepting transactions that might later be reverted (potentially creating duplicate assets across chains). 3. **Espresso as a Finality Accelerator** Espresso introduces a **BFT consensus layer** with economic security through slashable stake, effectively creating a fast-finality overlay for optimistic rollups. When an L2 transaction is confirmed by Espresso’s validator network, it can be considered final with near-instant certainty, without waiting for the challenge period to complete. 4. **Implementation in Our Cross-Chain Bridge** Our bridge leverages Espresso as a finality accelerator, allowing fillers to prove and rely on transaction settlement immediately. This enables smooth cross-chain operations without sacrificing security, as the economic guarantees of Espresso’s staking model provide protection comparable to waiting for the full challenge period. 5. **Transaction Finalization for Optimsistic L2s and Verification in Espresso** Understanding how Espresso finalizes transactions and how fillers can prove this finalization is critical to our cross-chain intent system: ### 1.4 Aztec Transaction Finalization #### Proving Aztec Transaction Finality for Cross-Chain Operations When bridging from Aztec to optimistic L2s, fillers must cryptographically prove that transactions on Aztec are finalized. This proof is essential for the security of the cross-chain intent system, ensuring assets can only be unlocked on the destination chain when they are verifiably locked on Aztec. 1. **Aztec Transaction Lifecycle** Transactions in Aztec follow a path to finality that includes: 2. **Finality Verification by Fillers** Fillers must verify several cryptographic elements to prove an Aztec transaction is final: 3. **Implementation in Cross-Chain Intents** When a user creates an order on Aztec, fillers must: 4. **Presenting Proofs to Optimistic L2s** The filler provides this Noir-generated ZK proof to the L2 vault or intent contract, which: This approach leverages Noir’s zero-knowledge capabilities to present a compact, privacy-preserving proof of Aztec transaction finality to optimistic L2s, streamlining the verification process while maintaining the atomicity and security of the cross-chain bridge. * * * ## 2. Cross-Bridge Intent Lifecycle We describe how a cross-chain intent (or job) moves from creation to completion (or cancellation). We primarily track state on the **source chain** , where the user’s assets are locked until the bridging or job is proven successful. - **On the source chain** , an order’s lifecycle can be: - **On the destination chain** , we typically see only two terminal states: * * * ### 2.1 Actors - **User** - **Filler (Relayer)** - **Aztec Intent Contract (Noir-based) / Opt L2 Intent Contract (EVM-based)** - **Espresso** - **Vault Contracts (Underlying Deposit/Withdraw)** ### 2.2 Vault Contracts on the Optimistic L2 Below is an **example interface** for an **Optimistic L2 vault**. It also implements origin/destination settlement logic by extending `IOriginSettler` and `IDestinationSettler`. Internally, such a contract might: - Maintain a mapping `(bytes32 jobId => bool withdrawn)` to ensure each job ID can only be withdrawn **once**. - Check that **assets cannot be withdrawn** without being locked from the Aztec side by verifying the supplied proofs (ZK proofs, consensus proofs, etc.). * * * ### 2.3 Aztec → Opt L2 Flow 1. **User Creates Intent on Aztec** 2. **Fee Payment** 3. **Filler Observes & Evaluates** 4. **Filler Executes Job on L2** 5. **Listening to Espresso Finalization** 6. **Settling Transaction Result** * * * ### 2.4 Opt L2 → Aztec Flow 1. **User Posts Intent on L2** 2. **Fee Payment** 3. **Espresso Finalization** 4. **Filler Monitors** 5. **Filler Executes on Aztec** 6. **Listening to Espresso Finalization** 7. **Settling Transaction Result** * * * ### 2.5 Cancelling Orders **User-Initiated Reclaim** - If no fill occurs before timeout—or at any time the user wants to abort (assuming no partial fill in progress)—the user can cancel. - On the **source chain** , it marks the job `cancelled` and unlocks the user’s assets. - On the **destination chain** , the user has two options to ensure the order is not fulfilled: **Race Conditions Between Cancellation and Execution** - **First-to-Finalize Wins** : It’s important to understand that there is a potential race condition between order cancellation and order execution. - If a user initiates a cancellation while a filler is already in the process of executing their order, whichever operation is finalized first on the chain will take effect. - There is **no override mechanism** - a cancellation cannot stop an execution that is already being processed, and vice versa. - This means that even after requesting cancellation on the source chain, an order may still be executed if a filler processes it before the cancellation is finalized. - Users should be aware of this timing consideration when attempting to cancel orders, especially for high-value transactions. **States** - **Source** : `pending` → `cancelled` or `pending` → `success`. - **Destination** : `success` from a single bridging transaction or `cancelled` if no bridging occurs or the user forcibly cancels. * * * ### 2.6 Security & Job IDs - **Random, Collision-Resistant IDs** Each cross-chain job has a unique ID. Once finalized or canceled, it cannot be reused. - **Two-Phase Commit** The user’s assets are locked on the source, proven to the destination for unlocking. The source only releases the locked assets if the destination success proof is submitted. - **Transaction Atomicity** Each chain’s transactions either succeed fully or revert—no partial fills. - **System Safety** Espresso’s finality plus ZK proofs ensures no duplication: no asset is minted/unlocked on the destination unless the lock is proven on the source. - **Economic Model** The filler fee + settlement fee approach encourages timely bridging and finalization. * * * ## 3. Additional Mechanisms ### 3.1 Timeout and Asset Reclaim Mechanism - **Intent Timeout Period** : Each intent has a window (e.g., 24–72 hours). If no bridging/final result is reported, the user can cancel/reclaim. - **User-Initiated Reclaim** : The user proves no fill was submitted; the vault contract reverts the job to `cancelled`. The user’s locked tokens/notes are returned. - **Cancel on Destination** : The user can also cancel on the destination chain at any time if they can prove job ownership, ensuring no filler tries to proceed with a stale order. - **Cool-Down** : An optional buffer to avoid last-minute collisions between a filler finalizing and a user canceling. ### 3.2 Maintaining Asset Consistency - **No Double-Spend & No Duplication** Two-phase commit ensures destination unlock only if source assets are locked, and vice versa. Job ID prevents collisions or replays. - **Synchronization** Espresso finality + ZK proofs ensure the source finalizes quickly once the destination transaction is confirmed. - **Failures & Timeouts** If bridging fails or never happens, user reclaims locked tokens. ### 3.3 Fee System (Dutch Auction + Settlement Fee) A **Dutch auction** determines the filler fee, starting high and decaying over time. A **Settlement Fee** incentivizes finalization on the origin chain: **Economic Behaviors & Pros** - **Encourages Early Filling** : Fillers can earn more if they act while the fee is still high. - **Ensures Final Settlement** : The Settlement Fee is paid to whoever submits the final proof—if the filler disappears, a third party can finalize and claim it. - **Market Efficiency** : If bridging costs are high, the filler fee remains high until it meets someone’s threshold. - **Protocol-Adjusted Settlement Fee** : The protocol can ensure this fee always exceeds proof-generation cost, making finalization profitable. **Disadvantages** - **Fee Setting Complexity** : Users must pick an initial fee, decay rate, floor, settlement fee, and exclusive window. - **Potential Censorship/Sniping** : A block producer might censor the filler’s final proof to steal the Settlement Fee. - **Collusion** : A filler might let a secondary address claim the Settlement Fee. **Possible Security Issues** - **Front-Running** : Another filler may see bridging in progress and try to replicate or undercut. - **Sabotage** : If the Settlement Fee is too large, malicious actors might block finalization. * * * ## 4. Implementation Details: Intent Instructions for Token Operations To provide a comprehensive understanding of the cross-chain intent system, we now detail the specific token operations that users can include in their intent instructions. These operations form the building blocks of cross-chain intents and are **executed by fillers** on both Optimistic L2s and Aztec networks as part of fulfilling the user’s cross-chain instructions. When a user creates an intent, they specify which of these operations should be performed, and a filler will execute them on the appropriate chain on behalf of the user. The filler pays gas fees and handles all the cross-chain communication, while the user simply creates an intent and waits for completion. The instructions can have an id like the following in Aztec: ### 4.1 Fungible Token Intent Instruction #### 4.1.1 **Lock/Deposit** (On **Opt L2** Only) - **Purpose** : Move user’s ERC-20 tokens into a vault on the Opt L2, locking them for bridging or escrow. - **In an Intent** : User specifies this operation when they want to lock tokens on L2 for bridging to Aztec. - **Executed By** : A filler operating on the Optimistic L2. - **Inputs** : - **User Address** (the owner) - **Token Address** (the ERC-20) - **Amount** (how many tokens to lock) - **Outputs** : - **Vault State Update** (the vault now holds these tokens) - **Event** (e.g. `Locked(user, token, amount, jobID)`) #### 4.1.2 **Unlock/Withdraw** (On **Opt L2** Only) - **Purpose** : Retrieve previously locked tokens from the vault (often after bridging finalization or cancellation proof). - **In an Intent** : Specified when a user wants to unlock tokens on L2 that were previously locked. - **Executed By** : A filler operating on the Optimistic L2. - **Inputs** : - **User Address** (the withdrawer) - **Token Address** - **Amount** - **Proof or Authorization** (bridging/finalization/cancellation) - **Outputs** : - **Tokens** returned to the user’s wallet - **Event** (e.g. `Unlocked(user, token, amount, jobID)`) #### 4.1.3 **Transfer** (On **Aztec** ) - **Purpose** : Move tokens from one address to another **on the same chain** (Aztec). - **In an Intent** : Part of multi-step intents where users want to move tokens within Aztec. - **Executed By** : A filler operating on the Aztec network. - **Inputs** : - **From Address** , **To Address** - **Token Address** , **Amount** - **Outputs** : - **Updated Balances** (sender decreases, recipient increases) - **Transfer Event** (e.g. `Transfer(from, to, amount)`) #### 4.1.4 **Swap** (On **Aztec** ) - **Purpose** : Swap one ERC-20 for another (e.g., via a DEX integrated on Aztec). - **In an Intent** : Allows users to specify token swaps as part of cross-chain operations. - **Executed By** : A filler operating on the Aztec network. - **Inputs** : - **Dex Contract** or **Liquidity Pool** - **TokenIn** , **TokenOut** , **AmountIn** , **MinAmountOut** - **Outputs** : - **User** receives **TokenOut** - **Swap Event** on the DEX - Possibly price or slippage info #### 4.1.5 **Approve** (On **Aztec** ) - **Purpose** : Let a spender (marketplace contract, aggregator, etc.) transfer tokens on behalf of the user. - **In an Intent** : Often combined with other operations that require allowances. - **Executed By** : A filler operating on the Aztec network. - **Inputs** : - **Owner** , **Spender** , **Amount** - **Outputs** : - **Allowance** updated in the ERC-20 contract - **Approval Event** (e.g. `Approval(owner, spender, amount)`) * * * ### 4.2 NFT Intent Instructions (ERC-721–like) #### 4.2.1 **Mint NFT** (On **Aztec** ) - **Purpose** : Create a new NFT (e.g., a collectible). - **In an Intent** : Users can specify NFT minting as part of complex operations. - **Executed By** : A filler operating on the Aztec network. - **Inputs** : - **Minter** (authorized to mint) - **Token URI** or **Metadata** - **Outputs** : - **New Token ID** created - **Mint Event** (e.g. `Transfer(address(0), minter, tokenId)`) #### 4.2.2 **Transfer NFT** (On **Aztec** ) - **Purpose** : Move ownership of the NFT from one address to another (same chain). - **In an Intent** : Often part of multi-step operations involving NFTs. - **Executed By** : A filler operating on the Aztec network. - **Inputs** : - **From** , **To** , **Token ID** - **Outputs** : - **Ownership** of the token changes - **Transfer Event** (e.g. `Transfer(from, to, tokenId)`) #### 4.2.3 **Lock/Deposit NFT** (On **Opt L2** Only) - **Purpose** : Lock an NFT in a vault on the Opt L2 (similar to depositing an ERC-20). - **In an Intent** : Specified when users want to bridge their NFT from L2 to Aztec. - **Executed By** : A filler operating on the Optimistic L2. - **Inputs** : - **Owner** , **NFT Contract** , **Token ID** - **Outputs** : - **Vault State Update** (the NFT is now escrowed) - **Locked Event** (e.g. `NFTLocked(owner, nftContract, tokenId, jobID)`) #### 4.2.4 **Unlock/Withdraw NFT** (On **Opt L2** Only) - **Purpose** : Withdraw an NFT from the vault (upon bridging finalization or cancellation). - **In an Intent** : Used when users want to reclaim their NFT on L2. - **Executed By** : A filler operating on the Optimistic L2. - **Inputs** : - **Owner** , **NFT Contract** , **Token ID** , **Proof** (or finalization/cancellation authorization) - **Outputs** : - **NFT** returned to the owner - **Unlocked Event** (e.g. `NFTUnlocked(owner, nftContract, tokenId, jobID)`) #### 4.2.5 **List NFT for Sale** (On **Aztec** ) - **Purpose** : Create a listing so others can buy the NFT (e.g., via an Aztec-based marketplace). - **In an Intent** : Can be part of complex NFT marketplace operations. - **Executed By** : A filler operating on the Aztec network. - **Inputs** : - **Seller** (current owner) - **NFT Contract** , **Token ID** - **Price** or **Min Bid** - Possibly requires an **Approve** if the marketplace needs custody - **Outputs** : - **Marketplace** records the listing - **Listing Event** (e.g. `NFTListed(seller, nftContract, tokenId, price)`) #### 4.2.6 **Buy NFT** (On **Aztec** ) - **Purpose** : Purchase an NFT from a listing. - **In an Intent** : A key operation for NFT acquisition in cross-chain flows. - **Executed By** : A filler operating on the Aztec network. - **Inputs** : - **Listing ID** or **NFT Contract + Token ID** - **Buyer** - **Payment Amount** (matching listing price) - **Outputs** : - **Ownership Transfer** to the buyer - **Funds** paid to the seller - **Sale Event** (e.g. `NFTPurchased(seller, buyer, tokenId, price)`) #### 4.2.7 **Accept NFT Bid** (On **Aztec** ) - **Purpose** : The NFT owner accepts a bid from a buyer (auction or direct bid). - **In an Intent** : Part of NFT auction operations within intents. - **Executed By** : A filler operating on the Aztec network. - **Inputs** : - **Bid ID** or **NFT Contract + Token ID** plus bidder info - **Owner** (accepting the bid) - **Offered Price** - **Outputs** : - **Ownership Transfer** to the bidder - **Funds** paid to the owner - **BidAccepted** event #### 4.2.8 **Delist or Cancel NFT Listing** (On **Aztec** ) - **Purpose** : Seller removes their NFT from the marketplace. - **In an Intent** : Used to cancel marketplace listings in intent flows. - **Executed By** : A filler operating on the Aztec network. - **Inputs** : - **Seller** , **Listing ID** (or NFT details) - **Outputs** : - **Listing** removed from the marketplace - **CancelListing** event #### 4.2.9 **Approve (for NFT)** (On **Aztec** ) - **Purpose** : Let an operator or marketplace manage your NFT. - **In an Intent** : Often combined with marketplace operations. - **Executed By** : A filler operating on the Aztec network. - **Inputs** : - **Owner** , **Operator** (another address), **Token ID** or “approve all” - **Outputs** : - **Approval** so the operator can transfer/list the NFT - **Approval Event** (e.g. `ApprovalForAll(owner, operator, true)`) * * * ### 4.3 Combining Intent Instructions into Complex Cross-Chain Operations Users can combine multiple instructions from sections 4.1 and 4.2 to create complex cross-chain intents. For example: - **NFT Purchase on L2 and Bridge to Aztec** : 1. Lock tokens on Aztec (user operation) 2. Bridge tokens to L2 (filler operation) 3. Execute NFT purchase on L2 (filler operation) 4. Lock NFT in L2 vault (filler operation) 5. Bridge NFT to Aztec (filler operation) 6. Finalize on Aztec (filler operation) These multi-step operations are executed by fillers who are incentivized by fees, with the entire process being atomic - either all steps complete successfully, or the intent reverts to its initial state. * * * ## 5. Example: End-to-End Privacy on Arbitrum (Swap Aztec for ETH, Buy NFT on Arbitrum, and Return NFT to Aztec) This example highlights how the intent system can facilitate a private relayer workflow. The user wants to swap Aztec tokens for ETH on Arbitrum, purchase an NFT, and bring that NFT back to Aztec—all without revealing the user’s identity on Arbitrum. * * * ### 5.1 Overview 1. The user creates an **intent** on Aztec that says: 2. A **private filler (relayer)** observes this intent and executes the necessary bridging, swaps, and NFT purchase steps on the user’s behalf. 3. The system ensures at no point does the user’s **real identity** or wallet address become visible on Arbitrum, thanks to Aztec’s zero-knowledge architecture and the filler’s private role. * * * ### 5.2 User Prepares the Intent 1. The user **locks** a certain amount of Aztec tokens (aZkTokens) in an Aztec vault/intent contract. 2. The user’s order data includes the NFT contract address on Arbitrum, the specific **NFT token ID** they wish to purchase, and bridging instructions to return the NFT to Aztec. 3. A **job ID** is created (random, collision-resistant). This ensures no collision and that the user’s deposit remains private in Aztec’s state. * * * ### 5.3 Filler Observes & Executes 1. **Sees Pending Order** : The filler checks whether the user’s filler fee (Dutch auction + settlement fee) is profitable enough. 2. **Withdraw Aztec Tokens** : - The filler obtains a ZK proof that the user’s aZkTokens are indeed locked on Aztec under the job ID. - The filler also obtains a ZK proof that job order is confirmed on the Aztec chain. - The filler bridges these tokens to Arbitrum (possibly swapping them for ETH in the process). 3. **Swap for ETH** (On Arbitrum): - The filler uses a local DEX or aggregator to convert the bridged tokens into ETH. 4. **Buy the NFT** : - The filler spends the ETH on the desired NFT (e.g., via an Arbitrum-based marketplace). 5. **Deposit the NFT into Aztec** : - Finally, the filler deposits the NFT into Aztec’s bridging system (or an Aztec vault), providing proof that the NFT is now locked on Arbitrum under the same job ID. * * * ### 5.4 Atomicity & Privacy 1. **Atomic Multi-Step Execution** : - If any sub-step fails or reverts, the user’s original aZkTokens stay locked on Aztec, and no partial fill persists. 2. **Private Relayer** : - The filler’s addresses and ephemeral accounts handle the bridging and purchases, **not** the user’s public address. - Thus, Arbitrum sees only “some buyer” purchased the NFT, while the user’s Aztec-based identity remains hidden. 3. **No User Data Leakage** : - No direct link is made between the user’s real-world identity or any public L2 wallet. - The filler’s instructions are private, referencing zero-knowledge proofs from Aztec. * * * ### 5.5 Final Settlement & Payment 1. **Espresso Finalization** : - Each bridging step references Espresso for near-instant finality, guaranteeing no reorgs on Arbitrum. 2. **Settlement Proof on Aztec** : - The filler (or a third party) eventually calls `AztecIntentContract.finalizeJob(jobID, proof)` to prove the entire operation succeeded. - The job is marked `success`. 3. **Fees & Conclusion** : - The user’s NFT is **now in Aztec** , minted or recognized in a private manner. - The filler receives the filler fee. - The user’s anonymity is preserved from end to end. * * * ### 4.6 Key Benefits Demonstrated - **Privacy Preservation** : The user’s identity is never exposed on Arbitrum—only the relayer’s addresses appear. - **Atomic Multi-Step Cross-Chain** : Lock tokens on Aztec, swap for ETH, buy NFT, deposit NFT on Aztec, all in one **unified** user flow. - **No Double-Spend** : Two-phase commit logic (locking on Aztec, verifying bridging success) ensures no duplication or unauthorized asset usage. - **Flexible & Composable** : Fillers handle the bridging, swapping, marketplace interactions, etc., without the user needing direct accounts on Arbitrum. - **Filler Incentives** : Dutch Auction + Settlement Fee ensures it’s always profitable for some filler to perform the job. * * * ## Grant Milestones & Roadmap ### Phase 1: Research & Design (April 1-21, 2025) - Initial Research & Architecture Design (Week 1-2) - Complete system architecture documentation - Define protocol interfaces and state transition logic - Security model formalization and threat analysis - Deliverable: Comprehensive technical specification document - Protocol Design & Smart Contract Planning (Week 3) - Finalize cross-chain messaging protocols - Design token vault contracts for both Aztec and target L2 - Espresso integration specification - Deliverable: Smart contract specifications and flow diagrams ### Phase 2: Development (April 22 - June 4, 2025) - Core Infrastructure Development (Week 4-6) - Develop Noir contracts for Aztec side - Implement vault contracts on target L2 - Implement private relayer infrastructure - Deliverable: Working contract codebase with test coverage - Filler Network & Dutch Auction Implementation (Week 7-8) - Develop filler/relayer node software - Implement Dutch auction mechanism for filler fees - Build settlement fee distribution system - Deliverable: Functioning filler network with economic incentives - Cross-Chain Verification System (Week 9-10) - Implement Espresso BFT consensus verification - Develop ZK proof generation for cross-chain state verification - Build cancellation and timeout handling mechanisms - Deliverable: End-to-end verification system with proper security guarantees ### Phase 3: Testing & Integration (June 5-30, 2025) - Integration & UI Development (Week 11-12) - Develop user interface for creating and monitoring cross-chain intents - Integrate with Aztec testnet and target L2 testnet - Implement gas sponsorship mechanisms - Deliverable: Working cross-chain application with UI - Testing & Optimization (Week 13) - Comprehensive testing across multiple scenarios - Security audit and performance optimization - Bug fixes and UX improvements - Deliverable: Audit report and test results documentation ### Post-MVP Roadmap (July 2025 onwards) - Expanded L2 Support (Q3 2025) - Extend bridge functionality to additional optimistic and ZK rollups - Implement specialized adapters for each L2’s unique characteristics - Deliverable: Multi-L2 support for the bridge - Enhanced Privacy Features (Q4 2025) - Develop advanced mixer functionality for improved privacy - Implement private transaction bundling for L2 operations Deliverable: Enhanced privacy guarantees for cross-chain operations 1. Mainnet Launch Preparation (Q1 2026) Final security audits and optimizations Filler incentive program launch Community education and documentation Deliverable: Production-ready system for mainnet deployment ## Grant Amount Requested $45,000 USD ## Grant Budget Rationale The requested grant amount of $45,000 is strategically allocated to ensure the successful development of our cross-chain intent bridge through the testnet MVP phase: - Development Resources ($25,000) - Security Audit ($10,000) - Research & Design ($5,000) - Infrastructure & Testing ($3,000) - UI/UX Development ($2,000) This budget represents a careful balance between technical development, security assurance, and user experience design. We’ve prioritized allocating significant resources to the core development challenges and security auditing, recognizing that a bridge handling user assets requires exceptional attention to security. The budget allows us to deliver a functional, secure testnet MVP within the specified timeframe while establishing the foundation for future expansion. Our team’s extensive expertise in zero-knowledge cryptography and cross-chain systems enables us to efficiently utilize these resources to build a solution that addresses the unique challenges of privacy-preserving cross-chain operations. Additionally, we’ll leverage open-source components and community collaboration to maximize the project’s impact beyond what this funding alone would typically support.