An interface for cross chain trade execution systems
Uniswap Labs and Across propose a new standard for cross-chain intents, establishing a unified framework for intents-based systems to specify cross-chain actions. With the proposal for the new standard, Uniswap Labs and Across have jointly published an Ethereum Request for Comment to the Ethereum Magicians forum. The two projects have proposed the standard to the CAKE Working Group for their discussion and review.
Abstract
The following standard allows for the implementation of a standard API for cross-chain trade execution systems. This standard provides a generic CrossChainOrder
struct, as well as a standard ISettlementContract
smart contract interface.
Motivation
Intent-based systems have become the preeminent solution for end-user cross-chain interaction by abstracting away the complexity and time constraints of traditional bridges. One of the key difficulties for cross-chain intents systems is accessing sufficient liquidity and a network of active fillers across chains. This challenge may be exacerbated as the number of distinct chains increases over time. The end result of this is a poor experience for users including higher costs, longer wait times and higher failure rates than necessary.
By implementing a standard, cross-chain intents systems can interoperate and share infrastructure such as order dissemination services and filler networks, thereby improving end-user experience by increasing competition for fulfilling user intents.
Specification
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
CrossChainOrder struct
A compliant cross-chain order type MUST be ABI decodable into the CrossChainOrder
type.
Cross-chain execution systems implementing this standard SHOULD create a custom sub-type that can be parsed from the arbitrary orderData
field. This may include information such as the tokens involved in the swap, the destination chain IDs, fulfillment constraints or settlement oracles.
ResolvedCrossChainOrder struct
A compliant cross-chain order type MUST be convertible into the ResolvedCrossChainOrder
struct.
ISettlementContract interface
A compliant settlement contract implementation MUST implement the ISettlementContract
interface:
Rationale
Generic OrderData
A key consideration is to ensure that a broad range of cross-chain intent designs can work within the same standard. To enable this, the specification is designed around a standard cross-chain intents flow, while allowing for varying implementation details within that flow.
Standard cross-chain intents flow:
The swapper signs an off-chain message defining the parameters of their order
The order is disseminated to fillers
The filler initiates the trade on the origin chain
The filler fills the order on the destination chain
A cross-chain settlement process takes place to settle the order
Within this flow, implementers of the standard have design flexibility to customize behavior such as:
Price resolution, e.g. dutch auctions or oracle-based pricing
Fulfillment constraints
Settlement procedures.
The orderData
field allows implementations to take arbitrary specifications for these behaviors while still enabling integrators to parse the primary fields of the order.
This functionality also motivated the resolve
view function and ResolvedCrossChainOrder
type. Resolution enables integrating fillers to validate and assess orders without specific knowledge of the orderData
field at hand.
Usage of Permit2
Permit2 is not specifically required by this standard, but does provide an efficient and straightforward approach to building standard-adherent protocols. Specifically, the witness
functions of permit2 allow swappers to both approve the token transfer and the order itself with a single signature. This also nicely couples the transfer of tokens with a successful initiation of the order.
In contrast, a standard approval model would require two separate signatures - a token approval and a signature to approve the terms of the swap. It also decouples the token approval from the swap, meaning approved tokens could potentially be taken at any time due to a buggy or untrusted settler contract.
When building a standard-compliant settler system around Permit2, the following considerations should be made
nonce
in the order struct should be a permit2 nonceinitiateDeadline
in the order struct should be the permit2 deadlineA full order struct including the parsed
orderData
should be used as the witness type during the permit2 call. This ensures maximum transparency to the swapper as they sign their order permit.
Last updated