📄️ Glossary
Here are some helpful terms to keep in mind.
📄️ Events
Collection Settings Registry Events
📄️ Data Structures
The following subsections detail the data structures needed for the creation of and filling of orders in Payment Processor. Note that maker signature formats vary by order-type.
📄️ Listings
A listing is an order (standard or cosigned) to sell an NFT once filled by a taker. Listings are gaslessly signed
📄️ Offers
Offers are gaslessly signed off-chain by one or more parties interested in purchasing the NFT.
📄️ Filling Orders
Filling A Single Listing (Buy Now)
📄️ Cancelling Orders
Cancelling A Single Order
📄️ Cosigner Security
Cosignatures on orders allow an order book to offer users the ability to gaslessly cancel their listings and offers. To guard against bad actors
📄️ Calldata Encoding
In order to not overflow smart contract bytecode size limits, Payment Processor is split into smaller library modules. When making calls to Payment Processor, these calls are forwarded to the corresponding module and implementation function using DELEGATECALL. For gas efficiency purposes, the function calldata must be passed in as a raw calldata byte array. Payment Processor is deployed with a helper contract called the PaymentProcessorEncoder. It accepts the expected function implementation parameters and encodes them as a single calldata byte array that should be passed into Payment Processor when making calls to fill orders. The subsections below detail each PaymentProcessorEncoder function.
📄️ Bulk Orders
Bulk Order Proofs allow for users to sign for multiple listings or offers in one signature. To make it more transparent, the marketplace should present the signature digest in a human readable format, allowing for users to review the data they sign before completing. Due to how EIP-712 struct hashing works, a nested array of [2] * treeHeight will produce the same hash as the root hash, provided it contains the same data and is padded with empty structs. Trees of depths 1 (2^1 = 2) to 10 (2^10 = 1024) are supported on Payment Processor.
📄️ Permits
Payment Processor has support to use a permit processor like PermitC to handle approvals in a more advanced and secure way. To handle this, the taker must first give standard approval on their token to the permit processor contract before executing the order. A signature for the permit processor would utilize the PermitTransferFromWithAdditionalData on PermitC.
📄️ Nonce Management
Payment Processor uses two types of nonces to manage orders - master nonces and order nonces. Every order maker on Payment Processor has their own master nonce and set of order nonces.