Chain abstraction: design decisions and trade-offs

We never knew what protocol and database web2 apps were dealing with while using them. With a transparency point of view, I should know how my actions and data are dealt with, but not care about the underlying tech. That sounds like just a perfect dream-level abstraction. But in “Web2“ apps, which are owned by centralized corporations, transparency is a myth, but users are well abstracted from complexities, and most of the things just happen with a single click. So blockchain-powered “Web3“ came into the picture. Web3 offered transparency and decentralization, but no abstraction.

Chain abstraction solves this problem. Users don’t need to worry about different chains/networks, gas fees, or loads of pop-ups.

The CAKE framework defines key design elements and decisions a protocol can make to create a chain abstraction framework. This framework consists of different layers, which serve various purposes as part of a stack.

The CAKE framework outlines key design elements and decisions for building a chain abstraction protocol. It consists of multiple layers, each serving a distinct purpose within the stack:

1. Application Layer: This layer connects users to the application and its services—the interface you see on your screen.

2. Permission Layer: Home to wallets and authentication, this is where users express their "intent" for transactions. An "intent" reflects the user’s desired outcome, e.g., "I want to stake 100 ETH on Lido," expecting to deposit 100 ETH into Lido contracts and receive stETH in return.

3. Solver Layer: This layer determines how the transaction will be executed, estimating costs based on complexity, network conditions, and the user’s balance.

4. Settlement Layer: The actual execution happens here. First, the user’s assets required for the transaction are bridged to the target chain. Then, the transaction is executed, with executors either providing their liquidity or bridging the user’s assets, depending on the execution path (explored further in the trade-offs section).

Design Decisions

1. Atomicity

   Multi-chain transactions often involve a series of smaller sub-transactions executed together. It’s critical to design the process so users aren’t required to approve each step manually.

• Permission Layer: Account abstraction (AA) wallets or policy-based agents can streamline this by eliminating repetitive approvals.

• Solver Layer: Users sign initial approvals on the origin chain, while solvers provide liquidity and execute transactions on the target chain on the user’s behalf.

• Settlement Layer: Programmable smart contracts with cross-chain arbitrary messaging (carrying payloads) can address this. However, this places responsibility on dApps and protocol developers to make their contracts natively cross-chain.

2. Information sharing with solvers -

   it is a significant challenge in intent-based systems, as there’s a risk of front-running. Chain abstraction frameworks can adopt various strategies to manage this:

• Public Mempool: All data is shared openly in the public mempool, accessible to all solvers. This risks leakage to malicious actors who could front-run transactions.

• Partial Sharing: Only partial data is shared, forcing solvers to infer the rest before bidding. This can lead to "max bidding" or spamming.

• Private Mempool: Data remains secure and isn’t shared publicly. Solvers specify their preferred transaction types, and the system matches them to the closest-fitting solver for execution.

3. Solver availability and data security -

   can be managed through selective access strategies:

• Open access to all solvers.

• Gated access via whitelisting or conditional solver sorting.

• Restricted access to a select group of solvers.

4. Medium for cross-chain communication

   It is critical and depends on external factors, such as the chains being built on or targeted for bridging value and information:

• In-Protocol Paths: These are ecosystem-specific, like IBC for Cosmos, AggLayer by Polygon, or Superchains by Optimism. They’re deeply integrated, with dedicated block space for sharing information across ecosystem chains.

• Out-of-Protocol Paths: Third-party validators participate in consensus to transfer information between chains. Examples include Wormhole, LayerZero, Chainlink, and Axelar.

5. Mediums to Bridge Tokens

• Lock-and-Mint Bridges: Tokens are locked on the source chain, and wrapped tokens are minted on the target chain.

• Token-Anointed Bridges: Also known as burn-and-mint bridges, these burn tokens on the source chain and mint them on the target chain. This applies to tokens deployed across multiple chains, like USDC.

• Liquidity Bridges: These leverage liquidity pools on chains to bridge tokens, e.g., swapping ETH for USDT from Ethereum to Avalanche.

These design decisions shape a chain abstraction framework, but they come with trade-offs..

Cross-chain trilemma

The trilemma highlights a trade-off where frameworks can only optimize for two of three properties:

• Certainty of execution

• Speed of execution

• Low fees

This leads to the following options:

Value Transfer

• Token-Anointed Bridges: Low speed but cost-efficient and certain.

• Solver Price Competition: Sharing order value data with solvers allows them to minimize fees. This offers high speed and low cost but lacks certainty.

• Solver Speed Competition: Prioritizes certainty and speed over minimizing costs.

Information Transfer

• Exclusive Batch Auctions: A select group of solvers handles intent data, with only one bidder executing the transaction. This reduces information leakage, ensuring certainty and speed, but at a higher cost.

• Ecosystem-Aligned Bridges: In-protocol bridges facilitate information transfer within ecosystem chains, offering low cost and certainty but slower speeds.

• Wallet-Coordinated Messaging: Cross-chain messaging via policy-based or account-abstraction wallets.

Conclusion

The space feels cluttered right now, but these initial drawbacks and trade-offs lay a strong foundation for future solutions. Chain abstraction frameworks can optimize for two of speed, certainty, and cost, with higher-level solutions—like L2s did for Ethereum—addressing the third. Combining components into a cohesive stack can also mitigate trade-offs.

Emerging standards like ERC-7683 are standardizing intent-based systems, expanding the solver pool, increasing speed, and enabling more integrations. This will drive adoption of chain abstraction. Major players like Particle Network, Across, and Uniswap are championing better UI/UX through chain abstraction and interoperability, paving the way for a new generation of dApps with improved user experiences.