The following standard allows for the implementation of a standard API for cross-chain value-transfer systems. This standard provides generic order structs, as well as a standard set of settlement smart contract interfaces.
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.
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.
A compliant cross-chain order type MUST be ABI decodable into either GaslessCrossChainOrder or OnchainCrossChainOrder type.
Cross-chain execution systems implementing this standard SHOULD use a sub-type that can be parsed from the arbitrary orderData field. This may include information such as the tokens involved in the transfer, the destination chain IDs, fulfillment constraints or settlement oracles.
All sub-types SHOULD be registered in a subtypes repository to encourage sharing of sub-types based on their functionality. See the examples section for an example of how sub-types can be used to support behavior like executing calldata on a target contract of the user's choice on the destination chain.
A compliant cross-chain order type MUST be convertible into the ResolvedCrossChainOrder struct. This means that the orderData must be decoded into the information needed to populate the ResolvedCrossChainOrder struct. Additionally, orderData SHOULD be decodable into a sub-type, which can be used for further functionality such as cross-chain calldata execution (see the examples section for an example of this). It is the responsibility of the user and the filler to ensure that the originSettler supports their order's contained sub-type.
A compliant Open event MUST adhere to the following abi:
A compliant origin settler contract implementation MUST implement the IOriginSettler interface:
A compliant destination settlement contract implementation MUST implement the IDestinationSettler interface:
Cross-chain execution systems implementing this standard SHOULD use a sub-type that can be parsed from the arbitrary fillerData field. This may include information such as the desired timing or form of payment for the filler
All sub-types SHOULD be registered in a subtypes repository to encourage sharing of sub-types based on their functionality.
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 cross-chain intents flow, with two variations: gasless and onchain.
Origin Chain:
Destination Chain(s):
Settlement:
Origin Chain:
Destination Chain(s):
Settlement:
Within this flow, implementers of the standard have design flexibility to customize behavior such as:
open in some settlement systemsThe 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.
An important component of the standard is creating a flexible and robust mechanism for fillers to ensure their fills are valid. For a fill to be valid, it typically must satisfy the following constraints:
open call on the origin chain (ex. dutch auctions based on open timing)The FillInstruction array in ResolvedCrossChainOrder is intended to ensure it's simple for the filler to meet all of these requirements by either
listening for the Open or by calling resolve.
One may notice that the originData field within FillInstruction is completely opaque. This opaqueness allows the settler implementations to
freely customize the data they transmit. Because fillers do not need to interpret this information, the opaqueness does not result in any
additional implementation costs on fillers.
This functionality also makes it feasible for a user, filler, or order distribution system to perform an end-to-end simulation of the order initiation and fill to evaluate all resulting state transitions without understanding the nuances of a particular execution system.
Since this standard is intended to reduce friction for users moving value across chains, non-EVM ecosystems should not be excluded. However, attempting to pull each non-EVM ecosystem in would dramatically increase the size and complexity of this standard, while omitting any that come in the future.
Instead, this standard is intended to be cross-compatible with other ecosystems. It standardizes interfaces and data types on EVM chains, but allows for the creation of sibling standards that define compatible interfaces, data types, and flows within other ecosystems. Intents created within these sibling standards should be able to be filled on an EVM chain and vice versa.
To ensure this cross-compatibility, all foreign addresses use bytes32 rather than address to allow for larger address identifiers.
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 users 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 order. It also decouples the token approval from the order, 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 nonceopenDeadline in the order struct should be the permit2 deadlineorderData should be used as the witness type during the permit2 call. This ensures maximum transparency to the user as they sign their order permit.This is an example of how a 7683 cross-chain value transfer order can include instructions to the filler to execute arbitrary calldata on behalf of the recipient on the destination chain. This calldata execution is performed by the settlement contract atomically within the filler's fill() execution, so the arbitrary contract execution can take advantage of the destination chain recipient's newly transferred value. A hypothetical user in this example would select an originSettler that is known to support the Message sub-type.
Let there be a sub-type called Message, which is defined by the following structs:
The Message sub-type is designed to be used by a 7683 user to incentivize a filler to execute arbitrary calldata on a target destination chain contract on the user's behalf. For example, the settlement contract might decode the originData containing the message information as follows:
In this example, the Message sub-type allows the user to delegate destination chain contract execution to fillers. However, because transactions are executed via filler, the msg.sender would be the DestinationSettler, making this Message sub-type limited if the target contract authenticates based on the msg.sender. Ideally, 7683 orders containing Messages can be combined with smart contract wallets like implementations of ERC-4337 or EIP-7702 to allow complete cross-chain delegated execution.
This ERC is agnostic of how the settlement system validates a 7683 order fulfillment and refunds the filler. In fact, this ERC is designed to delegate the responsibility of evaluating the settlement contract's security to the filler and the application that creates the user's 7683 order.
This design decision is motivated by the existence of many viable cross-chain messaging systems today offering settlement contracts a variety of tradeoffs. We hope that this standard can eventually support an ERC dedicated to standardizing a safe, trustless, cross-chain verification system.
Copyright and related rights waived via CC0.