Payment Processor: The Best NFT Exchange Protocol For Creators

Published in

Limit Break

9 min readFeb 5, 2024

Version 1 of Limit Break’s Payment Processor was a functional proof of concept that demonstrated that exchange protocols could reliably process on-chain, programmable royalties while offering creators choices over the trading parameters of their own collections including choice of payment methods and even setting pricing ranges that cannot be violated.

What’s New In Version 2

In the weeks since exchange integration for Version 1 went live, Payment Processor has securely processed thousands of trades across at least 100 collections. Taking notes from the proof of concept, Limit Break is thrilled to announce the launch of Payment Processor Version 2, the first true production version of the exchange protocol. Payment Processor Version 2 is now live on Ethereum, Polygon, Optimism, Arbitrum One, Base, Avalanche C-Chain, Binance Smart Chain (BSC), Polygon zkEVM, and Sepolia at 0x9A1D00bEd7CD04BCDA516d721A596eb22Aac6834.

It is packed with new features that improve the exchange experience for creators, marketplaces, and traders alike! Version 2 of Payment Processor marks major feature improvements needed to replace older, outdated exchange protocols. Matrices comparing Version 1 and 2 features are shown below.

For Creators

Payment Processor protects the interests of creators, offering them choices no other exchange protocol has ever provided.

Control Over Payment Methods and Pricing

Historically, marketplaces have dictated the accepted payment methods for NFT trades. Payment Processor flips control to creators, putting them in the driver’s seat to set what methods of payment are permitted for trades on their collections. The spectrum of choices are:

Default Payment Method Whitelist — Rather than allow any payment method by default, all collections are automatically protected from trading in meme coin or other undesirable coins unless otherwise specified by the collection’s creator. This protects creators from trades where royalties are paid in worthless, undesirable coins. The defaults include: Native Currency (ETH or Equivalent), Wrapped Native Coin, Wrapped ETH (when applicable), USDC (Native), USDC (Bridged).
Allow Any Payment Method — For creators that wish to accept trades and royalties in any currency, the option to remove all restrictions is available.
Custom Payment Method Whitelist — Creators may define their own shared list of coins that may be used to trade their collections. This works great for Web3 games that have their own in-game currencies, as they can allow trading only in their game’s coin(s).
Pricing Constraints — Creators may choose a single payment method and apply a minimum floor or maximum ceiling price at the individual token id or collection level. The pricing constraints can be either an acceptable price range or a fixed price tag. This is great for Web3 games with special ultra-rare items as it offers some control over the economic balance of a game.

Royalty Bounties

Creators may choose to offer a royalty bounty. This is a percentage of royalties creators may choose to share with marketplaces. Royalty bounties are completely voluntary and set by a collection’s creator if they wish. Consider this simple scenario: An NFT trades for 1E where the creator royalty is 10%, royalty bounty is 20%, and marketplace fee = 1%. The creator receives 0.08E, the marketplace receives 0.03E (0.01E standard fee + 0.02E royalty bounty), and the seller receives 0.89E.

Why would a creator volunteer to share royalties with a marketplace? Royalty bounties offer an incentive to align the interests of exchanges and creators. By offering a share of enforceable creator royalties to exchanges, or perhaps an exclusive partner exchange, it offers a new way to incentivize exchanges to cross-promote or boost the visibility of a collection for a period of time. Royalty bounties may be changed at any time by adjusting Payment Processor settings for your collections using developers.freenft.com.

Royalty Backfill

Many older collections may not implement the EIP-2981 royaltyInfo function. Some of these collections have exchange blocking features, while others do not. Regardless of whether or not a collection can block exchanges and guarantee trades occur within Payment Processor, if a creator designates a backfilled royalty receiver and percentage for their collections it is guaranteed to be honored and enforced on all trades flowing through the Payment Processor.

Trusted Channels

Many creators, especially Web3 game developers, will prefer to carve out their own private exchange. This won’t appeal to all creators, but there are several reasons they may choose to do so, including:

In-game marketplaces — a completely private collection and marketplace offers Web3 game developers the opportunity to keep all of their players within the game, instead of leaving the game to trade in-game assets.
Branded experiences — creators may desire complete creative control over their users’ experience with their on-chain products. By creating a completely private collection with private marketplace, the creator can improve the experience of their community members.
Ethereum is a dark forest — hostile exchanges or apps could offer trading incentives that subvert the intentions of the creator in some way. Trusted channels offer a means to block this sort of activity.

Here’s how creators can use trusted channels to carve out a private ecosystem completely free of disruption.

Step 1: Clone a Trusted Forwarder using the Trusted Forwarder Factory. This is a trusted application channel to the Payment Processor.
Step 1a: Optionally — set an authorized signer wallet on the channel. When an authorized signer is specified, the specified signer wallet must approve all transactions flowing through the channel. Unapproved transactions are blocked. This is useful when a creator wants to guarantee that all contract interactions go through their own application backend.
Step 2: On Payment Processor, turn on the Blocks Trades From Untrusted Channels flag for a collection.
Step 3: Whitelist the channel(s) of applications permitted to trade your collections.
Step 4: Optionally — set an app signer on your whitelisted trusted forwarder. Some backend signing infrastructure will be needed for your application, but it will prevent external apps from executing trades through your own forwarders.

The flow is visually represented below:

For Marketplaces

Payment Processor offers marketplaces with a world-class on-chain NFT trading backbone.

Supported Standards

All ERC721 or ERC1155 tokens can be traded using Payment Processor, not just ERC721-C and ERC1155-C tokens. ERC721-C and ERC1155-C help guarantee the use of Payment Processor for creators, but any legacy collection can be traded on Payment Processor as well with creator royalties honored.

Trading Functions

The execution flow of trades is very clear, and there is a clean delineation of listing orders and offer orders.

The buyListing function is executed by a buyer to fill a seller’s listing. This would typically be called using a Buy Now interface.
The bulkBuyListings function is executed by a buyer to fill multiple sellers’ listings. This would typically be called using a Shopping Cart Checkout interface.
The sweepCollection function is executed by a buyer to fill multiple sellers’ listings on a specific collection. This would typically be called using a professional trading Sweep interface to buy some number of items at some maximum price per item.
The acceptOffer function is executed by a seller to fill a buyer’s offer. This would typically be called using an Accept Offer interface. Buyers can place offer orders on specific items, entire collections, or a specific subset of items.
The bulkAcceptOffers function is executed by a seller to fill multiple buyers’ offers. This would typically be used in an interface where many available offers are selected and executed at simultaneously.

Fees For Marketplaces

Sometimes trades are filled via different marketplaces. In this case, the maker and taker used different marketplaces or aggregator apps. Thus, multiple fee types are available for marketplaces to take advantage of.

Maker Fee — The order maker acknowledges this marketplace fee receiver and percentage in their signed order. This fee is paid when the order is filled.
Fee On Top — This is a taker fee paid in excess of the item sale price as a tip for the taker marketplace or aggregator application that helped find and fill the trade. This kind of fee is implicitly acknowledged when the taker signs the transaction.
Royalty Bounties — this is a bonus fee for the maker marketplace for orders on collections where a royalty bounty has been voluntarily offered by the collection’s creator. This is not an additional fee paid by traders, but rather offered to marketplaces as a share of the creator’s royalty fee.

Trade Attribution For Marketplaces

A common complaint about other exchange protocols is that applications using an exchange protocol do not properly receive accurate attribution for trades in leaderboards such as the Etherscan gas guzzler chart, Dapp Radar, or Dune.

Payment Processor solves the attribution problem with Trusted Channels. A trusted channel is a lightweight forwarder contract that is optionally used as the blockchain entry point for a trade, allowing leaderboard apps to aggregate metrics for trades originating from different marketplaces.

To start receiving attribution, marketplaces may create a new Trusted Forwarder using the Trusted Forwarder Factory, and route trades from their front-end trading interface to the Payment Processor via their own forwarder instance.

For Traders

Payment Processor offers traders gas-efficient trading and a great user experience.

Fewer User Signatures

In Version 1, both the maker and taker had to sign their sides of the order. In Version 2, only the order maker needs to sign the order. The taker’s approval is implicit, as they sign and execute the transaction. Not only is this better for user experience but it reduces the taker’s gas cost when executing trades.

Buy Someone An NFT

There is no need to use expensive on-chain delegate registries to securely purchase an NFT with a cold wallet. Instead, a user can use a hot wallet to buy and NFT and send the NFT to a secure cold wallet.

Order Cancellation

Order makers may cancel trades either on-chain or off-chain. When cancelling an order on-chain the user must pay gas. However, a new order co-signing feature has been implemented that requires the marketplace API to co-sign when a trade is executed. The co-signing feature can be used to allow users to cancel orders off-chain with no gas costs!

Token Set Offers

Newly added to Payment Processor, token set offers facilitate trait-offers and can be used to protect buyers from buying stolen NFTs.

Partially Filled Orders

Newly added to Payment Processor, partially filled orders help avoid front-running denial of service attacks and allows several users to fill ERC1155 orders involving a large number of tokens when users want to buy or sell en masse.

Improved Gas Efficiency

Limit Break has packed the upgraded Payment Processor with new features while lowering gas costs at the same time. We forked OpenSea’s marketplace benchmark suite to compare the Seaport 1.5 with Payment Processor V1 and V2 and Payment Processor was the clear winner!

Note: benchmarks were written to be a fair, apples-to-apples comparison to the greatest extent possible and are mostly based upon the benchmarking code written by the OpenSea team. However, real-world gas efficiency of each trade can vary greatly based upon the input data of specific trades.

The results are visualized below: