ERC-6105: No Intermediary NFT Trading Protocol

Abstract

This ERC adds a marketplace functionality to ERC-721 to enable non-fungible token trading without relying on an intermediary trading platform. At the same time, creators may implement more diverse royalty schemes.

Motivation

Most current NFT trading relies on an NFT trading platform acting as an intermediary, which has the following problems:

1. Security concerns arise from authorization via the setApprovalForAll function. The permissions granted to NFT trading platforms expose unnecessary risks. Should a problem occur with the trading platform contract, it would result in significant losses to the industry as a whole. Additionally, if a user has authorized the trading platform to handle their NFTs, it allows a phishing scam to trick the user into signing a message that allows the scammer to place an order at a low price on the NFT trading platform and designate themselves as the recipient. This can be difficult for ordinary users to guard against.
2. High trading costs are a significant issue. On one hand, as the number of trading platforms increases, the liquidity of NFTs becomes dispersed. If a user needs to make a deal quickly, they must authorize and place orders on multiple platforms, which increases the risk exposure and requires additional gas expenditures for each authorization. For example, taking BAYC as an example, with a total supply of 10,000 and over 6,000 current holders, the average number of BAYC held by each holder is less than 2. While setApprovalForAll saves on gas expenditure for pending orders on a single platform, authorizing multiple platforms results in an overall increase in gas expenditures for users. On the other hand, trading service fees charged by trading platforms must also be considered as a cost of trading, which are often much higher than the required gas expenditures for authorization.
3. Aggregators provide a solution by aggregating liquidity, but the decision-making process is centralized. Furthermore, as order information on trading platforms is off-chain, the aggregator's efficiency in obtaining data is affected by the frequency of the trading platform's API and, at times, trading platforms may suspend the distribution of APIs and limit their frequency.
4. The project parties' royalty income is dependent on centralized decision-making by NFT trading platforms. Some trading platforms implement optional royalty without the consent of project parties, which is a violation of their interests.
5. NFT trading platforms are not resistant to censorship. Some platforms have delisted a number of NFTs and the formulation and implementation of delisting rules are centralized and not transparent enough. In the past, some NFT trading platforms have failed and wrongly delisted certain NFTs, leading to market panic.

Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Compliant contracts MUST implement the following interface:

Optional collection offer extension

Optional item offer extension

Rationale

Considerations for some local variables

The salePrice in the listItem function cannot be set to zero. Firstly, it is a rare occurrence for a caller to set the price to 0, and when it happens, it is often due to an operational error which can result in loss of assets. Secondly, a caller needs to spend gas to call this function, so if he can set the token price to 0, his income would be actually negative at this time, which does not conform to the concept of 'economic man' in economics. Additionally, a token price of 0 indicates that the item is not for sale, making the reference implementation more concise.

Setting expires in the listItem function allows callers to better manage their listings. If a listing expires automatically, the token owner will no longer need to manually delistItem, thus saving gas.

Setting supportedToken in the listItem function allows the caller or contract owner to choose which tokens they want to accept, rather than being limited to a single token.

The rationales of variable setting in the acceptCollectionOffer and acceptItemOffer functions are the same as described above.

More diverse royalty schemes

By introducing the parameter benchmarkPrice in the listItem, acceptCollectionOffer and acceptItemOffer functions, the _salePrice in the royaltyInfo(uint256 _tokenId, uint256 _salePrice) function in the ERC-2981 interface can be changed to taxablePrice, making the ERC-2981 royalty scheme more diverse. Here are several examples of royalty schemes:

(address royaltyRecipient, uint256 royalties) = royaltyInfo(tokenId, taxablePrice)

1. Value-added Royalty (VAR, royalties are only charged on the part of the seller's profit）: taxablePrice=max(salePrice- historicalPrice, 0)
2. Sale Royalty (SR): taxablePrice=salePrice
3. Capped Royalty(CR): taxablePrice=min(salePrice, constant)
4. Quantitative Royalty(QR, each token trading pays a fixed royalties): taxablePrice= constant

Optional Blocklist

Some viewpoints suggest that tokens should be prevented from trading on intermediary markets that do not comply with royalty schemes, but this standard only provides a functionality for non-intermediary NFT trading and does not offer a standardized interface to prevent tokens from trading on these markets. If deemed necessary to better protect the interests of the project team and community, they may consider adding a blocklist to their implementation contracts to prevent NFTs from being traded on platforms that do not comply with the project’s royalty scheme.

Backwards Compatibility

This standard is compatible with ERC-721 and ERC-2981.

Reference Implementation

Security Considerations

The buyItem function, as well as the acceptCollectionOffer and acceptItemOffer functions, has a potential front-running risk. Must check that salePrice and supportedToken match the expected price and token to prevent front-running attacks

There is a potential re-entrancy risk with the acceptCollectionOffer and acceptItemOffer functions. Make sure to obey the checks, effects, interactions pattern or use a reentrancy guard.

If a buyer uses ERC-20 tokens to purchase an NFT, the buyer needs to first call the approve(address spender, uint256 amount) function of the ERC-20 token to grant the NFT contract access to a certain amount of tokens. Please make sure to authorize an appropriate amount. Furthermore, caution is advised when dealing with non-audited contracts.

Copyright

Copyright and related rights waived via CC0.