HIP-376 Support Approve/Allowance/transferFrom standard calls from ERC20 and ERC721

[stoqnkpL]

Discussion for #376

[web3-nomad]

Is it possible to add something where the ERC20/721 token owner needs to 'opt-in' to this to allow this functionality to be enable for their token?

allowances allow for hacks similar to what occurred on opensea in February.
and while useful, they might add additional risk to owners of these who aren't as literate as others.

[stoqnkpL]

Only the token owner can allow someone to spend their tokens. For example if we have an NFT with id 0.0.1001 and:

• Alice is the owner of serial numbers 1, 2 and 5
• Bob is the owner of serial numbers 3 and 4
• Alice calls token1001.approve(Carol's address, 1) 🟢 this is allowed because Alice owns serial number 1
• Alice calls token1001.approve(Carol's address, 3) 🔴 this will return an error because Alice does not own serial number 3

So is it inferred that the owner agrees to 'opt-in' if such a valid request reaches the precompile, since no one can send it on their behalf.

[web3-nomad]

the hack i pointed to showed an example where a user was tricked into 'allow'ing their NFTs.
as it isn't a big use case, I was suggesting that this feature be optional at the token creation level.

[stoqnkpL]

the hack i pointed to showed an example where a user was tricked into 'allow'ing their NFTs. as it isn't a big use case, I was suggesting that this feature be optional at the token creation level.

If I understand correctly, you're proposing the token creator to have control and choose at the moment of creation whether token holders will have the ability to approve spenders. Do you mean only protect from ERC721 approveForAll or all types of allowances? What would be the default behaviour? Also, would this property of the token be updatable or immutable once set?
I think this may protect some people from being scammed, but may also cause confusion and limitations of usability for tokens, that have this protection - e.g. they won't be tradable on exchanges. Generally the direction we're going towards is being compatible with the current behaviour for ERC20 and ERC721 tokens and the way dapps and dexes work on Ethereum.

[ljkrause]

We'd really love to see these things implemented and live in the (very) near future :)