bZx Patched iToken Duplication Flaw After an $8 Million Drain

On September 13, 2020, decentralized lending and margin-trading protocol bZx said a flaw in its iToken contracts had allowed an attacker to create unbacked token balances and redeem them against assets in its lending pools. The team patched the duplication method, deployed replacement contract logic and resumed normal protocol operations after a temporary pause.

The incident mattered beyond one protocol. DeFi lending was expanding rapidly on Ethereum, and iTokens were intended to function as claims on supplied assets. A bug that inflated those claims without adding collateral struck at the accounting assumption that made the pools usable. It was also bZx’s third publicly reported exploit of 2020, despite prior reviews by security firms, making the episode a test of both smart-contract auditing and emergency administrative controls.

What bZx reported

In its incident disclosure, bZx recorded debts of 219,199.66 LINK, 4,502.70 ETH, 1,756,351.27 USDT, 1,412,048.48 USDC and 667,988.62 DAI. The protocol and contemporaneous news reports described the combined value as roughly $8 million.

That dollar figure should be treated as a contemporaneous estimate, not a reproducible market calculation. The disclosure did not specify a valuation timestamp, trading venue, price benchmark or conversion method for the five assets. The token quantities are therefore the firmer measurement; “roughly $8 million” is bZx’s event-period characterization rather than Coinburn’s independent mark.

bZx said it began investigating a decline in total value locked during the morning of September 13 and confirmed that several iTokens were affected. The team paused iToken minting and burning while it investigated. Borrowing and trading were not affected, according to the protocol.

How one accounting error multiplied claims

An iToken represented a lender’s share in a pool of deposited cryptocurrency. The vulnerable transfer routine first copied the sender’s and receiver’s balances into temporary variables, then wrote the subtraction and addition back to storage. When the sender and receiver were the same address, both temporary values referred to the same starting balance. The credit write could therefore overwrite the debit using stale information, increasing the user’s apparent balance after a transfer to itself.

The attacker could repeat that operation, produce iTokens that were not backed by new deposits, and then redeem the enlarged balance for real assets held by the pools. Contemporaneous accounts and the surviving contract record distinguish this from bZx’s February incidents, which involved manipulated market inputs. The September flaw was an internal token-accounting error.

Ethereum transactions preserve individual contract calls and timestamps, but one transaction page does not by itself prove bZx’s aggregate five-asset loss. The on-chain record supports the date and mechanics; the protocol’s disclosure supplies the consolidated quantities.

The response exposed a DeFi trade-off

bZx said it corrected the affected function, deployed updated iToken contracts, reset balances and sent the changes to PeckShield and CertiK for review. It also said the resulting debts had been charged to its insurance fund and that users would not bear losses. Those were protocol representations on September 13, not an independently audited guarantee of the fund’s capacity or the timing of reimbursement.

The rapid intervention limited further withdrawals, but it also showed that the system depended on a team able to pause functions, replace logic and alter accounting state. That capacity was useful in an emergency while also qualifying broad claims of immutability or complete decentralization.

As of September 13, the defensible conclusion was narrow: a self-transfer accounting flaw had produced unbacked claims, assets valued by bZx at about $8 million had left its pools, and administrators had patched and restarted the affected functions. Any subsequent recovery of assets belongs to a later chronology and is not used to soften the event-day record.