ERC-7683, Technically Explained: Cross-Chain Intents Standard for Blockchain Developers 

1. Liquidity Fragmentation: Traditional bridges operate in silos, forcing users to interact with separate filler networks for each protocol.  

2. Gas Inefficiency: Users often pay multiple gas fees for wrapping tokens and maintaining approvals across chains.

3. Trust Assumptions: Custom bridge implementations introduce security risks due to inconsistent auditing standards.

• Standardize cross-chain order structures to enable shared filler networks.  

• Reduce user friction through intent-based transactions (specify what, not how).  

• Enable atomic execution of multi-leg transfers across chains.  

These structs define two types of cross-chain orders specific to the ERC-7683 framework. The primary distinction between the two lies in how the orders are created and disseminated.

1. GaslessCrossChainOrder: This struct allows users to submit orders without directly interacting with the blockchain. Instead, users sign an off-chain message containing all order parameters. Fillers (or solvers) take on the responsibility of broadcasting this order to the blockchain. To securely sign the message, this struct follows the EIP-712 typehash signature. Some noteworthy fields:

   1. originSettler: Address of the contract on the origin chain, where the order is first sent for settlement. This dictates which smart contract will handle the order's functionality.

   2. orderData: An opaque bytes field allowing customized order behavior. It could define specific tokens, amounts, fees, or constraints for a fill. This modularity supports future extensions or order subtypes.

   3. nonce: Used for replay protection, ensuring uniqueness for user-signed orders.

   4. originChainId and openDeadline: Parameters to define the chain where the order originates and the period during which the order remains valid.

2. OnchainCrossChainOrder: Unlike the GaslessCrossChainOrder, this struct is tailored for orders directly opened by the user on-chain through a transaction. It omits several fields related to gasless workflows (e.g., originSettler, originFillerData) since users interact directly.

Both structs are designed to ensure compatibility across different types of settlement mechanisms, with the open event and resolveFor logic ensuring modularity in how these structs translate into actionable orders.

This implementation-generic struct decouples the logic of order resolution across chains. It is designed to define all necessary details for fillers to understand and fulfill the order, irrespective of the orderData specificities.

Important points:

• Inputs and Outputs:

  • maxSpent and minReceived: Define filler constraints. maxSpent caps the filler’s liability, while minReceived ensures the output guarantees for order execution. Both fields use the "Output" struct, which encodes token details, amounts, recipients, and destination chain IDs.

• Fill Instructions:

  • The FillInstruction[] array provides the data required to parameterize various "legs" of the transaction. Each leg corresponds to a fill on its respective destination chain, which may be partial.

  • The originData field ensures flexibility by allowing opaque data generated on the origin chain to flow to the destination chain for localized settlement logic.

The ResolvedCrossChainOrder serves as the bridge between implementation-specific semantics (within orderData) and the standardized representation fillers utilize for cross-chain execution.

This event is emitted whenever a compatible OnchainCrossChainOrder or GaslessCrossChainOrder is successfully opened. The orderId serves as a unique identifier for each order within a settlement system, ensuring traceability.

The Open event provides a standardized way for off-chain services (oracles, order distribution systems) to track the lifecycle of an order. This eliminates assumptions by allowing these services to rely solely on emitted events for order tracking. Additionally, combining this with the resolve view function ensures fillers can simulate orders and confirm validity prior to execution.

• IOriginSettler: This interface governs the behavior of origin settlement contracts. It ensures that cross-chain applications can standardize interaction points on the origin chain. Methods such as resolveFor allow fillers to decode and verify the orders without understanding the orderData specifics directly, fostering seamless integration.

  • openFor: Enables fillers to submit signed orders on behalf of users for gasless scenarios and emits the Open event.

  • resolveFor: Converts implementation-specific GaslessCrossChainOrder into the universal ResolvedCrossChainOrder.

• IDestinationSettler: This interface drives the execution of orders on destination chains, focusing singularly on filling discrete "legs" of an order.

Parameters like originData and fillerData allow for unique settlement mechanisms customized to the requirements of the destination ecosystem.

These interfaces promote interoperability among various settlement systems and fillers across blockchains, ensuring widespread adoption.

This struct specifies instructions for executing a single leg of a fill on the destination chain. Each instruction contains:

• destinationChainId: Identifies which chain the fill target resides on.

• destinationSettler: Specifies the contract address where the filler will interact to finalize the fill.

• originData: A black-box payload sent from the origin chain for destination chain settlement.

FillInstruction ensures that fillers only need to follow predefined instructions, making the derivative logic of multichain order settlement clearer and less error-prone.

The bytes orderData field allows protocols to encode different order data using the standard typehash system, EIP-712, which gives a lot of customization to the user and fillers. This balances standardization with protocol-specific needs.  

• Nonce Protection: Prevents replay attacks across chains.  

• Settlement Validation: ResolvedCrossChainOrder ensures fillers can’t alter swapper outputs post-resolution.  

• Filler Incentives: Compensations are bounded by orderData constraints to prevent front-running.