PaymentSplitter for NFT project


I'm considering using a PaymentSplitter from the OpenZeppelin v4 contracts library, in our upcoming NFT project.

What I am considering is how much more gas will it take for each mint operation, due to the PaymentReceived event emitted in the receive() function. Does anybody have a clue?

Question number 2, if I do decide to use it, I assume we should just inherit it from our main NFT contract, is that correct?

for example:
contract MyNFT is ERC721, ERC721Enumerable, Ownable, PaymentSplitter {...}

Thank you.

PaymentSplitter is designed to be used as a "standalone" contract, so you deploy it separately and you or anyone sends ETH to that separate contract.

It might work with inheritance in the way that you describe it though... But you will need to thoroughly test it to be sure. We have not tested it in this way.

The event should not really add significant cost. But you can and should always measure this.

Alright I understand,

Thanks for your help!

I was looking at implementing something similar for our NFT project. We are a team, with % splits ("shares"), then I found PaymentSplitter.

It seems like exactly what we need.

While I know you said you haven't tested it in this way @frangio, are there any security concerns with mixing ECR721s with PaymentSplitter that you can think of?

Is this generally a bad practice? I'm somewhat new to the crypto smart contract space.

Consider that PaymentSplitter does not currently support ERC20 tokens, only ETH.