Glossary

Here are some helpful terms to keep in mind.

Payment Processor: An NFT exchange protocol built by creators, for creators. Built for trading of ERC721-C and ERC1155-C tokens, but backwards compatible to support trading of any ERC721 or ERC1155 token as well. Analagous to Blur Marketplace and Seaport exchange protocols, but built entirely around honoring fully on-chain programmable royalties. Also known as PaymentProcessor.
PaymentProcessor: Shorthand for Payment Processor.
Payment Processor Encoder: A helper contract deployed alongside Payment Processor that integrated marketplaces use to format Payment Processor function calldata.
Maker(s): Create buying or selling orders that are not carried out immediately. For example, "sell NFT A at a price of $100" or "buy NFT B for $100". This creates liquidity, meaning that it is easier for others to instantly buy or sell NFTs when the conditions are met. When Bob lists an NFT he owns for sale, Bob is considered maker of the order. Similarly, when Bob offers to buy an NFT, Bob is considered the maker of the order.
Taker(s): The entities that buy or sell instantly are called takers. In other words, the takers fill the orders created by the makers. When Alice executes and order to buy Bob's listing, Alice is considered the taker of the order. Similarly, when Alice accepts an offer from Bob to buy an NFT she owns, Alice is considered the taker of the order.
Order(s): Payment Processor supports two broad categories of orders and four types:
- Standard Order: Any listing or offer that may be filled directly by a taker. Standard orders, when cancelled, must be cancelled on-chain by the order maker at their own gas expense. Standard orders are not susceptible to censorship provided they are accessible through an orderbook API.
- Cosigned Order: Any listing or offer that must be cosigned by another party in order to be filled by a taker. Cosigned orders, when cancelled, can be gaslessly cancelled off-chain. Order-book providers that support cosigned orders must properly secure and automate the co-signing process. The order-book provider must guarantee that no cosignature can be generated for a previously cancelled order. Similarly, the order-book provider must guarantee availability of cosignatures to takers such that orders can always be filled uninterrupted. The use of cosigned orders SHOULD be at the order maker's discretion. Pros include cheaper, faster cancellation/replacement of orders without incurring transaction gas costs. Cons include censorship/denial of service risks.
- Listing: An order (standard or cosigned) to sell an NFT once filled by a taker. Listings are gaslessly signed off-chain by the owner of the NFT.
- Item Offer: An order (standard or cosigned) to buy a single, specific NFT once filled by a taker. Item offers apply to exactly one specific token id in a collection. Offers are gaslessly signed off-chain by one or more parties interested in purchasing the NFT.
- Collection Offer: An order (standard or cosigned) to buy any NFT belonging to a specific collection once filled by a taker. Collection offers apply to any token id for a specific collection. Offers are gaslessly signed off-chain by one or more parties interested in purchasing an NFT.
- Token Set Offer: An order (standard or cosigned) to buy a single NFT from a subset of token ids in a specific collection once filled by a taker. Token set offers apply to a subset of token ids for a specific collection. Offers are gaslessly signed off-chain by one or more parties interested in purchasing an NFT.
Beneficiary: The address of the account that receives the NFT/item when an order is filled. The buyer and beneficiary can be, but don't have to be the same account. Beneficiaries are acknowledged and signed in offer orders when an offer is made. Alternately, the beneficiary is designated and signed in the calldata of the buy transaction when the taker buys a listing.
Marketplace Fee: A fee paid to the primary marketplace where an order was made. The marketplace fee is acknowledged in signed orders.
Fee On Top: A fee on top is typically reserved for a marketplace or specialized wallet that finds orders filled by the taker. This taker marketplace fee is an optional fee paid by the taker in excess of the items' prices in one or more orders.
Royalty Bounty: A percentage, optionally paid out of a creator's royalty on each trade, to the marketplace where the NFT order was made. Royalty bounties are optional, and creators can configure a percentage from 0-100% to share with marketplaces that provide liquidity. Royalty bounties are a powerful tool to align incentives between creators and marketplaces.
Bulk Orders: A signature provided by a maker which includes multiple approvals, confirmed by signing the root of a merkle tree and executed by takers who provide merkle proofs.
Permit Orders: An order which utilizes PermitC or other similar permit processors to handle approvals for ERC20, ERC721 and ERC1155 as well as validate additional data.
Minimum Protocol Fee: The minimum fee rate (BPS) collected by the Payment Processor procotocol. Default is 25 BPS (0.25%) unless otherwise configured/adjusted.
Protocol Exchange Fee Tax: The rate at which the marketplace/exchange fee is taxed. This is a tax the marketplace pays for the right to monetize trading using the Payment Processor protocol and is used to fund ongoing protocol development and enhancements. Protocol fees collected this way may fully or partially offset the minimum protocol fee to limit the excess fee applied to the seller's proceeds.
Protocol Fee On Top Tax: The rate at which the fee on top is taxed. This is a tax the app injecting a fee on top pays for the right to monetize trading using the Payment Processor protocol and is used to fund ongoing protocol development and enhancements.
Protocol Fee Version: If the protocol fee is adjusted by the fee manager, it creates a new version. Traders must acknowledge the protocol fee version in their sale approval signatures or their signed transaction to sell an item. Protocol fee versions have a grace period so that existing orders can be filled before they become invalidated and require new orders to use the latest fee version.