Leveraging Account-Based Swaps for Scalable Multi-Asset Flexibility

In the world of decentralized finance (DeFi) and blockchain technology, the ability to transfer assets across different networks is essential for scalability and usability. Traditional methods, such as atomic swaps and smart contract-based asset locks, often face limitations such as reliance on cryptographic curves, counterparty dependency, and chain-specific architectures. These methods introduce challenges in cross-chain interoperability, liquidity, and security, particularly when bridges are involved.

To overcome these obstacles, the concept of account transfer provides a more generalized approach to asset swapping. Instead of transferring individual assets, the entire account—which holds multiple assets such as tokens, DeFi positions, and NFTs—can be transferred across different blockchains in a single transaction. This method enhances cross-chain flexibility, improves liquidity, and reduces the complexity of multi-asset transfers.

By treating the account as a unified object, this approach eliminates the reliance on specific cryptographic standards and supports seamless transfers between different blockchain ecosystems, regardless of their underlying technology. Moreover, it opens up the possibility for a more scalable and efficient solution for cross-chain and multi-asset trading, without the drawbacks associated with atomic swaps and smart contract bridges.

In this document, we explore the architecture, mechanisms, and advantages of account transfer as a generalized solution for cross-domain asset swapping, highlighting how it addresses key challenges in today’s blockchain ecosystem.

Cross-Domain Assets Swapping Problems

As blockchain ecosystems continue to evolve, the ability to transfer assets across different chains has become a critical component for ensuring interoperability and liquidity. However, current approaches to cross-domain asset swapping, such as atomic swaps and smart contract-based solutions, face significant challenges. These methods often struggle with issues like dependency on specific cryptographic standards, limited flexibility in matching counterparties, and security risks associated with cross-chain bridges. Addressing these problems is crucial for enabling a more seamless and secure cross-chain experience.

Smart Contract-Based Asset Lock

• Cross-Chain Dependency: The success of a cross-chain bridge relies on smart contracts to lock assets on one chain and issue wrapped tokens on another. This introduces a dependency on multiple blockchains, each with its own consensus mechanism, finality times, and security risks. If one chain is compromised, the entire asset lock system can be affected.

• Bridge Security Risks: Cross-chain bridges are a central point of failure. We’ve seen several hacks involving bridge systems (e.g., Wormhole), where vulnerabilities in smart contract code or validator setups resulted in substantial asset losses. This raises security concerns for large-scale cross-chain activity.

• Dynamic Matching (Resolved by AMMs/Order Flow Auction): Though Automated Market Makers (AMMs) and order flow auctions can be implemented as smart contracts to improve dynamic matching in asset swaps, they still introduce additional layers of complexity and computational overhead. However, these mechanisms do provide an effective way to match counterparties dynamically in decentralized environments, which atomic swaps struggle to do.

Intents Architecture in Across

Atomic swap(HTLC)

• Cryptographic Curve Compatibility: Atomic swaps rely on Hash Time-Locked Contracts (HTLCs), and they are constrained by the need for both chains to support compatible cryptographic curves (e.g., secp256k1). If the chains use different cryptographic primitives, atomic swaps cannot be executed directly.

• Counterparty Dependence: Atomic swaps require both parties to agree on the swap before it begins, meaning you must find a counterparty who holds the desired asset. This limits liquidity and slows down trading, especially in decentralized settings where participants are not always online at the same time.

• Fixed Terms: The terms of atomic swaps (e.g., the exact amount and timing) need to be agreed upon in advance, reducing the flexibility that more dynamic trading environments, like decentralized exchanges (DEXs), provide.

We Still Need More Generalized Approach

The existing methods for cross-domain asset swapping, such as atomic swaps and smart contract-based asset locks, face limitations that make them less efficient and flexible in today’s multi-chain ecosystem. These challenges have driven the need for a more generalized and scalable approach to asset transfers.

• Breaking Dependency on Cryptographic Curves or Smart-Contracts: Atomic swaps often rely on specific cryptographic algorithms or token standards, which can hinder interoperability between blockchains using different cryptographic primitives. Similarly, smart contract-based asset locks depend on the architecture of the involved blockchains and introduce potential risks with cross-chain bridges. Account transfer overcomes these dependencies by treating the account as a transferable object. This allows assets to move seamlessly across different blockchains, independent of their cryptographic curves or smart contract frameworks.

• Improving Liquidity and Flexibility in Matching: Current methods often require users to pre-agree on exact swap terms or rely on automated systems for matching individual assets, which can be inefficient and restrictive. Account transfer addresses this by bundling all assets within an account, enabling more flexible and fluid trades without needing pre-arranged conditions or matching algorithms like AMMs or order flow auctions. This makes it easier to find counterparties and trade multi-asset portfolios seamlessly.

• Unified and Scalable Asset Transfer: Atomic swaps typically handle one asset at a time, which can lead to higher transaction complexity and costs when dealing with multi-asset portfolios. Account transfer offers a more scalable solution by allowing the movement of entire accounts, with all assets and positions transferred in a single transaction. This not only reduces complexity but also increases efficiency for users managing diverse asset holdings across multiple blockchains.

Account: An Approach to Generalize Assets

An account can be seen. as a digital portfolio that holds a variety of assets in one place. This means that instead of transferring each asset individually, the entire account, with all its associated assets, can be transferred seamlessly. This generalizes asset transferring in a more efficient, scalable way by treating the account as the main unit.

Examples of assets held in an account:

• Cryptocurrencies: Tokens such as ETH, BTC, stablecoins, or any other digital currencies that can exist on-chain.
• DeFi Positions: An account may include assets staked in decentralized finance (DeFi) protocols like Compound, Aave, or yearn.finance. Transferring the account moves the entire position across chains, without breaking up the underlying collateral or liquidity.
• Credentials: The account can store off-chain credentials or decentralized identity (DID) proofs. These are useful for proving ownership of off-chain assets or for granting access to services.

No Dependency on Crypto Curves or State Machine Architectures

The account is treated as a generalized object, and the transfer process does not rely on specific cryptographic curves or token standards. This opens up the possibility for cross-chain transfers between heterogeneous blockchains that don’t share the same technology stack. The account, as the unifying object, abstracts away the underlying differences between chains, allowing the same account to exist and operate across multiple blockchain environments.

Better Liquidity and Matching

Instead of matching trades for individual assets, entire accounts can be swapped between parties, much like a barter exchange. The account may hold a combination of assets (tokens, NFTs, DeFi positions, etc.), making it a more comprehensive and flexible trading object. This method allows participants to exchange portfolios rather than focusing on individual assets, improving liquidity and the ability to find counterparties willing to trade diverse assets.

Example Implementation: Orderbook Protocol: In a decentralized exchange environment, users can create an orderbook that lists their account for trade, with all the assets and positions tied to that account. Other participants can place orders to trade their own accounts or assets in exchange. This allows for multi-party matching and avoids the limitations of traditional AMM (Automated Market Maker) pools or fixed swaps. The account-based system offers greater flexibility for both large and small trades.

How to Transfer Accounts: Key and Ownership

A transferable account is a digital object that consists of two key components:

• Key: The actual private key that controls the account. This key is crucial because it governs the ability to sign transactions and perform actions with the assets held in the account.
• State: The ownership state of the account, which includes information about who owns the account.

Key Management

Managing the private key securely is critical when transferring accounts. To avoid exposing the key to potential vulnerabilities, advanced key management systems are used to handle the signing process and key transfer. Two primary methods are commonly used for this purpose: Threshold Signature Schemes (TSS) and Trusted Execution Environments (TEE), along with other mechanisms that ensure the private key is protected throughout the transfer process.

• Threshold Signature Scheme (TSS): A Threshold Signature Scheme is a cryptographic technique where the private key is divided into multiple key shares and distributed across a network of participants. This approach ensures that no single party has access to the entire key.

• Trusted Execution Environment (TEE): A Trusted Execution Environment is a secure area of a device’s processor that ensures sensitive operations (like key signing) are isolated from the main operating system and any potentially compromised software.

• Hybrid Approaches: In some cases, a hybrid approach that combines TSS and TEE can be used for maximum security and flexibility. For example, TSS can be applied in decentralized networks to distribute key shares, while individual participants can use TEEs to manage their share of the key securely.

Transfer

The transfer process involves both transferring control of the key and updating the state of the account to reflect new ownership. Here’s a simplified flow:

1. Key Verification: The current owner (Alice) uses her private key to sign the intent to transfer the account to another party (Bob).
2. Key Manager/MPC Protocol: The key management system (MPC network or TEE) verifies the signature and authorizes the transfer.
3. State Update: Once the key is validated, the state of the account is updated to reflect Bob as the new owner.
4. Asset Control: Bob now has control over the account and all the assets within it. He can manage, trade, or transfer the assets without needing to go through individual transactions for each one.

Swap

Submit Intents

Action: Alice and Bob submit their intents to the Intent Store. Each intent specifies the actions they wish to take (e.g., swap their assets) and the conditions under which this should happen.

• Intent Structure:

  • account_id: The ID of the account the user wants to transfer.
  • action: The desired action (e.g., swap A->B).
  • expiry_time: The time limit by which the intent must be executed.

• Account Structure:

  • owner: The owner of the account.
  • is_locked: The parameter to allow a signing transaction, checked by key managers.
  • intent_id: The ID of the intent the user submitted.

Both parties deposit their assets into the accounts before submitting the intent and approve transferring accounts to the solver.

Mathematical Definition:

For Alice:

$$\text{Intent}_A = (A_i, B_r, \tau_A)$$

For Bob:

$$\text{Intent}_B = (B_i, A_r, \tau_B)$$

Where:

• $A_i$and $B_i$are the initial accounts of Alice and Bob, respectively.
• $A_r$and $B_r$are the requested accounts that Alice and Bob want in return.
• $\tau_A$and $\tau_B$represent the expiration times for the intents.

Solve Intents

At this step, the solver processes Alice and Bob’s intents, checks whether they match, and then creates a partial transaction to handle the account swap. The partial transaction allows for reversion if the process fails.

1. Intent Matching: The solver checks whether Alice’s and Bob’s intents are compatible. If they are, the system starts the swap process.

   Matching Condition:

   $$\text{Match}(A_i, B_r) = \text{true} \quad \text{and} \quad \text{Match}(B_i, A_r) = \text{true}$$

2. Temporary Ownership Update: The Key Store temporarily records the new owner for both accounts, but ownership isn’t finalized yet. This temporary ownership ensures that the accounts are ready for the swap, but allows for reversion if one of the parties fails to verify.

   Temporary Ownership Equations:

   $$K_{\text{temp}}(A_i) = B \quad \text{and} \quad K_{\text{temp}}(B_i) = A$$

3. Partial Transaction: The system creates a partial transaction, which temporarily holds the state changes (ownership swap) but keeps them reversible until both parties verify the transfer.

   Partial Transaction Definition:

   $$\text{Tx}_{\text{partial}} = (A_i \xrightarrow{\text{temporary}} B, B_i \xrightarrow{\text{temporary}} A)$$

Unlock Accounts

After the intents have been matched and the partial transaction is created, Alice and Bob need to verify that the assets in their new accounts are correct.

1. Verification:

   • Alice verifies the assets in her new account, making sure they match what she expected to receive from Bob.
   • Bob does the same, verifying the assets in the account transferred from Alice.

   Verification Condition:

   $$\text{Verify}(A_r) = \text{true} \quad \text{and} \quad \text{Verify}(B_r) = \text{true}$$

2. Unlock and Finalize: If both parties confirm that the assets are correct, they unlock their accounts. The system finalizes the transaction, updating the Key State Store and Key Store with the new owners.

   Final Transaction:

   $$\text{Tx}_{\text{final}} = (A_i \xrightarrow{\text{final}} B, B_i \xrightarrow{\text{final}} A)$$

   Final Ownership Update:

   $$K(A_i) = B \quad \text{and} \quad K(B_i) = A$$

Request Withdraw

Once the accounts are unlocked, Alice and Bob submit a withdraw request to the key management network. This request signals that they want to withdraw their assets from the accounts.

Reversion Mechanism (If Verification Fails)

If either Alice or Bob fails to unlock their account within the timelock, the system will trigger a reversion, rolling back to the original state.

1. Reversion Condition: If verification fails or the timelock expires:

   $$\text{Revert}(S_{\text{temp}}) = S_{\text{original}}$$

2. Restore Ownership: The temporary ownership stored in the Key Store is nullified, and ownership reverts to the original account holders:

   $$K(A_i) = A \quad \text{and} \quad K(B_i) = B$$

3. Rollback: The partial transaction is discarded, and the original ownership is restored.

Comparison

Method	Matching Flexibility	Cross-Chain Support	Withdraw Cost	Swap Cost	Use Cases	Trust Assumption
Contract-Based	High (via AMMs or auction-based systems for flexible matching)	Low (Limited to specific chains and cross-chain bridges)	Medium (bridge fees + gas fees)	High (Gas fees + bridge fees)	Flexible swaps across chains, suited for DEXs and dynamic matching in decentralized environments.	Relies on smart contract security and bridge infrastructure.
Atomic Swaps (HTLCs)	Low (Requires pre-arranged counterparties for fixed-amount swaps)	Medium (Limited to cryptographic curves)	Low (on-chain transaction fees)	Low	Best for trustless, peer-to-peer swaps of fixed amounts across compatible chains.	Trustless mechanism based on cryptographic conditions, no external trust required.
Account Transfer	High (flexible multi-party barter exchange models possible)	High	High (need to withdraw each asset individually)	Low	Best for cross-chain swaps of multi-asset portfolios (tokens, NFTs, credentials, DeFi positions).	Trust assumption on MPC networks or TEEs for secure key management.

Sample implementation

Astraeus introduces a secure and decentralized infrastructure for managing Transferable Accounts using SUAVE. The architecture focuses on enabling the creation, transfer, and management of accounts in a confidential, transparent, and efficient manner, while leveraging key components like Kettle, MEVM and SUAVE.

Components of Astraeus Architecture

• SUAVE Kettles: a network of actors that provide confidential computation for SUAPPs. These all operate in Trusted Execution Environments (TEEs).
• Confidential Data Storage: a private place to store data (e.g. user transactions).
• SUAVE Chain: a public place to store data (e.g. intentionally leaked information) and SUAPP logic (e.g. deployed smart contracts). MEVM: a modified EVM that exposes confidential computation and storage APIs to developers

Account Creation and Transfer

In the Astraeus system, Alice (the initial account holder) starts by creating a Transferable Account that can later be transferred to another user (Bob). This process is facilitated by SUAVE and involves several key steps:

1. Create Account and Approve Transfer: Alice creates a request to create an account. The account is created in the Confidential Data Store within the MEVM layer of the SUAVE Kettle. The account creation process includes an approval step, where Alice grants permission for the account to be transferred to Bob to the application like DEX.

2. Generate and Store the Account Key: Once the account is created, the MEVM generates an account key and securely stores it within its Confidential Data Store. This account key is critical for signing transactions and managing the account. The key remains hidden and is only accessible under specific conditions, ensuring security and privacy throughout the lifecycle of the account.

3. Publish Public Key: The public key of the newly created account, along with the account ownership details, is published on the SUAVE Chain. This information is stored transparently on the chain, which maintains a record of ownership, approvals, and other account-related metadata (e.g., lock duration and transfer permissions).

4. Transfer Ownership: After Alice approves the transfer to the application (suchas order flow auction), the application verifies the transfer conditions which are the account balance, the lock duration, and approvals. If the conditions are met, the ownership of the account is securely transferred from Alice to Bob by updating the state on the contract on SUAVE Chain.

Interaction with SUAVE and Signing Transactions

Once the account has been transferred to Bob, Bob can use the account for transactions. SUAVE and the MEVM architecture facilitate this interaction securely and privately.

5. Request Signature: Bob initiates a transaction and requests a signature from the system to authenticate the operation. This request is sent to the SUAVE Kettle, which manages the confidential storage and execution environment.

6. Ownership Verification: Before generating the signature, the SUAVE Chain verifies that Bob is the current owner of the account. This verification involves checking the ownership information associated with the account.

7. Sign and Send Transaction: Once ownership is verified, the MEVM retrieves the account key from the Confidential Data Store, signs the transaction on behalf of Bob, and sends the transaction to the blockchain for execution.

Conclusion

The account transfer mechanism introduces a generalized, scalable, and secure method for cross-domain asset transfers. By allowing users to move entire portfolios across multiple blockchains without relying on cryptographic curves or bridge infrastructures, the approach enhances liquidity, trading flexibility, and interoperability. The implementation of TSS and TEE for key management ensures that assets and their ownership can be transferred securely and efficiently. As the landscape of decentralized finance (DeFi) continues to grow, account transfer provides a robust foundation for cross-chain interaction, making it easier for users to manage and trade assets seamlessly.

Future Works

Private Swapping with UTXO and ZKPs

To enhance privacy in cross-domain asset swapping, future development will focus on implementing private swapping using UTXO and Zero-Knowledge Proofs (ZKPs). This approach ensures that all transaction details remain confidential, including asset types, values, and the identities of involved parties.

Here’s a step-by-step breakdown of how private swapping would work:

1. Create Private Notes: Alice and Bob create private notes that represent their transferable accounts to be swapped. These notes are securely hidden in a shared shielded pool, ensuring the transaction details, such as asset type and value, remain confidential.
2. Submit Intents: Alice and Bob submit their intents to swap the accounts, including any Validity Predicates (VPs) that define the conditions for the swap. The VPs ensure that the swap can only occur if both parties agree to the specified terms.
3. Solve Intents: The Intent Machine processes and matches Alice’s and Bob’s intents. Throughout this process, all transaction details are kept private using ZKPs, which prove the validity of the swap without revealing sensitive information.
4. Unlock and Transfer: After the swap is completed, Alice and Bob can verify their newly swapped accounts. The previous private notes are nullified, and new notes reflecting the swapped accounts are generated. The entire process is finalized while keeping all details, including ownership and asset specifics, fully shielded from external parties.

Improving Withdrawal UX

Another key area of future improvement involves enhancing the user experience during withdrawals. Withdrawing assets from transferable accounts currently involves multiple steps that require the involvement of key managers and the network. Future work will aim to simplify this process to reduce friction, making it more user-friendly while maintaining security.

Key improvements will focus on:

• Single-Step Withdrawals: Reducing the number of steps required for users to withdraw assets from transferable accounts.
• User-Friendly Interfaces: Designing intuitive interfaces that guide users through the withdrawal process without compromising security.
• Automated Withdrawal Approvals: Leveraging advanced key management systems to automate approval processes for withdrawals, reducing the need for manual input from users.

References

• UniswapX
• Intents Architecture in Across
• Atomic Cross-Chain Swaps
• Anoma Resource Machine Specification
• SUAVE Specs
• Polygon Miden
• Taiga