A cake candle chart to quickly understand the key elements of chain abstraction
TechFlow Selected TechFlow Selected
A cake candle chart to quickly understand the key elements of chain abstraction
This article introduces the Chain Abstraction Key Elements (CAKE) framework.
Navigating Web3 tides with focused insightsAuthor: Favorite Mirror Reads Archive
Translation: TechFlow
Key Takeaways
-
The current default crypto user experience requires users to always know which network they are interacting with. However, internet users do not need to know which cloud provider they are interacting with. Bringing this approach to blockchains is what we call Chain Abstraction.
-
This article introduces the Chain Abstraction Key Elements (CAKE) framework, composed of four layers: Application Layer, Permissions Layer, Solver Layer, and Settlement Layer, aiming to deliver a seamless cross-chain user experience.
-
Achieving chain abstraction requires a complex set of technologies ensuring reliability, cost-efficiency, security, speed, and privacy in execution.
-
We define the trade-offs in chain abstraction as a trilemma and present six design approaches, each with unique advantages.
-
To successfully leap into a chain-abstracted future, our industry must define and adopt a common standard for information transfer across CAKE layers. A good standard is icing on the cake.
Introduction
In 2020, the Ethereum network transitioned to a rollup-centric scaling roadmap. Four years later, over 50 rollup layer (L2) networks are live. While rollups provide much-needed horizontal scalability, they have completely broken the user experience.
Users should not care about or be aware of which rollup they are interacting with. Knowing whether they're using a specific rollup (Optimism or Base) is equivalent for crypto users to Web2 users knowing which cloud provider (AWS or GCP) they're using. The vision of Chain Abstraction is to abstract away chain-specific details from the user's view. Users simply connect their wallet to a dApp and sign their intended action; all behind-the-scenes details—ensuring correct balances on target chains and executing the desired operation—are handled automatically.
In this article, we explore how chain abstraction is a truly multidisciplinary challenge involving interactions between the application layer, permissions layer, solver layer, and settlement layer. We introduce the Chain Abstraction Key Elements (CAKE) framework and dive deep into the design trade-offs of chain abstraction systems.
Introducing the CAKE Framework
In a world of chain abstraction, users visit a dApp website, connect their wallet, sign an intent, and wait for final settlement. All complex operations occur within the infrastructure layers of CAKE. The three infrastructure layers of CAKE are:
-
Permissions Layer: Users connect their wallet to a dApp and request a quote for their intent. An intent refers to the desired end-state outcome rather than the transaction path—for example, transferring USDT to a Tron address or depositing USDC into a yield-generating strategy on Arbitrum. Wallets should be able to read user assets (i.e., read state) and execute transactions on the target chain (i.e., update state).
-
Solver Layer: Based on the user’s initial balance and intent, this layer estimates fees and execution speed. In cross-chain setups, this process is called solving and is critical because transactions are asynchronous—sub-transactions may fail during execution. Asynchronicity introduces a cross-chain trilemma involving cost, execution speed, and execution guarantee.
-
Settlement Layer: After the user approves the transaction using their private key, the settlement layer ensures its execution. This includes two steps: bridging the user’s assets to the target chain and then executing the transaction. Protocols using sophisticated solvers can provide their own liquidity and execute actions on behalf of users without requiring bridging.
Implementing chain abstraction means integrating these three infrastructure layers into a unified product. A key insight in merging these layers is the distinction between information transfer and value transfer. Interchain information transfer should be lossless, so it must rely on the most secure paths. For instance, if a user votes “yes” in a governance vote on another chain, they don’t want their vote turning into “maybe.” On the other hand, value transfer may involve some loss depending on user preferences. Mature third parties can offer faster, cheaper, or guaranteed value transfers. Notably, 95% of Ethereum blockspace usage, measured by fees paid to validators, is dedicated to value transfer.
Key Design Decisions
The above three layers introduce key design decisions that CAF must make—decisions concerning who controls the power to execute intents, what information is disclosed to solvers, and what settlement paths are available to solvers. Below is a detailed analysis of each layer.
Permissions Layer
The permissions layer holds the user’s private keys and signs messages on their behalf, which are then executed on-chain as transactions. CAF must support signature schemes and transaction payloads across all target chains. For example, a wallet supporting ECDSA signatures and EVM transaction standards will be limited to Ethereum, its L2s, and sidechains (e.g., MetaMask). A wallet supporting both EVM and SVM (Solana VM) can serve both ecosystems (e.g., Phantom). Note that the same mnemonic phrase can generate wallets across EVM and SVM chains.
A multi-chain transaction consists of multiple sub-transactions that must be executed in the correct order. These sub-transactions span multiple chains, each with its own variable gas fees and nonce system. Coordinating and settling these sub-transactions is a key design decision at the permissions layer.
-
EOA Wallets are wallet software running on the user’s device holding their private keys. They can be browser extensions (like MetaMask and Phantom), mobile apps (like Coinbase Wallet), or dedicated hardware (like Ledger). EOA wallets require users to individually sign each sub-transaction, currently involving multiple clicks. They also require users to hold fee balances on the target chain, introducing significant friction. However, this friction can be abstracted away by allowing users to sign multiple sub-transactions with a single click.
-
Account Abstraction (AA) wallets still give users access to their private keys but decouple the message signer from the transaction executor. This enables complex parties to bundle and execute user transactions atomically (e.g., Avocado, Pimlico). AA wallets still require separate signing for each sub-transaction (currently via multiple clicks), but they do not require fee balances on every chain.
-
Policy-Based Agents store users’ private keys in a separate execution environment and generate signed messages on their behalf based on user-defined policies. Telegram bots, near-account aggregators, or SUAVE TEE are examples of policy-based wallets, while Entropy or Capsule are policy-based wallet extensions. Users sign a single approval, after which agents handle subsequent sub-transactions and fee management during the operation.
Solver Layer
After users publish their intent, the solver layer returns fee estimates and confirmation times. This problem closely relates to order flow auction design, discussed in detail here. CAF can use protocol-native paths to execute user intents or leverage sophisticated third-party solvers who compromise on certain security guarantees to improve UX. Introducing solvers into the CAF framework leads to the next two design decisions, both deeply tied to information handling.
An intent contains two types of Extractable Value (EV): EV_ordering and EV_signal.
-
EV_ordering is blockchain-specific value typically captured by entities executing user orders (e.g., block builders or validators).
-
EV_signal represents value accessible to any entity complying with an order before it is formally recorded on-chain.
Different user intents exhibit varying distributions between EV_ordering and EV_signal. For example, swapping tokens on a DEX usually has high EV_ordering but low EV_signal. Conversely, hacker trades have higher EV_signal because front-running yields more value than execution. Notably, EV_signal can sometimes be negative—for example, market maker trades where executors incur losses due to better-informed future market conditions known to the maker.
When someone can observe a user’s intent early, they can front-run it, causing value leakage. Additionally, the possibility of negative EV_signal creates adverse selection among solvers, leading them to submit lower bids and further eroding value. Ultimately, this leakage affects users through higher fees or worse prices. Note that low fees and improved prices are two sides of the same coin and will be used interchangeably throughout the rest of this article.
Information Sharing
There are three ways to share information with solvers:
-
Public Mempool: User intents are publicly broadcast to a public mempool or data availability layer. The first solver capable of fulfilling the request executes the order and wins. This system highly extracts user information since both EV_ordering and EV_signal are exposed. Examples include Ethereum’s public mempool and various blockchain bridges. In bridge scenarios, users must lock assets in escrow before transferring to the target chain to prevent malicious attacks—but this inadvertently reveals their intent.
-
Partial Sharing: CAF can reduce the amount of value revealed to bidders by limiting disclosed information. However, this directly sacrifices price optimality and may lead to bid spam issues.
-
Private Mempool: Advances in MPC and TEE now enable fully private mempools. No information leaks outside the execution environment; solvers encode their preferences and match against each intent. While private mempools capture EV_ordering, they cannot fully capture EV_signal. For instance, if a hacker trade enters the mempool, the first party seeing it can front-run and capture EV_signal. In a private mempool, information only becomes public after block confirmation, meaning anyone observing the transaction post-confirmation can still capture EV_signal. Solvers might even build certified nodes to extract EV_signal from newly minted blocks within TEEs, turning EV_signal capture into a race of latency.
Solver List
CAF must also decide how many and which solvers are allowed to participate in auctions. The main options are:
-
Open Access: Entry barriers to participation are kept as low as possible. Similar to a public mempool, this leaks both EV_signal and EV_ordering.
-
Restricted Access: Gatekeeping execution rights via whitelists, reputation systems, fees, or seat auctions. These mechanisms must ensure solvers do not capture EV_signal. Examples include 1inch Auction, Cowswap Auctions, and Uniswap X auctions. Competition among solvers captures EV_ordering for users, while gating allows intent originators (wallets, dApps) to capture EV_signal.
-
Exclusive Access: A special auction form where only one solver is selected per time window. Since no information is leaked to other solvers, there is no adverse selection or front-running discounting. The intent originator captures the expected value of both EV_signal and EV_ordering, but due to lack of competition, users receive execution without price improvement. Examples include Robinhood and DFlow auctions.
Settlement Layer
Once a wallet signs a set of transactions, they need to be executed on the blockchain. Cross-chain transactions turn settlement from an atomic operation into an asynchronous one. During the interval between initial execution and confirmation, the state on the target chain may change, potentially causing transaction failure. This section explores the trade-offs between safety cost, confirmation time, and execution guarantee.
Note that successful execution of the intended transaction on the target chain depends on the target chain’s transaction inclusion mechanism—including factors like censorship resistance and fee mechanisms. We consider target chain selection a dApp-level decision beyond the scope of this article.
Cross-Chain Oracles
Two blockchains with different states and consensus mechanisms require an intermediary—an oracle—to facilitate information transfer. Oracles act as relays for interchain communication, verifying that users have locked funds in escrow for lock-and-mint bridges or confirming token balances on the source chain to enable governance voting on the target chain.
Oracles transmit information at the speed of the slowest chain to manage reorg risk, as they must wait for consensus on the source chain. Suppose a user wants to bridge USDC from a source to a target chain, locking funds in escrow. If the oracle proceeds to mint tokens on the target chain without sufficient confirmations and a reorg occurs where the user reverses their deposit, the oracle could cause a double-spend.
There are two types of oracles:
-
Out-of-Protocol Oracles: Require third-party validators separate from the consensus mechanism to pass information between chains. Additional validators increase operational costs. LayerZero, Wormhole, ChainLink, and Axelar Network are examples.
-
In-Protocol Oracles: Deeply integrated into the ecosystem’s consensus algorithm, using the existing validator set to relay information. Cosmos IBC for chains built with Cosmos SDK, Polygon’s AggLayer under development, and Optimism’s Superchain are examples. Each uses dedicated blockspace to transfer information across chains within the same ecosystem.
-
Shared Sequencers are out-of-protocol entities that possess transaction ordering authority within protocols—they can bundle transactions across chains. Though still in development, shared sequencers may not need to wait for full block confirmations to mitigate reorg risks. To achieve true cross-chain atomicity, shared sequencers must conditionally execute subsequent transactions upon the success of earlier ones, effectively chaining them together.
Bridging Tokens
In a multi-chain world, users’ tokens and fee balances are scattered across networks. Before every cross-chain operation, users must bridge funds from the source to the target chain. Currently, there are 34 active cross-chain bridges with $7.7 billion in total TVL and $8.6 billion bridged in the past 30 days.
Token bridging is a case of value transfer. This creates opportunities for specialized third parties skilled in capital management and willing to assume reorg risk, reducing the cost and time required for user transactions.
There are two types of cross-chain bridges:
-
Lock-and-Mint Bridges: Verify deposits on the source chain and mint tokens on the target chain. These bridges require minimal startup capital but demand heavy investment in securely transferring lock information. Security breaches in such bridges (as documented) have led to billions in losses for token holders.
-
Liquidity Bridges: Use liquidity pools on both source and target chains, with algorithms determining exchange rates. While initial setup costs are higher, they require less stringent security. In case of exploits, only funds in the liquidity pool are at risk.
In both bridge types, users pay liquidity costs. In lock-and-mint bridges, this cost arises when swapping wrapped tokens (e.g., USDC.e to USDC) on the target chain. In liquidity bridges, the cost occurs when exchanging source-chain tokens for target-chain equivalents.
The Cross-Chain Trilemma
The five design decisions above give rise to a cross-chain trilemma. CAF must choose two out of three properties: execution guarantee, low fees, and execution speed.
-
In-Protocol Paths: Designated cross-chain information transmission routes. These systems account for reorg risk, sacrificing execution speed, but reduce costs by eliminating extra validator sets or liquidity overhead.
-
Solver Aggregation: Collect quotes from multiple solvers to identify the cheapest and fastest way to execute user intents. However, due to adverse selection and front-running, solvers may sometimes fail to fulfill intents, resulting in reduced execution.
-
Execution Competition: Arrange solvers to race for intent execution or select a single winner. Both methods result in high user fees, as solvers compete for execution rather than price improvement.
Six Components of CAKE
For this article, we studied over 20 teams—directly or indirectly working on chain abstraction designs—currently in production or development. In this section, we discuss six distinct CA implementations we believe have inherent efficiency and product-market fit. When properly built, these designs have the potential to integrate with one another.
A key conclusion is the need for a unified standard for expressing cross-chain intents. Each team is developing its own method and protocol for encoding user intents, leading to duplicated efforts. A unified standard would enhance user understanding of signed messages, simplify intent processing for solvers and oracles, and ease integration with wallets.
Token-Specified Bridges
A special case of lock-and-mint bridges that avoids liquidity costs—also known as burn-and-mint bridges (e.g., USDC CCTP). Token teams designate a canonical token address on each chain, and the bridge is authorized to mint the exact token users need.
Upon closer inspection, burn-and-mint bridges resemble cross-chain transfers conducted at sufficient block confirmation speeds. xERC20 is one such standard specifying canonical tokens and authorized bridges on target chains. Token-specified bridges are examples of in-protocol paths—they sacrifice speed for execution guarantee and low fees; for instance, CCTP takes about 20 minutes to complete a transfer.
Ecosystem-Coordinated Bridges
Ecosystem-coordinated bridges enable arbitrary message passing between chains within the same ecosystem. These belong to in-protocol paths, prioritizing execution guarantee and low fees over speed. Examples include Cosmos IBC, Polygon AggLayer, and Optimism Superchain.
Three years ago, the Cosmos ecosystem faced challenges similar to those Ethereum faces today: fragmented liquidity, each chain with its own fee token, and cumbersome multi-chain account management. Cosmos solved these by implementing the IBC in-protocol messaging bridge, enabling seamless multi-chain account management and cross-chain transfers.
The Cosmos ecosystem comprises sovereign chains with fast finality, enabling rapid in-protocol cross-chain messaging. Rollup ecosystems, however, depend on challenge period resolution (Optimistic Rollups) or zk-proof submission (ZK-Rollups) for finality. Due to these finality constraints, cross-ecosystem messaging is slower.
Solver Price Competition
Solver price competition involves sharing order information with all solvers. Solvers aim to aggregate the expected value (EV) generated by order intents and return it to users. The winning solver is selected based on maximizing user price improvement. However, this design carries non-execution risk, requiring additional mechanisms to ensure reliability. Examples include Uniswap X, Bungee, and Jumper.
Wallet-Coordinated Messaging
Wallet-coordinated messaging leverages features provided by AA or policy-based wallets to deliver a cross-chain experience compatible with any intent type. It acts as the ultimate CA aggregator, redirecting user intents across various CA designs to resolve specific needs. Examples include Avocado Wallet, Near Account Aggregator, and MetaMask Portfolio.
Note that over the past decade, the crypto ecosystem has learned that the relationship between users and their wallets is extremely sticky. Every time I consider migrating my mnemonic from MetaMask to another wallet, I feel intense anxiety. This is also why EIP-4337, despite Vitalik Buterin’s endorsement, still has low adoption after 2.5 years. Even though newer wallet protocols may offer better pricing (via account abstraction) or improved usability (via policy-based wallets), migrating users from their current wallets remains a daunting task.
Solver Speed Competition
Solver speed competition allows users to express intent for specific cross-chain swaps with high execution assurance. It does not help minimize fees but provides a reliable channel for including complex transactions. The first solver to execute the intent based on block builder fees or inclusion speed wins.
This design aims to achieve high inclusion rates by maximizing EV captured by solvers. However, it comes at the cost of centralization, relying on sophisticated capital management on Ethereum mainnet or low-latency execution on L2s.
Exclusive Batch Auctions
Exclusive batch auctions hold auctions for exclusive rights to execute all order flow within a time window. Since other solvers cannot see orders, they bid based on predicted market volatility and average execution quality. Exclusive batch auctions rely on a fallback price to ensure fair user pricing, so they cannot be used for price improvement. Sending all order flow to a single bidder eliminates information leakage and increases execution certainty.
Conclusion
The Chain Abstraction Framework (CAF) promises seamless cross-chain interactions for users. In this article, we examined several teams building and deploying designs—explicitly or implicitly addressing chain abstraction. We believe this year will be the year of CAF, expecting significant competition among different designs and implementations within the next 6–12 months.
Cross-chain value transfer will achieve low fees through token-authorized bridges, and fast execution through solver speed or price competitions. Information transfer will be routed via ecosystem-matched messaging bridges designed to minimize user costs and maximize speed through wallet-controlled platforms. Ultimately, these six distinct design approaches will converge into a cluster, satisfying different needs and leveraging efficiencies across different regions of the trade-off matrix.
One major takeaway from this process is the need for a universal standard to express cross-chain intents. Currently, multiple teams are independently developing protocols to encode user intents, resulting in redundant work. A unified standard would improve user comprehension of signed messages, streamline intent processing for solvers and oracles, and simplify wallet integration.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
