Leveraging MPC through dynamic TSS to Preserve Aztec's Privacy Guarantees for Universal Asset Interoperability

[muthiman]

Title

Leveraging MPC through dynamic TSS to Preserve Aztec’s Privacy Guarantees for Universal Asset Interoperability

.

.

Contact Details

Email: Justin@int3face.io
Telegram: @Ox_Rugged
Signal: @muthiman.22

.

.

Public Links:

Website: https://int3face.zone/
Bridge: INT3FACE
Github: BitFrost · GitHub
Docs: Bridge | Int3face Docs

.

.

Summary

This proposal introduces a confidential bridge between Aztec’s zero-knowledge environment and Arbitrum through Bitfrost’s existing cross-chain infrastructure. The integration maintains Aztecs privacy guarantees through a combination of private and public functions, partial notes, and selectively encrypted information that is only decrypted by the Bitfrost validators on the int3face chain.

This privacy-preserving design extends Bitfrost’s existing architecture by adding threshold encryption to the established threshold signature scheme. By leveraging Bitfrost’s dynamic validator infrastructure, the system can now process encrypted transaction data while maintaining security guarantees. The implementation utilises ephemeral data encryption for Aztec transactions, allowing the same validator components that currently secure UTXO-to-Cosmos transfers to handle private payloads without architectural restructuring. Bitfrost’s existing Cosmos SDK chain serves as the coordination layer for both encrypted message passing and signature aggregation, creating a unified framework for both transparent and confidential cross-chain transfers.

This approach enables Aztec users to maintain complete privacy during cross-chain operations by securing ephemeral transaction data that would otherwise be exposed at blockchain boundaries. When bridging from Aztec, sensitive information like destination addresses and amounts remain encrypted until they reach the coordination layer, preventing data leakage to the Aztec chain. Similarly, for inbound transfers to Aztec, the one-time stealth addressing prevents any public correlation between source and destination, preserving Aztec’s privacy guarantees even when funds originate from transparent chains. The ephemeral encryption layer ensures that metadata that might leak during cross-chain transfers remains shielded while in transit through Bitfrost, allowing users to navigate between ecosystems without revealing relationships between their identities across blockchains.

Our proposed implementation additionally unlocks significant liquidity for privacy-preserving DeFi applications through UTXO chain access and Wormhole compatibility. Planned Inherited Native Liquidity mechanisms will further enhance the system’s capabilities, creating new possibilities for confidential cross-chain operations while maintaining Bitfrost’s security guarantees.

.

.

Start and End Date

Start: 1st April 2025

End: 15th June 2025

Budget: $49,000

Breakdown:

Milestone	Start	End	Week	Budget
Arbitrum contract	April 1	April 15	1-2	$8,000
Aztec contract	April 15	May 1	3-4	$9,500
Client implementation	May 1	May 15	5-6	$11,000
Encryption for validators	May 15	June 1	6-8	$8,500
Basic UI	May 15	June 1	9-10	$4,000
Testing & buffer	June 1	June 15	11-12	$8,000
Total				$49,000

.

,

About Us

The Bitfrost team is a team of vastly experienced engineers with educations from MIT, Cambridge and having experience in developing protocols such as ThorChain, Babylon, Nibiru alongside largescale banking services and intelligence software. Many of the team were core contributors of Thorchain, and thus, have extensive knowledge on ECDSA and threshold cryptography. The current tech team is composed of 4 protocol engineers, all who are specialist cryptographers, 1 front-end developer and 1 devops. We are currently doing around $15 million volume a week on Osmosis and Neutron whilst finalising our deployments on Solana and integrations with Wormhole to enable EVM compatible cross-chain transfers.
.

.

Current Bitfrost Architecture and Context

Bitfrost is a high-performance Layer-1 blockchain implementing a novel leaderless, dynamic Threshold Signature Scheme (TSS) for secure cross-chain asset transfers. Built using a modified Cosmos SDK with Proof-of-Authority consensus, Bitfrost establishes trust-minimised bridges between heterogeneous blockchain architectures, particularly focusing on unlocking UTXO-based assets for broader ecosystem utility.

The protocol’s core innovation lies in its dynamic validator set implementation that,unlike previous TSS implementations requiring periodic key rotations during validator changes, Bitfrost’s architecture allows continuous operation with dynamic membership adjustments without interrupting service. The system employs a distributed multi-party computation (MPC) security model where no single validator possesses complete key material, yet a supermajority can collaboratively generate cryptographic signatures for cross-chain transactions.

Bitfrost’s bridge infrastructure comprises specialised validator components—scanners monitoring source chains for relevant transactions, observers validating transaction data, signers participating in the leaderless ECDSA threshold signature scheme, and clients broadcasting validated transactions to destination chains. This architecture currently facilitates $200K-$2M in daily transaction volume between UTXO chains and the Cosmos ecosystem.

.

.

Proposal For Aztec Implementation

Process Flow Logic

Outbound Transaction Logic (Aztec → Arbitrum)

.

Initiation: Alice decides to send 50 USDC from her Aztec account to her Arbitrum account

• Alice connects her Aztec wallet to the Bitfrost UI and selects “Bridge to Arbitrum”
• She enters the amount (50 USDC) and her Arbitrum destination address
• Her wallet client encrypts both her Arbitrum address AND the amount (50 USDC) using the validator committee’s public key
• This encryption ensures no single validator can see either her destination address or the amount

Transaction Creation and Submission:

• The wallet identifies appropriate notes in Alice’s Aztec account that total at least 50 USDC
• It constructs a transaction to the Bitfrost bridging contract on Aztec
• This transaction is a private function call in Noir that:
  • Consumes Alice’s note(s) for exactly 50 USDC
  • Creates a nullifier for each spent note to prevent double-spending
  • Records these nullifiers in Aztec’s state

Partial Note Creation (in the private function):

• The bridge contract creates a partial note containing:
  • Private fields: Alice’s Aztec identity (fully encrypted)
  • Public fields: A commitment to the note, asset type (USDC)
  • Ephemeral fields:
    • Encrypted Arbitrum address
    • Encrypted amount (50 USDC)
    • Destination chain ID
    • Bridge nonce
• The partial note’s commitment (a cryptographic hash of its contents) is recorded in Aztec’s state
• A withdrawal ID is generated based on the note commitment and transaction details

Public Function Execution:

• The private function then calls a public function in the same contract
• This is possible in Aztec’s architecture: private functions can call public ones, not vice versa
• The public function:
  • Decreases the total USDC supply on Aztec by 50
  • Emits a public event containing:
    • The withdrawal ID
    • The destination chain (Arbitrum)
    • The partial note commitment
  • This event deliberately contains minimal information to preserve privacy
  • Notably, it does NOT include Alice’s identity, her destination address, or the amount being transferred

Validator Observation:

• Bitfrost validators monitoring Aztec observe this withdrawal event
• They locate the corresponding partial note using its commitment
• Each validator can access the note’s ephemeral fields containing the encrypted payload
• No validator can independently decrypt either the destination address or amount

Threshold Decryption Process:

• Each validator generates a “decryption share” using their private key share
• This single share reveals nothing about the encrypted data
• These shares are submitted to the Int3face (Bitfrost) Cosmos chain
• Once sufficient shares are collected (e.g., 7 out of 10):
  • The shares are combined through a secure multi-party computation process
  • This reveals both Alice’s Arbitrum address AND the amount (50 USDC) to the protocol, not to individual validators
  • The decryption happens in a distributed way where no single entity sees the complete information

Cross-Chain Message Creation:

• Validators create a cross-chain message containing:
  • The withdrawal ID
  • The destination (Alice’s Arbitrum address, obtained through threshold decryption)
  • The asset type (USDC) and amount (50 USDC, also obtained through threshold decryption)
  • Proof of the Aztec transaction
• This message is recorded on the Int3face Cosmos chain

Threshold Signature Generation:

• Each validator generates a signature share for this message
• These signature shares are submitted to the Int3face chain
• Once sufficient shares are collected (e.g., 7 out of 10):
  • They are combined into a single threshold signature
  • This signature cryptographically proves that enough validators approved the transfer
  • No individual validator can generate a valid signature alone

Arbitrum Execution:

• A designated relayer submits the message and threshold signature to Arbitrum
• The Bitfrost bridge contract on Arbitrum:
  • Verifies the threshold signature using the validator committee’s public key
  • Checks that this withdrawal ID hasn’t been processed before
  • Releases exactly 50 USDC to Alice’s Arbitrum address
  • Records the withdrawal as processed to prevent replay
• Alice now has 50 USDC in her Arbitrum wallet

   sequenceDiagram
    participant UserWallet as Alice's Wallet
    participant AztecBridge as Aztec Bridge Contract
    participant Int3faceChain as Int3face Chain (Validator Network)
    participant ArbitrumBridge as Arbitrum Bridge Contract
    
    UserWallet->>UserWallet: Encrypt destination address & amount<br/>with validator committee public key
    
    UserWallet->>AztecBridge: withdrawToArbitrum(<br/>noteToSpend,<br/>amount: 50 USDC,<br/>arbitrumRecipient,<br/>assetId<br/>)
    
    %% Private Function Execution
    activate AztecBridge
    Note over AztecBridge: PRIVATE FUNCTION EXECUTION
    AztecBridge->>AztecBridge: Consume Alice's note(s)
    AztecBridge->>AztecBridge: Generate nullifier(s)
    
    AztecBridge->>AztecBridge: Create PartialNote {<br/>privateFields: {<br/>  owner: Alice's Aztec address<br/>},<br/>publicFields: {<br/>  assetId: USDC identifier,<br/>  noteCommitment: hash(note contents),<br/>  nullifier: uniqueId,<br/>  isPartial: true<br/>},<br/>ephemeralFields: {<br/>  encryptedPayload: {<br/>    destinationAddress: encrypted(Arbitrum address),<br/>    amount: encrypted(50 USDC)<br/>  },<br/>  destinationChainId: 42161,<br/>  bridgeNonce: unique counter,<br/>  additionalData: optional metadata<br/>}<br/>}
    
    AztecBridge->>AztecBridge: Generate withdrawalId = hash(nullifier, noteCommitment)
    
    %% Public Function Execution
    Note over AztecBridge: PUBLIC FUNCTION EXECUTION
    AztecBridge->>AztecBridge: Call publicHandleWithdrawal(<br/>noteCommitment,<br/>nullifier<br/>)
    
    AztecBridge->>AztecBridge: Decrease USDC supply by 50
    
    AztecBridge-->>Int3faceChain: Emit WithdrawalEvent {<br/>withdrawalId: unique identifier,<br/>noteCommitment: commitment from partial note,<br/>destinationChain: 42161 (Arbitrum),<br/>blockNumber: current block number,<br/>timestamp: current block time<br/>}
    deactivate AztecBridge
    
    %% Validator Processing on Int3face Chain
    activate Int3faceChain
    Note over Int3faceChain: VALIDATOR OPERATIONS ON INT3FACE CHAIN
    
    Int3faceChain->>AztecBridge: Locate partial note using commitment
    
    AztecBridge-->>Int3faceChain: Return partial note's ephemeral fields
    
    Note over Int3faceChain: Validators generate decryption shares<br/>for the encrypted payload
    
    Int3faceChain->>Int3faceChain: Collect t decryption shares (2/3 +1)<br/>from validators running on Int3face
    
    Int3faceChain->>Int3faceChain: Verify each decryption share as part<br/>of Int3face consensus process
    
    Int3faceChain->>Int3faceChain: Combine shares via secure<br/>multi-party computation on Int3face
    
    Note over Int3faceChain: Threshold decryption reveals:<br/>1. Arbitrum address<br/>2. Amount (50 USDC)
    
    Int3faceChain->>Int3faceChain: Create OutboundMessage {<br/>messageType: ASSET_TRANSFER,<br/>destinationChain: ARBITRUM,<br/>withdrawalId: from event,<br/>destinationAddress: decrypted address,<br/>assetId: USDC identifier,<br/>amount: 50 USDC (decrypted),<br/>sourceBlockHeight: from event,<br/>nonce: unique counter,<br/>timestamp: current time<br/>}
    
    Note over Int3faceChain: Validators generate signature shares<br/>as part of Int3face consensus
    
    Int3faceChain->>Int3faceChain: Collect t signature shares (2/3 +1)<br/>from validators on Int3face
    
    Int3faceChain->>Int3faceChain: Combine into threshold signature<br/>as part of Int3face block production
    
    Int3faceChain->>ArbitrumBridge: Relayer submits OutboundMessage + ThresholdSignature
    deactivate Int3faceChain
    
    %% Arbitrum Processing
    activate ArbitrumBridge
    ArbitrumBridge->>ArbitrumBridge: Verify threshold signature<br/>using Int3face validator committee public key
    
    ArbitrumBridge->>ArbitrumBridge: Check withdrawalId not already processed
    
    ArbitrumBridge->>ArbitrumBridge: Map assetId to Arbitrum token
    
    ArbitrumBridge->>ArbitrumBridge: Transfer 50 USDC to destinationAddress
    
    ArbitrumBridge->>ArbitrumBridge: Mark withdrawalId as processed
    
    ArbitrumBridge-->>UserWallet: Funds available in Arbitrum wallet
    deactivate ArbitrumBridge

.

.

Inbound Transaction Logic (Arbitrum → Aztec)

.

Initiation: Bob wants to send 100 USDC from Arbitrum to his Aztec account

• Bob connects his Arbitrum wallet to the Bitfrost UI and selects “Bridge to Aztec”
• Instead of using Bob’s known Aztec address, the interface:
  • Requests Bob’s Aztec public key (not his address)
  • Generates a one-time stealth address derived from his public key and random data
  • This stealth address appears completely unrelated to Bob’s main Aztec identity
  • Only Bob’s wallet can later recognise this stealth address as belonging to him

Transaction Submission:

• Bob approves the Bitfrost bridge contract to transfer 100 USDC from his Arbitrum wallet
• The bridge contract:
  • Transfers 100 USDC from Bob to itself (locking the funds)
  • Records the stealth address, amount, and asset type
  • Generates a unique deposit ID
  • Emits a deposit event containing this information

Validator Observation:

• Bitfrost validators monitoring Arbitrum observe this deposit event
• They wait for sufficient confirmations (typically 5+ blocks on Arbitrum)
• They extract the deposit details:
  • The deposit ID
  • The asset type (USDC) and amount (100)
  • The stealth address for the recipient on Aztec
• No validator can determine that this stealth address belongs to Bob

Cross-Chain Message Creation:

• Validators create a cross-chain message containing:
  • The deposit ID
  • The asset type and amount
  • The stealth address
  • Proof of the Arbitrum deposit (Merkle proof or transaction receipt)
• This message is recorded on the Int3face Cosmos chain

Threshold Signature Generation:

• Validators generate and combine signature shares as in the outbound flow
• The resulting threshold signature authorises the deposit on Aztec
• This signature proves that enough validators have verified the Arbitrum deposit

Aztec Bridge Contract Processing:

• A designated relayer submits the message and threshold signature to Aztec
• The Bitfrost bridge contract on Aztec:
  • Verifies the threshold signature
  • Checks that this deposit ID hasn’t been processed before
  • Maps the Arbitrum USDC to the corresponding Aztec asset ID
  • Creates a partial note with:
    • The stealth address as the recipient
    • The asset type (USDC)
    • Initially, the value field is left empty/undefined
  • Records a commitment to this note in Aztec’s state
  • Increases the total USDC supply on Aztec by 100
  • Emits an event containing:
    • The note commitment
    • The asset ID
    • The amount (100 USDC)
    • The deposit ID

Partial Note Completion:

• Bob’s Aztec wallet regularly scans the blockchain for new notes
• For each new partial note, it attempts to determine if the note was created for any of Bob’s stealth addresses
• It does this by:
  • Using Bob’s private key to derive a set of viewing keys
  • Checking if any of these keys can “recognise” the stealth address
  • This process happens entirely on Bob’s device
    *It reads the amount (100 USDC) from the corresponding event
  • It derives the specific viewing key for this stealth address
  • It completes the partial note by adding the encrypted amount value
  • This uses homomorphic encryption to combine:
    • The empty value field (encrypted zero)
    • The amount (encrypted 100 USDC)
  • The result is a fully formed note containing 100 USDC

Fund Availability:

The completed note appears in Bob’s Aztec wallet balance

• Bob can now spend these funds like any other Aztec assets
• No outside observer can connect this deposit to Bob’s Aztec identity
• Even the validators don’t know which Aztec user received the funds

.

.

   sequenceDiagram
    participant AztecWallet as Bob's Aztec Wallet
    participant ArbitrumWallet as Bob's Arbitrum Wallet
    participant ArbitrumBridge as Arbitrum Bridge Contract
    participant Int3faceChain as Int3face Chain (Validator Network)
    participant AztecBridge as Aztec Bridge Contract
    
    %% Stealth Address Generation (in Aztec Wallet)
    AztecWallet->>AztecWallet: Generate StealthAddressComponents {<br/>userPublicKey: Bob's Aztec public key,<br/>randomValue: secure random scalar r,<br/>ephemeralPoint: r·G (G is generator point),<br/>sharedSecret: hash(r·userPublicKey),<br/>stealthAddress: userPublicKey + sharedSecret·G,<br/>viewTag: one-byte identifier<br/>}
    
    Note over AztecWallet: Stealth address cannot be linked<br/>to Bob's main Aztec identity
    
    %% Transfer stealth address to Arbitrum wallet (could be manual copy/paste)
    AztecWallet-->>ArbitrumWallet: Share generated stealth address
    
    %% Arbitrum Deposit
    ArbitrumWallet->>ArbitrumBridge: depositToAztec(<br/>token: USDC contract address,<br/>amount: 100 USDC,<br/>stealthAddress: generated stealth address<br/>)
    
    activate ArbitrumBridge
    ArbitrumBridge->>ArbitrumBridge: Transfer 100 USDC from Bob to bridge vault
    
    ArbitrumBridge->>ArbitrumBridge: Generate depositId = hash(<br/>token,<br/>amount,<br/>stealthAddress,<br/>sender,<br/>blockNumber,<br/>nonce++<br/>)
    
    ArbitrumBridge->>ArbitrumBridge: Store Deposit {<br/>token: USDC address,<br/>amount: 100 USDC, // Amount fully visible on Arbitrum<br/>stealthAddress: one-time stealth address,<br/>depositor: Bob's Arbitrum address,<br/>timestamp: block timestamp,<br/>status: PENDING<br/>}
    
    ArbitrumBridge-->>Int3faceChain: Emit DepositEvent {<br/>depositId: unique identifier,<br/>token: USDC address,<br/>amount: 100 USDC, // Amount fully visible in event<br/>stealthAddress: one-time address<br/>}
    deactivate ArbitrumBridge
    
    %% Int3face Chain Processing
    activate Int3faceChain
    Note over Int3faceChain: VALIDATOR OPERATIONS ON INT3FACE CHAIN
    
    Int3faceChain->>Int3faceChain: Validators verify sufficient confirmations<br/>(5+ blocks) on Arbitrum
    
    Int3faceChain->>Int3faceChain: Create InboundMessage {<br/>messageType: ASSET_TRANSFER,<br/>sourceChain: ARBITRUM,<br/>destinationChain: AZTEC,<br/>depositId: from event,<br/>tokenAddress: USDC address,<br/>amount: 100 USDC, // Amount fully visible in message<br/>stealthAddress: from event,<br/>sourceBlockHeight: block number,<br/>nonce: unique counter,<br/>timestamp: current time<br/>}
    
    Note over Int3faceChain: Validators generate signature shares<br/>as part of Int3face consensus
    
    Int3faceChain->>Int3faceChain: Collect t signature shares (2/3 +1)<br/>from validators on Int3face
    
    Int3faceChain->>Int3faceChain: Combine into threshold signature<br/>as part of Int3face block production
    
    Int3faceChain->>AztecBridge: Relayer submits InboundMessage + ThresholdSignature
    deactivate Int3faceChain
    
    %% Aztec Processing
    activate AztecBridge
    AztecBridge->>AztecBridge: Verify threshold signature<br/>using Int3face validator committee public key
    
    AztecBridge->>AztecBridge: Check depositId not already processed
    
    AztecBridge->>AztecBridge: Map Arbitrum token to Aztec assetId
    
    Note over AztecBridge: PUBLIC FUNCTION EXECUTION
    
    AztecBridge->>AztecBridge: Create empty partial note for stealthAddress {<br/>privateFields: {<br/>  owner: stealthAddress<br/>},<br/>publicFields: {<br/>  assetId: USDC identifier,<br/>  noteCommitment: hash(note contents),<br/>  isPartial: true<br/>},<br/>ephemeralFields: {<br/>  depositId: from message<br/>}<br/>}
    
    AztecBridge->>AztecBridge: Increase USDC supply by 100
    
    AztecBridge->>AztecBridge: Mark depositId as processed
    
    AztecBridge-->>AztecWallet: Emit PartialNoteCreatedEvent {<br/>noteCommitment: commitment to partial note,<br/>assetId: USDC identifier on Aztec,<br/>amount: 100 USDC, // Amount included in event<br/>depositId: from message,<br/>timestamp: current block time<br/>}
    deactivate AztecBridge
    
    %% Wallet Note Completion
    activate AztecWallet
    Note over AztecWallet: Aztec wallet regularly scans blockchain for new notes
    
    AztecWallet->>AztecWallet: For each partial note, derive potential viewing keys<br/>from Bob's private key
    
    AztecWallet->>AztecWallet: Check if any viewing key matches the<br/>note's stealth address
    
    Note over AztecWallet: Match found! This note belongs to Bob
    
    AztecWallet->>AztecWallet: Create NoteCompletionData {<br/>noteCommitment: from event,<br/>assetId: USDC identifier,<br/>amount: 100 USDC from event,<br/>stealthAddress: matched address,<br/>viewingKey: derived from private key,<br/>encryptedValue: homomorphically encrypted amount<br/>}
    
    AztecWallet->>AztecWallet: Complete partial note using homomorphic encryption:<br/>encryptedValue = encrypt(0) + encrypt(100 USDC)
    
    Note over AztecWallet: Funds now available in Bob's private balance<br/>No on-chain connection to Bob's Aztec identity
    deactivate AztecWallet

.

.

Key Privacy-Preserving Elements

Aztec to Arbitrum:

• The amount and destination address remains private throughout the Aztec side of the process
  • Public knowledge of someone looking at the Aztec public state is “someone has sent something to another chain”
• Alice’s Aztec identity is never linked to her Arbitrum address on-chain
• Both the destination address AND amount are protected by threshold encryption
• No single validator can see either piece of sensitive information
• The Int3face chain serves as a secure coordination layer for validators

Arbitrum to Aztec:

• Bobs real address is not revealed to anyone on Arbitrum
  • Stealth addresses on Aztec prevents linking Bob’s Arbitrum activity to his Aztec identity
  • Arbitrum records will state that “Bob is sending 100USDC to someone on Aztec”
  • Aztec public records will state that “someone has received an unknown sum of an asset from another chain”.
• Each deposit uses a different stealth address, preventing correlation of multiple deposits
• The note completion process happens privately on Bob’s device
• The transaction appears on Aztec as an ordinary private note with no connection to Arbitrum

.

.

Future Developments

Inherited Native Liquidity (INL)

Inherited native liquidity is a novel method of accessing native liquidity without additional liquidity pools on each chain.

.

Intent-based private bridging leveraging Aztec as an intermediary to create a privacy layer.

This idea involves multi-hop bridging where a user may select a private bridge where Aztec is neither the source or destination chain. Here the process flow:

1. Source chain to Int3facechain
2. Int3facechain to Aztec (privacy and obfuscation on a public level occurs)
3. Aztec to Int3facechain - Further obfuscation on a public level
4. Int3facechain to Destination chain

.

.

POC Scope (MVP by 15th June 2025)

Core POC Components

1. Basic Aztec Bridge Contract (Noir)

• Simplified private withdrawal function with:
  • Basic note consumption and nullifier generation
  • Ephemeral fields for encrypted destination address and amount
  • Partial note creation for cross-chain messaging
• Public function with:
  • Event emission for validator observation
  • Simple supply management
• Focus on functionality over optimisation

2. Simple Arbitrum Bridge Contract (Solidity)

• Basic token vault for USDC
• This adds some functionality to existing bridging contracts for EVM (Specific data fields for populating memo and partial note)

3. Minimal Validator Infrastructure

• Addition of threshold encryption to the validator protocol
  • 1 of 1 threshold encryption for POC
• Simple blockchain monitoring for both chains - Light client implementation
• The biggest addition to our repo would be adding scanners (clients of aztec to arbitrum)

4. Basic User Interface

• Connection to both Aztec and Arbitrum wallets

POC Technical Trade-offs

• Limited Privacy Features: Focus on essential privacy mechanisms only
• Simplified Cryptography: Use established libraries rather than custom implementations
• Controlled Validator Set: 1 validator proof of concept for threshold encryption
• Single Asset Support: USDC only for initial demonstration
• Limited Gas Sponsorship: Basic implementation without complex controls - Basic protocol sponsorship

Technical Implementation Details

1. POC Gas Sponsorship (Minimal Implementation)

• Simple app-sponsored fee sponsorship built into the bridging contract
• Basic rate limiting to prevent abuse - Rate limiting will be improved to meet our current standards in full implementation

2. POC Edge Case Handling

• Simple timeout handling for stalled transactions
• Basic retry mechanism for validator operations

3. POC UX Considerations

• Direct connection to both Aztec and EVM wallets
• Simple status updates during transaction processing

.

.

Future Development to Full Design

Phase 1: Security & Privacy Enhancement (Post-POC)

1. Full Threshold Implementation

• Upgrade to enable full set of validators to participate in threshold encryption along with signature schemes
• Create dynamic memo and validation processes

2. Enhanced Privacy Mechanisms

• Complete implementation of encrypted address and amount in ephemeral fields
• Advanced stealth address protocol with dual-key implementation
• Add transaction batching for improved anonymity sets
• Implement timing decorrelation to prevent transaction linking

Phase 2: Feature Completion & Reliability

1. Complete Contract Implementation

• Comprehensive error handling and recovery mechanisms
• Gas optimisation for all operations
• Support for multiple asset types

2. Advanced Note Operations

Fully optimised partial note handling

• Complete homomorphic operations implementation
• Efficient note scanning and completion
• Comprehensive nullifier management

3. Robust Cross-Chain Messaging

• Reliable message delivery with retries - this is currently available on Bitfrost but would require implementation to this part of the bridge
• Complete verification of cross-chain state
• Atomic execution guarantees
• Handling of chain reorganisations through a decaying curve of probability for re-orgs over time.

Phase 3: UX & Advanced Features

1. Complete Gas Sponsorship

• Full gas sponsorship on Aztec through gas faucet funding from users base asset rather than native gas asset.
• Integration with account abstraction on Arbitrum (EIP-4337)
• Efficient fee management system - enabling a potential reduction in partial notes

.

Roadmap to Full Implementation

The full implementation will progressively build on the POC to include all specified components of our design:

1. Complete Privacy Preservation

• Full threshold encryption system for all sensitive data
• Complete stealth address protocol with optimal privacy
• Advanced transaction batching and timing management
• Comprehensive privacy guarantees on both chains

2. Robust Cross-Chain Architecture

• Complete Int3face chain integration with proper validator network
• Full threshold operations in secure environment
• Comprehensive cross-chain verification
• Reliable message delivery with strong guarantees

3. Production-Ready System

• Complete gas sponsorship on both chains
• Comprehensive edge case handling
• Optimised performance and gas efficiency

.

[rahul-kothari]

@muthiman

Alice decides to send 50 USDC from her Aztec account to her Arbitrum account

…
This encryption ensures no single validator can see either her destination address or the amount

Since funds are going to Arbitrum, why does hiding the destination address matter?

@muthiman

Partial Note Creation (in the private function):

this doesn’t need a partial note. In fact it doesn’t need a note at all.
User already knows all the data so creating a partial note just for bridge information is a waste of DA and gas.

User approves bridge to take 50 USD from its address (authwit)
User calls bridge contract’s private function which transfers their private 50 usd to public to themselves and then proceeds to do your public function execution.
I.E your partial note creation does nothing.
Since it is a public functio, every validator can just see it all the details- this doesn’t leak privacy because the details are going to be public knowledge anyway (“like someone wants to deposit 50 usd to arbtirum and they have added 50 usd to our bridge contract” )

Again since arbitrum is public, the threshold encryption work is not needed - all of this data is gonna be public anyway.

---

On arbitrum → aztec
Using stealth address is a good idea. It may not be always needed especialyl because aztec is private already so knowing your address doesn’t give me any info.
Though in some cases very nice -
we have been playing with an elegant way of doing stealth address that I’d point you to - What is msg_sender when calling private->public? (Plus a big foray into Stealth Addresses)

the problem is aztec doesn’t have a generic public key - instead like zcash we have several key pairs and account abstraction so simply doing r*G would not help here.

is the threshold signature more like gathering attestations? And once you have attestations your bridge is ok?