12

Is there a relevant difference for an ER721 contract? Is there a difference in gas cost?

highrankin
  • 183
  • 2
  • 7

2 Answers2

15

I am familiar to which implementations you are referring. (As this is not a specified ERC-721 feature.)

The _safeMint flavor of minting causes the recipient of the tokens, if it is a smart contract, to react upon receipt of the tokens.

Here is a general consideration to help you decide which one to use:

  • If YOU are paying for the minting of tokens, use _mint. The _safeMint might cost you an arbitrary amount of money because of choices made by the recipient of the tokens. This is enough to deter you from considering it.
  • If THEY are paying for the minting of tokens and you expect buyers to be composing functionality with smart contracts, use _safeMint. There is some marginal benefit of allowing the extra features with smart contracts this allows.
  • If THEY are paying and you expect INDIVIDUAL PEOPLE to buy tokens, then use _mint. The extra features in _safeMint are not expected.

The extra cost from using _safeMint is non-zero. And cost is also always a concern.

William Entriken
  • 4,690
  • 15
  • 42
  • Would really help here if you can elaborate who YOU and THEY are and whether you're talking about paying for the gas fee or paying for mint of the token (payable). – Ayrton Senna Mar 04 '22 at 13:14
  • Above "YOU" is the contract designer/administrator who is deploying the contract. "THEY" are the customers of your product (i.e. "hodlers"). – William Entriken Mar 04 '22 at 15:15
  • This is an amazingly helpful answer. Thank you! – KcC0 Mar 21 '22 at 09:39
  • 1
    Excellent answer William. I like how you gave different scenarios and framed them in terms of what we are trying to solve. – Tomiwa May 28 '22 at 13:29
1

_mint and _safeMint are not part of the ERC721 standard, so you should check the specific implementation of those methods to see what are the differences in the smart contract. Even differences in gas costs can only be verified looking at the code (plus sometimes the current state of the chain) and cannot be derived only by the interface.

This is always true for every smart contract, not only for those exposing a standard interface.

Please note also that, like other ERC token standards (i.e. ERC20), the specification is useful only to share the signature of the methods (name and parameters) to be able to interoperate with other smart contracts and application, but it does not impose a specific implementation nor it allow you to check if the smart contract behaves as you expected under the hood. Again, you must always check the code by your own.

Giuseppe Bertone
  • 5,487
  • 17
  • 25