ERC-20s in the Wild: Why Vanilla Assumptions Breaks

Table of contents

Hey everyone 👋

I’m back from a short vacation and diving straight into smart contract audits again.

This week there’s also a brand-new chapter in the Docker security series 🐳. If you’re into container security, I’m covering practical Docker breakout techniques along with some progress updates on Valeris, the tool I’m building in Rust to explore these scenarios. If that sounds interesting, make sure to check it out before diving into today’s smart contract topic!

When Containers Lie: Escaping Root and Breaking Docker Isolation

We explore how root containers and host mounts enable privilege escalation, from SUID binaries in shared volumes to abusing /proc/<PID>/root. Then we show how Valeris detects these risky setups with YAML-based rules before they lead to full host compromise.

KaysselRuben Santos Garcia

One thing I’ve noticed over and over is how often protocols assume ERC-20s behave like “vanilla” tokens. You know, simple balanceOf, transfer, transferFrom … nothing fancy.
But first, let’s quickly recap what an ERC-20 is. In short, it’s a token standard on Ethereum that defines a common interface for fungible assets. This means any token that follows the ERC-20 rules can be used interchangeably by wallets, exchanges, and protocols. At its core, an ERC-20 keeps track of balances and allows transfers between accounts. It also defines functions like approve and transferFrom so contracts can move tokens on behalf of users. The whole point is interoperability: if every token speaks the same “language”, developers can build without worrying about the specific implementation of each asset.

The catch is that not every ERC-20 sticks to this “vanilla” model. Some introduce quirks or edge cases that can completely break integrations if you don’t account for them.

Let’s go through some of the most common troublemakers.

Fee-on-Transfer Tokens

Some tokens apply a fee on every transfer. You might try to send 100 tokens, but the recipient only ends up with 95. This breaks assumptions in many protocols that expect one-to-one transfers. Accounting, reward distribution, and balance checks often fail when the received amount is smaller than expected.

Reverting on Zero Transfers

In vanilla tokens, transferring zero is harmless and often used by protocols as a quick sanity check. However, some implementations revert if you try to transfer zero. Suddenly, batch transfers or loops that assume this behavior will start failing.

Rebasing or Elastic Supply Tokens

Rebasing tokens change balances automatically, either increasing or decreasing them to maintain certain supply dynamics. This can completely throw off systems that rely on static accounting. Governance systems or lending protocols that depend on exact balance snapshots can break because user balances shift outside of their control.

Burn-on-Transfer or Deflationary Tokens

Some tokens burn part of the amount being transferred. Over time, this chips away at supply and confuses contracts that assume transfers are lossless. Reward systems, accounting models, and treasuries may miscalculate values as a result.

Tokens That Don’t Return a Boolean

The ERC-20 spec says transfer should return a boolean, but early tokens like USDT don’t follow this rule. If your contract uses the raw IERC20 interface and expects a return value, things can fail silently. Libraries like OpenZeppelin’s SafeERC20 patch this issue, but it’s always important to verify the behavior of the specific token.

Wrapping Up

When building or auditing protocols, don’t just assume you’re dealing with a vanilla ERC-20. The reality is that fees, burns, rebases, frozen accounts, or missing return values are all out there in production tokens. If your system isn’t prepared, it will eventually fail when faced with these variations.

That’s why one of the safest design choices is to avoid supporting arbitrary tokens altogether. Instead of accepting any ERC-20, build a curated list of approved assets. Expanding this list gradually, after testing each token type, reduces the attack surface and avoids hidden edge cases that can cost real money.

That’s it for this week, stay sharp out there 🕶️
Ruben

References

I usually don’t share references in the newsletter because it’s more of a “personal experience” thing, but I thought I’d share two articles that are quite interesting if you’d like to dive deeper into these topics.

• Fee on transfer & Rebase Tokens. https://medium.com/@0xnolo/fee-on-transfer-rebase-tokens-an-erc-20-security-bug-you-need-to-know-f4e5badea1ee
• ERC-20 Token Security: What You Need to Consider. https://medium.com/thesis-defense/erc20-token-security-what-you-need-to-consider-46ab8231a050

Chapters

Breaking Mobile-to-Device Logic: When BLE Access Falls Apart

Previous Issue

Bypassing Cloud Firewalls: Size Does Matter

Next Issue