The $201 Million Design Flaw
In 2017, a developer known as Dexaran opened GitHub issue #223 on the Ethereum Improvement Proposals repository. His argument was precise: ERC-20, the token standard that underpins the majority of the Ethereum ecosystem, had a fundamental flaw baked into its architecture. Tokens transferred directly to a smart contract using the standard `transfer()` function would arrive, and stay there forever, irretrievable.
By his calculations, over $201 million in ERC-20 tokens had already been permanently lost this way. The number has grown significantly since. EIP editors would later acknowledge the security concern while declining to place a formal warning on the ERC-20 standard itself. *(Source: Dexaran, dexaran.github.io/erc223, 2023)*
The proposal that became ERC-223 was Dexaran's answer. Eight years later, it is formally documented in Ethereum's developer standards. The flaw it was designed to fix is still causing losses.
Why ERC-20 Loses Tokens
ERC-20 defines two transfer mechanisms. The first is `transfer(address, uint256)`, a direct push from sender to recipient. The second is `approve(address, uint256)` followed by `transferFrom(address, address, uint256)`, a two-step pull pattern where the sender authorizes a contract to collect tokens on their behalf.
For transfers between wallets, `transfer()` is correct. For deposits into a smart contract, a DEX, a lending protocol, a staking contract, the correct pattern is `approve() + transferFrom()`. The contract must explicitly call `transferFrom` to collect the tokens, which gives it a chance to execute logic in response.
The problem: `transfer()` does not notify the receiving contract that tokens arrived. The tokens exist at the contract's address at the EVM level, but no function in the contract is called. No logic executes. The tokens are received in the accounting sense and invisible in every practical sense.
Most users cannot be expected to know which pattern is correct for which recipient. They see an address, they call `transfer()`, and the tokens disappear. The burden of understanding the destination contract's internal design was placed on non-technical users, a burden they cannot consistently bear. *(Source: EIP-223, eips.ethereum.org/EIPS/eip-223)*