ERC-7683: Cross Chain Intents

An interface for cross-chain trade execution systems.

Metadata

Status: DraftStandards Track: ERCCreated: 2024-04-11

Authors

Mark Toda (@marktoda), Matt Rice (@mrice32), Nick Pai (@nicholaspai)

Links

GitHub page Discussion on Ethereum Magicians

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 (either ERC-2612 or on-chain) 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 nonce
initiateDeadline in the order struct should be the permit2 deadline
A 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.