Title: What_to_do_about_hidden_or_undisclosed_logic_in_ER
Category: Magicians

Author: jpitts
Date: 2020-04-07T17:28:26.371Z

This is a starter thread for standard ways to better enforce user expectations for ERC-20 contracts, or at least provide mechanisms to inform users of hidden / undisclosed logic.
This issue was brought up in a Tweet today by @LefterisJP, and I’ve heard it discussed before.


twitter.com


Lefteris Karapetsas | Hiring for @rotkiapp (@LefterisJP) on X
@LefterisJP

TIL: @Tether_to's $USDT ERC20 token in #ethereum takes a cut out of every single transfer.The cut goes to the contract owner which I assume is none other than @Tether_to

Wtf?Who uses this shit?

Source: https://t.co/5igSPett3K

Thanks to @owocki for bringing this to my attention









A key problem is that potential fees triggered by maintainers and other logic can break the user experience. There is a set of assumptions/expectations around ERC-20s that is not enforced.


twitter.com



Lefteris Karapetsas | Hiring for @rotkiapp (@LefterisJP) on X
@LefterisJP

@will_harborne @RonaldoVamo @hasufl @Tether_to @owocki Any fee is just wrong and messes with the UX and expected implementation by most dapps for ERC20 token transfers.

No doubts on the centralization part. They can also blacklist you and issue more tokens. Same thing with USDC.

There is an amount of trust involved for sure.









Additional logic also leads to higher gas costs for users.
https://twitter.com/LefterisJP/status/1247582282443087872
Solutions
There an effort organized by @p0n1 to track buggy / nonstandard code in ERC-20s, it may be defunct as the last commit is Oct 10, 2018.


github.com




GitHub - sec-bit/awesome-buggy-erc20-tokens: A Collection of Vulnerabilities in ERC20 Smart...
A Collection of Vulnerabilities in ERC20 Smart Contracts With Tokens Affected







Update:
Article by Daniel Que describing the general situation and techniques used:  What we learned from auditing the top 20 ERC20 token contracts

Author: LefterisJP
Date: 2020-04-08T12:11:51.581Z

Hey @jpitts.
Thanks for making the thread. I got a lot of shit for writing that tweet 
I think that such tokens should be flagged in a database maybe much like the one you linked and wallets, dapps, portfolio trackers should show some kind of warning to the user.
The biggest problem imo comes when transfer/transferFrom() does not work as expected. Many contracts assert that the transferred amount was fully transferred to the recipient. If at some point this breaks for a contract, like say the tether contract enables fees then all dapps using it would break.

Author: GridTechs
Date: 2020-04-09T01:14:19.778Z

I need to understand the issue with the smart contracts. Can you explain what you are experiencing?
Thank you

Author: owocki
Date: 2020-05-11T02:56:29.124Z

Usdt doesn’t work on gitcoin grants rn because of this. It’s a big pain in the butt.
I think that verified contracts on etherscan do the work of letting us all see why though. Which is positive. Not sure what else can be done other than many creating a community based taxonomy of erc20s and their “quirks”

Author: wjmelements
Date: 2020-05-15T04:16:24.564Z

Just wrap the token with a token that actually conforms to ERC20 and doesn’t charge fees. You can also do this for inefficient implementations like the GUSD.

Author: kohshiba
Date: 2020-06-06T06:42:15.347Z

I think wrapping up is an interesting idea.
Given there are many other forms of USD pegged tokens, I think some sort of TCR or other curation style system for the issue might be helpful.

Author: jpitts
Date: 2020-08-25T18:01:17.303Z

There is an article posted today which covers this issue, specifically citing a recent paper on identifying poor implementations of ERC-20. There are also numerous misconceptions in the article about how governance of ERC standards work (which I will not yet speak to).
https://www.coindesk.com/erc-20-ethereum-tokens-fake-deposit
Quote from the paper DEPOSafe: Demystifying the Fake Deposit Vulnerability in Ethereum Smart Contracts (PDF):

we implement DEPOSafe, an automated tool to detect and verify (exploit) the fake deposit vulnerability in ERC-20 smart contracts. DEPOSafe incorporates several key techniques including symbolic execution based static analysis and behavior modeling based dynamic verification. By applying DEPOSafe to 176,000 ERC-20 smart contracts, we have identified over 7,000 vulnerable contracts that may suffer from two types of attacks.

This is @AlexeyAkhunov describing the vulnerability, which impacts how exchanges deal with tokens:

The attacks relies on a flawed code at the side of an exchange. Early versions of ERC-20 assumed that if transfer’s precondition aren’t satisfied, it should “throw” (using assert). Then, the “bool” return value was added, meaning that the “new” way of signalling
that the transfer did not happen is to return false instead of throw
So exchanges that assume that invalid transfer always throws, and invalid transfer does not, do not check the return value of “transfer” function
I think this “attack” is basically exploiting the confusing nature of slightly different versions of ERC-20 and their incompatibility with each other. ERC-20 should have never been changed like that, a new standard should have been created instead

Author: nagydani
Date: 2023-07-26T08:05:47.392Z

The problem of not automatically flagging malicious ERC20 token contracts is still with us. I did this writeup about an ongoing scam which critically relies on malicious ERC20 token contracts that execute transferFrom() calls without a matching approve() call by the payer.