Introducing ERC721-C Payment Processor: A Game-Changing NFT Marketplace Protocol
At the beginning of May, Limit Break publicly unveiled and open-sourced ERC721-C, an innovation for the NFT space poised to end the NFT royalty debate once-and-for-all. ERC721-C includes transfer security levels for which there are no work-arounds that give NFT creators leverage to block exchanges that do not properly handle royalty payments according to what is programmed into the NFT smart contracts through use of EIP-2981’s royaltyInfo function. This is a major unlock for the NFT industry because ERC721-C allows creators to build programmable royalty features into smart contracts that can reward their communities in so many ways that would otherwise have no meaning in a world of royalty-optional NFT exchanges.
Today, Limit Break is thrilled to announce the release of Payment Processor, the world’s first NFT marketplace protocol contract that is fully compatible with ERC721-C and programmable royalties! The Payment Processor is an audited marketplace protocol that performs trust-less validation and execution of NFT trades. It reliably pays all seller, marketplace, and royalty proceeds free of off-chain exchange manipulation.
The contract is now available for all new and existing NFT exchanges that wish integrate programmable royalties with their order books without shouldering the time and expense burden required to develop their own marketplace protocol contracts.
Payment Processor is deployed to the following networks/addresses:
- Mainnet: 0x009a1dC629242961C9E4f089b437aFD394474cc0
- Polygon: 0x009a1Daf6B5b8ADC6B3DB720C58D43caA2fdAc56
- Goerli: 0x009a1D88379A604664006FFf6c32877bFF6723Bd
- Sepolia: 0x009a1D8DE8D80Fcd9C6aaAFE97A237dC663f2978
- Mumbai: 0x009A1D6bDf55B25ca21436ED30968C1fb7648244
How Does Payment Processor Work?
The Payment Processor is contained entirely in one smart contract, written in high-level solidity, that includes a robust feature-set.
- Multi-Standard Support for NFTs
- Flexible Payment Methods
- Several Trade Types
- Programmable Fee Enforcement
- Creator Defined Security Profiles
Payment Processor supports trades of any ERC721 or ERC1155 token. It is the only current marketplace protocol that natively support ERC721-C and programmable royalties exposed through EIP-2981! All purchase functions automatically query and payout royalties in accordance with the EIP-2981 royaltyInfo interface implemented on NFTs being sold. NFTs that do not implement this interface do not collect royalties.
Payments can be made in both native (ETH or equivalent) currency or any ERC20 token. However, creators have the flexibility to either allow any currency for purchases on their collections or to define their own set of approved payment methods.
There are four primary types of purchases:
- Buy Single Listing
- Buy Batch of Listings (Shopping Cart)
- Buy Bundled Listing where the seller lists a bundle of items from one collection and buyer purchases entire bundle
- Sweep Collection where the buyer purchases a number of items from one collection listed individually by one or more sellers
Similar to ERC721-C, Payment Processor provides NFT creators with a variety of security settings that influence the behavior trade execution. It allows creators to choose from the following options:
- Exchange Whitelist On/Off
- Payment Method Whitelist On/Off
- Pricing Constraints On/Off
- Private Sales On/Off
- Delegate Purchase Wallets On/Off
- Smart Contract Buyers and Sellers On/Off
- Exchange Whitelist Bypass for EOAs On/Off
- Creator-defined pricing bounds (minimum floor, maximum ceiling and currency) on specific collections or individual tokens
Payment Processor is written with gas-efficiency in mind, but prioritizes readability, security and flexibility for NFT creators when making trade-offs on implementation details that impact gas costs.
Why Not Just Use Seaport or Blur?
Why is Payment Processor necessary when Seaport and Blur Exchange marketplace protocols already exist?
By design, those two protocols accept a set of fees as inputs to their NFT trading/purchasing functions. This design provides no assurances that royalties will be paid in the proper amount or to the proper recipient as defined in EIP-2981. There is also no assurance that creators will be paid at all, as we have seen many exchanges change their policies on royalties time and again.
In order to assure royalties to the recipients defined in ERC721-C programmable royalties, the royalty lookup and payout MUST be written into the marketplace protocol contract permanently in a way that is free of off-chain modification. Payment Processor is the first-of-its-kind marketplace protocol to permanently include EIP-2981 royalty support, establishing a new bar requiring competitive marketplace contracts to perform all royalty queries and payments on-chain. The remainder of this article is focused on an in-depth comparison of the three marketplace protocols.
Comparing Marketplace Protocols
This section compares Payment Processor, Seaport, and Blur Exchange on several criteria: gas-efficiency, immutability, simplicity and readability, support for token standards, flexibility, and security/protection for NFT creators.
Gas Efficiency
To compare the three marketplace protocols we forked the seaport github repository and the blur exchange github repository.
Methodology: We generated a set of benchmarking tests to perform a fair, objective apples-to-apples comparison between trades using the three protocols. We sought to replicate identical scenarios and outcomes to the greatest extent possible. You can review the Seaport benchmarks here, the Blur Exchange benchmarks here, and the Payment Processor benchmarks here. To measure the difference between warm and cold purchases, we executed the sales 100 times each and took the average gas cost as the warm purchase value and the maximum gas cost as the cold purchase value.
We benchmarked the following commonly used trading styles:
- Buy Single Listing
- Buy Bundled Listing (1 buyer, 1 seller, multiple items from a single collection)
- Collection Sweep (1 buyer, multiple sellers, multiple items from a single collection)
For each type of trade, we used the following baseline conditions:
- Native ETH Payment
- ERC721 Token Sales
- No Fees
- Marketplace-Only Fees,
- Marketplace and Royalty Fees
- Measured Warm and Cold Purchases
Note: A “Cold” purchase is one where the seller and buyer have never interacted with either the marketplace or NFT contract before. These tend to be the most expensive, one-time transactions because they often involve setting storage slot values from zero to non-zero values at a cost of 20K gas units each. A “Warm” purchase is one where the seller and buyer have both interacted with the marketplace contract before and where the buyer’s NFT balance is already greater than zero. The “Warm” transaction cost is more representative of the majority of transactions as buyers and sellers are far more likely to buy and sell more than one NFT over the lifetime of the wallet.
Note: Actual gas-prices on-chain will vary according to a large number of variables that impact control flow of the smart contract (ETH vs ERC20 payment, ERC721 vs ERC1155, warm vs cold sales, custom conduits/zones/advanced order criteria in Seaport, etc). The gas measurements listed below are measured by Foundry’s testing suite and built-in gas reporter which will vary from the gas costs on the live Ethereum network. These measurements should still provide a fair representation of the order of magnitude differences between the two contracts.
Note: Seaport sales may or may not use a conduit, which impacts gas costs. Our measurements average the conduit vs no-conduit cases assuming a roughly 50% split between these cases.
Benchmark — Buy Single Listing
As you can see below, Seaport was more efficient for individual “cold” purchases, but Payment Processor wins in the “warm” purchase category. As you will see throughout this comparison, Blur Exchange is nowhere near competitive on gas costs with either of the other protocols.
Benchmark — Buy Bundled Listing
As you can see below, Payment Processor is generally the most efficient for both warm and cold purchases, especially the more items are contained in the bundle. Note that no benchmark exists for Blur Exchange for 100 items. This is because at 37 items the Blur Exchange implementation actually reverts, potentially due to a memory allocation bug.
Benchmark — Collection Sweeps
As you can see below, Payment Processor is generally the most efficient for both warm and cold purchases, especially the more items are contained in the sweep order.
Winner: Payment Processor
Caveat: Seaport will likely exhibit better gas performance for some elevated creator-defined security levels on individual item sales
The Seaport Benchmark Test Code can be found here!
The Blur Exchange Benchmark Test Code can be found here!
The Payment Processor Benchmark Test Code can be found here!
Immutability
Among the three protocols, Blur Exchange is the only contract built using an upgradeable proxy system. While this does allow frictionless upgrade of the marketplace contract from a user standpoint, this carries a lot of risk for traders.
Because Blur Exchange collects approvals to transfer ERC20, ERC721, and ERC1155 assets the fact that it is upgradeable carries a significant centralization risk for those assets. A loss of administrator signing keys could result in a malicious upgrade where a function is introduced that permits an attacker to transfer all user assets.
A safer strategy would be to use immutable contracts and deploy separate marketplace contracts with upgraded features and require users to approve the new marketplace contract. This is the approach take by Seaport and Payment Processor.
Winner: Payment Processor and Seaport
Simplicity and Readability
In general, the simpler the contract design the easier it should be for external and off-chain systems to integrate. Seaport is extremely flexible in terms of order building and execution, but the trade-off is additional complexity of system design. Consider the following design diagram. Clearly there is a lot happening within Seaport to process NFT trades, and Seaport as a system requires its own glossary of terms.
Blur Exchange is quite a bit simpler, but there are still a few contract interactions to understand.
By contrast, Payment Processor is a single, self-contained smart contract with no external interactions required.
Another important consideration is that marketplace contracts require users to grant approvals in order to facilitate NFT trades. The ability to comprehend what a contract is doing and how it works is critical to being able to trust a contract with approval to transfer your assets!
With inline assembly, it is possible to ruthlessly optimize the gas cost of executing code. It varies on a case-by-case basis, but the amount saved using Yul over Solidity for a well-written contract is probably on the order of 1–3%. And boy, engineers that write all of their code in Yul look undeniably intelligent.
But when it comes to trusting a contract with something like asset approval, we feel that the ability for most lay people to read and understand a verified contract takes precedence.
Seaport consists of well over 10,000 lines of code split across dozens of code files. Trying to follow along and understand all the logic and execution flow of Seaport is difficult at best.
Both Blur Exchange and Payment Processor, on the other hand is in the neighborhood of 1500 lines of high-level solidity code with minimal Yul in a single contract file that can be read and understood much more easily, especially with the supporting documentation comments.
Winner: Payment Processor and Blur
Token Standards Support
All three marketplace protocols support trading ERC721 and ERC1155 tokens using both native currency and ERC-20 coins. However, neither Seaport nor Blur Exchange natively supports the EIP-2981 royalty standard like Payment Processor, making it the obvious choice for collections that require royalty support.
Winner: Payment Processor
Flexibility of Trade Execution Logic and Order Complexity
Payment Processor and Blur Exchange implement several styles of trade elegantly, but with a very precise, well-defined execution flow. Seaport, on the other hand, is purpose-built for arbitrary complexity of orders and execution flow. It is clearly more flexible when it comes to order creation, validation, and execution.
Winner: Seaport
Security and Protection For NFT Creators
Payment Processor and ERC721-C were purpose-built give NFT creators options with respect to how their NFTs are traded. Seaport, on the other hand, is fully open and allows trading in ways that may not be favorable to what a creator is trying to achieve with their collection.
Seaport provides no real controls or guardrails for creators. Lets also look at the OpenSea Blacklist, or Operator Filter Registry. This attempt to safeguard creator royalties by blocking royalty-optional was ultimately doomed to fail, in large part because Seaport is designed to be an open marketplace protocol. At the end of the day, Blur was able to piggy back on Seaport to bypass the Operator Filter Registry.
Winner: Payment Processor
Conclusions
For NFT creators and game developers, the Payment Processor marketplace protocol provides clear advantages over Seaport and Blur Exchange. Payment Processor is certainly more creator friendly, and objectively speaking it is more performant with respect to user gas fees in many scenarios.
As a next step, Limit Break is currently working with partners on the integration of order-books and trading interfaces to fully unlock the game-changing potential of ERC721-C and programmable royalties.
Limit Break welcomes you to review the code and documentation on our Github.
Disclaimer
Payment Processor is made available by Limit Break International (“Limit Break”) in an effort to advance the NFT and Ethereum ecosystem (the “Payment Processor Contracts”). Limit Break is committed to following, and has sought to apply, commercially reasonable best practices as it pertains to safety and security in making Payment Processor publicly available. Nevertheless, smart contracts are a new and emerging technology and carry a high level of technical risk and uncertainty. Please report any actual or suspected security vulnerabilities to our team at security@limitbreak.com.
Payment Processor made available under the MIT License, which disclaims all warranties in relation to the project and which limits the liability of those that contribute and maintain the project, including Limit Break As set out further in Limit Break’s Terms of Service, as may be amended and revised from time to time, you acknowledge that you are solely responsible for any use of Payment Processor Contracts and you assume all risks associated with any such use. For the avoidance of doubt, such assumption of risk by the user also implies all risks associated with the legality or related implications tied to the use of smart contracts in any given jurisdiction, whether now known or yet to be determined.
Supplemental Benchmarks
OpenSea maintains a great benchmarking repository. Limit Break has added payment processor to the benchmarked marketplaces using OpenSea’s benching framework. Here are the results comparing payment processor to an expanded set of marketplaces (Seaport, Blur, X2Y2, LooksRare, Sudoswap v1, and ZeroEx.
