Curriculum·G303 Storage, Upgrades, and Trust·about 33 min
Return values, and tokens that misbehave
By the end of this lesson you can
- →Explain that not all tokens revert on failure, so a call's return value must be checked
- →Describe how Force DAO credited shares for transfers that had silently failed and returned false
- →Reason that a misbehaving token is common, not an edge case, so code must not assume standard behavior
- →Check return values and handle tokens that return false, return nothing, or take fees on transfer
Graduate · enrolled learners
This lesson opens with Force DAO, April 2021.
- What happened
- Force DAO's staking contract accepted FORCE tokens through a transferFrom call and, in return, credited the depositor with xFORCE staking shares. The mistake was that it did not check the return value of the transfer. The FORCE token followed an older style that returned false when a transfer failed instead of reverting, so when five attackers called the deposit without actually holding or approving FORCE, the transferFrom quietly returned false, no tokens moved, and because the return value was never checked the contract credited them the xFORCE shares anyway. They then redeemed those shares for real FORCE, taking about 367,000 dollars; four of the five returned the funds afterward. Nothing exotic happened: the contract assumed the transfer had succeeded because it did not revert, when in fact the token signaled failure through a return value the code ignored. A transfer that fails silently and is not checked is a transfer the contract believes happened when it did not.
- The decision point
- Not every token reverts when a transfer fails; some return false, some return nothing, some silently take a fee on transfer, so a contract must check the return value of a token call and handle tokens that do not behave like the idealized standard, because assuming standard behavior is assuming something many real tokens do not do. Force DAO is the case: its staking contract credited xFORCE shares in exchange for a transferFrom it never checked, and because the FORCE token returned false instead of reverting on a failed transfer, attackers were credited shares for transfers that never happened and redeemed them for about 367,000 dollars. This is the same trust boundary as the prior lesson, seen from the token side: a token is external code, and its response, including whether it reverts or returns false, is a signal the contract must read, not assume. A contract that treats
- Recorded loss
- $367,000
What you will be able to answer
- →How was Force DAO exploited (April 2021)?
- →How do tokens signal a failed transfer?
- →Why is a misbehaving token a design concern, not an edge case?
- →What must code do when it moves tokens?
Orientation and Year One are open: anyone can read them without an account. From Year Two onward the lessons are for enrolled learners, because progress through the later years only means anything if it is tracked against a record.
It is free. We do not sell the list and there is nothing to buy at the end of it.
Sources and review
Confidence high·Volatility low·Reviewed 2026-09-17·Owner unassigned
Contested
The roughly 367,000 dollar figure is the approximate amount taken by the five attackers; four of the five returned the funds afterward, so the net loss was much smaller. The lesson uses the unchecked-return-value mechanism, not a precise net loss.
The specific behavior was that the FORCE token returned false on a failed transfer rather than reverting; this lesson generalizes to the broader class of tokens that return false, return nothing, or take fees, which is the transferable point.