Archetype
Over 100 subscribers
Written by Nick Pai
This post is divided into two sections. First, I describe my belief that chain abstraction infrastructure is vital for consumer adoption of crypto and that intent-based architecture is the best way to engineer it. Second, I describe the main obstacle toward broader adoption of intents: solver network liveness.
I end the piece with a solution and introduce the standard that Across and Uniswap have collaborated on, using feedback derived from the CAKE working group. This standard is designed to optimize for the solver UX, lower barriers to entry to a universal solver network that most intents can be routed to, and ultimately enable a larger, more competitive solver network to flourish.
0. Defining the end state: what makes crypto applications "usable"
1. Why "chain abstraction" is a solution to a UX problem that arises out of the fundamental topology of modular blockchains
2. Why usable crypto applications must be built on top of chain abstraction infrastructure
3. How intent-based architecture will give rise to chain abstraction
4. Understanding that intent marketplaces perform best when the solver network is large and competitive
5. Bootstrapping the intent solver network requires onboarding more applications that will produce intents
6. Why we need a cross-chain intents standard that prioritizes "solver UX" to grow the solver and intent marketplace to large enough scale to achieve network effects
Are our best and brightest building redundant infra?
Many have lamented that the best crypto engineers and most based thinkers are overallocating attention and energy toward offering more blockspace to end users. This criticism has merit; there are too many L2s available for end users relative to the demand for them.
However, I reject the notion that there aren’t any useful crypto applications in existence.
Decentralized finance offers individuals the ability to self-custody digital assets, allowing them to work around draconian service providers and use their digital assets to buy things valued in the real world. The promise of self-custodied data also offers a utopian alternative for individuals that are becoming increasingly wary of trusting FAANG monopolies to keep their data secure.
The real problem in my opinion is not lack of useful crypto applications but friction for end users trying to access them. End users should be able to experience the following when interacting with crypto applications:
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-ness"): Anyone with a wallet should be able to interact with the application if they can afford to click.
Security: Clicks should do what users expect them to do and not revert—all web3 updates should be permanent.
These are the properties of "usable" crypto applications.
Today’s modular blockchain solutions offer consumers all of these properties, but they are not all available in the same place.
In 2020, blockchains were monolithic, offering two of three properties to end users: speed, cost, or security. We then envisioned a rollup-centric or modular future that would unlock all three properties simultaneously.
Today, we have built the groundwork for this rollup-centric infrastructure. L2s offer cheap and fast blockspace, and most of them offer permissionless blockspace. Conversely, L1 offers WW3-resistant, secure blockspace. (You can read more about the security-UX tradeoff offered by L1s and L2s in my short survey article). These L2s connect securely to L1 via canonical message paths, laying the foundation for a modular yet interoperable network. In the past four years, we've built the optical fiber between blockchains that will one day support useful crypto applications. But why are modular blockchains so unusable?
The inevitability of modular blockchain networks is that capital assets will accrue at the most secure layers while user clicks will accrue at the faster and cheaper layers.
Modular blockchain topology encourages secure blockspace to be offered on a different layer than cheap and fast blockspace. Users will naturally prefer to store their value on the most secure networks, but they will demand to interact most frequently with the cheap and fast ones. By design, the canonical paths between L2s and L1 are slow and/or expensive. These phenomena explain why users must traverse these canonical pathways to pay for L2 interactions using L1 assets. This results in "unusable" crypto UX.
The goal of chain abstraction is to reduce the friction of sending value across these in-protocol paths away from the user. Chain abstractors assume that users prefer to specify their desired end state to dapps as "intents" and it is the responsibility of the dapp to fulfill their intents. Users should not have to compromise secure custody of their assets in order to access low fees and low latency.
Therefore, chain abstraction depends critically on users being able to transfer value across networks securely, cheaply, and quickly. A common user flow today is that a user with a USDC balance on a "secure" chain like Ethereum wants to mint an NFT or swap for new tokens on a newer chain like Blast or Base. The way to do this in as few steps as possible is to sequentially execute a Bridge→Swap→Mint series of transactions (or Swap→Bridge→Mint).
In this example, the user's intent is to use their USDC on the secure chain to mint an NFT on another chain. The user will be satisfied as long as they receive the NFT and their USDC balance is charged wherever they choose to custody.
Chain abstraction relies on cross-chain value transfer, but sending value via canonical messaging paths is either expensive or slow. "Fast bridges" offer cheap and fast alternatives for users to send value across networks, but they introduce new trust assumptions. Message passing is the most intuitive way to build a fast bridge because it is modeled off of the TCP/IP architecture; it relies on a bridge protocol acting as the TCP Router to connect two chains.
Value transfer via message passing involves the bridge protocol sending messages between its contracts on the origin and destination chains. This message is triggered on the origin side by a user transaction and relayed to the destination side once the message's "validity" is verified.
A message can only be verified after the origin chain transaction initiating the message has finalized, meaning the transaction is permanently included in the origin chain’s canonical blockchain. This verification can be completed as a validity proof proving consensus inclusion of the transaction on the origin chain, as an optimistic proposal, or after a threshold of witness signatures attesting to its inclusion have accumulated on the origin side. Once the message is relayed to the bridge contract on the destination chain, tokens are released to the user.
There are several fundamental issues with this architecture:
The verification mechanism must wait for full finality before sending the message to the destination chain protocol contract. This can take up to seven days for L2s with optimistic finality periods.
One cross-chain message is sent per bridge transaction OR messages are batched together, but the batch can only be sent after the last message in the batch is finalized.
The bridge has limited ability to source external liquidity to give user price improvements because it must be declarative about the fulfillment path of the user intent.
Message-passing fast bridges are going to be either unsecure, slow, or expensive depending on the verification mechanism. Intent marketplaces are an alternative architecture for fast bridging that arise from a key insight:
Can a bridge outsource the value transfer to a sophisticated agent to gain speed and lower cost? Liquidity is dynamic on and offchain and price improvement can be realized if the bridge mechanism has flexibility to choose an optimal execution path at the time of the bridge transfer.
Intent mechanisms allow users to specify precise conditions or covenants under which their value transfer transaction can be executed.
A minimal viable intent is an order to pay X token from chain A to receive Y token on chain B.
The bridge protocol does not need to send a message between domains per bridge transaction to fulfill a user's cross-domain intent. Instead, the protocol outsources the value transfer to an agent drawn from a permissionless solver network, and the individual solver will seek repayment later from the bridge protocol. In comparison, message-passing mechanisms specify exactly how their transactions should be executed and do not need to rely on the availability of an agent.
Intent-based bridge protocols can be labeled more precisely as intent settlement protocols that are responsible for ensuring that solvers do not violate the user-specified conditions. Intent settlement protocols offer solvers security that they will be repaid and rewarded for fulfilling user intents. To do so, intent settlement protocols need to appeal to an oracle to verify the authenticity of the intent fulfillment. The oracle's security can be grounded in an optimistic challenge period, a witness threshold, or be ZK validity proof based, for example.
Message-passing bridges can only communicate as quickly as finality is reached by the originating chain. Finality times are seven days on optimistic rollups and one hour on ZK rollups today. Even though these finality times should trend down following broader adoption of ZK light client technology and advancements in shared-sequencing pre-confirmation technology, it is unlikely that finality times for all blockchains will ever feel "instant" for users, suggesting a persistent need for fast bridging solutions. It is impossible to relay a message faster than the finality period without assuming finality risk—which is outside the scope of a message-passing bridge—unless the bridge wants to add an additional trusted agent to the relay path who will backstop losses due to chain reorganizations.
The speedup offered by intent-based architecture arises because individual solvers within a heterogenous solver network can assume more finality risk than a message-passing protocol can and fill a user's intent before chain-reorg risk completely disappears. Solvers will subsequently charge users for this finality risk they assume in exchange for faster fill times.
Outsourcing cross-chain intent fulfillment to an agent also leads to price improvement on average for users. In intent-based bridges, solvers who front user orders on the desired destination chain are repaid later by the system after their fulfillment is validated. These intent settlements can be batched together to amortize cost. Fillers, unlike users, do not demand instant repayment and will charge users accordingly for fronting them capital. Batch settlement is not unique to intent-based architecture, but the architecture is more synergistic with batch settlement because it separates the repayment step from the intent fulfillment step.
The larger source of price improvement comes from the intuition that value is fungible, and finding the best path just-in-time will usually outperform value transfer. (However, some paths will be impossible to beat on cost just-in-time, like when bridging USDC over CCTP.)
Message-passing bridges must encode how they will transfer value to the user. Some elect to send tokens out of a liquidity pool at a predetermined exchange rate, while others mint representative tokens to recipients who need to then swap for the desired canonical token asset.
When fulfilling a user's intent, an agent can source liquidity from a combination of onchain and offchain liquidity venues. Competitive solver networks offer users unlimited sources of liquidity in theory (but even these sources of liquidity can be depleted quickly when volume trends in one direction during high volatility onchain events like popular NFT mints, airdrops, and rug pulls).
Submitting a cross-chain order as an intent allows solvers to internalize the order's generated MEV as price-improvement.
Intent-based bridges can be built securely because they separate the urgent demands of the user from the complex demands of the settlement network. Solvers can wait for repayment, unlike users, and they will charge users for the amount of time that the settlement protocol makes them wait for repayment. Therefore, intent settlements can be validated using very robust mechanisms without a strict time constraint. This is preferable from a security standpoint because verifying an intent fulfillment is intuitively complex.
As an example of intent verification in production, Across validates and repays fillers in batches following a 90-minute optimistic challenge period. Of course, settlement networks should strive to repay fillers as quickly as possible to reduce end user fees. An improvement on the optimistic challenge mechanism would be a ZK validity proof mechanism, which would require encoding the intent validation logic into a ZK circuit. In my opinion, it’s an inevitability that validity proving mechanisms will replace optimistic challenge mechanisms and enable intent settlement networks to repay users faster.
Recall that chain abstraction requires fast and cheap cross-chain value transfer. It also shouldn't require the user to submit an onchain transaction on the network where their assets are stored.
A user's intent does not need to be submitted onchain by the user if it includes a Permit2 or EIP3074 signature. This is true for both message-passing and intent-based bridges. Both architectures can take advantage of the Permit2 pattern to allow the user to sign offchain the amount of tokens that they are willing to pay from their origin chain wallet.
Intent marketplaces best support chain abstraction because they offer cheap and fast cross-chain value transfer. Imagine a world where a user could request a solver to give them a quote to enter into a WETH staking position on Arbitrum, using their USDC on Optimism as payment. The user could send this intent offchain to an RFQ auction where solvers could bid on it. The winning solver of the auction could then receive the user’s signed intent, containing an allowance to spend their USDC on Optimism, their desired amount of WETH to receive on Arbitrum, and the calldata needed to deposit this WETH into a staking position on Arbitrum. The solver could subsequently submit this transaction on Optimism (on behalf of the user) to initiate the cross-chain intent and pull USDC from the user’s Optimism wallet. Finally, the solver could fill the user’s intent on Arbitrum by sending them WETH and forwarding the calldata to enter the user into the onchain staking position.
Building chain abstraction infrastructure means making this user flow feel instantaneous and cheap without requiring them to submit an onchain transaction. Let's conclude this article by discussing obstacles to broader adoption of intents.
Bridging with intents depends on solver network effects to perform better than message-passing variants. This is the core tradeoff of intent versus message-passing architectures. Realistically, not all applications producing intents will need access to a perfectly competitive set of solvers, and some might prefer routing their intents to oligopolistic solver networks. However, the current state of solver networks is immature and isn't close to fulfilling the assumptions of solver network liveness that intent marketplaces depend on.
We don't want a world where each dapp is routing intents to isolated solver networks. The best case for UX is that many dapps communicate with the same solver pools, and all dapps have the freedom to change which solver pools they send their intents to.
We must prioritize solver UX.
Running an intent solver is complicated and requires expertise in building highly performant software as well as managing cross-chain inventory risk. Naturally, there will be limited parties interested in paying the startup cost to run this code. In the best case scenario, a solver written for one dapp, like a UniswapX solver, could be reused to solve for other intent-producing dapps like Across and CowSwap.
We really need to increase the aggregate capital efficiency of the solver network for all intent-based dapps. This will require addressing the barriers to running a solver.
For this, we'll need dapps producing intents to be visible to any solver and ensure all solvers have access to many differentiated and competitive intent settlement networks. This would give confidence to solvers that they could choose to route their intent fulfillments to a settlement network that they trust. The competition between settlement networks would also lower costs for solvers.
The value proposition of intent settlement networks is offering security to solvers as well as other features that would affect the solver's ability to fill an intent.
The solver's choice of intent settlement network will affect their ability to offer fees and execution-time guarantees to users. Some settlement networks might offer solver exclusivity periods, which would support the development of offchain auctions where solvers and users could negotiate and commit to relay fees. (These intent auctions might moreover offer economically bonded pre-confirmations, further enhancing UX. To learn more about a user flow featuring intent discovery via auctions and pre-confirmations I recommend this talk by Karthik of Sorella.)
Some settlement networks might offer intent expiry (i.e., sending value back to users after some fulfillment deadline is passed), intent backstopping (i.e., the settlement network using its own balance sheet to fulfill a user's intent if no solver does), or flexible repayment chain (i.e., allowing the solver to get repaid on their chain of choice).
In the end, settlement networks will compete ferociously to repay solvers quickly and cheaply without compromising on security. In turn, solvers will send their orderflow to the settlement networks that allow them to offer the cheapest fees to users so that they can win the dapp orderflow. Competition in settlement and solver networks depends on all parties in the intent supply chain coordinating to speak the same language, and competition will lead to the best UX for cross-chain value transfer.
If solvers can assume that intents will share common elements, then they can reuse their code to solve intents originated by different dapps and subsequently lower their setup costs. If different dapps create intents that conform to the same standard, then they can all route their intents to the same solver pools. This would help onboard the next generation of dapps by giving them the ability to plug their cross-chain intents directly into an existing and mature solver pool. New dapps would not have to individually onboard solvers and, instead, would get access to cheap, fast, secure, and permissionless value transfers.
Third party tracking software would also be more easily able to track intent statuses for any new dapp if they conform to a standard.
I envision competing settlement protocols like SUAVE, Across, Anoma, and Khalani offering differentiated features to intent solvers. Depending on which settlement network is repaying the solver, the solver can offer different price and time guarantees to the owner of the intent. The dapp and solver could agree to route a user's intent to a settlement network they trust to avoid censorship, maintain data privacy, and also be secure enough to be trusted to repay the solver.
By enshrining the choice of settlement network into the intent order itself, the solver could bake this certainty into the quote that they would show to the user. The solver and user would eliminate upfront uncertainty about bridge pricing before submitting the intent onchain, reducing costs.
/// @title CrossChainOrder type /// @notice Standard order struct to be signed by swappers, disseminated to fillers, and submitted to settlement contracts struct CrossChainOrder { /// @dev The contract address that the order is meant to be settled by. /// Fillers send this order to this contract address on the origin chain address settlementContract; /// @dev The address of the user who is initiating the swap, /// whose input tokens will be taken and escrowed address swapper; /// @dev Nonce to be used as replay protection for the order uint256 nonce; /// @dev The chainId of the origin chain uint32 originChainId; /// @dev The timestamp by which the order must be initiated uint32 initiateDeadline; /// @dev The timestamp by which the order must be filled on the destination chain uint32 fillDeadline; /// @dev Arbitrary implementation-specific data /// Can be used to define tokens, amounts, destination chains, fees, settlement parameters, /// or any other order-type specific information bytes orderData; }
This standard is designed to make a solver’s job easier. One opinionated choice it makes is supporting Permit2/EIP3074 natively with the nonce and initiateDeadline and it gives fillers some guarantees, such as the amount they will be refunded from the settlement network and the format of the user intent that they can track. Moreover, an initiate function is defined in the standard that crucially allows the filler, the one who will bring the order onchain, to specify additional “fillerData” onchain that the user would not have known about at the time that they signed the CrossChainOrder. This allows the filler to make sure that they are rewarded by the settlement contract for submitting the user’s meta-transaction and also set repayment specific information such as repayment chain.
This standard is also designed to make it easier for dapps to track intent fulfillment status throughout its lifecycle. Any settlement contract implementing this standard should create a custom sub-type ResolvedCrossChainOrder that can be parsed from the arbitrary orderData field. This may include information such as the tokens involved in the swap, the destination chain(s), and other fulfillment constraints. A resolve function is included in the standard to enable dapps to understand how to display intent statuses to users and for solvers to know the exact intent order structure they are working with.
/// @title ResolvedCrossChainOrder type /// @notice An implementation-generic representation of an order /// @dev Defines all requirements for filling an order by unbundling the implementation-specific orderData. /// @dev Intended to improve integration generalization by allowing fillers to compute the exact input and output information of any order struct ResolvedCrossChainOrder { /// @dev The contract address that the order is meant to be settled by. address settlementContract; /// @dev The address of the user who is initiating the swap address swapper; /// @dev Nonce to be used as replay protection for the order uint256 nonce; /// @dev The chainId of the origin chain uint32 originChainId; /// @dev The timestamp by which the order must be initiated uint32 initiateDeadline; /// @dev The timestamp by which the order must be filled on the destination chain(s) uint32 fillDeadline; /// @dev The inputs to be taken from the swapper as part of order initiation Input[] swapperInputs; /// @dev The outputs to be given to the swapper as part of order fulfillment Output[] swapperOutputs; /// @dev The outputs to be given to the filler as part of order settlement Output[] fillerOutputs; } /// @notice Tokens sent by the swapper as inputs to the order struct Input { /// @dev The address of the ERC20 token on the origin chain address token; /// @dev The amount of the token to be sent uint256 amount; } /// @notice Tokens that must be receive for a valid order fulfillment struct Output { /// @dev The address of the ERC20 token on the destination chain /// @dev address(0) used as a sentinel for the native token address token; /// @dev The amount of the token to be sent uint256 amount; /// @dev The address to receive the output tokens address recipient; /// @dev The destination chain for this output uint32 chainId; }
A compliant settlement contract implementation MUST implement the ISettlementContract interface:
/// @title ISettlementContract /// @notice Standard interface for settlement contracts interface ISettlementContract { /// @notice Initiates the settlement of a cross-chain order /// @dev To be called by the filler /// @param order The CrossChainOrder definition /// @param signature The swapper's signature over the order /// @param fillerData Any filler-defined data required by the settler function initiate(CrossChainOrder order, bytes signature, bytes fillerData) external; /// @notice Resolves a specific CrossChainOrder into a generic ResolvedCrossChainOrder /// @dev Intended to improve standardized integration of various order types and settlement contracts /// @param order The CrossChainOrder definition /// @param fillerData Any filler-defined data required by the settler /// @returns ResolvedCrossChainOrder hydrated order data including the inputs and outputs of the order function resolve(CrossChainOrder order, bytes fillerData) external view returns (ResolvedCrossChainOrder); }
The design goals of this standard were to enhance solver UX, make it easier for them to support multiple settlement networks, and deterministically compute their rewards. I believe that this will allow them to give more accurate and tighter quotes to users. You can read more details about this standard, code-named ERC7683, in this X/Twitter post and the discussion surrounding it on the Ethereum Magicians forum.
"Intents" are confusing because they are not defined, and this lack of a definition is creating real UX defects.
Everyone wants everyone else to use their standard definition of an intent, so I fully acknowledge that standards are practically impossible to establish. I don’t think that defining an intent settlement system first and trying to attract orderflow second is the right approach to establishing an industry-wide standard.
In my opinion, the more tractable approach is for dapps that already own a lot of user flow and originate many user intents will agree to conform to some minimal standard that their existing solvers will adopt. This will form a new and larger solver pool. By getting access to merged orderflow from already prominent venues, this new solver pool will earn more profits and be able quote better prices to end users. Eventually, newer dapps will also demand to route their intents to this solver pool and will support its intent standard.
To get us kickstarted, Across and Uniswap are jointly proposing a standard for all intent supply chain parties to use when handling user orders to send X tokens from chain A and receive Y tokens on chain B. The orderflow running through UniswapX (having a comparative advantage in auction design and originating intents) and Across (having a comparative advantage in settling intent fulfillments) can merge and kick off the process of nurturing a larger, more competitive solver network.
This article was inspired by many IRL and online discussions with the following folks building actively within the intents supply chain:
Ankit Chiplunkar from frontier.tech, Mark Toda, Alice Henshaw, and Emily Williams from Uniswap, Arjun Chand from Li.Fi, Karthik Srinivasan from Sorella, Kevin Wang from Khalani, tumilet from The Spartan Group, Matt Rice, Ryan Carmen and Hart Lambur from Across, Benjamin Funk and Dmitriy Berenzon from Archetype, Will Kantaros from Decent, and Francesco from Flood.
Finally, the ideas in this article are summarized in the following ETH Denver talks that Hart Lambur and I gave:
https://www.youtube.com/watch?v=S3WV_eBF45w
Disclaimer:
This post is for general information purposes only. It does not constitute investment advice or a recommendation or solicitation to buy or sell any investment and should not be used in the evaluation of the merits of making any investment decision. It should not be relied upon for accounting, legal or tax advice or investment recommendations. You should consult your own advisers as to legal, business, tax, and other related matters concerning any investment or legal matters. Certain information contained in here has been obtained from third-party sources, including from portfolio companies of funds managed by Archetype. This post reflects the current opinions of the authors and is not made on behalf of Archetype or its affiliates and does not necessarily reflect the opinions of Archetype, its affiliates or individuals associated with Archetype. The opinions reflected herein are subject to change without being updated.
