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 aren't 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 face 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 “per click” cost 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 the user expects, 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 future centered around rollup upgrades, or modularity, 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 WW3. These L2s are securely connected to L1s via canonical message paths, laying the foundation for a modular and interoperable network. Over the past four years, we have built fiber 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 results in 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 it is the dapp's responsibility to fulfill 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 as few steps as possible is to perform a series of transactions such as bridge → exchange → mint (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 at the depository of their choice, the user is 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 the 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 is relayed to the target side once the message’s “validity” has been verified.
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 agent 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 an order 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 user's 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 user's 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 based on 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 from the ground up to be secure
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 user's intent does not need to be submitted on-chain by the user if a Permit2 or EIP 3074 signature is included. This is true for both messaging and intent-based bridging. Both architectures can take advantage of the Permit2 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, which solvers can bid on. The winner of the auction can then receive the user's 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 user's Optimism wallet. Finally, the solver can fill the user's intent by sending the user WETH and forwarding the calldata to the user's 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.
Solvers’ 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.
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 user's 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 to coordinate to speak the same language, and competition will lead to 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 user’s 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 that put solver user experience first:
The standard is designed to make solvers' jobs easier. One of the opinionated choices it makes is to natively support Permit2/EIP3074 with nonce and initiateDeadline, and to provide fillers with some guarantees about the refund amount they will get from the settlement network, and the format of the user's intent that they can track. In addition, a initiate function is defined in the standard that allows fillers (the people who bring the order on-chain) to specify additional "fillerData" on-chain that is not known to the user when signing the CrossChainOrder. This allows fillers to ensure that they get rewarded by the settlement contract for submitting the user's meta transaction, and 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 of 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.
