You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Like the previously disscused at OpenZeppelin Forum. i am agreed that zero address checks in OpenZeppelin Contracts it's not that important. since people can burn through other address like 0x0dEad and many more ways.
maybe we can consider to remove zero address checks so the contracts more flexible as a module. and maybe it can saving some gas. so any update of this issue?
The text was updated successfully, but these errors were encountered:
Hello @gentasumantri, and thank you for raising this issue.
Can you give us more specific details about which check you have issues with? Are you talking about Ownable? ERC20/721 transfers? Depending on the contract, we might have good reasons to do these checks. I'd love to know more about your usecase.
If I was going to write a token standard again, I would exclude to != 0x0 checks in the code, and then make up for it with Clients MUST produce a warning before attempting to send to the 0x0 address if the user intention is to transfer.
But as long as we have the current standards that are widely supported and there are no glaring errors with them, we should prefer consistency over minor innovations.
I don't really see reasons to allow use of 0x0 like any other address (in transfers or elsewhere), and I do see some reasons to disallow it, namely that it can show up accidentally in a few places: read from an uninitialized variable or in the return value of ecrecover. They are not particularly strong reasons but I think the net result is that we should treat the zero address specially and disallow its use in most places.
Like the previously disscused at OpenZeppelin Forum. i am agreed that zero address checks in OpenZeppelin Contracts it's not that important. since people can burn through other address like
0x0dEad
and many more ways.maybe we can consider to remove zero address checks so the contracts more flexible as a module. and maybe it can saving some gas. so any update of this issue?
The text was updated successfully, but these errors were encountered: