A place for developers to talk about building on Farcaster.

/dev

Picture this: you're building the next big thing on @ethereum

Your app allows users to __ ERC20 tokens. Cats, dogs, penguins, the US dollar, you name it, anything that's a token, users can __. They click the button. Something breaks.

Let's explore the dark side of ERC20s👇🧵

Ethereum is the world computer. The universal platform for cryptocurrencies, blockchain apps, stablecoins, and decentralized technologies.

Co-founder and CPO @Sablier. Product designer and engineer.

Fancy a long-form option you can bookmark and enjoy later?

Head over to the @sablier blog to get the full piece.

https://blog.sablier.com/the-dark-side-of-erc20s/

Or keep reading for some not-so-easy to spot pitfalls with ERC20 tokens.

➡️ Token details, string vs bytes32

Most ERC20s return name/symbol as strings. To optimize gas, devs may choose to represent these in bytes32.

The switch can cause failing queries, or worst, failing infra when indexers like @graphprotocol or @envio stop parsing events ✋

Solution?

Don't expect to always get strings. Query for token details in both formats, at once or in sequence. If the call expecting a string result fails, revert to the bytes32 version (and manually convert to strings afterwards).

➡️ The 96 bits allowance

Infinite allowances are an anti-pattern. But, in the spirit of shipping fast, they're at times overlooked. Passing in generic max values can cause approval txs for tokens like COMP to fail.

The solution?

Implement granular allowances or handle max values for these special tokens. For example, an allowance of 10^25 should fit just fine for COMP, while for most tokens, you're free to go even higher.

➡️ Token balance “go up”

Mechanisms like rebasing tokens or Aave yield tokens rely on dynamic balances. Failing to account for this can cause things to break, or in case of yield, the surplus is lost forever.

Solution? Warn users or implement smart wrappers like ERC4626.

➡️ Blacklists, rules and more rules

Issuers will now and then implement special types of constraints. Where Circle's USDC will prevent malicious usage through blacklists, other projects may go with allowlists for wallets which can hold more than e.g. 10% of the supply.

The latter usually fails for public escrows where funds accrue, like @uniswap pools or @sablier vesting contracts 🏦

How to fix these?

Well, since there’s no way to quickly cover all these edge-cases, you should simply keep an eye out for such behavior when debugging.

After endless hours of debugging txs and reports, I’ve compiled a list of common pitfalls involving ERC20s. Prevent them and users will be forever grateful.

→ Details, string v bytes32
→ The 96 bits allowance
→ Balance “go up”
→ Blacklists
→ Admin rights

Let's dive in!