Aztec Ghost: Run Transactions Anonymously on Optimistic L2s using Privacy Relayers

Aztec
,
1

Aztec Ghost: Run Transactions Anonymously on Optimistic L2s using Privacy Relayers

Contact Details

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:

    1. Phase 1: Lock assets on the source chain.
    2. Phase 2: Mint/unlock or utilize those assets on the destination chain, but only upon cryptographic proof that the source lock is in place.

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:

    • HotShot BFT Consensus Mechanism
      Espresso uses a Byzantine Fault Tolerant consensus protocol called HotShot (an evolution of HotStuff) where a set of validators with staked collateral vote on blocks:

      • A leader proposes a block containing transaction batches
      • Validators verify and sign (vote for) the proposed block
      • Once signatures from validators representing ≥ 2/3 of the total stake are collected, a Quorum Certificate (QC) is formed
      • A block with a valid QC is considered finalized and cannot be reverted without breaking the BFT security threshold (> 1/3 malicious stake)

    • Step-by-Step Finalization Process

      1. Optimistic L2 sequencer submits transaction batch to Espresso
      2. Espresso leader includes the batch in a block proposal
      3. Validators verify block data is available and properly structured
      4. Validators sign the block header using BLS signatures
      5. Signatures are aggregated into a compact QC
      6. The block is declared final once the QC threshold is met
      7. The L2 chain can then detect and trust this finalized block

    • Mathematical Verification with BLS Signatures
      Espresso employs Boneh-Lynn-Shacham (BLS) signature scheme for cryptographic verification of finalized blocks, providing both security and efficiency:

      Mathematical Foundation:

      • BLS signatures operate on pairing-friendly elliptic curves with groups G₁, G₂, and Gₜ
      • Each validator i possesses a private key skᵢ ∈ Zₚ and a public key pkᵢ = g₂^skᵢ ∈ G₂
      • When signing a block header h, a validator computes σᵢ = H(h)^skᵢ ∈ G₁ where H maps the header to a point in G₁

      Signature Aggregation:

      • The core cryptographic innovation is the ability to combine multiple signatures:
        • Aggregate signature: σₐₒₒ = ∏ᵢ∈signers σᵢ ∈ G₁
        • Aggregate public key: pkₐₒₒ = ∑ᵢ∈signers pkᵢ ∈ G₂
      • Verification uses a single bilinear pairing check: e(σₐₒₒ, g₂) = e(H(h), pkₐₒₒ)
      • If this equation holds, it proves that validators holding ≥2/3 of stake signed the block

      Verification Process in Cross-Chain Context:

      • The filler obtains the finalized block header h and its aggregate signature σₐₒₒ
      • The verifier (L2 contract) checks:
        1. The signers’ combined stake exceeds the 2/3 threshold
        2. The pairing equation e(σₐₒₒ, g₂) = e(H(h), pkₐₒₒ) is satisfied
        3. The transaction Merkle proof validates against the block’s data root
      • This single pairing operation reduces verification complexity from O(n) to O(1)
      • The dramatic efficiency gains make it feasible to verify Espresso finality on resource-constrained L2s
      • Noir ZK proofs further compact this verification, allowing succinct proof of Espresso finalization

    • Proof Presentation to Optimistic L2s
      Fillers submit the Noir-generated ZK proof to the L2 vault or intent contract, which can efficiently verify the cryptographic validity without understanding the complex underlying mechanisms of Espresso’s consensus. This provides a compact, privacy-preserving way to prove Espresso finality to any blockchain 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:

    • Transaction Creation: Users create transactions with private inputs and generate ZK proofs to validate their correctness
    • Block Production: Sequencers collect transactions into blocks, construct block headers with Merkle roots
    • Validation: Validators check and attest to block validity through signatures
    • ZK Proof Generation: Provers generate ZK rollup proofs for entire blocks without revealing private data
    • L1 Settlement: The block proofs and archive roots are submitted to Ethereum where the Aztec rollup contract verifies them

  2. Finality Verification by Fillers
    Fillers must verify several cryptographic elements to prove an Aztec transaction is final:

    • Transaction Inclusion Proof: Verify the transaction exists in a specific Aztec block
    • Block Canonicity Proof: Prove the block is part of the canonical Aztec chain using archive sibling paths
    • L1 Finalization Proof: Confirm the block has been proven on Ethereum through the rollup contract
    • Nullifier and Note Verification: For private transactions, verify nullifiers and note commitments are properly included

  3. Implementation in Cross-Chain Intents
    When a user creates an order on Aztec, fillers must:

    • Obtain the transaction receipt and block information
    • Verify transaction inclusion using Merkle proofs
    • Check that the block is in the canonical chain
    • Confirm L1 finalization by querying the Aztec rollup contract on Ethereum
    • Generate a succinct zero-knowledge proof using Noir that combines all these verification steps into a single cryptographic attestation

  4. Presenting Proofs to Optimistic L2s
    The filler provides this Noir-generated ZK proof to the L2 vault or intent contract, which:

    • Verifies the proof’s cryptographic validity without needing to understand the underlying Aztec finality mechanisms
    • Efficiently confirms that the transaction is final according to Aztec’s consensus through this single succinct proof
    • Authorizes the execution of cross-chain instructions only after verification succeeds

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:

    • pending – The user has posted the order (assets locked), awaiting a filler.
    • cancelled – The user revoked/canceled before fill completion, or it timed out.
    • success – The fill was proven successful on the destination chain, so the job finalizes.

  • On the destination chain, we typically see only two terminal states:

    • cancelled – The origin order was canceled, so no action is valid on the destination.
    • success – The bridging or job was fully executed in one shot, or not at all.

2.1 Actors

  • User

    • Posts an order (intent) on one chain.
    • Assets are locked in a Vault/Intent Contract on the source chain.
    • Can cancel the job if it remains unfilled (see Cancellation).

  • Filler (Relayer)

    • Monitors for new cross-chain orders.
    • Pays gas and bridging costs.
    • Proves to the source contract that the job is done by submitting a zk proof + Espresso finality data.
    • Receives the filler fee upon success.

  • Aztec Intent Contract (Noir-based) / Opt L2 Intent Contract (EVM-based)

    • Receives bridging requests, locks user funds, and only unlocks upon valid finalization.
    • Tracks order states (pending, cancelled, success).

  • Espresso

    • Confirms L2 transactions with BFT-based near-instant finality, preventing reorgs.

  • Vault Contracts (Underlying Deposit/Withdraw)

    • Deposit: Locks a native asset under a random, collision-resistant ID.
    • Withdraw: Releases locked funds only with a valid proof of bridging success or a cancellation/timeout event.
    • Exist on both Aztec and the L2(s).

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

    • The user locks assets in the Aztec Intent Contract with a randomly generated job ID.
    • The job is marked pending.

  2. Fee Payment

    • The user sets a Filler Fee (via Dutch auction) in Aztec tokens or bridging assets.
    • A Settlement Fee also exists, rewarding whoever finalizes the proof (the filler or a third party).

  3. Filler Observes & Evaluates

    • The filler checks if the filler fee at current auction price exceeds bridging costs.

  4. Filler Executes Job on L2

    • The filler obtains/validates a ZK proof that Aztec has locked the user’s assets under the job ID.
    • The filler pays gas on the L2 to execute the user’s instructions (e.g. bridging, swapping, NFT purchase).
    • If it succeeds, the L2 emits a “job succeeded” event.

  5. Listening to Espresso Finalization

    • Espresso finalizes the L2 block containing the “job succeeded” event.
    • This prevents reorgs.

  6. Settling Transaction Result

    • Filler or Another Entity: The original filler has a short exclusive window to settle. If they fail, any other entity can finalize instead, collecting the Settlement Fee.
    • They call AztecIntentContract.finalizeJob(jobID, proof), referencing Espresso finality + the L2 success event.
    • Upon validation, the job is marked success, and the filler fee is awarded.

2.4 Opt L2 → Aztec Flow

  1. User Posts Intent on L2

    • The user locks assets in the L2 Intent Contract with a random job ID.
    • The job is marked pending.

  2. Fee Payment

    • The user sets a Filler Fee (Dutch auction) in L2 tokens.
    • A Settlement Fee is allocated for finalizing the proof on L2.

  3. Espresso Finalization

    • The L2 contract emits a “job succeeded” event.
    • Espresso finalizes the L2 block containing the “job succeeded” event.

  4. Filler Monitors

    • Fillers watches the confirmed transactions and emitted log events on Espresso.
    • If bridging to Aztec is profitable, they proceed.

  5. Filler Executes on Aztec

    • The filler obtains a ZK proof that the user’s assets are locked in espresso under the job ID.
    • The filler pays gas on Aztec to perform the bridging instructions.
    • If successful, Aztec emits a “job succeeded” event.

  6. Listening to Espresso Finalization

    • Espresso finalizes the Aztec transaction, ensuring near-instant finality.

  7. Settling Transaction Result

    • Filler or Another Entity: If the filler doesn’t finalize in its exclusive window, a third party can step in.
    • They call L2IntentContract.finalizeJob(jobID, proof), referencing Espresso finality + the Aztec success event.
    • The L2 contract marks the job success and releases the filler fee.

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:

    Option 1: Source-Initiated Propagation

    • The user cancels on the source chain, which marks the job as cancelled.
    • A filler observes this cancellation event and propagates it to the destination chain.
    • The filler submits a proof of the source chain cancellation to the destination contract.
    • The filler earns a small fee for this service, making it economically viable.

    Option 2: Direct Destination Cancellation

    • The user directly interacts with the destination chain contract.
    • The user provides a zero-knowledge proof that they are the legitimate owner of the job.
    • The proof verifies that the job exists, has not been processed yet, and belongs to the user.
    • Once verified, the destination contract marks the job as cancelled, preventing any future fulfillment.
    • This approach is useful when the user needs immediate cancellation and doesn’t want to wait for a filler.

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:

    “Swap some amount of my Aztec tokens for ETH on Arbitrum, purchase a specific NFT, and bring that NFT back onto Aztec, preserving privacy.”

  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)

    • Senior Zero Knowledge Engineering: Development of Noir contracts, ZK proofs for cross-chain verification, and privacy-preserving mechanisms
    • Blockchain Engineering: Implementation of L2 smart contracts, Espresso integration, and filler network development

  • Security Audit ($10,000)

    • Professional third-party security audit to identify and remediate potential vulnerabilities
    • Focus on cross-chain verification logic, asset locking mechanisms, and privacy guarantees
    • Critical for ensuring the bridge’s integrity and user fund safety

  • Research & Design ($5,000)

    • Cryptographic research and formal security model verification
    • Protocol design, state transition modeling, and comprehensive documentation

  • Infrastructure & Testing ($3,000)

    • Testnet deployment across multiple networks (Aztec, target L2, and Espresso)
    • Specialized testing frameworks for cross-chain operations

  • UI/UX Development ($2,000)

    • User interface development for the cross-chain application

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.

2 Likes