SNIP-2: the fungible token specification (a la ERC20) for Starknet

[moodysalem]

Discussion for https://github.com/starknet-io/SNIPs/blob/main/SNIPS/snip-2.md

[moodysalem]

Recently #28 was merged, which removed the approval and allowance methods from the specification. The rationale was that these methods are not necessary when every account is able to make multiple calls atomically in a single transaction. You can always transfer the exact or maximum amount of token needed at the beginning of a transaction, then call the contract that you just used to refund any excess tokens if necessary.

This simplification is desirable because it reduces the surface area for building a fungible token on Starknet. In addition, approvals are a significant attack surface for ERC20 tokens. E.g. you approve a contract for the maximum amount, and then later the contract is found to have a bug or upgraded, now the contract can steal all the tokens that you approved.

Also, approvals are quite difficult to work with for inter-contract interactions. Different tokens may include differences in behavior for approvals, e.g. approve only from 0 allowance. This creates a lot of edge cases when working with approvals between contracts that do not exist when you only use transfers.

[gaetbout]

Gm,

I think it is very dangerous to tamper with that mechanism. Let me elaborate.:

Especially because there is account abstraction as first class citizen this approval mechanism should stay in place.
In one atomic call, you could allow the contract to spend X, make the transfer of X, then the allowance should be back to zero. Is it up to the wallet to flag dangerous transaction.
Regarding dangling allowances, I think wallets (or dapp) should provide a way to remove X approvals in one single multicall call.
It could even be implemented at the account level as a plugin to always make sure no allowance stays unused for too long.

Besides that, the removal of transferFrom would effectively remove all possibility of doing off chain signatures (EIP712).

Imagine I allow a marketplace to buy an NFT for 1ETH, without transferFrom how can this be achieved?

This shouldn't become the standard of fungible tokens, but it does make sense for specific use cases. But it could be achieved using a wrapper around the standard ERC20 interface.

In the hope that this comment may provide some input to this proposal 🙂

[moodysalem]

You don't need approvals to support NFT marketplaces. You can just transfer the token to the marketplace to give it custody. This is how Blur works despite ERC20 containing allowance/approve. I think it makes sense to transfer the tokens because it's more explicit than approving a contract, since you always know when your tokens are at risk with the marketplace, versus on Ethereum where you have to use a tool like revoke.cash to know what's at risk.

This does have the drawback that you can't have orders on multiple marketplaces simultaneously, unless they work together to standardize on this wrapping/order contract.

[gaetbout]

So if that smart contract gets hacked it has directly access to my funds, instead of me being able to revoke allowance?

[moodysalem]

If the contract gets hacked and has access to your allowance, you can be sure your tokens will be transferred out before you get a chance to revoke your approval (for any competent hacker and significant balance)

[milancermak]

You can just transfer the token to the marketplace to give it custody.

What if I want to list it in multiple marketplaces?

[mottyl]

I think that the primary objective should be to safeguard users from dApps that request infinite approval. This is a necessary evil on L1 that we need to try and eliminate on Starknet. As @moodysalem already highlighted, this presents a significant attack vector.

However, I understand the concerns regarding breaking the API and the support for off-chain signatures. Therefore, another solution worth exploring is to nullify the spender's allowance after the transferFrom operation. In other words, there wouldn't be any remaining allowance (large or small) for the spender after the funds have been transferred. This approach would largely prevent users from long-term exposure to contract bugs.

Of course, this should come in addition to the wallet's responsibility to flag dangerous transactions. Unfortunately, users don't always heed such warnings.

[moodysalem]

However, I understand the concerns regarding breaking the API and the support for off-chain signatures. Therefore, another solution worth exploring is to nullify the spender's allowance after the transferFrom operation. In other words, there wouldn't be any remaining allowance (large or small) for the spender after the funds have been transferred. This approach would largely prevent users from long-term exposure to contract bugs.

IMO this solution would become another in a long list of non standard implementations of approve and allowance that would make it harder to work with.

Imagine for example you want to write a contract that does multiple smaller calls to transferFrom to other addresses, now you have to write it to take custody of all the tokens first and then do transfers to be interoperable with tokens that have this behavior, and then you might still need to include a refund.

[mottyl]

The aim of this discussion is indeed to standardize it :)

Regarding your example above, where custody of all tokens is taken first in the case of multiple smaller calls to transferFrom, wouldn't this still be the case if we were to eliminate Approve and transferFrom?

[moodysalem]

The aim of this discussion is indeed to standardize it :)

Adding behavior to the spec would make a bunch of existing tokens non-standard, since they are implementing older versions of the spec, and also creates additional ways in which tokens can be non-standard. Removing from the spec on the other hand makes more tokens standard. Fungible tokens are probably the most frequent contract on any network, and many will not upgrade, so developers have to consider all the common non-standard implementations of the spec.

Consider that even with the simplified transfer-only spec, developers will still create non-standard tokens that take fees on transfer and users will want to use them. There is no way to make all the tokens work the same, but it is possible to limit the surface area where non-standard behavior can be introduced.

Regarding your example above, where custody of all tokens is taken first in the case of multiple smaller calls to transferFrom, wouldn't this still be the case if we were to eliminate Approve and transferFrom?

Yes, the contract would need to transiently custody the tokens, but the point is that the spec that includes approvals is more complicated to achieve the same result.