Razvan Gabriel

@razgraf

129 Following

83 Followers

Razvan Gabriel pfp

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.

1 reply

1 recast

0 reaction

Razvan Gabriel pfp

Another round of shipping 🚚 driven by user feedback! Large-scale airdrops, professional vesting, streamed payments - @sablier just keeps getting better. https://blog.sablier.com/introducing-ranged-airdrops/

0 reply

0 recast

0 reaction

Razvan Gabriel pfp

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👇🧵

1 reply

1 recast

0 reaction

Razvan Gabriel pfp

🧵 https://warpcast.com/razgraf/0x2d60ab71

0 reply

0 recast

0 reaction

Razvan Gabriel pfp

Things can always break. ERC20 have a dark side only known to select web3 product engineers. You are now one of them. Prevent, fix or explain - either way, users will thank you. And when they're silent, it means you did an amazing job 🔥 hiding all this complexity from them. Congrats!

1 reply

0 recast

0 reaction

Razvan Gabriel pfp

While these are great and show a need for improved token functionality, they don't all address the full list of gotchas we just went through.

1 reply

0 recast

0 reaction

Razvan Gabriel pfp

As a final tip, learning to read the chain will help uncover more “mysteries” down the road 🕵️‍♂️ From basic analysis with Etherscan to (personal favorite) debugging at its finest with Tenderly , you’ll develop an eagle eye for unexpected behavior.

1 reply

0 recast

0 reaction

Razvan Gabriel pfp

Fixing what’s broken.. In the spirit of innovation, teams have already started implementing alternative systems, that may one day replace the ERC20 "standard" - @fuel-network SRC20, where all assets are native (like ETH) - @optimism SuperchainERC20, BEP20, xERC20 - @solana SPL

1 reply

0 recast

0 reaction

Razvan Gabriel pfp

The list, of course, is just the start. A few other quality-of-life features to consider: - correctly handling token decimals (18 is common, not standard) - preventing token addresses from being filled in recipient fields - bundling allowances with txs ( @safe or EIP 5794)

1 reply

0 recast

0 reaction

Razvan Gabriel pfp

Well, what can we do? Since it's yet again, a hard to predict behavior, keep an eye out for shady tokens. If your protocol is immutable, explain that forceful actions like burning tokens are at the discretion and the sole responsibility of the token admins.

1 reply

0 recast

0 reaction

Razvan Gabriel pfp

Part 2 ➡️ Admin rights Some tokens come with admin rights. One such right is to burn assets from handpicked wallets or forcefully transfer them without the user's knowledge 🥷. A far-from-standard practice resulting in assets disappearing from the protocol.

1 reply

0 recast

0 reaction

Razvan Gabriel pfp

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.

0 reply

0 recast

0 reaction

Razvan Gabriel pfp

➡️ 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.

1 reply

0 recast

0 reaction

Razvan Gabriel pfp

➡️ 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.

1 reply

0 recast

0 reaction

Razvan Gabriel pfp

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.

1 reply

0 recast

0 reaction

Razvan Gabriel pfp

➡️ 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.

1 reply

0 recast

0 reaction

Razvan Gabriel pfp

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).

1 reply

0 recast

0 reaction

Razvan Gabriel pfp

➡️ 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 ✋

1 reply

0 recast

0 reaction

Razvan Gabriel pfp

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.

1 reply

1 recast

0 reaction

Razvan Gabriel pfp

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!

1 reply

0 recast

0 reaction