FAQ
Frequently Asked Questions
General Questions
What is a Crosschain Intent?
A crosschain intent represents any programmable user-defined action—like financial transactions, staking, or governance—that signals the outcome a user expects to happen on a target chain.
What is the ERC-7683 standard?
ERC-7683 standardizes how these crosschain interactions are expressed as intents, allowing shared infrastructure and orders for seamless crosschain interactions between Ethereum mainnet, L2s, and sidechains.
The ERC-7683 standard defines the structure of a crosschain intent, acting like an order ticket that anyone can create and any solver can fulfill.
What Is the one-liner description of ERC-7683?
ERC-7683 standardizes how these crosschain interactions are expressed as intents, allowing for shared infrastructure for seamless crosschain transactions between Ethereum mainnet, L2s, and sidechains.
Why do we need a standard for crosschain intents (ERC-7683)?
The ERC-7683 standard is necessary for establishing a common framework for managing crosschain intents, simplifying development and enhancing compatibility across networks. Specifying a uniform standard prevents fragmented approaches, ensuring that interoperability—one of the core goals of intents—is achieved efficiently and securely for protocols, relayers, and users alike.
How does ERC-7683 help unify Ethereum?
While L2s have improved Ethereum's scalability, they have also introduced fragmentation within the ecosystem. With ERC-7683, users simply specify what they want to achieve—their "intent"—without worrying about the underlying steps to transfer assets or data between chains. Relayers then compete to fulfill these intents, ensuring users receive the expected outcomes.
This streamlined process makes crosschain transactions feel like they're happening on one chain, creating a unified experience across the Ethereum ecosystem.
How does ERC-7683 help users?
ERC-7683 enhances the user experience by enabling seamless transactions across different L2s. A shared relayer network promotes competition among relayers to fulfill users' intents. From the users' perspective, the ERC-7683 reduces transaction costs and accelerates processes due to the competitive environment among relayers. Additionally, ERC-7683 abstracts the complexities of crosschain interactions, reducing friction, which makes the Ethereum ecosystem more accessible and easier to use for everyone.
How does ERC-7683 help protocols?
ERC-7683 establishes a shared relayer network that protocols can leverage, enabling relayers to support multiple protocols from day one. This interconnectedness fosters network effects and drives ecosystem growth, making protocols more unified and efficient.
Protocols that rely on crosschain liquidity, seamless user experiences, and interoperable infrastructure can utilize systems built on top of ERC-7683—such as Across and UniswapX—to operate cohesively across multiple chains.
How does ERC-7683 help relayers?
ERC-7683 provides relayers with a unified framework that minimizes the need for custom solutions for each intent protocol. This simplification allows relayers to support protocols that adopt ERC-7683 more easily, reducing their operational overhead and creating additional opportunities.
As a result, more relayers are attracted to support protocols adopting ERC-7683, given the chance to handle a larger volume of transactions across the Ethereum ecosystem.
Why is this only focused on crosschain swaps? Have you considered making a more generalized version?
ERC-7683 initially focuses on crosschain swaps because they are the most common use case, and it is designed to support more complex actions. The orderData field in the CrossChainOrder struct allows encoding arbitrary data, enabling advanced functionalities like executing additional actions on the destination chain. This flexibility lets intent settlement networks, such as Across, support a range of user-defined actions beyond swaps.
Examples; Bridge + Stake, Bridge + Mint
Can ERC-7683 send crosschain messages?
While ERC-7683 primarily focuses on crosschain intents involving token swaps and settlements, it is designed to be compatible with existing messaging networks.
The standard itself does not serve as a messaging protocol but acts as a unifying layer that connects offchain messages to onchain settlement contracts. Projects that adopt ERC-7683 have complete flexibility on which messaging approach to adopt in their protocol.
What does it mean for a chain to support ERC-7683?
Every EVM chain technically supports ERC-7683. ERC-7683's benefit compounds the more settlement contracts, fillers, and dApps that use it. If a chain supports ERC-7683, it means that users and protocols on that chain are actively using the standard to transfer value.
A chain doesn’t need to take special actions to support ERC-7683 beyond signaling support and enabling dApps to adopt and implement it.
Compatability Questions
Are crosschain intents compatible with L2 native interop solutions (agglayer, elastic chain etc.)?
ERC-7683 is compatible with L2 native interoperability solutions, such as Polygon AggLayer, Optimism Superchain, and ZKsync Elastic Chain. These native interoperability solutions are a type of crosschain messaging, so ERC-7683 protocols can leverage these interoperability solutions for their settlement contract. ERC-7683 is proof system agnostic, offering a flexible framework that allows users to choose their preferred settlement systems and proof mechanisms. By pairing ERC-7683 with these native interop solutions, developers can build a comprehensive system that supports crosschain token transfers on top of these messaging interfaces. Specifically, ERC-7683 can utilize these native interop solutions as its settlement layer.
Are RIP-7755 and ERC-7683 compatible?
RIP-7755 and ERC-7683 are compatible and complementary standards that enhance crosschain interactions within the Ethereum ecosystem. RIP-7755 standardizes message verification, providing a consistent and secure settlement layer for trust-minimized messaging. ERC-7683 is proof system agnostic, offering a flexible framework that allows users to choose their preferred settlement systems and proof mechanisms. By pairing ERC-7683 with RIP-7755, developers can build a comprehensive system that supports crosschain token transfers on top of a standardized crosschain messaging interface. Specifically, ERC-7683 can utilize RIP-7755 as its settlement layer. This integration combines the flexible, proof system agnostic approach of ERC-7683 with the standardized message verification process of RIP-7755.Specifically, ERC-7683 can utilize these native interop solutions as its settlement layer.
Are EIP-7702 and ERC-7683 compatible?
EIP-7702 focuses on account abstraction by allowing externally owned accounts (EOAs) to temporarily function as smart contract wallets during a transaction, enhancing flexibility and user experience. ERC-7683 aims to standardize crosschain trade execution, facilitating seamless interactions across multiple blockchain networks.
Together, they allow users to initiate complex crosschain transactions directly from their EOAs, enhancing interoperability and user experience within the Ethereum ecosystem.
Technical Questions
What is the purpose of a CrossChainOrder struct?
The CrossChainOrder struct in ERC-7683 serves as a standardized template for defining crosschain transactions. It encapsulates all necessary details—such as the origin and destination chains, involved assets, and execution parameters—into a single, coherent data structure.
This standardization ensures that different protocols and relayers can interpret and process crosschain intents consistently, reducing the risk of errors and enhancing interoperability across various blockchain networks
How does ERC-7683 handle order settlement?
ERC-7683 handles order settlement by defining a clear, standardized process for fulfilling crosschain intents. Once a user submits an intent, relayers compete to complete the task by executing the required transaction on the destination chain. The protocol then verifies that the intent was successfully fulfilled before releasing the escrowed assets or funds to the relayer. This ensures a secure and efficient transfer that abstracts away complex crosschain interactions, allowing for seamless settlements that maintain trust between parties.
What is flexible in this standard, and can you provide examples?
Within this flow, implementers of the standard have design flexibility to customize behavior such as:
Price resolution, e.g. dutch auctions (on origin or destination) or oracle-based pricing
Fulfillment constraints
Settlement procedures
Ordering of the origin and destination chain actions, e.g. the fill could happen before open in some settlement systems
For example, the flexibility of ERC-7683 allows anyone to create their own settlement procedure using different verification methods, whether it’s RIP-7755, ZK proofs, or native interoperability like Superchain.
Can somebody do an arbitrary action after the crosschain swap? If so, how?
Yes, ERC-7683 supports arbitrary actions after a crosschain swap through the bytes orderData field in the CrossChainOrder struct.
This field can include custom data that specifies an action to be executed on the destination chain. For example, users can encode details of a target contract and the necessary calldata for that action. When the solver fulfills the user’s intent, it triggers the specified call to the target contract with the provided data on behalf of the depositor.
Does this standard enforce / assume that the settlement contract has to live on the source chain of the intent?
No, ERC-7683 does not enforce or assume that the settlement contract must reside solely on the source chain of the intent. While the standard requires that a contract on the origin chain processes the initial intent (as it holds the user’s tokens), it does not limit validation or further interactions to that chain alone.
Have you thought about a standard function for filling?
We have considered a standard fill function, like fill(CrossChainOrder order, bytes fillerData), but there are challenges. Different protocols need varying parts of the orderData, so requiring the full order would be inefficient. Additionally, some protocols rely on blockchain state at the time of initiation, meaning fillers need a way to communicate contextual information that isn’t known until after initiation. Thus, while a standardized fill function could be useful, the variation in protocol needs makes it difficult to implement without imposing inefficiencies or redundant requirements on different systems.
The chainID is kept as a top-level variable for simplicity and better integration with gasless crosschain intent frameworks, such as Permit2 and EIP-7702. Including chainID at the top level also prevents added complexity for fillers, who would otherwise have to manage multiple chainIDs, track finality across multiple input chains, and handle more complicated market conditions.
Last updated