maxflowo2 / erc2981

EIP-2981 solution

• 👋 Hi, I’m @MaxflowO2
• 👀 I’m interested in ... turning GitHub into a dating app
• 💞️ I’m looking to collaborate on ... turning GitHub into a dating app
• 📫 How to reach me ... Here

erc2981's Issues

Two types instead of blanket

In an upcoming commit will have issues 1-3 addressed, as well as two types of ERC2981.

ERC2981Collections and ERC2981:

Reasoning, for collection mints (the 10k random ones being a prime example) it shouldn’t matter what ID it is, it would be the same royalty amount. Whereas, a public minter say for BakerySwap or PaintSwap the user minting the NFT should be able to set their own royalties.

Reconsider use of ERC165Storage

ERC2981/contracts/ERC2981.sol

Line 20 in 010744c

abstract contract ERC2981 is IERC2981, ERC165Storage {

While an example in the ERC did use the ERC165Storage.registerInterface() method, it should be optional in a framework. In an architecture that uses other methods for managing supported interfaces this contract will not be used.

Particularly in the case of proxied contracts (which almost all of any import will be) and especially ERC2535 Diamonds, ERC165Storage is no good because it does not write to a unique storage slot. Even the 'upgradable' version does not do this, and so its storage in a fine-grained proxy like the diamond which allows multiple implementation contracts (called facets) to supply functions, if any other contract fails to put all its data in a targeted, unique slot, it will conflict with the data in ERC165Storage's slot.

In short it is much better to simply implement supportsInterface and allow descendant contracts to determine how to handle management of supported interfaces. Such contract can decide to use ERC165Storage if it wants, and register all the interfaces it supports in one go (similar to how the example in the 2981 spec has it).

I just built such a system for Seen.Haus marketplace, with different kinds of proxies including Diamond, and each required its own approach to managing and supported interfaces. Those were best handled at the final descendant.

Change case on return value & format code for readability

ERC2981/contracts/ERC2981.sol

Line 49 in 010744c

function royaltyInfo(uint256 _tokenId, uint256 _salePrice) external view override(IERC2981) returns (address Receiver, uint256 royaltyAmount) {

Readability is important in reference and framework code. Formatting it with that in mind (as we did in the ERC), will be appreciated by those who evaluate it when considering adoption.

function royaltyInfo(uint256 _tokenId, uint256 _salePrice) 
external 
view 
override(IERC2981) 
returns (address Receiver, uint256 royaltyAmount) { }

Also, return values should begin with lower case receiver not Receiver.

No need for SafeMath any more

ERC2981/contracts/ERC2981.sol

Line 21 in 010744c

using SafeMath for uint256;

This has been obviated by language changes

Since Solidity 0.8.0, all arithmetic operations revert on over- and underflow by default, thus making the use of these libraries unnecessary.

Also there is discussion about removing it from OZ entirely, the only good reasons to keep it being backward compatibility and potential use in unchecked blocks.

Nevertheless, not something we should propagate with new works.

Public Minting vs Team Minting

Hey there,

I'm reviewing ERC721v2.1.2ETHColWLWith2981.sol and I'm wondering for a seasoned developer but new to blockchain, what is team minting as opposed to public minting.

Does 'team mint' refer to the 'team' deploying the NFT project (essentially a private mint) as opposed to allowing normal users to mint their own assets?

---