Seaport

https://docs.opensea.io/v2.0/reference/seaport-overview

Seaport 是一个市场合同，用于安全有效地创建和履行 ERC721 和 ERC1155 项目的订单。每个订单包含供应商愿意提供的任意数量的物品（“offer”卖的东西）以及必须与其各自的接收者提供的任意数量的物品（“consideration”买家要付给其他人的钱）。
Seaport is a marketplace contract for safely and efficiently creating and fulfilling orders for ERC721 and ERC1155 items. Each order contains an arbitrary number of items that the offerer is willing to give (the "offer") along with an arbitrary number of items that must be received along with their respective receivers (the "consideration").

订单 Order

每个订单包含十一个关键组件：Each order contains eleven key components:

• 订单的提供所有提供的物品，并且必须亲自履行订单（即）或通过签名（标准的 65 字节 EDCSA、64 字节 EIP-2098 或 EIP-1271支票）或列出链上订单（即调用）。offerer``msg.sender == offerer``isValidSignature``validate

• The offerer of the order supplies all offered items and must either fulfill the order personally (i.e. msg.sender == offerer) or approve the order via signature (either standard 65-byte EDCSA, 64-byte EIP-2098, or an EIP-1271 isValidSignature check) or by listing the order on-chain (i.e. calling validate).

• 订单的区域是附加到订单的可选辅助帐户，具有两个额外的权限：zone

  • 该区域可以通过调用来取消它被命名为该区域的订单。（请注意，提供者也可以取消他们自己的订单，可以单独取消，也可以通过调用 立即取消所有使用当前 nonce 签名的订单）。cancel``incrementNonce
  • “受限”订单（由订单类型指定）必须由区域或要约人执行，或者必须通过调用区域上的或查看功能所指示的方式获得批准。isValidOrder``isValidOrderIncludingExtraData
  • The zone of the order is an optional secondary account attached to the order with two additional privileges:* The zone may cancel orders where it is named as the zone by calling cancel. (Note that offerers can also cancel their own orders, either individually or for all orders signed with their current nonce at once by calling incrementNonce).

• "Restricted" orders (as specified by the order type) must either be executed by the zone or the offerer, or must be approved as indicated by a call to an isValidOrder or isValidOrderIncludingExtraData view function on the zone.

• offer包含可以从提供者帐户转移的一系列项目，其中每个项目由以下组件组成：

  • itemType ：指定项目的类型，有效类型为 Ether（或给定链的其他原生代币）、ERC20、ERC721、ERC1155、ERC721 与“标准”（如下所述），以及 ERC1155 与标准。
  • token：指定项目代币合约的账户（空地址用于以太币或其他原生代币）。
  • identifierOrCriteria :表示 ERC721 或 ERC1155 令牌标识符，或者在基于标准的项目类型的情况下，表示由项目的有效令牌标识符集组成的 merkle 根。对于 Ether 和 ERC20 项目类型，此值将被忽略，并且对于基于标准的项目类型可以选择为零以允许任何标识符。
  • startAmount : 表示如果在订单激活时完成订单，则需要的相关项目的数量。
  • endAmount 表示如果在订单到期时履行订单，将需要的相关项目的数量。如果此值与startAmount项目的值不同，则根据订单激活后经过的时间线性计算已实现金额。

The offer contains an array of items that may be transferred from the offerer's account, where each item consists of the following components:* The itemType designates the type of item, with valid types being Ether (or other native token for the given chain), ERC20, ERC721, ERC1155, ERC721 with "criteria" (explained below), and ERC1155 with criteria.

• The token designates the account of the item's token contract (with the null address used for Ether or other native tokens).

• The identifierOrCriteria represents either the ERC721 or ERC1155 token identifier or, in the case of a criteria-based item type, a merkle root composed of the valid set of token identifiers for the item. This value will be ignored for Ether and ERC20 item types, and can optionally be zero for criteria-based item types to allow for any identifier.

• The startAmount represents the amount of the item in question that will be required should the order be fulfilled at the moment the order becomes active.

• The endAmount represents the amount of the item in question that will be required should the order be fulfilled at the moment the order expires. If this value differs from the item's startAmount, the realized amount is calculated linearly based on the time elapsed since the order became active.

• consideration包含为完成订单而必须接收的一系列项目。它包含与提供的项目相同的所有组件，并且还包括一个将接收每个项目的组件recipient。该数组可以由履行者在订单履行时扩展，以支持“小费”（例如中继者或推荐支付）。

• The consideration contains an array of items that must be received in order to fulfill the order. It contains all of the same components as an offered item, and additionally includes a recipient that will receive each item. This array may be extended by the fulfiller on order fulfillment so as to support "tipping" (e.g. relayer or referral payments).

• orderType根据两个不同的偏好，指定订单的四种类型之一：

  • FULL表示订单不支持部分填充，而PARTIAL允许填充订单的一部分，重要的警告是每个项目必须被提供的分数完全整除（即除法后没有余数）。
  • OPEN指示执行订单的调用可以由任何账户提交，而RESTRICTED要求订单要么由要约人执行，要么由订单所在区域执行，或者调用isValidOrder或isValidOrderIncludingExtraData在区域上的查看功能。

• startTime 指示订单激活的区块时间戳。

• endTime指示订单到期的区块时间戳。该值 和startTime与每个项目的startAmount``endAmount一起使用以得出它们的当前金额。

• zoneHash表示一个任意的 32 字节值，当执行受限订单时，该值将提供给区域，区域在确定是否授权订单时可以使用该值。

• salt表示订单的任意熵源。

• conduitKey是一个bytes32值，指示在执行转移时应将哪个管道（如果有）用作令牌批准的来源。默认情况下（即当设置为零散列时），offer方将直接向 Seaport 授予 ERC20、ERC721 和 ERC1155 令牌批准，以便它可以在履行期间执行订单指定的任何转移。相反，选择使用管道的提议者将授予与提供的管道密钥相对应的管道合同的代币批准，然后seaport将指示该管道转移相应的代币。

• nonce指示必须与给定提议者的当前随机数匹配的值。

The orderType designates one of four types for the order depending on two distinct preferences:
FULL indicates that the order does not support partial fills, whereas PARTIAL enables filling some fraction of the order, with the important caveat that each item must be cleanly divisible by the supplied fraction (i.e. no remainder after division).
OPEN indicates that the call to execute the order can be submitted by any account, whereas RESTRICTED requires that the order either be executed by the offerer or the zone of the order, or that a magic value indicating that the order is approved is returned upon calling an isValidOrder or isValidOrderIncludingExtraData view function on the zone.

The startTime indicates the block timestamp at which the order becomes active.
The endTime indicates the block timestamp at which the order expires. This value and the startTime are used in conjunction with the startAmount and endAmount of each item to derive their current amount.
The zoneHash represents an arbitrary 32-byte value that will be supplied to the zone when fulfilling restricted orders that the zone can utilize when making a determination on whether to authorize the order.
The salt represents an arbitrary source of entropy for the order.
The conduitKey is a bytes32 value that indicates what conduit, if any, should be utilized as a source for token approvals when performing transfers. By default (i.e. when conduitKey is set to the zero hash), the offerer will grant ERC20, ERC721, and ERC1155 token approvals to Seaport directly so that it can perform any transfers specified by the order during fulfillment. In contrast, an offerer that elects to utilize a conduit will grant token approvals to the conduit contract corresponding to the supplied conduit key, and Seaport will then instruct that conduit to transfer the respective tokens.
The nonce indicates a value that must match the current nonce for the given offerer.

订单完成度 Order Fulfillment

订单通过以下四种方法之一完成： Orders are fulfilled via one of four methods:

• 调用两个“标准”函数中的一个，fulfillOrder``fulfillAdvancedOrder，其中将构造第二个隐含订单，调用者作为要约人，已履行订单的consideration作为要约，已履行订单的要约作为consideration（使用“高级” 订单包含应与一组“标准解析器”一起填写的部分，这些“标准解析器”为已履行订单上的每个基于标准的项目指定一个标识符和相应的包含证明）。所有offer项目将从订单的提供者转移到履行者，然后所有consideration项目将从履行者转移到指定的接收者。

Calling one of two "standard" functions, fulfillOrder and fulfillAdvancedOrder, where a second implied order will be constructed with the caller as the offerer, the consideration of the fulfilled order as the offer, and the offer of the fulfilled order as the consideration (with "advanced" orders containing the fraction that should be filled alongside a set of "criteria resolvers" that designate an identifier and a corresponding inclusion proof for each criteria-based item on the fulfilled order). All offer items will be transferred from the offerer of the order to the fulfiller, then all consideration items will be transferred from the fulfiller to the named recipient.

• 调用“基本”函数，fulfillBasicOrder提供六种基本路线类型之一（ETH_TO_ERC721``ETH_TO_ERC1155``ERC20_TO_ERC721``ERC20_TO_ERC1155``ERC721_TO_ERC20``ERC1155_TO_ERC20），将从组件子集派生要履行的订单，假设相关订单符合以下条件：
  • 该订单仅包含一个offer项目，并且包含至少一个consideration项目。
  • 该订单仅包含一个 ERC721 或 ERC1155 项目，并且该项目不是基于标准的。
  • 订单的提供者是第一consideration项目的接收者。
  • 所有其他物品都具有相同的以太币（或其他原生代币）或 ERC20 物品类型和代币。
  • 该订单不提供以以太币（或其他原生代币）作为其商品类型的商品。
  • 每个项目上的startAmount``endAmount必须与该项目匹配（即项目不能有升序/降序数量）。
  • 所有“忽略”的项目字段（即token``identifierOrCriteria原生项目和identifierOrCriteriaERC20项目）都设置为空地址或零。
  • 如果订单中有 ERC721 商品，则该商品的金额为.1
  • 如果订单有多个consideration项目，且除第一consideration项目外的所有consideration项目与offer项目的项目类型相同，offer项目数量不小于除第一consideration项目数量外的所有consideration项目数量之和。

Calling the "basic" function, fulfillBasicOrder with one of six basic route types supplied (ETH_TO_ERC721, ETH_TO_ERC1155, ERC20_TO_ERC721, ERC20_TO_ERC1155, ERC721_TO_ERC20, and ERC1155_TO_ERC20) will derive the order to fulfill from a subset of components, assuming the order in question adheres to the following:
The order only contains a single offer item and contains at least one consideration item.
The order contains exactly one ERC721 or ERC1155 item and that item is not criteria-based.
The offerer of the order is the recipient of the first consideration item.
All other items have the same Ether (or other native tokens) or ERC20 item type and token.
The order does not offer an item with Ether (or other native tokens) as its item type.
The startAmount on each item must match that item's endAmount (i.e. items cannot have an ascending/descending amount).
All "ignored" item fields (i.e. token and identifierOrCriteria on native items and identifierOrCriteria on ERC20 items) are set to the null address or zero.
If the order has an ERC721 item, that item has an amount of 1.
If the order has multiple consideration items and all consideration items other than the first consideration item have the same item type as the offered item, the offered item amount is not less than the sum of all consideration item amounts excluding the first consideration item amount.

• 调用两个“可用履行”函数中fulfillAvailableOrders``fulfillAvailableAdvancedOrders的一个，并且，其中一组订单与一组履行一起提供，指定哪些offer项目可以聚合到不同的转移中，哪些consideration项目可以相应地聚合，以及任何订单已经已取消、有无效时间或已被完全执行将被跳过，而不会导致其余可用订单恢复。此外，一旦找到maximumFulfilled可用订单，任何剩余的订单都将被跳过。与标准履行方法类似，所有offer项目将从各自的offer者转移到履行者，然后所有consideration项目将从履行者转移到指定的接收者。

Calling one of two "fulfill available" functions, fulfillAvailableOrders and fulfillAvailableAdvancedOrders, where a group of orders are supplied alongside a group of fulfillments specifying which offer items can be aggregated into distinct transfers and which consideration items can be accordingly aggregated, and where any orders that have been cancelled, have an invalid time, or have already been fully filled will be skipped without causing the rest of the available orders to revert. Additionally, any remaining orders will be skipped once maximumFulfilled available orders have been located. Similar to the standard fulfillment method, all offer items will be transferred from the respective offerer to the fulfiller, then all consideration items will be transferred from the fulfiller to the named recipient.

• 调用两个“匹配”函数中的一个，并且，matchOrders``matchAdvancedOrders其中一组明确的订单与一组履行指定哪些offer项目适用于哪些consideration项目一起提供（并且“高级”案例以与标准类似的方式运行方法，但支持通过提供的numerator``denominator和小数值以及一个可选extraData参数进行部分填充，当满足受限订单类型时，该参数isValidOrderIncludingExtraData将作为调用区域上的视图函数的一部分提供）。请注意，以这种方式履行的订单没有明确的履行者；相反，Seaport 将简单地确保每个订单的需求一致。

Calling one of two "match" functions, matchOrders and matchAdvancedOrders, where a group of explicit orders are supplied alongside a group of fulfillments specifying which offer items to apply to which consideration items (and with the "advanced" case operating in a similar fashion to the standard method, but supporting partial fills via supplied numerator and denominator fractional values as well as an optional extraData argument that will be supplied as part of a call to the isValidOrderIncludingExtraData view function on the zone when fulfilling restricted order types). Note that orders fulfilled in this manner do not have an explicit fulfiller; instead, Seaport will simply ensure coincidence of wants across each order.
虽然标准方法在技术上可用于履行任何订单，但在某些情况下存在关键效率限制：
While the standard method can technically be used for fulfilling any order, it suffers from key efficiency limitations in certain scenarios:

• 与简单“热路径”的基本方法相比，它需要额外的调用数据。
• 它要求履行者批准每个consideration项目，即使consideration项目可以使用offer项目来履行（在履行为 ERC721 或 ERC1155 项目提供 ERC20 项目并且还包括具有相同的consideration项目的订单时通常是这种情况用于支付费用的 ERC20 项目类型）。
• 它可能导致不必要的转移，而在“匹配”情况下，这些转移可以减少到更小的集合。
  It requires additional calldata compared to the basic method for simple "hot paths".
  It requires the fulfiller to approve each consideration item, even if the consideration item can be fulfilled using an offer item (as is commonly the case when fulfilling an order that offers ERC20 items for an ERC721 or ERC1155 item and also includes consideration items with the same ERC20 item type for paying fees).
  It can result in unnecessary transfers, whereas in the "match" case those transfers can be reduced to a more minimal set.

余额和批准要求 Balance & Approval Requirements

创建offer时，应检查以下要求以确保订单可以履行：
When creating an offer, the following requirements should be checked to ensure that the order will be fulfillable:

• 提供者应在所有提供的项目中有足够的余额。
  The offerer should have sufficient balance of all offered items.
• 如果订单未指示使用管道，则要约人应为所有提供的 ERC20、ERC721 和 ERC1155 项目的 Seaport 合同设置足够的批准。
  If the order does not indicate to use a conduit, the offerer should have sufficient approvals set for the Seaport contract for all offered ERC20, ERC721, and ERC1155 items.
• 如果订单确实表明使用管道，则要约人应为所有提供的 ERC20、ERC721 和 ERC1155 项目的相应管道合同设置足够的批准。
  If the order does indicate to use a conduit, the offerer should have sufficient approvals set for the respective conduit contract for all offered ERC20, ERC721 and ERC1155 items.

履行基本订单时，需要检查以下要求以确保订单可以履行：
When fulfilling a basic order, the following requirements need to be checked to ensure that the order will be fulfillable:

• 需要进行上述检查以确保要约人仍有足够的余额和批准。
• 履行者应该对所有consideration项目有足够的余额，除了那些项目类型与订单提供的项目类型相匹配的项目——例如，如果履行的订单提供 ERC20 项目，并且要求提供者提供 ERC721 项目和相同的 ERC20项目到另一个收件人，履行者需要拥有 ERC721 项目，但不需要拥有 ERC20 项目，因为它将来自提供者。
• 如果履行者不选择使用管道，他们需要为已履行订单上的所有 ERC20、ERC721 和 ERC1155 consideration项目设置足够的seaport合同批准，但项目类型与订单提供的项目匹配的 ERC20 项目除外类型。
• 如果履行者确实选择使用管道，则他们需要为已履行订单上的所有 ERC20、ERC721 和 ERC1155 consideration项目为其各自的管道设置足够的批准，但项目类型与订单提供的项目类型匹配的 ERC20 项目除外.
• 如果已履行的订单将以太币（或其他原生代币）指定为consideration项目，则履行者必须能够将这些项目的总和提供为msg.value
  The above checks need to be performed to ensure that the offerer still has sufficient balance and approvals.
  The fulfiller should have sufficient balance of all consideration items except for those with an item type that matches the order's offered item type — by way of example, if the fulfilled order offers an ERC20 item and requires an ERC721 item to the offerer and the same ERC20 item to another recipient, the fulfiller needs to own the ERC721 item but does not need to own the ERC20 item as it will be sourced from the offerer.
  If the fulfiller does not elect to utilize a conduit, they need to have sufficient approvals set for the Seaport contract for all ERC20, ERC721, and ERC1155 consideration items on the fulfilled order except for ERC20 items with an item type that matches the order's offered item type.
  If the fulfiller does elect to utilize a conduit, they need to have sufficient approvals set for their respective conduit for all ERC20, ERC721, and ERC1155 consideration items on the fulfilled order except for ERC20 items with an item type that matches the order's offered item type.
  If the fulfilled order specifies Ether (or other native tokens) as consideration items, the fulfiller must be able to supply the sum total of those items as msg.value.

履行标准订单时，需要检查以下要求以确保订单可以履行：
When fulfilling a standard order, the following requirements need to be checked to ensure that the order will be fulfillable:

• 需要进行上述检查以确保要约人仍有足够的余额和批准。
• 在收到所有提供的物品后，履行者应该对所有consideration项目有足够的余额——例如，如果履行的订单提供了 ERC20 物品，并且需要向提供者提供 ERC721 物品，并且向另一个接收者提供相同的 ERC20 物品，金额小于或等于提供的金额，履行者不需要拥有 ERC20 项目，因为它将首先从提供者处收到。
• 如果履行者不选择使用管道，他们需要为已履行订单上的所有 ERC20、ERC721 和 ERC1155 consideration项目的seaport合同设置足够的批准。
• 如果履行者确实选择使用管道，则他们需要为已履行订单上的所有 ERC20、ERC721 和 ERC1155 consideration项目为其各自的管道设置足够的批准。
• 如果已履行的订单将以太币（或其他原生代币）指定为consideration项目，则履行者必须能够将这些项目的总和提供为.msg.value
  The above checks need to be performed to ensure that the offerer still has sufficient balance and approvals.
  The fulfiller should have sufficient balance of all consideration items after receiving all offered items — by way of example, if the fulfilled order offers an ERC20 item and requires an ERC721 item to the offerer and the same ERC20 item to another recipient with an amount less than or equal to the offered amount, the fulfiller does not need to own the ERC20 item as it will first be received from the offerer.
  If the fulfiller does not elect to utilize a conduit, they need to have sufficient approvals set for the Seaport contract for all ERC20, ERC721, and ERC1155 consideration items on the fulfilled order.
  If the fulfiller does elect to utilize a conduit, they need to have sufficient approvals set for their respective conduit for all ERC20, ERC721, and ERC1155 consideration items on the fulfilled order.
  If the fulfilled order specifies Ether (or other native tokens) as consideration items, the fulfiller must be able to supply the sum total of those items as msg.value.

在履行一组匹配订单时，需要检查以下要求以确保订单可以履行：
When fulfilling a set of match orders, the following requirements need to be checked to ensure that the order will be fulfillable:

• 为将作为履行的一部分执行的执行采购 ERC20、ERC721 或 ERC1155 项目的每个帐户必须在触发执行时在 Seaport 或指定的渠道上具有足够的余额和批准。请注意，先前的执行可能会为后续执行提供必要的平衡。
• 涉及以太币（或其他原生代币）的所有执行的总和必须以. 请注意，提供者和接收者是同一帐户的执行将从最终执行集中被过滤掉。msg.value
  Each account that sources the ERC20, ERC721, or ERC1155 item for an execution that will be performed as part of the fulfillment must have sufficient balance and approval on Seaport or the indicated conduit at the time the execution is triggered. Note that prior executions may supply the necessary balance for subsequent executions.
  The sum total of all executions involving Ether (or other native tokens) must be supplied as msg.value. Note that executions where the offerer and the recipient are the same account will be filtered out of the final execution set.

部分填充 Partial Fills

在构建订单时，offer方可以选择通过设置适当的订单类型来启用部分成交。然后，支持部分执行的订单可以在相应订单的一部分中执行，从而允许后续执行绕过签名验证。总结一下部分填充的几个关键点：
When constructing an order, the offerer may elect to enable partial fills by setting an appropriate order type. Then, orders that support partial fills can be fulfilled for some fraction of the respective order, allowing subsequent fills to bypass signature verification. To summarize a few key points on partial fills:

• 当创建支持部分成交的定单或确定要在这些定单上成交的分数时，定单上的所有项目（offer和consideration）必须完全可被提供的分数整除（即除法后没有余数）。
• 如果要填写的所需部分会导致要填写的订单数量超过全部订单数量，则该部分将减少为剩余要填写的数量。这适用于部分填充尝试和完全填充尝试。如果不需要这种行为（即填充应该是“全部或无”），则履行者可以使用“基本”订单方法（如果可用）（这需要填写全部订单金额），或使用“匹配” order 方法，并明确提供一个要求收到全部所需金额的订单。
  • 举例来说：如果一个履行者尝试履行订单的 1/2，但另一个履行者首先履行订单的 3/4，则原始履行者最终将履行订单的 1/4。
• 如果部分可成交订单上的任何项目指定了不同的“startAmount”和“endAmount”（例如，它们是递增数量或递减数量的项目），则在确定当前价格之前，该分数将应用于这两个数量。这确保了在构建订单时可以选择完全可分的数量，而不依赖于最终完成订单的时间。
• 部分填写可以与基于标准的项目组合，以支持构建提供或接收多个项目的订单，否则这些项目将无法部分填写（例如 ERC721 项目）。
  • 举个例子：offer者可以创建一个部分可成交的订单，为给定集合中最多 10 个 ERC721 项目提供最多 10 个 ETH；然后，任何履行者都可以履行该订单的一部分，直到它被完全履行（或取消）。
    When creating orders that support partial fills or determining a fraction to fill on those orders, all items (both offer and consideration) on the order must be cleanly divisible by the supplied fraction (i.e. no remainder after division).
    If the desired fraction to fill would result in more than the full order amount being filled, that fraction will be reduced to the amount remaining to fill. This applies to both partial fill attempts as well as full fill attempts. If this behavior is not desired (i.e. the fill should be "all or none"), the fulfiller can either use a "basic" order method if available (which requires that the full order amount be filled), or use the "match" order method and explicitly provide an order that requires the full desired amount be received back.
    By way of example: if one fulfiller tries to fill 1/2 of an order but another fulfiller first fills 3/4 of the order, the original fulfiller will end up filling 1/4 of the order.
    If any of the items on a partially fillable order specify a different "startAmount" and "endAmount (e.g. they are ascending-amount or descending-amount items), the fraction will be applied to both amounts prior to determining the current price. This ensures that cleanly divisible amounts can be chosen when constructing the order without a dependency on the time when the order is ultimately fulfilled.
    Partial fills can be combined with criteria-based items to enable constructing orders that offer or receive multiple items that would otherwise not be partially fillable (e.g. ERC721 items).
    By way of example: an offerer can create a partially fillable order to supply up to 10 ETH for up to 10 ERC721 items from a given collection; then, any fulfiller can fill a portion of that order until it has been fully filled (or cancelled).

Sequence of Events 事件顺序

履行订单 Fulfill Order

通过fulfillOrder``fulfillAdvancedOrder 履行订单

1. 哈希顺序

   • 为offer项目和consideration项目派生哈希
   • 检索提议者的当前随机数
   • 导出订单哈希
     Hash order
     Derive hashes for offer items and consideration items
     Retrieve current nonce for the offerer
     Derive hash for order

2. 执行初始验证

   • 确保当前时间在订单范围内
   • 确保订单类型的调用者有效；如果订单类型受限且调用方不是offerer或zone，调用zone判断订单是否有效
     Perform initial validation
     Ensure current time is inside order range
     Ensure valid caller for the order type; if the order type is restricted and the caller is not the offerer or the zone, call the zone to determine whether the order is valid

3. 检索和更新订单状态

   • 确保订单不被取消
   • 确保订单未满
     • 如果订单部分成交，必要时减少提供的成交量，以免订单被超额成交
   • 如果尚未验证，请验证订单签名
   • 根据偏好 + 可用数量确定要填充的分数
   • 更新订单状态（已验证 + 成交率）
     Retrieve and update order status
     Ensure order is not cancelled
     Ensure order is not fully filled
     If the order is partially filled, reduce the supplied fill amount if necessary so that the order is not overfilled
     Verify the order signature if not already validated
     Determine fraction to fill based on preference + available amount
     Update order status (validated + fill fraction)

4. 确定每个项目的金额

   • 比较起始金额和结束金额
     • 如果它们相等：将填充分数应用于任何一个，确保它干净地划分，并使用该数量
     • 如果不是：将填充分数应用于两者，确保它们都干净地划分，然后根据当前时间找到线性拟合
       Determine amount for each item
       Compare start amount and end amount
       if they are equal: apply fill fraction to either one, ensure it divides cleanly, and use that amount
       if not: apply fill fraction to both, ensuring they both divide cleanly, then find linear fit based on current time

5. 应用标准解析器

   • 确保每个标准解析器都引用基于标准的订单项
   • 如果项目具有非零标准根，则通过包含证明确保为每个项目提供的标识符有效
   • 更新每个项目类型和标识符
   • 确保所有剩余项目均不基于标准
     Apply criteria resolvers
     Ensure each criteria resolver refers to a criteria-based order item
     Ensure the supplied identifier for each item is valid via inclusion proof if the item has a non-zero criteria root
     Update each item type and identifier
     Ensure all remaining items are non-criteria-based

6. 发出 OrderFulfilled 事件

   • 包括更新的项目（即在金额调整和标准解决之后）
     Emit OrderFulfilled event
     Include updated items (i.e. after amount adjustment and criteria resolution)

7. 将要约项目从要约人转移到来电者

   • 根据订单类型，直接使用管道或seaport获得批准
     Transfer offer items from offerer to caller
     Use either conduit or Seaport directly to source approvals, depending on order type

8. 将consideration项目从呼叫者转移到相应的接收者

   • 使用管道或seaport直接获得批准，具体取决于履行者声明的偏好
     Transfer considerati