Voltage Finance ERC-677 Reentrancy

On March 31, 2022, Voltage Finance — a DeFi suite on the Fuse Network — lost approximately $4 million from its lending market through an ERC-677 reentrancy. Voltage's fork of a Compound-style lending contract supported ERC-677 tokens, whose transferAndCall callback let an attacker re-enter the borrow function before their debt was recorded.

What happened

Voltage's lending market accepted various tokens as collateral, including ERC-677 tokens. ERC-677 extends ERC-20 with a transferAndCall function — when tokens are transferred, the recipient contract's onTokenTransfer hook is invoked, allowing the recipient to execute arbitrary code during the transfer.

The lending contract followed the standard (vulnerable) pattern: send borrowed tokens to the borrower, then update the borrower's debt accounting. With an ERC-677 token, the "send borrowed tokens" step triggered the borrower's onTokenTransfer callback before the debt was recorded.

The attack:

1. Used an ERC-677 token in the borrow path.
2. Called borrow — the contract sent the borrowed tokens, triggering the attacker's onTokenTransfer callback.
3. From inside the callback — before the first borrow's debt was recorded — the attacker re-entered borrow again, against collateral the contract still saw as unencumbered.
4. Looped the reentrancy, accumulating borrowed funds with no corresponding recorded debt.
5. Walked away with ~$4M.

Aftermath

• Voltage Finance paused the lending market and published a post-mortem identifying the ERC-677 reentrancy as the root cause.
• A compensation plan was rolled out; recovery from the attacker was minimal.

Why it matters

Voltage Finance is part of the callback-enabled-token reentrancy lineage — the same structural class as Cream Finance's AMP exploit (ERC-777 tokensReceived). The recurring lesson:

Token standards with transfer callbacks (ERC-777, ERC-677, ERC-1363, and others) break the reentrancy assumptions that hold for plain ERC-20. A lending or vault contract that is reentrancy-safe for ERC-20 tokens may be completely exploitable the moment it accepts a callback-enabled token, because the "transfer" step now executes attacker-controlled code mid-operation.

The defensive answers:

1. Apply reentrancy guards to every state-mutating path that makes token transfers — not selectively, and not on the assumption that "ERC-20 transfers don't call back" (true for plain ERC-20, false for the callback-enabled extensions).
2. Audit each listed token's actual standard, not just "is it an ERC-20 interface." Many tokens implement ERC-20 plus a callback extension; the extension is the attack surface.
3. Follow checks-effects-interactions rigorously — record debt before sending borrowed tokens, so a reentrant call sees the updated state.

Voltage is one of the smaller-loss entries in the catalogue, but it's a clean instance of a lesson the ecosystem keeps re-learning across years and chains: the token you list determines your reentrancy surface, and callback-enabled tokens are a different threat model than plain ERC-20.