@opensea/seaport-js 1.0.0 → 1.0.1-beta.0

package/lib/utils/balanceAndApprovalCheck.d.ts

@@ -1,108 +1,108 @@
-import { providers as multicallProviders } from "@0xsequence/multicall";
-import { BigNumber } from "ethers";
-import { ItemType } from "../constants";
-import type { InputCriteria, Item, OrderParameters } from "../types";
-import { getSummedTokenAndIdentifierAmounts, TimeBasedItemParams } from "./item";
-export declare type BalancesAndApprovals = {
-    token: string;
-    identifierOrCriteria: string;
-    balance: BigNumber;
-    approvedAmount: BigNumber;
-    itemType: ItemType;
-}[];
-export declare type InsufficientBalances = {
-    token: string;
-    identifierOrCriteria: string;
-    requiredAmount: BigNumber;
-    amountHave: BigNumber;
-    itemType: ItemType;
-}[];
-export declare type InsufficientApprovals = {
-    token: string;
-    identifierOrCriteria: string;
-    approvedAmount: BigNumber;
-    requiredApprovedAmount: BigNumber;
-    operator: string;
-    itemType: ItemType;
-}[];
-export declare const getBalancesAndApprovals: ({ owner, items, criterias, operator, multicallProvider, }: {
-    owner: string;
-    items: Item[];
-    criterias: InputCriteria[];
-    operator: string;
-    multicallProvider: multicallProviders.MulticallProvider;
-}) => Promise<BalancesAndApprovals>;
-export declare const getInsufficientBalanceAndApprovalAmounts: ({ balancesAndApprovals, tokenAndIdentifierAmounts, operator, }: {
-    balancesAndApprovals: BalancesAndApprovals;
-    tokenAndIdentifierAmounts: ReturnType<typeof getSummedTokenAndIdentifierAmounts>;
-    operator: string;
-}) => {
-    insufficientBalances: InsufficientBalances;
-    insufficientApprovals: InsufficientApprovals;
-};
-/**
- * 1. The offerer should have sufficient balance of all offered items.
- * 2. If the order does not indicate proxy utilization, the offerer should have sufficient approvals set
- *    for the Seaport contract for all offered ERC20, ERC721, and ERC1155 items.
- * 3. If the order does indicate proxy utilization, the offerer should have sufficient approvals set
- *    for their respective proxy contract for all offered ERC20, ERC721, and ERC1155 items.
- */
-export declare const validateOfferBalancesAndApprovals: ({ offer, criterias, balancesAndApprovals, timeBasedItemParams, throwOnInsufficientBalances, throwOnInsufficientApprovals, operator, }: {
-    balancesAndApprovals: BalancesAndApprovals;
-    timeBasedItemParams?: TimeBasedItemParams | undefined;
-    throwOnInsufficientBalances?: boolean | undefined;
-    throwOnInsufficientApprovals?: boolean | undefined;
-    operator: string;
-} & Pick<OrderParameters, "offer"> & {
-    criterias: InputCriteria[];
-}) => InsufficientApprovals;
-/**
- * When fulfilling a basic order, the following requirements need to be checked to ensure that the order will be fulfillable:
- * 1. Offer checks need to be performed to ensure that the offerer still has sufficient balance and approvals
- * 2. 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.
- * 3. If the fulfiller does not elect to utilize a proxy, 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.
- * 4. If the fulfiller does elect to utilize a proxy, they need to have sufficient approvals set for their
- *    respective proxy 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.
- * 5. 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.
- *
- * @returns the list of insufficient owner and proxy approvals
- */
-export declare const validateBasicFulfillBalancesAndApprovals: ({ offer, consideration, offererBalancesAndApprovals, fulfillerBalancesAndApprovals, timeBasedItemParams, offererOperator, fulfillerOperator, }: {
-    offererBalancesAndApprovals: BalancesAndApprovals;
-    fulfillerBalancesAndApprovals: BalancesAndApprovals;
-    timeBasedItemParams: TimeBasedItemParams;
-    offererOperator: string;
-    fulfillerOperator: string;
-} & Pick<OrderParameters, "offer" | "consideration">) => InsufficientApprovals;
-/**
- * When fulfilling a standard order, the following requirements need to be checked to ensure that the order will be fulfillable:
- * 1. Offer checks need to be performed to ensure that the offerer still has sufficient balance and approvals
- * 2. 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.
- * 3. If the fulfiller does not elect to utilize a proxy, they need to have sufficient approvals set for the
- *    Seaport contract for all ERC20, ERC721, and ERC1155 consideration items on the fulfilled order.
- * 4. If the fulfiller does elect to utilize a proxy, they need to have sufficient approvals set for their
- *    respective proxy contract for all ERC20, ERC721, and ERC1155 consideration items on the fulfilled order.
- * 5. 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.
- *
- * @returns the list of insufficient owner and proxy approvals
- */
-export declare const validateStandardFulfillBalancesAndApprovals: ({ offer, consideration, offerCriteria, considerationCriteria, offererBalancesAndApprovals, fulfillerBalancesAndApprovals, timeBasedItemParams, offererOperator, fulfillerOperator, }: Pick<OrderParameters, "offer" | "consideration"> & {
-    offerCriteria: InputCriteria[];
-    considerationCriteria: InputCriteria[];
-    offererBalancesAndApprovals: BalancesAndApprovals;
-    fulfillerBalancesAndApprovals: BalancesAndApprovals;
-    timeBasedItemParams: TimeBasedItemParams;
-    offererOperator: string;
-    fulfillerOperator: string;
-}) => InsufficientApprovals;
+import { providers as multicallProviders } from "@0xsequence/multicall";
+import { BigNumber } from "ethers";
+import { ItemType } from "../constants";
+import type { InputCriteria, Item, OrderParameters } from "../types";
+import { getSummedTokenAndIdentifierAmounts, TimeBasedItemParams } from "./item";
+export declare type BalancesAndApprovals = {
+    token: string;
+    identifierOrCriteria: string;
+    balance: BigNumber;
+    approvedAmount: BigNumber;
+    itemType: ItemType;
+}[];
+export declare type InsufficientBalances = {
+    token: string;
+    identifierOrCriteria: string;
+    requiredAmount: BigNumber;
+    amountHave: BigNumber;
+    itemType: ItemType;
+}[];
+export declare type InsufficientApprovals = {
+    token: string;
+    identifierOrCriteria: string;
+    approvedAmount: BigNumber;
+    requiredApprovedAmount: BigNumber;
+    operator: string;
+    itemType: ItemType;
+}[];
+export declare const getBalancesAndApprovals: ({ owner, items, criterias, operator, multicallProvider, }: {
+    owner: string;
+    items: Item[];
+    criterias: InputCriteria[];
+    operator: string;
+    multicallProvider: multicallProviders.MulticallProvider;
+}) => Promise<BalancesAndApprovals>;
+export declare const getInsufficientBalanceAndApprovalAmounts: ({ balancesAndApprovals, tokenAndIdentifierAmounts, operator, }: {
+    balancesAndApprovals: BalancesAndApprovals;
+    tokenAndIdentifierAmounts: ReturnType<typeof getSummedTokenAndIdentifierAmounts>;
+    operator: string;
+}) => {
+    insufficientBalances: InsufficientBalances;
+    insufficientApprovals: InsufficientApprovals;
+};
+/**
+ * 1. The offerer should have sufficient balance of all offered items.
+ * 2. If the order does not indicate proxy utilization, the offerer should have sufficient approvals set
+ *    for the Seaport contract for all offered ERC20, ERC721, and ERC1155 items.
+ * 3. If the order does indicate proxy utilization, the offerer should have sufficient approvals set
+ *    for their respective proxy contract for all offered ERC20, ERC721, and ERC1155 items.
+ */
+export declare const validateOfferBalancesAndApprovals: ({ offer, criterias, balancesAndApprovals, timeBasedItemParams, throwOnInsufficientBalances, throwOnInsufficientApprovals, operator, }: {
+    balancesAndApprovals: BalancesAndApprovals;
+    timeBasedItemParams?: TimeBasedItemParams | undefined;
+    throwOnInsufficientBalances?: boolean | undefined;
+    throwOnInsufficientApprovals?: boolean | undefined;
+    operator: string;
+} & Pick<OrderParameters, "offer"> & {
+    criterias: InputCriteria[];
+}) => InsufficientApprovals;
+/**
+ * When fulfilling a basic order, the following requirements need to be checked to ensure that the order will be fulfillable:
+ * 1. Offer checks need to be performed to ensure that the offerer still has sufficient balance and approvals
+ * 2. 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.
+ * 3. If the fulfiller does not elect to utilize a proxy, 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.
+ * 4. If the fulfiller does elect to utilize a proxy, they need to have sufficient approvals set for their
+ *    respective proxy 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.
+ * 5. 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.
+ *
+ * @returns the list of insufficient owner and proxy approvals
+ */
+export declare const validateBasicFulfillBalancesAndApprovals: ({ offer, consideration, offererBalancesAndApprovals, fulfillerBalancesAndApprovals, timeBasedItemParams, offererOperator, fulfillerOperator, }: {
+    offererBalancesAndApprovals: BalancesAndApprovals;
+    fulfillerBalancesAndApprovals: BalancesAndApprovals;
+    timeBasedItemParams: TimeBasedItemParams;
+    offererOperator: string;
+    fulfillerOperator: string;
+} & Pick<OrderParameters, "offer" | "consideration">) => InsufficientApprovals;
+/**
+ * When fulfilling a standard order, the following requirements need to be checked to ensure that the order will be fulfillable:
+ * 1. Offer checks need to be performed to ensure that the offerer still has sufficient balance and approvals
+ * 2. 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.
+ * 3. If the fulfiller does not elect to utilize a proxy, they need to have sufficient approvals set for the
+ *    Seaport contract for all ERC20, ERC721, and ERC1155 consideration items on the fulfilled order.
+ * 4. If the fulfiller does elect to utilize a proxy, they need to have sufficient approvals set for their
+ *    respective proxy contract for all ERC20, ERC721, and ERC1155 consideration items on the fulfilled order.
+ * 5. 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.
+ *
+ * @returns the list of insufficient owner and proxy approvals
+ */
+export declare const validateStandardFulfillBalancesAndApprovals: ({ offer, consideration, offerCriteria, considerationCriteria, offererBalancesAndApprovals, fulfillerBalancesAndApprovals, timeBasedItemParams, offererOperator, fulfillerOperator, }: Pick<OrderParameters, "offer" | "consideration"> & {
+    offerCriteria: InputCriteria[];
+    considerationCriteria: InputCriteria[];
+    offererBalancesAndApprovals: BalancesAndApprovals;
+    fulfillerBalancesAndApprovals: BalancesAndApprovals;
+    timeBasedItemParams: TimeBasedItemParams;
+    offererOperator: string;
+    fulfillerOperator: string;
+}) => InsufficientApprovals;

package/lib/utils/criteria.d.ts

@@ -1,14 +1,13 @@
-import { Side } from "../constants";
-import { InputCriteria, Item, Order } from "../types";
-export declare const generateCriteriaResolvers: ({ orders, offerCriterias, considerationCriterias, }: {
-    orders: Order[];
-    offerCriterias?: InputCriteria[][] | undefined;
-    considerationCriterias?: InputCriteria[][] | undefined;
-}) => {
-    orderIndex: number;
-    index: number;
-    side: Side;
-    identifier: string;
-    criteriaProof: string[];
-}[];
-export declare const getItemToCriteriaMap: (items: Item[], criterias: InputCriteria[]) => Map<Item, InputCriteria>;
+import { Side } from "../constants";
+import { InputCriteria, Order } from "../types";
+export declare const generateCriteriaResolvers: ({ orders, offerCriterias, considerationCriterias, }: {
+    orders: Order[];
+    offerCriterias?: InputCriteria[][] | undefined;
+    considerationCriterias?: InputCriteria[][] | undefined;
+}) => {
+    orderIndex: number;
+    index: number;
+    side: Side;
+    identifier: string;
+    criteriaProof: string[];
+}[];

package/lib/utils/fulfill.d.ts

@@ -1,84 +1,84 @@
-import { BigNumber, BigNumberish, providers } from "ethers";
-import type { Seaport as SeaportContract, Seaport, FulfillmentComponentStruct } from "../typechain/Seaport";
-import type { ConsiderationItem, ExchangeAction, InputCriteria, Order, OrderParameters, OrderStatus, OrderUseCase, ContractMethodReturnType } from "../types";
-import { BalancesAndApprovals } from "./balanceAndApprovalCheck";
-import { TimeBasedItemParams } from "./item";
-/**
- * We should use basic fulfill order if the order adheres to the following criteria:
- * 1. The order should not be partially filled.
- * 2. The order only contains a single offer item and contains at least one consideration item
- * 3. The order does not offer an item with Ether (or other native tokens) as its item type.
- * 4. The order only contains a single ERC721 or ERC1155 item and that item is not criteria-based
- * 5. All other items have the same Native or ERC20 item type and token
- * 6. All items have the same startAmount and endAmount
- * 7. First consideration item must contain the offerer as the recipient
- * 8. 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
- * 9. The token on native currency items needs to be set to the null address and the identifier on
- *    currencies needs to be zero, and the amounts on the 721 item need to be 1
- */
-export declare const shouldUseBasicFulfill: ({ offer, consideration, offerer }: OrderParameters, totalFilled: OrderStatus["totalFilled"]) => boolean;
-export declare function fulfillBasicOrder({ order, seaportContract, offererBalancesAndApprovals, fulfillerBalancesAndApprovals, timeBasedItemParams, offererOperator, fulfillerOperator, signer, tips, conduitKey, }: {
-    order: Order;
-    seaportContract: Seaport;
-    offererBalancesAndApprovals: BalancesAndApprovals;
-    fulfillerBalancesAndApprovals: BalancesAndApprovals;
-    timeBasedItemParams: TimeBasedItemParams;
-    offererOperator: string;
-    fulfillerOperator: string;
-    signer: providers.JsonRpcSigner;
-    tips?: ConsiderationItem[];
-    conduitKey: string;
-}): Promise<OrderUseCase<ExchangeAction<ContractMethodReturnType<SeaportContract, "fulfillBasicOrder">>>>;
-export declare function fulfillStandardOrder({ order, unitsToFill, totalSize, totalFilled, offerCriteria, considerationCriteria, tips, extraData, seaportContract, offererBalancesAndApprovals, fulfillerBalancesAndApprovals, offererOperator, fulfillerOperator, timeBasedItemParams, conduitKey, recipientAddress, signer, }: {
-    order: Order;
-    unitsToFill?: BigNumberish;
-    totalFilled: BigNumber;
-    totalSize: BigNumber;
-    offerCriteria: InputCriteria[];
-    considerationCriteria: InputCriteria[];
-    tips?: ConsiderationItem[];
-    extraData?: string;
-    seaportContract: Seaport;
-    offererBalancesAndApprovals: BalancesAndApprovals;
-    fulfillerBalancesAndApprovals: BalancesAndApprovals;
-    offererOperator: string;
-    fulfillerOperator: string;
-    conduitKey: string;
-    recipientAddress: string;
-    timeBasedItemParams: TimeBasedItemParams;
-    signer: providers.JsonRpcSigner;
-}): Promise<OrderUseCase<ExchangeAction<ContractMethodReturnType<SeaportContract, "fulfillAdvancedOrder" | "fulfillOrder">>>>;
-export declare function validateAndSanitizeFromOrderStatus(order: Order, orderStatus: OrderStatus): Order;
-export declare type FulfillOrdersMetadata = {
-    order: Order;
-    unitsToFill?: BigNumberish;
-    orderStatus: OrderStatus;
-    offerCriteria: InputCriteria[];
-    considerationCriteria: InputCriteria[];
-    tips: ConsiderationItem[];
-    extraData: string;
-    offererBalancesAndApprovals: BalancesAndApprovals;
-    offererOperator: string;
-}[];
-export declare function fulfillAvailableOrders({ ordersMetadata, seaportContract, fulfillerBalancesAndApprovals, fulfillerOperator, currentBlockTimestamp, ascendingAmountTimestampBuffer, conduitKey, signer, recipientAddress, }: {
-    ordersMetadata: FulfillOrdersMetadata;
-    seaportContract: Seaport;
-    fulfillerBalancesAndApprovals: BalancesAndApprovals;
-    fulfillerOperator: string;
-    currentBlockTimestamp: number;
-    ascendingAmountTimestampBuffer: number;
-    conduitKey: string;
-    signer: providers.JsonRpcSigner;
-    recipientAddress: string;
-}): Promise<OrderUseCase<ExchangeAction<ContractMethodReturnType<SeaportContract, "fulfillAvailableAdvancedOrders">>>>;
-export declare function generateFulfillOrdersFulfillments(ordersMetadata: FulfillOrdersMetadata): {
-    offerFulfillments: FulfillmentComponentStruct[];
-    considerationFulfillments: FulfillmentComponentStruct[];
-};
-export declare const getAdvancedOrderNumeratorDenominator: (order: Order, unitsToFill?: BigNumberish | undefined) => {
-    numerator: BigNumber;
-    denominator: BigNumber;
-};
+import { BigNumber, BigNumberish, providers } from "ethers";
+import type { Seaport as SeaportContract, Seaport, FulfillmentComponentStruct } from "../typechain/Seaport";
+import type { ConsiderationItem, ExchangeAction, InputCriteria, Order, OrderParameters, OrderStatus, OrderUseCase, ContractMethodReturnType } from "../types";
+import { BalancesAndApprovals } from "./balanceAndApprovalCheck";
+import { TimeBasedItemParams } from "./item";
+/**
+ * We should use basic fulfill order if the order adheres to the following criteria:
+ * 1. The order should not be partially filled.
+ * 2. The order only contains a single offer item and contains at least one consideration item
+ * 3. The order does not offer an item with Ether (or other native tokens) as its item type.
+ * 4. The order only contains a single ERC721 or ERC1155 item and that item is not criteria-based
+ * 5. All other items have the same Native or ERC20 item type and token
+ * 6. All items have the same startAmount and endAmount
+ * 7. First consideration item must contain the offerer as the recipient
+ * 8. 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
+ * 9. The token on native currency items needs to be set to the null address and the identifier on
+ *    currencies needs to be zero, and the amounts on the 721 item need to be 1
+ */
+export declare const shouldUseBasicFulfill: ({ offer, consideration, offerer }: OrderParameters, totalFilled: OrderStatus["totalFilled"]) => boolean;
+export declare function fulfillBasicOrder({ order, seaportContract, offererBalancesAndApprovals, fulfillerBalancesAndApprovals, timeBasedItemParams, offererOperator, fulfillerOperator, signer, tips, conduitKey, }: {
+    order: Order;
+    seaportContract: Seaport;
+    offererBalancesAndApprovals: BalancesAndApprovals;
+    fulfillerBalancesAndApprovals: BalancesAndApprovals;
+    timeBasedItemParams: TimeBasedItemParams;
+    offererOperator: string;
+    fulfillerOperator: string;
+    signer: providers.JsonRpcSigner;
+    tips?: ConsiderationItem[];
+    conduitKey: string;
+}): Promise<OrderUseCase<ExchangeAction<ContractMethodReturnType<SeaportContract, "fulfillBasicOrder">>>>;
+export declare function fulfillStandardOrder({ order, unitsToFill, totalSize, totalFilled, offerCriteria, considerationCriteria, tips, extraData, seaportContract, offererBalancesAndApprovals, fulfillerBalancesAndApprovals, offererOperator, fulfillerOperator, timeBasedItemParams, conduitKey, recipientAddress, signer, }: {
+    order: Order;
+    unitsToFill?: BigNumberish;
+    totalFilled: BigNumber;
+    totalSize: BigNumber;
+    offerCriteria: InputCriteria[];
+    considerationCriteria: InputCriteria[];
+    tips?: ConsiderationItem[];
+    extraData?: string;
+    seaportContract: Seaport;
+    offererBalancesAndApprovals: BalancesAndApprovals;
+    fulfillerBalancesAndApprovals: BalancesAndApprovals;
+    offererOperator: string;
+    fulfillerOperator: string;
+    conduitKey: string;
+    recipientAddress: string;
+    timeBasedItemParams: TimeBasedItemParams;
+    signer: providers.JsonRpcSigner;
+}): Promise<OrderUseCase<ExchangeAction<ContractMethodReturnType<SeaportContract, "fulfillAdvancedOrder" | "fulfillOrder">>>>;
+export declare function validateAndSanitizeFromOrderStatus(order: Order, orderStatus: OrderStatus): Order;
+export declare type FulfillOrdersMetadata = {
+    order: Order;
+    unitsToFill?: BigNumberish;
+    orderStatus: OrderStatus;
+    offerCriteria: InputCriteria[];
+    considerationCriteria: InputCriteria[];
+    tips: ConsiderationItem[];
+    extraData: string;
+    offererBalancesAndApprovals: BalancesAndApprovals;
+    offererOperator: string;
+}[];
+export declare function fulfillAvailableOrders({ ordersMetadata, seaportContract, fulfillerBalancesAndApprovals, fulfillerOperator, currentBlockTimestamp, ascendingAmountTimestampBuffer, conduitKey, signer, recipientAddress, }: {
+    ordersMetadata: FulfillOrdersMetadata;
+    seaportContract: Seaport;
+    fulfillerBalancesAndApprovals: BalancesAndApprovals;
+    fulfillerOperator: string;
+    currentBlockTimestamp: number;
+    ascendingAmountTimestampBuffer: number;
+    conduitKey: string;
+    signer: providers.JsonRpcSigner;
+    recipientAddress: string;
+}): Promise<OrderUseCase<ExchangeAction<ContractMethodReturnType<SeaportContract, "fulfillAvailableAdvancedOrders">>>>;
+export declare function generateFulfillOrdersFulfillments(ordersMetadata: FulfillOrdersMetadata): {
+    offerFulfillments: FulfillmentComponentStruct[];
+    considerationFulfillments: FulfillmentComponentStruct[];
+};
+export declare const getAdvancedOrderNumeratorDenominator: (order: Order, unitsToFill?: BigNumberish | undefined) => {
+    numerator: BigNumber;
+    denominator: BigNumber;
+};

package/lib/utils/gcd.d.ts

@@ -1,3 +1,3 @@
-import { BigNumber, BigNumberish } from "ethers";
-export declare const gcd: (a: BigNumberish, b: BigNumberish) => BigNumber;
-export declare const findGcd: (elements: BigNumberish[]) => BigNumber;
+import { BigNumber, BigNumberish } from "ethers";
+export declare const gcd: (a: BigNumberish, b: BigNumberish) => BigNumber;
+export declare const findGcd: (elements: BigNumberish[]) => BigNumber;

package/lib/utils/item.d.ts

@@ -1,29 +1,30 @@
-import { BigNumber } from "ethers";
-import type { InputCriteria, Item, Order, OrderParameters } from "../types";
-export declare const isCurrencyItem: ({ itemType }: Item) => boolean;
-export declare const isNativeCurrencyItem: ({ itemType }: Item) => boolean;
-export declare const isErc20Item: (itemType: Item["itemType"]) => boolean;
-export declare const isErc721Item: (itemType: Item["itemType"]) => boolean;
-export declare const isErc1155Item: (itemType: Item["itemType"]) => boolean;
-export declare const isCriteriaItem: (itemType: Item["itemType"]) => boolean;
-export declare type TimeBasedItemParams = {
-    isConsiderationItem?: boolean;
-    currentBlockTimestamp: number;
-    ascendingAmountTimestampBuffer: number;
-} & Pick<OrderParameters, "startTime" | "endTime">;
-export declare const getPresentItemAmount: ({ startAmount, endAmount, timeBasedItemParams, }: Pick<Item, "startAmount" | "endAmount"> & {
-    timeBasedItemParams?: TimeBasedItemParams | undefined;
-}) => BigNumber;
-export declare const getSummedTokenAndIdentifierAmounts: ({ items, criterias, timeBasedItemParams, }: {
-    items: Item[];
-    criterias: InputCriteria[];
-    timeBasedItemParams?: TimeBasedItemParams | undefined;
-}) => Record<string, Record<string, BigNumber>>;
-/**
- * Returns the maximum size of units possible for 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.
- */
-export declare const getMaximumSizeForOrder: ({ parameters: { offer, consideration }, }: Order) => BigNumber;
+import { BigNumber } from "ethers";
+import type { InputCriteria, Item, Order, OrderParameters } from "../types";
+export declare const isCurrencyItem: ({ itemType }: Item) => boolean;
+export declare const isNativeCurrencyItem: ({ itemType }: Item) => boolean;
+export declare const isErc20Item: (itemType: Item["itemType"]) => boolean;
+export declare const isErc721Item: (itemType: Item["itemType"]) => boolean;
+export declare const isErc1155Item: (itemType: Item["itemType"]) => boolean;
+export declare const isCriteriaItem: (itemType: Item["itemType"]) => boolean;
+export declare type TimeBasedItemParams = {
+    isConsiderationItem?: boolean;
+    currentBlockTimestamp: number;
+    ascendingAmountTimestampBuffer: number;
+} & Pick<OrderParameters, "startTime" | "endTime">;
+export declare const getPresentItemAmount: ({ startAmount, endAmount, timeBasedItemParams, }: Pick<Item, "startAmount" | "endAmount"> & {
+    timeBasedItemParams?: TimeBasedItemParams | undefined;
+}) => BigNumber;
+export declare const getSummedTokenAndIdentifierAmounts: ({ items, criterias, timeBasedItemParams, }: {
+    items: Item[];
+    criterias: InputCriteria[];
+    timeBasedItemParams?: TimeBasedItemParams | undefined;
+}) => Record<string, Record<string, BigNumber>>;
+/**
+ * Returns the maximum size of units possible for 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.
+ */
+export declare const getMaximumSizeForOrder: ({ parameters: { offer, consideration }, }: Order) => BigNumber;
+export declare const getItemToCriteriaMap: (items: Item[], criterias: InputCriteria[]) => Map<Item, InputCriteria>;

package/lib/utils/match.d.ts

@@ -1,54 +1,54 @@
-/** Giant TODO for match orders
-# Match orders
+/** Giant TODO for match orders
+# Match orders
 
-- Format: list of fulfillments
-    - Each fulfillment represents a single transfer or “execution”
-    - Each fulfillment specifies an array of offer “components” corresponding to offer items to spend as well as an array of consideration “components” corresponding to consideration items to receive
-    - every offer component and consideration component contains an index of the order it is from as well as an index of the item in the respective offer or consideration array on that order
-    - the “from” address will be the offerer of whatever offer items are being spent
-    - the “to” address will be the recipient of whatever consideration items are being received
-- the “One rule” to follow for the whole set of fulfillments:
-    - All consideration items must be fully accounted for after adjusting for partial fills and ascending/descending amounts
-- the “Four rules” to follow for each distinct fulfillment:
-    1. you need at least one offer component and at least one consideration component for each fulfillment; otherwise you don’t know what the “from” or “to” address should be
-    2. the offer item corresponding to the first offer component has to match the consideration item corresponding to the first consideration component (with the exception of the amount); otherwise you’re not sending the item that the recipient is expecting
-    3. any additional offer items need to match the original offer items (with the exception of the amount) and the same *the offerer*; otherwise you’re composing different items or different origins.
-        1. This implies that ERC721 fulfillments will always have a single offer component (even if that corresponding offer item is present in multiple fulfillments, i.e. criteria-based partial fills)
+- Format: list of fulfillments
+    - Each fulfillment represents a single transfer or “execution”
+    - Each fulfillment specifies an array of offer “components” corresponding to offer items to spend as well as an array of consideration “components” corresponding to consideration items to receive
+    - every offer component and consideration component contains an index of the order it is from as well as an index of the item in the respective offer or consideration array on that order
+    - the “from” address will be the offerer of whatever offer items are being spent
+    - the “to” address will be the recipient of whatever consideration items are being received
+- the “One rule” to follow for the whole set of fulfillments:
+    - All consideration items must be fully accounted for after adjusting for partial fills and ascending/descending amounts
+- the “Four rules” to follow for each distinct fulfillment:
+    1. you need at least one offer component and at least one consideration component for each fulfillment; otherwise you don’t know what the “from” or “to” address should be
+    2. the offer item corresponding to the first offer component has to match the consideration item corresponding to the first consideration component (with the exception of the amount); otherwise you’re not sending the item that the recipient is expecting
+    3. any additional offer items need to match the original offer items (with the exception of the amount) and the same *the offerer*; otherwise you’re composing different items or different origins.
+        1. This implies that ERC721 fulfillments will always have a single offer component (even if that corresponding offer item is present in multiple fulfillments, i.e. criteria-based partial fills)
 
-Example: Bulk purchase
+Example: Bulk purchase
 
-- Five distinct sellers create orders to sell ERC721 NFTs for ETH.
-    - single offer item on each order: the NFT
-    - two consideration items on each order: 10 ETH to the offerer and 1 ETH to OpenSea
-    - order index 1 through 5
-- To fulfill this, fulfiller creates a *sixth* order to buy all 5 NFTs for ETH
-    - single offer item: 55 ETH or `(10 + 1) * 5`
-    - five consideration items: all five NFTs
-    - order index 0 (by convention)
-- This order requires exactly 11 transfers or executions (assuming 5 distinct sellers), translating to 11 fulfillments:
-    - 5 transfers of 10 ETH each from order 0 offerer (i.e. fulfiller) to order 1-5 offerers
-        - These fulfillments will have a single offer component and single consideration component (offer component: order 0 index 0 and consideration component: orders 1-5 index 0)
-    - 5 transfers of 1 NFT each from order 1-5 offers to order 0 offerer (i.e. fulfiller)
-        - These fulfillments will have a single offer component and single fulfillment component (offer component: orders 1-5 index 0 and consideration component order 0 index 0-4)
-    - 1 transfer of 5 ETH from order 0 offerer (i.e. fulfiller) to OpenSea
-        - This fulfillment will have a single offer component mapping to order index 0 + item index 0, but *five* consideration components mapping to order index 1-5 + item index 1
+- Five distinct sellers create orders to sell ERC721 NFTs for ETH.
+    - single offer item on each order: the NFT
+    - two consideration items on each order: 10 ETH to the offerer and 1 ETH to OpenSea
+    - order index 1 through 5
+- To fulfill this, fulfiller creates a *sixth* order to buy all 5 NFTs for ETH
+    - single offer item: 55 ETH or `(10 + 1) * 5`
+    - five consideration items: all five NFTs
+    - order index 0 (by convention)
+- This order requires exactly 11 transfers or executions (assuming 5 distinct sellers), translating to 11 fulfillments:
+    - 5 transfers of 10 ETH each from order 0 offerer (i.e. fulfiller) to order 1-5 offerers
+        - These fulfillments will have a single offer component and single consideration component (offer component: order 0 index 0 and consideration component: orders 1-5 index 0)
+    - 5 transfers of 1 NFT each from order 1-5 offers to order 0 offerer (i.e. fulfiller)
+        - These fulfillments will have a single offer component and single fulfillment component (offer component: orders 1-5 index 0 and consideration component order 0 index 0-4)
+    - 1 transfer of 5 ETH from order 0 offerer (i.e. fulfiller) to OpenSea
+        - This fulfillment will have a single offer component mapping to order index 0 + item index 0, but *five* consideration components mapping to order index 1-5 + item index 1
 
-The algorithm (broad-strokes first pass)
+The algorithm (broad-strokes first pass)
 
-1. Take all the orders you want to fulfill and retrieve the latest amounts for those orders based on amount filled, amount *desired* to fill, and ascending/descending amounts (include sufficient buffer on those)
-2. “flatten” those orders into:
-    - all the offer items (and include the order index, item index, and offerer alongside the item)
-    - all the consideration items (and include the order index and item index alongside the item; the recipient is already on the consideration items)
-3. Aggregate those items by type + token + identifier + (offerer / recipient), summing up all the amounts (we do need to track the original amounts as well here)
-4. Quickly check to see if there are any aggregated offer items with the same type + token + identifier + offerer as an aggregated consideration item’s type + token + identifier + recipient (i.e. offerer == recipient) — if so, create a fulfillment for those and decrement both (no execution / transfer will be created for these fulfillments)
-5. Retrieve all approvals and balances for each aggregated offer item; increment / decrement them as we go and ensure they never go below zero
-6. Search for fulfillments that can already be performed before the fulfiller’s order has even been created; if any exist, generate those fulfillments first (the goal is to reduce the number of items on the fulfiller’s order).
-    - To generate a fulfillment, subtract whatever is lower between the aggregated offer and aggregated consideration it is being matched with from both and register the fulfillment.
-    - There will likely be some combination that optimizes for total number of transfers; see if these can be optimized.
-        - By way of example, say a fulfiller is accepting offers to sell multiple NFTs at once, and the aggregate fees owed to OpenSea are exactly 1 WETH and it so happens that one of the NFTS has an offer for exactly 1 WETH — that offerer should pay the fees for all the orders being fulfilled in a single transaction.
-    - Repeat this process until the fulfillments cannot be compressed any further.
-7. Then, create the mirror order with an offer item for each remaining (aggregated) consideration item and a consideration item for each remaining (aggregated) offer item; check for sufficient approval on each derived offer item
-8. Run the same sequence as from in step 6, but include the last order as well
-9. Ensure that all consideration items have been met!
-  */
-export {};
+1. Take all the orders you want to fulfill and retrieve the latest amounts for those orders based on amount filled, amount *desired* to fill, and ascending/descending amounts (include sufficient buffer on those)
+2. “flatten” those orders into:
+    - all the offer items (and include the order index, item index, and offerer alongside the item)
+    - all the consideration items (and include the order index and item index alongside the item; the recipient is already on the consideration items)
+3. Aggregate those items by type + token + identifier + (offerer / recipient), summing up all the amounts (we do need to track the original amounts as well here)
+4. Quickly check to see if there are any aggregated offer items with the same type + token + identifier + offerer as an aggregated consideration item’s type + token + identifier + recipient (i.e. offerer == recipient) — if so, create a fulfillment for those and decrement both (no execution / transfer will be created for these fulfillments)
+5. Retrieve all approvals and balances for each aggregated offer item; increment / decrement them as we go and ensure they never go below zero
+6. Search for fulfillments that can already be performed before the fulfiller’s order has even been created; if any exist, generate those fulfillments first (the goal is to reduce the number of items on the fulfiller’s order).
+    - To generate a fulfillment, subtract whatever is lower between the aggregated offer and aggregated consideration it is being matched with from both and register the fulfillment.
+    - There will likely be some combination that optimizes for total number of transfers; see if these can be optimized.
+        - By way of example, say a fulfiller is accepting offers to sell multiple NFTs at once, and the aggregate fees owed to OpenSea are exactly 1 WETH and it so happens that one of the NFTS has an offer for exactly 1 WETH — that offerer should pay the fees for all the orders being fulfilled in a single transaction.
+    - Repeat this process until the fulfillments cannot be compressed any further.
+7. Then, create the mirror order with an offer item for each remaining (aggregated) consideration item and a consideration item for each remaining (aggregated) offer item; check for sufficient approval on each derived offer item
+8. Run the same sequence as from in step 6, but include the last order as well
+9. Ensure that all consideration items have been met!
+  */
+export {};

package/lib/utils/merkletree.d.ts

@@ -1,11 +1,11 @@
-import MerkleTreeJS from "merkletreejs";
-/**
- * Simple wrapper over the MerkleTree in merkletreejs.
- * Handles hashing identifiers to be compatible with Seaport.
- */
-export declare class MerkleTree {
-    tree: MerkleTreeJS;
-    constructor(identifiers: string[]);
-    getProof(identifier: string): string[];
-    getRoot(): string;
-}
+import MerkleTreeJS from "merkletreejs";
+/**
+ * Simple wrapper over the MerkleTree in merkletreejs.
+ * Handles hashing identifiers to be compatible with Seaport.
+ */
+export declare class MerkleTree {
+    tree: MerkleTreeJS;
+    constructor(identifiers: string[]);
+    getProof(identifier: string): string[];
+    getRoot(): string;
+}