comments

Signed-off-by: Matt Rice <[email protected]>

ERCS/erc-7683.md

@@ -52,8 +52,8 @@ struct GaslessCrossChainOrder {
 	uint256 nonce;
 	/// @dev The chainId of the origin chain
 	uint64 originChainId;
-	/// @dev The timestamp by which the order must be initiated
-	uint32 initiateDeadline;
+	/// @dev The timestamp by which the order must be opened
+	uint32 openDeadline;
 	/// @dev The timestamp by which the order must be filled on the destination chain
 	uint32 fillDeadline;
 	/// @dev Arbitrary implementation-specific data
@@ -63,7 +63,7 @@ struct GaslessCrossChainOrder {
 }
 
 /// @title OnchainCrossChainOrder CrossChainOrder type
-/// @notice Standard order struct for user-initiated orders, where the user is the msg.sender.
+/// @notice Standard order struct for user-opened orders, where the user is the msg.sender.
 struct OnchainCrossChainOrder {
 	/// @dev The timestamp by which the order must be filled on the destination chain
 	uint32 fillDeadline;
@@ -92,16 +92,16 @@ struct ResolvedCrossChainOrder {
 	address user;
 	/// @dev The chainId of the origin chain
 	uint64 originChainId;
-	/// @dev The timestamp by which the order must be initiated
-	uint32 initiateDeadline;
+	/// @dev The timestamp by which the order must be opened
+	uint32 openDeadline;
 	/// @dev The timestamp by which the order must be filled on the destination chain(s)
 	uint32 fillDeadline;
 
 	/// @dev The max outputs that the filler will send. It's possible the actual amount depends on the state of the destination
 	///      chain (destination dutch auction, for instance), so these outputs should be considered a cap on filler liabilities.
 	Output[] maxSpent;
 	/// @dev The minimum outputs that must to be given to the filler as part of order settlement. Similar to maxSpent, it's possible
-	///      that special order types may not be able to guarantee the exact amount at initiate time, so this should be considered
+	///      that special order types may not be able to guarantee the exact amount at open time, so this should be considered
 	///      a floor on filler receipts.
 	Output[] minReceived;
 	/// @dev Each instruction in this array is parameterizes a single leg of the fill. This provides the filler with the information
@@ -143,15 +143,15 @@ struct FillInstruction {
 }
 ```
 
-### Initiate event
+### Open event
 
-A compliant `Initiate` event MUST adhere to the following abi:
+A compliant `Open` event MUST adhere to the following abi:
 
 ```solidity
-/// @notice Signals that an order has been initiated
+/// @notice Signals that an order has been opened
 /// @param orderId a unique order identifier within this settlement system
 /// @param fillInstructions instructions to parameterize each fill leg, with each element representing a single leg
-event Initiate(bytes32 indexed orderId, ResolvedCrossChainOrder resolvedOrder);
+event Open(bytes32 indexed orderId, ResolvedCrossChainOrder resolvedOrder);
 ```
 
 ### Settlement interfaces
@@ -162,22 +162,22 @@ A compliant origin settler contract implementation MUST implement the `IOriginSe
 /// @title IOriginSettler
 /// @notice Standard interface for settlement contracts on the origin chain
 interface IOriginSettler {
-	/// @notice Initiates the settlement of a gasless cross-chain order on behalf of a user.
+	/// @notice Opens a gasless cross-chain order on behalf of a user.
 	/// @dev To be called by the filler.
-	/// @dev This method must emit the Initiated event
+	/// @dev This method must emit the Open event
 	/// @param order The GaslessCrossChainOrder definition
 	/// @param signature The user's signature over the order
 	/// @param fillerData Any filler-defined data required by the settler
 	/// @returns fillInstructions instructions to parameterize each fill leg, with each element representing a single leg
-	function initiateFor(GaslessCrossChainOrder order, bytes signature, bytes originFillerData) external;
+	function openFor(GaslessCrossChainOrder order, bytes signature, bytes originFillerData) external;
 
-	/// @notice Initiates the settlement of a cross-chain order
+	/// @notice Opens a cross-chain order
 	/// @dev To be called by the user
-	/// @dev This method must emit the Initiated event
+	/// @dev This method must emit the Open event
 	/// @param order The OnchainCrossChainOrder definition
 	/// @param signature The user's signature over the order
 	/// @param fillerData Any filler-defined data required by the settler
-	function initiate(OnchainCrossChainOrder order) external;
+	function open(OnchainCrossChainOrder order) external;
 
 	/// @notice Resolves a specific GaslessCrossChainOrder into a generic ResolvedCrossChainOrder
 	/// @dev Intended to improve standardized integration of various order types and settlement contracts
@@ -227,7 +227,7 @@ Origin Chain:
 1. The user signs an off-chain message defining the parameters of their order
 2. The order is disseminated to fillers
 3. The filler calls resolve to unpack the order's requirements
-4. The filler initiates the order on the origin chain
+4. The filler opens the order on the origin chain
 
 Destination Chain(s):
 - The filler fills each leg of the order on the destination chain(s)
@@ -238,7 +238,7 @@ Settlement:
 #### Onchain cross-chain intents flow
 
 Origin Chain:
-1. The caller signs a transaction calling initiate with their order
+1. The caller signs a transaction calling open with their order
 2. The filler retrieves the emitted event to determine requirements
 
 Destination Chain(s):
@@ -254,7 +254,7 @@ Within this flow, implementers of the standard have design flexibility to custom
 - 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 initiate in some settlement systems
+- Ordering of the origin and destination chain actions, e.g. the fill could happen before `open` in some settlement systems
 
 The `orderData` field allows implementations to take arbitrary specifications for these behaviors while still enabling integrators to parse the primary fields of the order.
 
@@ -268,10 +268,10 @@ it typically must satisfy the following constraints:
 1. It must be filled on the correct destination chain(s)
 2. It must be filled on the correct destination contract
 3. It must include some (not necessarily all) information from the order that the user provided on the origin chain
-4. It may require some execution information from the initiate call on the origin chain (ex. dutch auctions based on initiate timing)
+4. It may require some execution information from the `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 `Initiate` or by calling `resolve`.
+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
@@ -357,7 +357,7 @@ In contrast, a standard approval model would require two separate signatures - a
 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
+- `openDeadline` 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 user as they sign their order permit.
 
 ## Security Considerations