Has anyone implemented EIP 2981

has anyone implemented EIP-2981: NFT Royalty Standard?

https://eips.ethereum.org/EIPS/eip-2981

I was looking for some example code before I tried to implement myself.

2 Likes

have you succeeded to find the implementation?

you can find an example here: dievardump/EIP2981-implementation: Repository that shows how to easily implement EIP2981 (github.com)

and a good article here: Exploring the NFT Royalty Standard (EIP-2981) | Gemini

1 Like

@scottsuhy what would i send on _setRoyalties if i want to take 1 percentange on every sale i tried different option but still fail those things

There's my repo, in the running for doing this...

Also it's on the discussion board... so who knows, if it wins I'll push my repo to OpenZeppelin.

3 Likes

Is this working? When will OZ support EIP-2981 with royalty?

2 Likes

plus when it'll be on the contract wizard? :slight_smile:

1 Like

it's at least 30k in gas to implement if you do one mapping, 60k in gas for a double mapping.

Unless you do a struct, and map the struct... 30k in gas...

Been trying to breakdown the NFT minting process to reduce gas costs, on top of EIP 2981

Any news on this? Would love to have this implemented with ERC721 or 1155

1 Like

This is a pretty good article on 2981.
Have you found any new data on the topic? I want to implement royalties on every mint but don't know where these royalties are even going.

Hi @Jalapina, we are also trying to make this work here. Have you found a way to implement this?

Kind regards,
Tailor

I'm implementing this now and wondering if it can be this simple:

	uint16 internal constant _DEFAULT_ROYALTY_BASIS = 250; // 2.5%

    // erc2981 interface
    function royaltyInfo(uint _tokenId, uint _salePrice) external view returns (address receiver, uint royaltyAmount) {
        return (payable(owner()), uint((_salePrice * _DEFAULT_ROYALTY_BASIS)/10000));
    }

All the examples I see set these values on a per token basis, but I'm inclined to make the recipient and royalty basis fixed and eliminate the overhead of tracking these values per token.

Will this cause any problems with the marketplaces that sell my ERC721 tokens (NFTs)?

I will probably introduce the an address royaltyAddress and uint royaltyBasis with setters available to only the contract owner, so I can change who receives the royalties and probably reduce them over time. But it would still be one formula that works for all tokens.

Any issues that I'm not considering here?

You can find example implementations here: https://github.com/dievardump/EIP2981-implementation
But be careful these are only created for testing.

Any implementation that could be used for production already, with an ERC2981interface bytecode ?

METASALT - https://metasalt.io

This marketplace implemented EIP2918. They also made an open call to other marketplaces to implement to improve interoperability.

OpenZeppelin Contracts has an EIP-2981 implementation ERC2981 and also ERC721Royalty which is the same just with a minor tweak to better handle burns.

OpenSea has said they will support EIP-2981 royalties with Seaport but I don't know that they do yet.

1 Like

Hey there Frangio,

Thank you for the update. This is exactly what I was waiting for, but I don't know how to implement as I am predominantly a creator.

I have a Manifold Studio proxy ERC 721 contract that is deployed on testnet. Manifold has advised me to inherit ERC2981 before deploying to Mainnet. But, the devil is in the details.

Would I open my 721 in Remix and copy your 2981 Git code into an extension? If you have a tutorial (I did try to find), I would deeply appreciate it. I am sure others will too.

Kind regards

If you use Remix you can do

import "@openzeppelin/contracts@2.7.3/token/common/ERC2981.sol";

contract NFT is ..., ERC2981 {

You also need to use _setDefaultRoyalty or _setTokenRoyalty. Refer to the docs.