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
Similar to _mint, the _burn method may need to be called by a particular token's implementation when various events occur. One could work around this by making the token be its own operator, but that just seems silly and is a waste of gas.
The text was updated successfully, but these errors were encountered:
We have an open PR (#1908) tackling this that has become stuck but I would like to move it forward.
Can you let me know your thoughts on the concern I expressed there before we implement this?
My only concern with this PR is that it allows passing an arbitrary operator. This would be consistent with the current _mint function, but I feel that may have been an oversight. In my mind it would make much more sense to automatically set either this (or msg.sender?) as the operator in the internal functions. Otherwise the events emitted could be "lying". I realize this may be too much of a detail but I want us to think about it a bit before merging.
The concern is that the contract could be observed through the events as having any arbitrary operator that hasn't been registered before as a default or account-specific operator. I'm not sure how this could affect users of the interface.
openzeppelin-contracts/contracts/token/ERC777/ERC777.sol
Lines 373 to 380 in 19a6590
Similar to
_mint
, the_burn
method may need to be called by a particular token's implementation when various events occur. One could work around this by making the token be its own operator, but that just seems silly and is a waste of gas.The text was updated successfully, but these errors were encountered: