ERC-7683: Cross Chain Intents Standard

ERCs
, , ,
13

Hey y’all, small point of feedback - in the resolve function, why does the return type ResolvedCrossChainOrder repeat all of the fields on the parameter CrossChainOrder? is there ever a circumstance where the repeated fields would or should change between the input CrossChainOrder and the output ResolvedCrossChainOrder? in practice, copying these fields from the input type to the return type makes developing smart contracts that implement this standard unnecessarily uglier to write.

repeated fields:

    /// @dev The contract address that the order is meant to be settled by.
    /// Fillers send this order to this contract address on the origin chain
    address settlementContract;
    /// @dev The address of the user who is initiating the swap,
    /// whose input tokens will be taken and escrowed
    address swapper;
    /// @dev Nonce to be used as replay protection for the order
    uint256 nonce;
    /// @dev The chainId of the origin chain
    uint32 originChainId;
    /// @dev The timestamp by which the order must be initiated
    uint32 initiateDeadline;
    /// @dev The timestamp by which the order must be filled on the destination chain
    uint32 fillDeadline;

I would cut the repeated fields from ResolvedCrossChainOrder to change the type to something like ResolvedOrderData:

/// @title ResolvedOrderData type
/// @notice An implementation-generic representation of an order
/// @dev Defines all requirements for filling an order by unbundling the implementation-specific orderData.
/// @dev Intended to improve integration generalization by allowing fillers to compute the exact input and output information of any order
struct ResolvedOrderData {
    /// @dev The inputs to be taken from the swapper as part of order initiation
    Input[] swapperInputs;
    /// @dev The outputs to be given to the swapper as part of order fulfillment
    Output[] swapperOutputs;
    /// @dev The outputs to be given to the filler as part of order settlement
    Output[] fillerOutputs;
}

then

    /// @notice Resolves a specific CrossChainOrder into ResolvedOrderData
    /// @dev Intended to improve standardized integration of various order types and settlement contracts
    /// @param order The CrossChainOrder definition
    /// @param fillerData Any filler-defined data required by the settler
    /// @return ResolvedOrderData hydrated order data including the inputs and outputs of the order
    function resolve(CrossChainOrder order, bytes fillerData)
        external
        view
        returns (ResolvedOrderData);

of course, we still need to pass in the entire CrossChainOrder and fillerData as parameters (not just the raw orderData bytes) as ResolvedOrderData resolution may depend on additional fields

1 Like