Original article by Nick Pai, Archetype
Original translation: TechFlow
This post is divided into two parts. First, I explain why I believe chain abstraction infrastructure is critical to consumer adoption of cryptocurrencies, and that intent-based architecture is the best way to design it. Second, I describe the main barrier to widespread adoption of intent: the liveness of the solution network.
At the end of the article, I proposed a solution and introduced the standard developed by Across and Uniswap based on feedback from the CAKE working group. This standard aims to optimize the solution user experience, lower the barrier to entry to the general solution network, enable most intents to be routed to this network, and ultimately enable a larger and more competitive solution network to flourish.
Agenda
question:
Defining the end state: What makes a crypto application “usable”?
Why is “chain abstraction” the solution to the user experience problems created by the basic topology of modular blockchains?
Why must usable crypto applications be built on top of chain abstraction infrastructure?
Solution Space:
How Intent-Based Architecture Produces Chain Abstraction
Understand that intent marketplaces perform best when the solution network is large and competitive
Launching an intent-based solution network requires introducing more applications that will generate intent
proposal:
Why we need a cross-chain intent standard that prioritizes “solution user experience” to scale the solution and intent markets large enough to achieve network effects
Without chain abstraction, it is impossible to build usable crypto applications
Are our best and brightest building redundant infrastructure?
Many have complained that the best crypto engineers are overly focused on delivering more blockspace to end users. This criticism is valid; there are too many L2 solutions being delivered to end users relative to demand.
However, I refuse to accept the idea that there arent any useful applications for encryption.
Decentralized finance offers individuals the ability to self-custody their digital assets, allowing them to bypass demanding service providers and use their digital assets to purchase things of value in the real world. The promise of self-custody of data also offers a utopian alternative for individuals who have grown wary of trusting the FAANG monopoly to keep their data safe.
I believe the real problem is not the lack of useful crypto apps, but the friction end users experience when trying to access them. End users should experience the following when interacting with crypto apps:
Speed: Applications should feel as fast as web2 applications
Cost: Unlike web2, all web3 interactions must incur some cost, but the cost per click should be negligible
Censorship resistance (“permissionless”): Anyone with a wallet should be able to interact with the application, as long as they can afford the costs
Security: Clicks should complete the actions that users expect, should not be reversible, and all web3 updates should be permanent
These are the properties of usable cryptographic applications.
We have been trying to build usable encryption for a long time
Today’s modular blockchain solutions offer consumers all of these attributes, but they are not all available in the same place.
In 2020, blockchains are monolithic, providing two of three properties to end users: speed, cost, or security. We then envision a rollup-centric or modular future that unlocks all three properties simultaneously.
Today, we have laid the foundation for this rollup-centric infrastructure. L2 provides cheap and fast blockspace, and most L2s provide permissionless blockspace. In contrast, L1 provides secure blockspace that is resistant to WW 3 (you can read more about the tradeoffs between security and user experience provided by L1 and L2 in my article). These L2s are securely connected to L1 via canonical message paths, laying the foundation for a modular and interoperable network. Over the past four years, we have built optical fibers between blockchains that support useful crypto applications. But why are modular blockchains so unusable?
The inevitability of a modular blockchain network is that capital assets will aggregate on the most secure layer, while user clicks will aggregate on the faster and cheaper layers.
Modular blockchain topologies encourage secure blockspace to be provided on a different layer than cheap and fast blockspace. Users will naturally prefer to store their value on the most secure network, but they will demand frequent interactions with the cheap and fast networks. The canonical paths between L2 and L1 are slow and/or expensive by design. These phenomena explain why users must traverse these canonical paths, using L1 assets to pay for L2 interactions. This leads to an unusable crypto user experience.
The goal of chain abstraction is to reduce the friction for users to send value across these protocol paths. Chain abstractors assume that users prefer to specify their desired end state to dapps as intents, and dapps are responsible for fulfilling their intents. Users should not have to compromise the custody of secure assets in order to access low fees and low latency.
Therefore, the chain abstraction lies in the ability for users to transfer value across networks securely, cheaply, and quickly. A common user flow today is that a user with a USDC balance on a safe chain (such as Ethereum) wants to mint an NFT or exchange a new token on a new chain (such as Blast or Base). The way to perform this operation in the fewest steps possible is to perform a series of bridge → exchange → mint transactions (or exchange → bridge → mint) in sequence.
In this example, the user’s intent is to use their USDC on the secure chain to mint an NFT on another chain. As long as they receive the NFT and their USDC balance is deducted from the escrow of their choice, the user will be satisfied.
Intent-based architecture is the only way to build chain abstractions
Chain abstraction relies on cross-chain value transfer, but sending value through canonical message paths is either expensive or slow. Fast bridges provide users with cheap and fast alternatives to sending value across networks, but they introduce new trust assumptions. Messaging is the most intuitive way to build a fast bridge because it is modeled after the TCP/IP architecture; it relies on a bridge protocol that acts as a TCP router to connect two chains.
TCP/IP diagram from ResearchGate
Value transfer via messaging involves the bridge protocol sending messages between contracts on the origin and target chains. This message is triggered on the origin side by a user transaction, and once the validity of the message is verified, it is relayed to the target side.
A message can only be verified after the original chain transaction that initiated the message has been completed, that is, after the transaction has been permanently included in the canonical blockchain of the original chain. This verification can be done through a validity proof that the transaction has been included in the consensus of the original chain, or an optimistic proposal, or after a certain number of witness signatures have been accumulated on the original side. Once the message is relayed to the bridge contract on the target chain, the tokens are released to the user.
There are several fundamental problems with this architecture:
The verification mechanism must wait for full finality before sending the message to the target chain protocol contract. For L2 with optimistic finality, this can take up to seven days.
Each bridge transaction sends only one cross-chain message, or batches messages together, but the batch can only be sent after the last message in the batch is completed.
A bridge has limited ability to access external liquidity to provide price improvements to users because it must declare the fulfillment path of the user’s intent.
Fast bridging based on messaging will be insecure, slow, or expensive depending on the authentication mechanism. Intent marketplaces are an alternative architecture for fast bridging that stems from a key insight:
Value is fungible, and it doesn’t matter to the recipient how the value is transferred, as long as the funds are received
Can bridges outsource value transfers to a complex proxy to increase speed and reduce costs? Liquidity is dynamic on-chain and off-chain, and price improvements can be achieved if the bridge mechanism can flexibly choose the best execution path when bridging transfers.
The intent mechanism allows users to specify the precise conditions or contracts under which their value transfer transactions can be executed.
The most simplified intent is to pay X tokens from chain A to receive Y tokens on chain B.
Bridge protocols do not need to send messages between domains in order to satisfy the users cross-domain intent. Instead, the protocol outsources the transfer of value to agents selected from a network of permissionless solvers, and individual solvers will later seek repayment from the bridge protocol. In contrast, message-based mechanisms specify precisely how their transactions should be executed and do not need to rely on the availability of agents.
Intent to Settle Agreement
Intent-based bridge protocols can be more precisely labeled as intent settlement protocols, which are responsible for ensuring that solvers do not violate the conditions specified by the user. Intent settlement protocols provide guarantees to solvers to ensure that they can be reimbursed and rewarded when they fulfill the users intent. To do this, the intent settlement protocol needs to appeal to the Oracle to verify the authenticity of the intent fulfillment. The security of the oracle can be based on optimistic challenge periods, witness thresholds, or ZK validity proofs, etc.
Intent settlement protocols provide fast, low-cost value transfer because a single solver takes ultimate risk and determines the best execution path
A messaging bridge can only communicate when the original chain has reached finality. Today, finality times are seven days on Optimistic Rollup and one hour on ZK Rollup. While these finality times should drop with wider adoption of ZK light client technology and advances in shared sorter pre-confirmation technology, it is unlikely that finality times will ever feel “instant” to users for all blockchains, demonstrating the ongoing need for fast bridging solutions. Even if a bridge wanted to add an additional trusted agent in the relay path to vouch for losses due to chain reorganizations, it would not be possible to increase messaging speeds beyond the finality period without taking on finality risk.
The speedup provided by the intent-based architecture is because a single solver in a heterogeneous network of solvers can take on more finality risk than a messaging protocol and satisfy the user’s intent before the chain reorganization risk completely disappears. The solver then charges the user for the finality risk they took on in exchange for faster time.
Outsourcing cross-chain intent fulfillment to an agent will also improve prices for users on average. In intent-based bridging, solvers on the front end are paid back by the system after verifying their fulfillment in order to fulfill a user’s order on the target chain. These intent settlements can be batched together to amortize costs. Unlike users, fillers do not require immediate repayment and will charge users a funds front-end fee accordingly. Batched settlements are not the only feature of intent-based architectures, but the architecture is more synergistic with batched settlements because it separates the repayment step from the intent fulfillment step.
A larger source of price improvement comes from the intuition that value is fungible and finding the best path in time will generally outperform value transfer, however, some paths cannot be beaten in time in terms of cost, such as when transferring USDC over CCTP.
Messaging bridges must encode how they will transmit value to users. Some choose to send tokens from a liquidity pool at a predetermined exchange rate, while others mint representative tokens to recipients who then exchange the required canonical token asset.
In fulfilling user intent, agents can source liquidity from a combination of on-chain and off-chain liquidity venues. The competitive solver network theoretically provides users with unlimited sources of liquidity (but even these liquidity sources can be quickly exhausted in one-way trends during high-volatility on-chain events, such as popular NFT minting, airdrops, and rug pull events).
Once a cross-chain order is submitted as an intent, the solver can internalize the MEV generated by the order as a price improvement.
Intent-based architecture is designed to be secure from the ground up
Intent-based bridges can be built securely because they separate the urgent needs of users from the complex needs of the settlement network. Solvers can wait for reimbursement, unlike users, who will be charged based on the time the settlement protocol makes them wait for reimbursement. As a result, intent settlements can be verified using very robust mechanisms without strict time constraints. This is preferable from a security perspective, as verifying intent fulfillment is intuitively complex.
As an example of intent verification in production, Across batch verifies and reimburses fillers after a 90 minute optimistic challenge period. Of course, settlement networks should strive to reimburse fillers as quickly as possible to reduce fees for end users. An improvement to the optimistic challenge mechanism would be a ZK proof of validity mechanism, which would require encoding the intent verification logic into a ZK circuit. In my opinion, it is inevitable that a proof of verification mechanism will replace the optimistic challenge mechanism and enable intent settlement networks to reimburse users faster.
So, how does chain abstraction emerge from intent-based architecture?
Recall that chain abstraction requires fast and cheap cross-chain value transfer. It also should not require users to submit on-chain transactions on the network where their assets are stored.
The users intent does not need to be submitted on-chain by the user if a Permit 2 or EIP 3074 signature is included. This is true for both messaging and intent-based bridging. Both architectures can take advantage of the Permit 2 model, allowing users to sign the amount of tokens they are willing to pay offline on the origin chain wallet.
Intent-based marketplaces best support chain abstraction because they provide cheap and fast cross-chain value transfer. Imagine that a user can request a solver to provide them with a quote to enter a WETH collateral position on Arbitrum using their USDC on Optimism as payment. The user can send this intent to an RFQ auction, and solvers can bid on it. The winner of the auction can then receive the users signed intent, which contains a copy of the permission to spend their USDC on Optimism, the amount of WETH obtained on Arbitrum, and the calldata for depositing this WETH into the Arbitrum collateral position. The solver can then submit this transaction on Optimism (on behalf of the user) to initiate the cross-chain intent and withdraw USDC from the users Optimism wallet. Finally, the solver can fill the users intent by sending the user WETH and forwarding the calldata to the users on-chain collateral position.
Building chain abstraction infrastructure means making user processes feel instant and cheap without requiring them to submit on-chain transactions. Let’s end this article by discussing the barriers to wider adoption.
To achieve the best user experience from the intent-based chain abstraction, we need a competitive solver network
The key to achieving the best user experience with intent-based chain abstractions is to build a competitive solver network. Bridging intents depends on solver network effects to perform better than message passing variants. This is the core tradeoff between intent and message passing architectures. The reality is that not all applications generating intents need access to a fully competitive set of solvers, and some may prefer to have their intents routed to an oligopolistic solver network. However, the current state of solver networks is rudimentary and far from the solver network liveness assumptions that intent markets rely on.
We don’t want every DApp to route intents to an isolated network of solvers. The best user experience is when many DApps communicate with the same pool of solvers, and all DApps have the freedom to change the pool of solvers they send intents to.
How to bootstrap the solver network?
We must make solver user experience a top priority.
Running an intent solver is complex and requires expertise in building high-performance software as well as managing cross-chain inventory risk. Naturally, there will be a small number of parties interested in paying the startup costs of running this code. In the best case, a solver written for one DApp, like the UniswapX solver, can be reused to solve other intent-generating DApps, like Across and CowSwap.
We really need to improve the aggregate capital efficiency of the solver network for all intent-based DApps. This will require addressing the barriers to running solvers.
To do this, we need DApps that generate intents to be visible to any solver, and ensure that all solvers have access to multiple differentiated and competitive intent settlement networks. This will give solvers confidence that they can choose to route their intent fulfillment to a settlement network they trust. Competition between settlement networks will also reduce costs for solvers.
The value proposition of the Intent Settlement Network is to provide security to solvers as well as other features that may influence solvers to fill intents.
A solver’s choice of intent settlement network will impact their ability to offer fee and execution time guarantees to users. Some settlement networks may offer solver exclusivity periods, which will support the development of off-chain auctions where solvers and users can negotiate and commit to relay fees. (Additionally, these intent auctions may also offer financially guaranteed pre-confirmations, further enhancing the user experience. To understand the user flow of intent discovery with auctions and pre-confirmations, I recommend this talk by Karthik from Sorella)
Some settlement networks may offer intent expiration (i.e., sending value back to the user after a certain fulfillment deadline has been reached), intent backing (i.e., the settlement network uses its own balance sheet to fulfill the users intent if no solver fulfills), or flexible repayment chains (i.e., allowing solvers to choose the chain of their choice for repayment).
Ultimately, settlement networks will compete fiercely to reimburse solvers quickly and cheaply without compromising on security. Solvers, in turn, will send their order flow to the settlement network that allows them to offer the cheapest fees to users in order to win order flow for DApps. Competition among settlement and solver networks depends on all parties in the intent supply chain coordinating to speak the same language, and competition will result in the best user experience for cross-chain value transfers.
Clearly, we need a cross-chain intent standard
If solvers can assume that intents will share common elements, then they can reuse their code to solve intents initiated by different DApps, reducing their setup costs. If different DApps create intents that meet the same criteria, then they can all route their intents to the same pool of solvers. This will help provide access to the next generation of DApps by enabling them to directly plug their cross-chain intents into the existing pool of mature solvers without having to plug in solvers individually, and will get cheap, fast, secure, and permissionless value transfer.
It will also be easier for third-party tracking software to track the intended state of any new DApp if it complies with the standards.
This intent standard should allow intent subjects or solvers to specify on which settlement network they wish to settle their intent.
I envision competing settlement protocols like SUAVE, Across, Anoma, and Khalani offering different features to solvers. Solvers can offer different prices and time guarantees to intent owners depending on which settlement network is reimbursing the solver. DApps and solvers can agree to route a users intent to a settlement network they trust to avoid censorship, maintain data privacy, and also be secure enough for solvers to trust for repayment.
By writing the choice of settlement network into the intent order itself, solvers can build this certainty into the quotes they present to users. Solvers and users can reduce costs by removing upfront uncertainty about bridge pricing before submitting intents on-chain.
In collaboration with Uniswap and based on feedback from the CAKE working group, Across and I proposed the following cross-chain intent standards to put solver user experience first:
The standard is designed to make solvers jobs easier. One of the smart choices it makes is to natively support Permit 2/EIP 3074 with nonce and initiateDeadline, and to provide some guarantees to fillers, such as the refund amount they will get from the settlement network, and the format of the users intent that they can track. In addition, a initiate function is defined in the standard that allows fillers (people who bring orders on-chain) to specify additional fillerData on-chain that is unknown to the user when signing the CrossChainOrder. This allows fillers to ensure that they receive rewards from the settlement contract for submitting the users meta transaction, and can also set repayment specific information such as the repayment chain.
This standard is also intended to make it easier for DApps to track intent fulfillment status. Any settlement contract implementing this standard should create a custom subtype ResolvedCrossChainOrder that can be resolved from an arbitrary orderData field. This may include the tokens involved in the exchange, the target chain, and other fulfillment constraints. A resolve function is included in the standard so that DApps can understand how to display the intent status to the user, as well as for solvers to know the exact intent order structure they are dealing with.
The design goal of this standard is to enhance the solver user experience, making it easier for them to support multiple settlement networks and calculate their rewards deterministically. I believe this will enable them to provide more accurate and compact quotes to their users. You can read more details in this post and in the discussion on the Ethereum Magicians forum about this standard, named ERC 7683.
Conclusion
“Intents” are confusing because they are not defined, and this lack of definition is causing real UX flaws.
Everyone wants everyone else to use their standard definition of intent, so I fully acknowledge that standards are impossible to establish in practice. I think defining the intent to settle a system first and then trying to attract order flow is the right approach to establishing industry standards.
A more feasible approach, in my opinion, is that DApps that already have a lot of user traffic and generate a lot of user intent will agree to conform to some minimum standards, which will be adopted by their existing solvers. This will form a new, larger pool of solvers. By capturing the combined order flow from already prominent venues, this new pool of solvers will make more profit and be able to offer better prices to end users. Eventually, new DApps will also require that their intents be routed to this pool of solvers and support its intent standards.
To kickstart this process, Across and Uniswap have jointly proposed a standard that all intent supply chain participants use when processing user orders to send X tokens from chain A and receive Y tokens on chain B. Order flows running through UniswapX (which has comparative advantages in auction design and intent origination) and Across (which has comparative advantages in settlement intent fulfillment) can be merged, kicking off the process of fostering a larger, more competitive network of solvers.
