Explain the new protocol ERC7683: Uniswap and Across's joint development of a new standard for cross-chain intent

By Nick Pai, Archetype

Compiler: Deep Tide TechFlow

This article is divided into two parts. First, I elaborated on what I think chain abstraction infrastructure is critical to consumer adoption of Crypto Assets, and that intent-based architecture is the best way to design it. Second, I described the main obstacle to the intention of widespread adoption: the liveliness of the solution network.

At the end of the article, I propose a solution and introduce a standard developed in collaboration between Across and Uniswap, which is based on feedback from the CAKE Working Group. The purpose of this standard is to optimize the solution user experience, drop the barrier to entry into a common solution network, so that a large long number of intents can be routed to this network, and ultimately enable a larger, more competitive solution network to flourish.

Agenda

Problem:

1. Define the end state: What makes an encryption app "usable"?
2. Why is "chain abstraction" the solution to the user experience problems arising from the basic topology of modular blockchains?
3. Why do available encryption applications have to be built on top of the chain abstraction infrastructure?

Solution shorter:

1. How Intent-Based Architecture Produces Chain Abstraction
2. Understand that the intent market performs best when the solution network is large and competitive
3. Launching an Intent Solution Network requires the introduction of more long apps that will generate intent

Proposal:

1. Why we need a cross-chain intent standard that prioritizes "solution user experience" to scale the solution and intent marketplace large enough to enable network effects

Without chain abstraction, you can't build usable encryption apps

Are our best and Satoshi people building more than long infrastructure?

long people complain that the best encryption engineers are overly focused on providing more long Block short to the end user. This criticism is justified; there are longing L2 solutions for end users relative to demand.

However, I refuse to accept the idea that no useful encryption application exists. **

DeFi provides individuals with the ability to self-custody their digital assets, allowing them to bypass harsh service providers and use their digital assets to buy things that are valuable in the real world. The commitment to self-custody of data also provides a utopian alternative for individuals who are increasingly concerned about trusting the FAANG (an acronym for the five most popular and best-performing tech stocks in the U.S. market) monopoly to keep their data safe.

In my opinion, the real problem is not the lack of useful encryption apps, but the friction when end users try to access them. End users should experience the following when interacting with an encryption app:

• Speed: The app should feel as fast as a web2 app
• Cost: Unlike Web2, all Web3 interactions must incur some cost, but the cost per click should be insignificant
• Censorship resistance ("permissionless required"): Anyone with a wallet should be able to interact with the app as long as they can afford the fee
• Security: Clicks should complete the user's desired action, should not be undone, and all web3 updates should be permanent

These are the properties of the "available" encryption app.

We've been trying to build usable encryption for a long time

Today's modular blockchain solutions provide consumers with all of these attributes, but they are not all available in the same location.

In 2020, Blockchain is monolithic, offering two of three attributes to the end user: speed, cost, or security. We then envisioned a rollup-centric or modular future that unlocks all three attributes at the same time.

Today, we've laid the groundwork for this rollup-centric infrastructure. L2 offers cheap and fast Block short rooms, while long L2 offers license-free Block short rooms. Conversely, L1 provides a security Block short room against WW3 (you can read more about long trade-off between the security provided by L1 and L2 and the user experience in my article). These L2s are securely connected to L1 via a canonical message path, laying the foundation for a modular and interoperable network. Over the past four years, we've built fiber optics between blockchains that support useful encryption applications. But why are modular blockchains so unavailable?

The inevitability of modular blockchain networks is that capital assets will be clustered on the most secure layer, and user clicks will be clustered on a faster and cheaper layer. **

The modular Blockchain topology encourages secure Block short rooms to be provided on a different layer than cheap and fast Block short rooms. Users will naturally tend to store their value on the most secure network, but they will demand frequent interaction with cheap and fast networks. By design, the canonical path between L2 and L1 is slow and/or expensive. These phenomena explain why users must traverse these canonical paths and pay for L2 interactions using L1 assets. This results in an "unusable" encryption user experience.

The goal of chain abstraction is to reduce the friction of users sending value through these protocol paths. Chain abstractors assume that users are more inclined to assign their desired end state to the dapp as the "intent", and that the dapp is responsible for implementing their intent. Users should not compromise the custody of secure assets for the sake of low fees and low latency for access.

Therefore, the chain abstraction lies in the ability of 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 "secure" on-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 do this in as few steps as possible is to perform a sequential bridge→ exchange →minting a series of transactions (or exchange →bridge→minting).

In this example, the user's intent is to use their USDC in the security on-chain to on-chain minting one NFT another. Users will be satisfied as long as they receive the NFT and their USDC balance is deducted at the depository location of their choice.

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 a cheap and fast alternative 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 on a TCP/IP architecture; it relies on a bridge protocol to act as a TCP router to connect the two chains.

ResearchGate's TCP/IP chart

A message can only be verified after the original chain transaction originating the message has been completed, that is, the transaction has been permanently included in the canonical Blockchain of the original chain. This verification can be done through a validity proof, proving that the transaction has been included in the consensus of the original chain, or by an optimistic proposal, or after accumulating a certain number of witness signatures on the original side. Once the message is relayed to the bridge contract on the target on-chain, the tokens are released to the user.

There are several fundamental problems with this architecture:

• The validation mechanism must wait for full determinism before sending the message to the target chain protocol contract. For L2 with an optimistic determination period, 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.
• Bridges have limited ability to access external liquidity to provide price improvements to users because it must declare a fulfillment path of user intent.

Fast messaging-based bridges can be insecure, slow, or expensive depending on the verification mechanism. The Intent Marketplace is a rapidly bridged alternative architecture 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 can be received

Can bridge outsource value transfer to a complex agent to increase speed and drop costs?Liquidity on-chain and off-chain are dynamic, and price improvements can be achieved if the bridge mechanism has the flexibility to choose the best execution path when bridge 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 Token from Chain A to receive an order for Y Token on Chain B.

bridge protocol don't need to send messages between domains in order to satisfy the user's cross-domain intent. Instead, protocol outsource the transfer of value to an agent selected from a network of unlicensed solvers, and individual solvers will later seek repayment from bridge protocol. In contrast, messaging-based mechanisms specify precisely how their transactions should be executed and do not need to rely on the availability of the broker.

Intent Settlement protocol

Intent-based bridge protocol can be more precisely labeled as intent Settlement protocol, and they are responsible for ensuring that the solver does not violate user-specified conditions. Intent Settlement protocol provides a safeguard for solvers, ensuring that they are repaid and rewarded for fulfilling the user's intent. For this purpose, the intent Settlement protocol needs to appeal to Oracle to verify the authenticity of the intent fulfillment. Oracle Machine security can be based on optimistic challenge periods, witness thresholds, or ZK validity proofs, etc.

Intent Settlement protocol provide fast, low-cost value transfer as a single solver takes the ultimate risk and determines the best execution path**

Messaging bridges can only communicate when the original chain has reached finality. Today, the finality time on the Optimistic Rollup is seven days, while on the ZK Rollup it is one hour. While these finality times should decline with the widespread adoption of ZK light client technology and advances in shared sequencer preconfirmation technology, it is never possible for all blockchains to feel "instantaneous" to users, indicating the ongoing need for fast bridges solutions. Without risking finality, even if the bridge wants to add an additional trusted agent to the relay path to guarantee losses due to chain reorganization, it will not be able to increase the message delivery speed before the finality period.

The acceleration provided by an intent-based architecture is because a single solver in a heterogeneous solver network can take a more long finality risk than the messaging protocol and satisfy the user's intent before the chain reorganization risk disappears completely. The solver then charges the user for the finality risk they would have taken at the faster time of the exchange.

Outsourcing cross-chain intent fulfillment to proxies will also improve prices for users on average. In an intent-based bridge, in order to fulfill the user's order on the target on-chain, the solver on the front-end will be returned by the system after verifying their fulfillment. These intent settlements can be batched together to spread costs. Unlike the user, the filler does not require immediate repayment and will charge the user a funding upfront fee accordingly. Batch Settlement is not the only feature of an intent-based architecture, but it is more synergistic with Batch Settlement 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 that finding the best path in time is often better than value transfer, however, there are some paths that cannot be beaten in time in terms of cost, such as when transferring USDC on CCTP.

Messaging bridges must encode how they will deliver value to users. Some choose to send Tokens from the liquidity pool at a predetermined exchange rate, while others mint representative Tokens to recipients who need to subsequently exchange the required canonical Token assets.

When fulfilling user intent, agents can obtain liquidity from a combination of liquidity venues on-chain and off-chain. Competing solver networks theoretically provide users with an infinite number of Liquidity sources (but even these Liquidity sources can be rapidly exhausted in a one-way trend during high-Fluctuation on-chain events, such as popular NFT minting, Airdrop, and rug pull events).

After submitting a cross-chain order as an intent, the solver internalizes the MEV generated by the order as a price improvement.

Intent-based architecture is fundamentally designed 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 repayment, unlike users, who will charge users based on how long Settlement protocol keep them waiting for repayment. Therefore, intent settlement can be verified using a very robust mechanism without strict time constraints. This is preferable from a security standpoint, as validating intent implementation is intuitively complex.

So, how does chain abstraction emerge from intent-based architecture?

Recall that chain abstraction requires fast and cheap cross-chain value transfer. It should also not require users to submit on-chain transactions on the network where their assets are stored.

If a Permit2 or EIP 3074 signature is included, the user's intent does not need to be submitted by the user on-chain. This is true for both messaging and intent-based bridges. Both architectures can take advantage of the Permit2 model, allowing users to sign the number of tokens they are willing to pay offline on the origin chain Wallet.

Intent-based markets 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 use their USDC on Optimism as payment to enter a WETH collateralized position in Arbitrum. Users can send this intent to an RFQ auction where the solver can bid on it. The winner of the auction can then receive the user's signature intent, which contains a copy of the USDC allowed to spend on Optimism, the amount of WETH earned on Arbitrum, and the calldata used to deposit this WETH into the Arbitrum collateral position. The solver can then submit this transaction on Optimism (on behalf of the user) to initiate cross-chain intent and withdraw USDC from the user's Optimism Wallet. Finally, the solver can populate the user's intent by sending the user WETH and forwarding the calldata to the user's on-chain collateral position.

Building a chain abstraction infrastructure means making user processes feel instant and cheap without requiring them to commit on-chain transactions. Let's conclude this article by discussing the barriers to wider adoption of intent.

To achieve the best user experience from intent-based chain abstraction, we need a competitive network of solvers

The key to achieving the best user experience with intent-based chain abstraction lies in building a highly competitive network of solvers. The bridges of connection intents depend on solver network effects to perform better than messaging variants. This is a core trade-off between intent and messaging architecture. The reality is that not all applications that generate intents need access to a perfectly competitive set of solvers, and some may be more inclined to route their intents to a network of Oligopoly solvers. However, the current state of the solver network is immature and falls far from the level of the solver network activity assumption on which the intent market depends.

We don't want every DApp to route intents to an isolated solver network. The best user experience is one where long DApp are allowed to communicate with the same solver pool, and all DApp have a solver pool that is free to change the intent they send.

How do I bootstrap a solver network?**

We had to make the solver user experience a top priority.

Running an intent solver is complex and requires expertise in building high-performance software and managing cross-chain inventory risk. Naturally, there will be a handful of parties interested in paying for the startup costs of running this code. In the best case, a solver written for one DApp, such as the UniswapX solver, can be reused to solve other DApps that generate intent, such as Across and CowSwap.

We really need to improve the total capital efficiency of the solver network for all intent-based DApps. This will require addressing the impediment of running a solver.

To do this, we need a DApp that generates intent that is visible to any solver and ensures that all solvers have access to longest 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 drop costs for solvers.

The value proposition of the Intent Settlement Network is to provide security to the solver and other features that may affect the solver's intent. **

A solver's choice of an intent settlement network will affect their ability to provide users with fee and execution time guarantees. Some settlement networks may offer a solver-exclusive period, which will support the development of off-chain auctions, where solvers and users can negotiate and commit to relay fees. (In addition, these intent auctions may also provide financially secured pre-confirmation, further enhancing the user experience.) To understand the user flow of intent discovery through auctions and pre-confirmations, I recommend this presentation by Karthik of Sorella)

Some Settlement networks may offer intent expiration (i.e., sending value back to the user after a certain fulfillment period has been reached), intent support (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 the solver to choose the chain of their choice for repayment).

Ultimately, settlement networks will compete fiercely to repay solvers quickly and cheaply without compromising on security. Solvers, in turn, will send their order flow to a settlement network that allows them to offer the cheapest fees to users in order to win the DApp. Settlement and solver network competition depends on intent that all parties in the supply chain coordinate to use the same language, and competition will result in the best user experience for cross-chain value transfer.

Obviously, we need a cross-chain intent standard

If solvers can assume that intents will share common elements, then they can reuse their code to resolve different DApp-initiated intents, dropping their setup costs. If different DApps create intents that conform to the same criteria, they can all route their intents to the same solver pool. This will help provide access to the next generation of DApps by enabling them to insert their cross-chain intents directly into existing mature solver pools, without the need for separate access to solvers, and will result in cheap, fast, secure, and permissionless value transfer.

Third-party tracking software will also make it easier to track the intent status of any new DApp if the criteria are met.

This intent criterion should allow intent principals or solvers to specify which Settlement Network they wish to Settlement their intent on.

I envision competing Settlement protocol (such as SUAVE, Across, Anoma, and Khalani) providing different properties for the solver. Depending on which settlement network is repaying the solver, the solver can offer different price and time guarantees to the intent owner. DApps and solvers can agree to route a user's intent to a settlement network they trust to avoid censorship, maintain data privacy, and be secure enough for solvers to trust their repayment.

By writing the choice of the settlement network into the intent order itself, solvers can incorporate this certainty into the offer they present to the user. Solvers and users can drop costs by removing upfront uncertainty in bridge pricing before committing an intent on-chain.

Working with Uniswap, and based on feedback from the CAKE Working Group, Across and I proposed the following cross-chain intent criteria, putting the solver user experience first

The standard is designed to simplify the work of the solver. An assertive choice it makes is to natively support Permit2/EIP3074 with nonce and initiateDeadline, and provides some guarantees for form-fillers, such as the amount of refund they'll get from Settlement networks, and the user's intent format they can track. In addition, the standard defines a launch function that allows the filler (the person who brings the order onto the on-chain) to specify additional "fillerData" on the on-chain that the user is unaware of when signing the CrossChainOrder. In this way, fillers can ensure that they are rewarded for settlement contracts for submitting users' metatransactions, and can also set up repayment-specific information such as repayment chains.

This standard is also intended to make it easier for DApps to track intent completion status. Any settlement contract that implements this standard should create a custom subtype ResolvedCrossChainOrder that can be resolved from any orderData field. This may include Tokens involved in the exchange, destination chains, and other fulfillment constraints. Included in the standard is a resolve function that enables DApps to understand how to display the intent state to the user, as well as to let the solver know the exact intent order structure they are working on.

The design goal of this standard is to enhance the solver user experience, make it easier for them to support longest settlement networks, and calculate their rewards deterministically. I believe this will allow them to make a more accurate and compact offer to their users. You can read more details about this standard named long ERC7683 in this post and on the Ethereum Magicians forum.

Conclusion

"Intents" are confusing because they are not defined, and this lack of definition is creating real user experience flaws.

Everyone wants others to use their standard definition of intent, so I fully admit that standards are practically impossible to establish. I think first defining an intent settlement system and then trying to attract order flow is the right way to establish an industry standard.

In my opinion, a more feasible approach would be that DApp that already have a lot of user traffic and generate a long user intent will agree to meet some minimum standards that will be adopted by their existing solvers. This will form a new and larger pool of solvers. By capturing consolidated order flows from already prominent venues, this new pool of solvers will earn long more profits and be able to offer better prices to end users. Eventually, new DApps will also require their intents to be routed to this solver pool and support their intent criteria.

To kickstart this process, Across and Uniswap jointly proposed a standard that all intending Supply Chain participants use when processing user orders that send X Tokens from Chain A and receive Y Tokens on Chain B. Order flows run through UniswapX (which has a comparative advantage in auction design and intent origination) and Across (which has a comparative advantage in Settlement intent fulfillment) can be combined to start the process of nurturing a larger, more competitive network of solvers.