Thread by @w1nt3r_eth

Best practices when handing payments 💸 in NFT contracts #solidity ↓

Pull, don't push.
* If you forward ether payments from your mint function, it makes minting more expensive.
* If your contract gets some Ether without triggering the mint function, these funds will be lost forever.

Instead, make a function that transfers you the full balance.

Note that the withdrawAll function isn't marked as onlyOwner. Anyone can call it. This lets you set up automation (e.g. via Infura or OZ defender) that doesn't depend on your private keys.

While you are here, it's also a good idea to include a function that does the same but for any ERC20 token.

There are plenty of ways your contract can get these, and it would be unfortunate to lose thousands of dollars by not implementing this simple function.

Always check for the exact payment value.

I used msg.value > X ether in my first NFT contract, and it caused a lot of headaches. Some users minted from Etherscan's UI and miscalculated the proper value, and then chased me asking for a refund (which I did). Not fun.

Royalties (IERC2981) is a good idea, but there are some gotchas. The payment token can be anything, so make sure the royalties receiver is either the owner or the contract has a way to extract ERC20s. Here's an example where funds got locked forever

Here's how we are implementing royalties support for @watchfacesworld. Note that we can upgrade the royaltyInfo in the future by supplying a new implementation. This is cool because we could offer our holders some royalties (no promises 😅), without locking the logic now.

Last 2💸 tips for now:

1) Use a shared @gnosisSafe for your team (ideally with N/M signatures requirement). It'd really suck to lose your hard earnings in case someone is compromised.

2) Use @0xSplits to painlessly split the profits.