updates after 0age's comments

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

ERCS/erc-7683.md

@@ -97,13 +97,16 @@ struct ResolvedCrossChainOrder {
 	/// @dev The timestamp by which the order must be filled on the destination chain(s)
 	uint32 fillDeadline;
 
-	/// @dev The inputs to be taken from the user as part of order initiation
-	Input[] userInputs;
-	/// @dev The max outputs that the user will recieve. It's possible the actual amount depends on the state of the destination
+	/// @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[] maxOutputs;
-	/// @dev The outputs to be given to the filler as part of order settlement
-	Output[] minFillerOutputs;
+	Output[] maxSent;
+	/// @dev The minimum outputs that must to be given to the filler as part of order settlement. Similar to maxSent, it's possible
+	///      that special order types may not be able to guarantee the exact amount at initiate time, so this should be considered
+	///      a floor on filler receipts.
+	Output[] minRecieved;
+	/// @dev Each instruction in this array is parameterizes a single leg of the fill. This provides the filler with the information
+	///      necessary to perform the fill on the destination(s).
+	FillInstruction[] fillInstructions;
 }
 
 /// @notice Tokens sent by the user as inputs to the order
@@ -126,29 +129,29 @@ struct Output {
 	/// @dev The destination chain for this output
 	uint64 chainId;
 }
-```
-
-### Initiated event
 
-A compliant `Initiated` event MUST adhere to the following abi:
-
-```solidity
-/// @title FillInstructions type
+/// @title FillInstruction type
 /// @notice Instructions to parameterize each leg of the fill
 /// @dev Provides all the origin-generated information required to produce a valid fill leg
-struct FillInstructions {
+struct FillInstruction {
 	/// @dev The contract address that the order is meant to be settled by
 	uint64 destinationChainId;
 	/// @dev The contract address that the order is meant to be filled on
 	bytes32 destinationSettler;
 	/// @dev The data generated on the origin chain needed by the destinationSettler to process the fill
 	bytes originData;
 }
+```
+
+### Initiate event
+
+A compliant `Initiate` event MUST adhere to the following abi:
 
+```solidity
 /// @notice Signals that an order has been initiated
 /// @param orderId a unique order identifier within this settlement system
-/// @param fillInstructions fillInstructions instructions to parameterize each fill leg, with each element representing a single leg
-event Initiated(bytes32 indexed orderId, FillInstructions[] fillInstructions);
+/// @param fillInstructions instructions to parameterize each fill leg, with each element representing a single leg
+event Initiate(bytes32 indexed orderId, ResolvedCrossChainOrder resolvedOrder);
 ```
 
 ### Settlement interfaces
@@ -166,16 +169,15 @@ interface IOriginSettler {
 	/// @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 returns (FillInstructions[]);
+	function initiateFor(GaslessCrossChainOrder order, bytes signature, bytes originFillerData) external;
 
 	/// @notice Initiates the settlement of a cross-chain order
 	/// @dev To be called by the user
 	/// @dev This method must emit the Initiated 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
-	/// @returns fillInstructions instructions to parameterize each fill leg, with each element representing a single leg
-	function initiate(OnchainCrossChainOrder order) external returns (FillInstructions[] fillInstructions);
+	function initiate(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
@@ -219,26 +221,38 @@ All sub-types SHOULD be registered in the [Filler Data Subtypes Repo](github.com
 
 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.
 
-Gasless cross-chain intents flow:
+**Gasless cross-chain intents flow**
 
+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 initiates the order on the origin chain
-4. The filler fills the order on the destination chain
-5. A cross-chain settlement process takes place to settle the order
+3. The filler calls resolve to unpack the order's requirements
+4. The filler initiates the order on the origin chain
+
+Destination Chain(s):
+- The filler fills each leg of the order on the destination chain(s)
+
+Settlement:
+- A cross-chain settlement process takes place to settle the order
+
+**Onchain cross-chain intents flow**
+
+Origin Chain:
+1. The caller signs a transaction calling initiate with their order
+2. The filler retrieves the emitted event to determine requirements
 
-Onchain cross-chain intents flow:
+Destination Chain(s):
+- The filler fills each leg of the order on the destination chain(s)
 
-1. The user signs a transaction calling initiate with their order
-2. The filler retrieves the emitted event
-3. The filler fills the order on the destination chain
-4. A cross-chain settlement process takes place to settle the order
+Settlement:
+- A cross-chain settlement process takes place to settle the order
 
 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.
+- Settlement procedures
+- Ordering of the origin and destination chain actions, e.g. the fill could happen before initiate 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.
 
@@ -254,11 +268,10 @@ it typically must satisfy the following constraints:
 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)
 
-1 & 2 could potentially be generated by a re-simulation of `resolve`. However, a filler must deeply understand the settlement system to determine
-3 & 4. `FillInstructions` is intended to remove this burden from the filler, allowing them to rely on the origin settler contract to provide them
-the information needed to both simulate and perform fills.
+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`.
 
-One may notice that the `originData` field within `FillInstructions` is completely opaque. This opaqueness allows the settler implementations to
+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.