Chain Abstraction: From Concept to Implementation
Who We Are
We are the developers of VOOI — a DeFi dApp for perpetual trading, powered by a chain abstraction implementation under the hood. In the ever-evolving and increasingly complex world of DeFi, where innovation and experimentation are constant, we know firsthand what it means to be on the bleeding edge of technology.
In this article, we’ll dive into one of the latest trends shaping the DeFi landscape: chain abstraction. We’ll share how we arrived at adopting this approach, provide insights into the current state of chain abstraction based on our experience, and highlight topics for further thought and innovation. To ensure a clear understanding, we’ll also cover the basic concepts of chain abstraction as a foundation for the discussion.
This article was contributed by OneBalance and Particle Network teams - our Chain Abstraction implementation partners.
Our Way to Chain Abstraction
Our users are traders, and they ultimately care about three things: price, execution, and the safety of their funds. The DeFi world poses harsh challenges to all three.
While developing VOOI, we initially adopted the intent-based approach. However, after implementing and thoroughly testing it, we realized it didn’t fully address the needs of our users. We decided to seek a better solution that aligned with our goals. This journey led us to chain abstraction.
Chain Abstraction: Rough Cut View
We’ll dive into the technical details a little further down, but for now, let’s outline the big picture. As the name suggests, chain abstraction hides the complexity of interacting with multiple networks from dApp developers and end users.
For developers: There’s no need to integrate every new blockchain individually. Instead, they can build a single dApp that works seamlessly across all networks.
For users: Chain abstraction refines the user experience. They can use Web3 apps — say, for leveraged trading on perpetual DEXs — without worrying about boring details like asset inventory management across chains, gas tokens, or transaction times. The complexity is hidden, delivering a smooth and intuitive experience.
Diversity of Chain Abstraction Implementations
Although chain abstraction is a relatively new concept, various approaches to its implementation have already emerged. While these implementations may differ in certain areas, they also share fundamental similarities that define what chain abstraction truly is.
Similarities
To explore the similarities and dive deeper into chain abstraction, we refer to the Chain Abstraction Key Elements (CAKE) framework — the most comprehensive model outlining key technologies and components collectively enabling chain abstraction. This framework provides a structured view of how chain abstraction implementations operate across different layers:
Application Layer handles tasks like processing user inputs and displaying outputs, creating a bridge between the user and the underlying networks. It removes things like "chain", "bridging", "gas", and so on away from the end user. Applications like VOOI operate at this layer, focusing on user-centric functionality while leveraging the underlying layers.
Permission Layer abstracts users from the details of account management and transaction authorization. This layer ensures that users don't have to manually authorize every step or manage private keys themselves — it’s all handled under the hood.
Solver Layer is responsible for transaction optimization. It identifies the best routes, sequences transactions, matches orders, and even can act as a liquidity provider when necessary.
Settlement Layer handles bridging, liquidity, data availability, and ensures execution and finalization. It’s the accountant and mediator rolled into one, settling all debts and disputes.
For more information about the CAKE framework, please refer to this resource.
How Layers Work Together The application layer sits at the top of the CAKE, enabling user interaction with the chain abstraction framework. During the first interaction, the app provides functionality for creating or importing a Chain Abstracted Account (CAA). After that, it generates intents and passes them to the Permission Layer. Using data providers and information from the Solver and Settlement Layers, it monitors transaction progress and promptly updates the user.
Through these interactions, the Application Layer abstracts technical complexity, delivering a smooth, user-friendly experience while coordinating seamlessly with the underlying layers.
Differences
At first glance, it may seem that the concept of chain abstraction has solved all the problems and a bright future is just around the corner. However, the reality is more nuanced. While chain abstraction introduces a unifying concept, it also brings new challenges.
The variety of implementations reveals key differences in design and functionality. The differences primarily lie in the layers beneath the Application Layer — specifically, the Permission, Solver, and Settlement layers — and in how these layers interact.
Permission Layer
Solutions in this layer vary based on account management methods, including:
Smart Contract Accounts (e.g., ERC-4337): Offering enhanced flexibility and programmability.
Externally Owned Accounts (EOAs): Simpler but less flexible alternatives.
Policy-based Agents: Enabling automated, rules-driven transaction management.
Currently, VOOI uses ERC-4337 Smart Contract Accounts for their flexibility and programmability but is still exploring other approaches to find the best solution for its users.
These choices impact key aspects such as transaction flexibility, user experience, and security, making the Permission Layer critical to any chain abstraction approach.
Solver Layer
In the Solver Layer, implementations differ in their roles and transparency:
Roles: Some solvers identify optimal transaction routes, while others act as liquidity providers or "fillers," responsible for executing cross-chain transactions and ensuring their successful completion in intent-based systems.
Transparency: Protocols vary from using public mempools to private ones or only partially revealing intent details to enhance privacy and prevent front-running.
Competition: In some implementations, solvers compete with one another, while others focus on collaboration, with competition conditions tailored to the protocol's needs.
These differences influence transaction speed, efficiency, and overall user experience.
Settlement Layer: The Settlement Layer also showcases significant variation, including:
Finality Methods: Approaches like optimistic oracles, messaging systems, or zk-proofs determine how quickly and securely transactions are finalized.
Clearing Engines: This critical component manages solver invoices, rebalances liquidity between chains, and ensures smooth payment flows, tying closely to the Settlement Layer’s effectiveness.
The diversity in settlement approaches directly impacts transaction finality, security, and the efficiency of liquidity management across chains.
Application Layer brings its own questions and challenges: How much functionality should be exposed to the user? Won’t the user be overwhelmed with all these functionalities and just run away?
Let’s shift from the general to the specific.
Deep Dive into One of the Realizations
We work with protocols that implement chain abstraction in the way described below. In our view, this is the only approach that truly defines what chain abstraction should be. Let’s take a closer look.
First, a couple of definitions:
Chain Abstracted Balance (CAB): A unified balance that can be used across multiple chains, represented by various tokens (such as stablecoins).
Chain Abstracted Account (CAA): Holds the CAB and can be structured as either an Externally Owned Account (EOA) or a Smart Contract Account (SCA).
How it Works from a User's Perspective
Imagine you have 100 USDC on Arbitrum and want to open positions on a perpetual DEX across multiple chains, such as BNB and Base. You deposit 100 USDC into your CAA on Arbitrum. Once your funds are accounted for in your CAB, you can seamlessly spend them across multiple chains, allowing you to open positions on BNB and Base in just one click.
What’s important: you only need gas tokens if there are no assets in your CAB. Otherwise, all operations are paid directly from the CAB. Whether your funds are on a single chain or spread across multiple chains, once assets are deposited into a CAA on any chain and your CAB is updated, you can seamlessly spend or withdraw those assets on any chain. This consolidates the process into an N:1 chain-wise execution, eliminating the need to manage gas tokens or fragmented balances manually.
How It Works under the Hood
Here’s a simplified description of the transaction life cycle. The details may vary depending on the specific implementation.
When tokens are deposited to your CAA, they are placed under a temporal resource lock (in some cases this step can be omitted). The resource lock is an important concept – it represents a user’s commitment to temporarily hold a state in escrow until the target transaction is either finalized or expires. Once the process is completed, your balance becomes chain abstracted.
This commitment is crucial for preventing solvers from double-spending or processing conflicting user requests, either by accident or with malicious intent, before the target transaction is finalized. By leveraging this commitment, solvers can execute the transaction on the destination chain without waiting for finality on the source chain.
This feature provides a significant advantage: it reduces latency. In fact, the execution time of a user intent (user operation) closely approaches the transaction mining time on the destination chain.
When initiating a transaction that spends funds from your CAB, you form an intent. This intent includes the calldata (encoded function call), the token you're spending, the amount and the intent’s execution deadline.
At this stage, solvers step in. One of them prepares a transaction to be recorded on the blockchain. You then sign the transaction with your private key. Once the signed transaction is sent, the associated funds are locked and cannot be used to create another intent unless the deadline for the first transaction expires. The solver sponsors the transaction by either fronting the necessary funds or providing a signature that enables the transaction to proceed. As a result, the transaction is finalized and recorded on the blockchain.
After that solver provides proof of fulfillment of the users intent to the engine that is responsible for the settlement and receives funds from your CAB that have been used for transaction execution. The difference between what the solver provided and what is received from your CAB includes all applicable commissions: gas fees for executing the transaction, protocol fees, and solver commissions.
What’s important: In this process, user operations do not require traditional token bridging between chains. The solver uses its own tokens already available on the target chain to fulfill the user's intent and receives reimbursement, along with compensation, on the networks where the user holds tokens in their CAA. Solvers can rebalance their assets at any time using established bridging mechanisms, but this is a separate process that does not require speed. This design significantly enhances both the speed and security of cross-chain transactions.
Conclusion
This process highlights how chain abstraction simplifies complexity, enhances user experience, and boosts efficiency. By eliminating the need for traditional token bridging during user operations, it enables faster and more secure cross-chain transactions. Resource locks and intent-based operations further reduce latency without compromising security. However, the reliance on solvers and the settlement engine underscores the importance of robust implementation to ensure trust, scalability, and seamless operation.
For Dessert: A Taste of Challenges
While chain abstraction offers a promising solution to blockchain fragmentation, two significant challenges remain:
Lack of a Unified Standard While there have been efforts to create a standard for chain abstraction, no universal approach has been established yet. This lack of standardization creates variability in how different protocols operate, making interoperability between implementations more difficult.
Asset Fragmentation Across Implementations Chain abstraction implementations often handle assets differently, leading to fragmented balances and liquidity across various systems. This fragmentation can complicate asset management for both developers and end users.
These challenges highlight areas where further innovation and collaboration are needed. We may explore them in greater detail in future publications.
VOOI Official Links: