Router Protocol is baking Chain Abstraction around the C.A.K.E Framework.
Chain Abstraction aims to simplify the user experience in the blockchain world by removing the need for users to know which specific blockchain network they are interacting with. Well, to be fair, this is one definition of chain abstraction, and everyone likes to define it differently. However, for the end goal, most of the industry seems to be aligned–it’s about making it easy and intuitive for users to interact with different chains and DApps.
In a chain-abstracted world, users can connect their wallet to a dApp, sign the intended operation, and let the underlying infrastructure handle the complexities of cross-chain interactions. This vision allows seamless operations across different blockchains without exposing users to the intricacies of each chain.
The CAKE (Chain Abstraction Key Elements) framework provides a comprehensive blueprint for achieving Chain Abstraction. It consists of four key layers: Application, Permission, Solver, and Settlement!
Router and CAKE Framework.
In this article, we’re going to slice through the layers of the CAKE framework and explore how Router works on each layer to support chain abstraction.
So, what is CAKE? 🎂
The CAKE framework, which stands for Chain Abstraction Key Elements, was introduced as part of a research article titled “Chain Abstraction is a piece of CAKE 🍰” authored by Ankit Chiplunkar and Stephane Gosselin for Frontier Research. It was developed to standardize and streamline cross-chain interactions by breaking down the chain abstraction into different layers! It’s a top-down approach that helps us explore, slice, and build a mental model around chain abstraction.
The article addresses the fragmented user experience in the current multi-chain blockchain ecosystem. While Ethereum and its rollups (L2s) have enabled scalability, they have also complicated the user experience by making users aware of which specific chains or rollups they interact with. The interaction journey if a user is on an Ethereum Layer-2 and wants to interact with a DApp on Ethereum Layer-2 is still very hard and requires multiple steps to do anything. Much harder if you put a different Layer-1 chain into the mix.
The authors draw an analogy to the internet, where users don’t need to know which cloud provider is hosting a website; similarly, blockchain users shouldn’t know which chain their transaction is happening on. This vision is what the authors refer to as “Chain Abstraction.”
As mentioned above, it is composed of four layers: Applications, Permissions, Solving, and Settlement. These layers collectively facilitate seamless cross-chain operations for users.
Application Layer: Simplifying User Experience
The Application Layer is the front line of the CAKE framework — where users interact with dApps without understanding the complex infrastructure behind the scenes. In a fully abstracted system, users don’t need to worry about which blockchain they use or how assets are being moved. All they see is the application they’re interacting with, and everything else happens seamlessly under the hood.
From the flagship dApp Router Nitro to various POCs like StakeStone and Nuri, we have already demonstrated how simplified interactions work in real-world applications, offering users a smooth and intuitive interface. For instance, using the StakeStone adapter, users can stake ETH from any chain using any asset on Scroll while the background of the transaction is handled by the Router’s CCIF.
Below is a snapshot of StakeStone POC showcasing how users can come from any chain and token to start their staking journey-
Permission layer: Managing Access and Authorization
FT. CAKE FRAMEWORK
Permission Layer holds your private key and signs transactions on your behalf. Whether you’re on Ethereum, Solana, or both, this layer ensures your wallet can handle the right signing methods for the chains you’re working with. But as simple and as dreamy as it sounds, when you’re doing a cross-chain move, it’s not just one transaction — it’s a series of sub-transactions spread across different chains, each with its own fees and requirements. Keeping track of all those details and fees? That’s a job for the Permission Layer.
With traditional EOA wallets like Metamask or Phantom, you’re clicking “sign” for every transaction. Plus, you’ve got to keep enough gas on every chain you’re interacting with, which can get annoying and slow things down.
Hence, a daily crypto user can benefit from Account Abstraction (AA) Wallets and Policy-Based Agents. For example, AA wallets can still make you sign off on each transaction, but they bundle the steps together. You don’t need to worry about holding fees on every chain you interact with.
Additionally, Policy-Based Wallets require you to sign once, and then these wallets automatically sign sub-transactions and manage fees based on the policies you’ve set. So, these agents hold your private key in a secure environment and sign off on transactions for you!
Ultimately, the Permission Layer turns a chaotic multi-chain process into a streamlined, user-friendly experience.
FT. ROUTER
In Router’s case, users express their intent using their EOA wallets! This intent can range from swapping, bridging, staking, providing liquidity, etc.
Everything kicks off at the Application Layer, where users interact with the platform. The permission layer gives users permission to execute what they want to do.
One of the best examples of the same is what we have done with StakeStone, a single click Adapter for staking ETH from any chain and any token via Stakestone on Scroll!
While as of now, Router doesn’t support any wallet abstractions or signing process on behalf of users, the Application’s interface outlines a feature that enables users holding funds on any compatible chain to stake funds on StakeStone (on Ethereum) in one step. Users can also choose the chain on which the funds (STONE) should be received after liquid staking.
How Router’s Permission Layer Fits into the CAKE Framework:
Router’s approach fits into the CAKE framework by enabling users to interact with multiple chains without the typical friction associated with cross-chain transactions. Although Router doesn’t yet automate the signing process like AA wallets, it simplifies user interactions at the front end, making it easier to perform complex actions like staking from any chain in just one step. Router’s infrastructure can also be integrated with account abstraction infrastructure providers like Biconomy, allowing intent-based policy implementations of cross-chain flows. We also suggest you check out our ecosystem project called Tagzz, which allows users to mint omnichain identities. In the upcoming releases, the accounts tied to these addresses can also support policy-based interactions. For example, imagine minting ‘john’ as the username on taggz and being able to define policy like anyone can send funds to john/usdc, and irrespective of what asset someone sends — john will only receive USDC.
Solver Layer: The Brains Behind Transaction Execution
FT. CAKE FRAMEWORK
Once a user posts their transaction intent, the Solver Layer works — calculating the fee, estimating confirmation time, and ensuring the transaction goes through. Think of it as an auction where different solvers bid to execute the transaction, each offering a balance between speed, cost, and reliability. The Solver Layer can use either in-protocol solutions or more advanced third-party solvers to improve the user experience, sometimes at the cost of reduced security guarantees.
Information Sharing & Solver Access: What You Reveal Affects Who Can Solve
How much information you share about your transaction directly impacts who can execute it and how much value you might lose in the process. Here’s a breakdown of the approaches:
- Public Mempool (Open Access): In this approach, your transaction is fully visible to anyone. This gives everyone the chance to jump in and solve it, but it exposes your transaction details, making it vulnerable to value leakage through front-running. It’s open but highly risky.
- Partial Sharing (Gated Access): Here, you reveal just enough info to trusted solvers while keeping some details hidden. This reduces exposure but introduces inefficiencies, as solvers may guess the missing details or spam bids. Access is limited to those who meet certain criteria, like being on a whitelist or having a solid reputation.
- Private Mempool (Exclusive Access): This option keeps your transaction hidden until it’s fully confirmed, allowing only one solver to act at a time. While this prevents value leakage, it also means no competition among solvers, which could result in missing out on better prices or faster execution.
The Solver Layer is all about balancing trade-offs: speed, security, and cost. By controlling how much information is shared and who can access it, users can optimize their cross-chain transactions to minimize value loss and improve efficiency.
FT. ROUTER
In the Solver Layer, Router ensures that the user’s intent is executed smoothly. Here’s how Router fits in:
- Path Solving Layer: Router’s PathFinder API does the heavy lifting, finding the most optimal path to execute the user’s intent. Whether a simple swap or a complex cross-chain transaction, Router’s path-solving abilities ensure users get the best possible route, minimizing fees and maximizing efficiency.
- Bridging Layer: Need to move assets across chains to make things happen? Router’s bridging capabilities seamlessly transfer assets between chains to get the job done. No friction, and no delays — just smooth cross-chain transfers when needed.
- Solvers (Forwarders): In Router’s world, solvers (or forwarders) are the Market Makers, executing the necessary actions to fulfill the user’s intent. Whether it’s swapping, bridging, or liquidity management, Router’s solvers are on it, making sure everything goes through like clockwork.
For example, in the case of StakeStone, the PathFinder API figures out the optimal path–for smaller transactions, it optimizes by directly swapping on Scroll to maximize user returns. On the other hand for larger transactions, it transfers the user’s tokens to Ethereum, stakes them, and then bridges the corresponding STONE to Scroll, ensuring maximum return optimization.
How Router’s Solver Layer Fits into the CAKE Framework:
Router’s Solver Layer aligns with the CAKE framework by handling everything from pathfinding to asset bridging efficiently. It provides a streamlined user experience by automating complex multi-chain processes and making them feel intuitive and straightforward.
While the CAKE framework’s Solver Layer balances speed, security, and cost through varying levels of solver access and information sharing, Router enhances this by ensuring that the best possible routes are selected to execute user intent seamlessly.
Solvers set their fees, and Router provides the best available quote to the user. When users initiate a transaction, it triggers an event that’s broadcasted for Solvers to pick up. The system works on a first-come, first-served basis, so the first Solver to claim the transaction completes it by settling it on the destination chain.
This overall ensures that users benefit from optimized transaction execution, regardless of the complexity of their cross-chain activities. By leveraging Router’s PathFinder API, bridging capabilities, and forwarders/solvers, the Solver Layer transforms intricate multi-chain processes into a hassle-free, efficient experience.
Settlement Layer: Where It All Comes Together
FT. CAKE FRAMEWORK
Once your wallet signs off on a transaction, it’s not just about pressing “send” and hoping for the best. The Settlement Layer is where the magic (and challenges) happen, especially for cross-chain transactions. Unlike single-chain transactions that happen all at once (atomic), cross-chain deals go through a process called asynchronous settlement — meaning the transaction has to jump through multiple hoops before it’s finalized. This opens up risks like chain state changes or even transaction failure. In short, the more chains involved, the more complex the settlement game becomes.
The Trade-off Game: Security vs. Speed vs. Guarantees
Each decision in the Settlement Layer affects one or more of these trade-offs:
The real trick in cross-chain settlements is balancing three things:
- Security: Is the transaction safe from failure or manipulation?
- Speed: How fast can it move through the chains involved?
- Execution Guarantee: Will the transaction be completed successfully, even with hiccups?
In summary, the Settlement Layer is where the final execution happens!!
FT. ROUTER
Router chain acts as a settlement and clearing layer for all intents generated by users. This ensures that everything gets wrapped up neatly after the transaction is executed.
- Transaction Settlement Layer: After the solvers (forwarders) complete their task, the Router chain verifies whether their execution aligns with the user’s original intent.
- Transaction Clearing Layer: Once the transaction is verified, the solvers are reimbursed for any liquidity they provide. This ensures they get what they’re owed, keeping the process flowing smoothly.
Router makes sure transactions are properly verified and all parties are compensated, so users don’t have to worry about a thing after they hit “confirm.”
Lastly, to highlight the power of the Router Intent Framework, we’re excited to share that the StakeStone Adapter processed over 45,000 transactions, handling $16.4M in volume within just two months of its launch.
How Router’s Settlement Layer Fits into the CAKE Framework:
Router’s Settlement Layer complements the CAKE framework by providing a reliable infrastructure for transaction finality and clearing. While the CAKE framework’s Settlement Layer focuses on managing asynchronous settlements, and balancing security, speed, and execution guarantees, Router enhances this by ensuring every transaction is properly verified and that all involved parties receive their due compensation.
Besides, one key primitive to highlight here is the Forwarder Flow which offers a fast, secure, and cost-effective solution for cross-chain asset transfers. By leveraging a trustless optimistic approach, forwarders or solvers provide users with immediate access to assets on the destination chain, ensuring seamless transactions and once the transaction is validated and confirmed on Router chain, the forwarders can retrieve the equivalent value of assets.
This deferred settlement approach allows for instant user transactions, minimizes delays, and reduces costs, allowing users to experience efficient cross-chain swaps.
Router’s system acts as a safety net, verifying that transactions meet user expectations and that liquidity providers are reimbursed for their contributions. This structure ensures a streamlined, efficient, and trustworthy settlement process across multiple chains, integrating seamlessly into the CAKE framework’s broader vision of cross-chain transaction management.
Conclusion
At the end of the day, users just want things to be simple — simple ways to use products, simple ways to earn, and simple journeys that don’t involve endless headaches. That’s exactly what chain abstraction aims to solve, stripping away the complexity and delivering smooth, intuitive experiences. And it’s the same vision Router shares.
We’re all about making cross-chain operations as effortless as possible, fitting into the CAKE framework to give users that frictionless journey they crave. But we’re not stopping here. Router is committed to continuously bringing more features and products that align with this mission!!
