📄️ Glossary
Here are some helpful terms to keep in mind.
📄️ Events
Payment Processor emits several indexible events that should be indexed by off-chain order books and analytics platforms.
📄️ 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.
📄️ 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.