Confidential Cross-Chain Bridging: Enabling Private and Trust-Minimized Interoperability for Aztec

[Substance]

Confidential Cross-Chain Bridging: Enabling Private and Trust-Minimized Interoperability for Aztec

Contact Details

Mail: info@substancelabs.xyz

Telegram: @ludobianco

Summary

We propose building a privacy-preserving, trust-minimized cross-chain intent execution framework that enables secure transactions between Aztec and Arbitrum. The MVP will feature a front-end demonstrating a cross-chain asset transfer between Aztec and Arbitrum, showcasing seamless interoperability. While Arbitrum is the testnet of choice for this implementation, the solution is designed to be fully compatible with any L2 that settles on Ethereum, enabling broader adoption beyond the initial scope.
This solution allows users to transfer assets and execute cross-chain interactions while maintaining privacy and trust-minimized execution.

The framework is based on ERC-7683 intents, leveraging Aztec’s privacy features and a Forwarder contract on Ethereum to ensure verifiable cross-chain settlement. It follows a solver-based model, where solvers fulfill intents and execute transactions across chains.

For private intents, users submit intents using secret hashes to conceal the recipient address:

• EVM to Aztec: Solvers lock funds on Aztec, and users claim them privately using a secret, triggering settlement verification through storage proofs.

• Aztec to EVM: Solvers advance funds on the destination L2, and the Forwarder contract verifies settlement before solvers can claim reimbursement on Aztec.

For public intents, solvers execute intent orders by transferring funds on the destination chain:

• EVM to Aztec: Solvers verify fulfillment using storage proofs against Ethereum block headers, ensuring they are reimbursed only after confirming execution.

• Aztec to EVM: Solvers record a commitment in the ERC-7683 contract on the L2, and the Forwarder contract validates this against the L2 state root before allowing reimbursement on Aztec.

Looking ahead, the framework offers a clear path for future enhancements, including Merkle tree batching to reduce gas costs, RIP-7755 integration for trust-minimized execution, partial notes for simplified claiming, and Hashi integration to expand compatibility with non-Ethereum-settled chains. These advancements will further decentralize the solver market, enhance efficiency, and broaden interoperability beyond Ethereum-centric rollups.

This project aligns with Aztec’s vision for confidential, gas-efficient, and scalable cross-chain interoperability, offering a robust approach to intent-based transactions.

Start and End Date

We envision starting work on the solution in April and reaching a functional version on the Aztec Testnet by June.

About You

We are the team behind Hashi, a cross-chain security framework designed to bring additive security to blockchain interoperability.
Our work focuses on enhancing cross-chain messaging and verification by aggregating multiple verification mechanisms, reducing single points of failure, and eliminating vendor lock-in.

In addition to its bridge security model, we have evolved Hashi into the Hashi State Sharing Network (SSN)—a cross-chain state verification layer that enables secure and verifiable access to external blockchain states. By relaying block headers across chains, Hashi SSN provides developers with trust-minimized access to cross-chain data, facilitating efficient interoperability.

Our team has extensive experience in cross-chain infrastructure, zero-knowledge technologies, and interoperability. We have successfully deployed Hashi across eight major blockchain ecosystems, integrating with 20+ cross-chain oracles, including GMP bridges (such as Wormhole, LayerZero, Axelar, and CCIP) and ZK light clients (sp1-helios, DendrETH, Spectre).

We have received funding and support from key ecosystem players such as GnosisDAO, Oasys Games, Kleros, Arbitrum, and Optimism, securing over $200,000 in grants to expand Hashi’s capabilities. Our work has also been recognized by Uniswap’s independent security assessment, which identified Hashi as a promising framework for cross-chain security.

With a track record of delivering on grants, deep technical expertise, and a strong commitment to secure interoperability, we are well-equipped to build a trust-minimized, private, and secure cross-chain bridge that aligns with Aztec’s vision for confidential interoperability.

Project Details

The Cross-Chain App and Its Purpose in the Aztec Ecosystem

The proposed cross-chain bridge enables confidential and trust-minimized intent execution between Aztec and Arbitrum. The MVP will feature a front-end application demonstrating a seamless cross-chain asset transfer. By leveraging Aztec’s privacy features, ERC-7683 intents, Ethereum storage proofs, and Aztec Portals, users can perform secure, private cross-chain transactions while ensuring solvers can only claim funds after proving execution.
While Arbitrum is the L2 selected for the proof of concept, the architecture is inherently compatible with any L2 that settles on Ethereum, ensuring that future expansions can include Optimism, Base, and other Ethereum L2 ecosystems without significant modifications.

Instead of relying on liquidity pools or centralized relayers, the bridge follows a solver-based execution model:

• Private Intents:

  • EVM to Aztec: Users submit intents using secret hashes to conceal the recipient address. Solvers lock funds on Aztec, and users claim them privately using a secret. This action triggers an L2_aztec-to-L1 message to the Forwarder contract on Ethereum. Since Arbitrum can directly read Ethereum block headers, solvers can verify the settlement using storage proofs and securely claim reimbursement on L2.

  • Aztec to EVM: Solvers advance funds on Arbitrum, record a commitment, and the Forwarder contract verifies settlement against the Arbitrum state root. The Aztec Portals facilitate the L1-to-L2_aztec message, enabling solvers to claim reimbursement.

• Public Intents:

  • EVM to Aztec: Solvers advance funds on Aztec and send an L2_aztec-to-L1 message to the Forwarder contract on Ethereum, which records a commitment. Solvers verify fulfillment using storage proofs against Ethereum block headers before claiming reimbursement on Arbitrum.

  • Aztec to EVM: Solvers transfer funds on Arbitrum, record a commitment in the ERC-7683 contract, and the Forwarder contract verifies this against the Arbitrum state root. An L1-to-L2_aztec message is then sent through Aztec Portals, allowing solvers to claim reimbursement on Aztec.

This model ensures:

• Privacy-preserving execution: Uses secret hashes to keep recipient addresses confidential until execution.

• Accurate settlement validation: Storage proofs and Aztec Portals ensure solvers can only claim funds after successful fulfillment.

• Scalable execution: The future roadmap includes Merkle tree batching to optimize commitment storage and reduce gas costs.

The solution provides a scalable and efficient alternative to traditional cross-chain bridges, eliminating liquidity fragmentation and avoiding centralized intermediaries. By integrating with Aztec Portals, the bridge enhances L1↔L2 (Ethereum↔Aztec) communication, ensuring secure messaging and proof validation. Future iterations may allow direct verification on Aztec, reducing costs and complexity.

How Will the Design Meet Aztec’s Requirements?

The proposed solution aligns with Aztec’s privacy-first approach, enabling private, efficient, and trust-minimized cross-chain execution. It satisfies key requirements, including:

• Bridging to another L2 testnet, initially targeting Arbitrum.

• Supporting both public and private deposits and withdrawals through the ERC-7683-compatible contract, ensuring recipient privacy for private intents via secret hashes.

• Trust-minimized execution by using a solver-based model that verifies fulfillment via Ethereum storage proofs: solvers are only compensated after proving execution, reducing counterparty risks.

• Providing a roadmap for future optimizations, including Merkle tree batching to improve gas efficiency, RIP-7755 integration for decentralization, and Hashi’s state-sharing model to support non-Ethereum-settled chains.

This approach guarantees scalability, security, and composability while maintaining Aztec’s core principles of confidentiality and efficient interoperability.

User Flow and Journey

Private Intents

The private intent mechanism is designed to enable users to perform cross-chain intent actions without disclosing the recipient address on Aztec (or the sender address on Aztec if the intent is initiated from Aztec). To achieve this, a secure and privacy-preserving communication channel between the User and Solver is required.

From Arbitrum to Aztec

• Off-chain, the user generates a cryptographic secret and computes its hash: secretHash = hash(secret)

• The user submits an intent on the ERC-7683 contract on Arbitrum, using secretHash as the recipient address. This ensures that only the holder of the original secret can later claim these funds.

• The solver locks the specified funds into the ERC-7683 contract on Aztec, linking them to secretHash. This ensures that only the user who knows the secret can claim the funds. If the user does not claim the funds within the predefined period, the solver can reclaim them.

• The user submits a private transaction to the ERC-7683 contract on Aztec, revealing the secret. The contract verifies hash(secret) == secretHash. If successful, the user receives the funds. Within the same transaction, the ERC-7683 contract on Aztec sends an L2_aztec-to-L1 message to the Forwarder contract on Ethereum containing a commitment associated with the intent. The Forwarder contract stores this commitment, containing secretHash and the solver’s Ethereum address (solver_L2_address). Since Arbitrum contracts can read Ethereum block headers, this message serves as a verifiable signal that the user has successfully claimed the funds.

• Because on Arbitrum it’s possible to read Ethereum block headers, the solver can verify this recorded commitment on Arbitrum using a storage proof against an Ethereum block header.

From Aztec to Arbitrum

• A user creates an intent in the ERC-7683 contract on Aztec, specifying a destination address on Arbitrum. In the same transaction, the user privately transfers tokens to the ERC-7683 contract. The ERC-7683 contract then stores a commitment containing the destination_L2_address, amount, and nonce. This ensures the solver can later claim the locked funds once the order is settled.

• On Arbitrum, the solver sends the specified amount to the user’s destination address via the ERC-7683 contract. Within the same transaction, the ERC-7683 contract stores a commitment containing: destination_L2_address, amount, nonce and aztec_solver_address. The solver address on Aztec is used for the reimbursement.

• The Forwarder contract on Ethereum verifies that the solver fulfilled the order by reading the commitment from the Arbitrum state root taken from the L2 bridge contract via a storage proof. If the commitment is valid, the Forwarder sends an L1-to-L2_aztec message to Aztec containing: destination_L2_address, amount, nonce, aztec_solver_address.

• Upon receiving the L1-to-L2_aztec message, the ERC-7683 contract on Aztec sends the funds to the solver.

• If Aztec would gain direct access to Ethereum blocks, then this verification could be performed on Aztec rather than on L1, thereby reducing both gas costs and overall complexity.

Public Intents

From Arbitrum to Aztec

• A user creates an intent in the ERC-7683 contract on Arbitrum.

• A solver detects the user’s intent and transfers the specified funds to the user on Aztec via the ERC-7683 contract deployed there.

• In the same transaction, the solver sends an L2_aztec-to-L1 message to the Forwarder contract on Ethereum, signaling that the transfer has been completed on Aztec.

• The Forwarder contract on Ethereum receives the L2_aztec-to-L1 message and stores a commitment of the intent on-chain.

• This commitment proves that the solver has successfully transferred the user’s funds on Aztec.

• Because on Arbitrum it’s possible to read Ethereum block headers, the solver can verify this recorded commitment on Arbitrum using a storage proof against an Ethereum block header.

• After verification, the solver claims reimbursement for completing the user’s transfer.

From Aztec to Arbitrum

• A user creates an intent in the ERC-7683 contract on Aztec, specifying a destination address on Arbitrum.

• A solver detects this intent, transfers the specified funds to the user on Arbitrum and records a commitment in the ERC-7683 contract confirming that the transfer took place.

• Once the Arbitrum state root is finalized on Ethereum (L1), the Forwarder contract verifies—via storage proofs against that Arbitrum state root—that the solver has indeed fulfilled the intent. Specifically, it reads the commitment from the ERC7683 contract storage on Arbitrum and validates it against the Arbitrum state root taken from the L2 bridge contract on L1 using storage proofs.

• After verification, the Forwarder sends an L1-to-L2_aztec message to Aztec, indicating that the transfer was successful.

• When Aztec receives the L1-to-L2_aztec message, the solver can claim their reimbursement, completing the settlement process.

• If Aztec would gain direct access to Ethereum blocks, then this verification could be performed on Aztec rather than on L1, thereby reducing both gas costs and overall complexity.

Grant Milestones and Roadmap

MVP Development (Covered by the Grant, April–June 2025)

Smart Contract Implementation (April 2025, Weeks 1-4)

• Develop and deploy ERC-7683 on Aztec and ERC-7683-compatible contracts on Arbitrum.

• Deploy and test the Forwarder contract on Ethereum.

• Implement storage-proof validation mechanisms for solvers, ensuring correct settlement validation.

Solver Execution & Settlement (May 2025, Weeks 5-6)

• Implement and test the solver execution flow for both public and private intents.

• Ensure proper L2_aztec-to-L1 and L1-to-L2_aztec message processing, including commitment recording on Ethereum.

• Test timeout and reclaim mechanisms for private intents.

• Deploy test contracts to Aztec Testnet and Arbitrum Testnet.

Minimal UI & Solver Onboarding (May 2025, Weeks 7-8)

• Develop a basic interface for users to submit intents, track solver participation, and monitor settlement status.

• Onboard initial solvers, ensuring they are equipped for both public and private intents.

• Conduct internal testing and debugging to ensure security and functionality.

Testnet Deployment & Public Trial (June 2025)

• Fully deploy the MVP to Aztec Testnet and Arbitrum Testnet.

• Launch public testnet trials for users and solvers, collecting feedback to refine the solution.

Future Roadmap (Post-June 2025)

After delivering the MVP, we envision several enhancements and extensions, including:

• Merkle Tree Batching for Gas Optimization: Introduce a Merkle tree to batch L1-to-L2 and L2-to-L1 commitments, allowing only the Merkle tree root to be transmitted at regular intervals. This approach will reduce gas costs and messaging overhead by avoiding individual transactions for each commitment.

• RIP-7755 Integration: Transition to trust-minimized execution by enhancing storage proof-based settlement verification.

• Partial Notes for simple Claiming: Improve user experience by allowing the completion of the claiming phase in one single transaction, so that users do not have to pay for it.

• Hashi Integration for Non-Ethereum-Settled Chains: Expand compatibility for chains that don’t settle on Ethereum, by leveraging Hashi’s state-sharing model.

These advancements will further decentralize the solver market, enhance efficiency, and broaden interoperability beyond Ethereum-centric rollups.

Grant Amount Requested & Budget Rationale

We request $50,000 to develop, deploy, and test an MVP that enables confidential, trust-minimized intent execution between Aztec and Arbitrum testnets. The funding will support:

• Smart contract development, including ERC-7683-compatible contracts, and the Forwarder contract.

• Solver onboarding and infrastructure setup, focusing on execution reliability, including timeout and reclaim features for private intents.

• Storage proof validation mechanisms for settlement enforcement, ensuring solvers can only claim funds after proving execution.

• UI development for public and private intent submission, monitoring solver activity, and intent status tracking.

• Testing and debugging to ensure security and correctness before the testnet deployment.

This budget covers the full lifecycle of the MVP, including front-end development to demonstrate a cross-chain asset transfer between Aztec and Arbitrum. The solution will be ready for testing by June 2025.