Cowrie Research

forcedao-xforce-minime-transferfrom-false-return-unbacked-share-mint-drain-2021-04-04

11 min read

ForceDAO xFORCE MiniMe transferFrom False-Return / Unbacked-Share Mint Drain (2021-04-04)

  • Name: ForceDAO xFORCE MiniMe transferFrom false-return / unbacked-share mint drain
  • Date: 2021-04-04
  • Protocol: ForceDAO xFORCE vault
  • Chain: Ethereum
  • Category: interface conformance / semantic compatibility failure / issuance-redemption solvency asymmetry / non-standard ERC-20 return-value mismatch
  • Loss: 183 ETH, roughly $367k at the time
  • Summary: ForceDAO’s xFORCE vault forked the familiar xSUSHI staking-vault pattern, but paired it with a FORCE token implemented as an Aragon MiniMe token rather than a vanilla ERC-20. The forked vault logic assumed a failed transferFrom() would revert. FORCE instead returned false on failure. Because the vault never wrapped the token transfer in SafeERC20-style success checks, attackers could call the deposit path with more FORCE than they owned, let transferFrom() fail silently, and still receive freshly minted xFORCE shares. Those counterfeit shares were then redeemed against the real FORCE already sitting in the vault and sold for ETH. The critical lesson is not merely weird token; it is that one side of the vault’s solvency boundary stopped proving asset receipt while the exit side still honored the resulting shares as fully backed claims.
  • Trigger / entry point:
    • On 2021-04-04, multiple attackers targeted the xFORCE vault contract, which ForceDAO later described as an xSUSHI fork.
    • ForceDAO’s own postmortem said the exploited implementation assumed token transfers would revert on failure.
    • The FORCE token, however, was an Aragon MiniMe token whose transferFrom() could return false instead of reverting when the sender lacked sufficient balance or allowance.
    • The vulnerable mint path therefore accepted a failed token pull as if the deposit had succeeded, then minted xFORCE anyway.
  • Root cause:
    • The vault’s share-mint path treated IERC20.transferFrom(...) as if call returned meant assets received.
    • That assumption was valid for many well-behaved ERC-20s and for the xSUSHI deployment context the pattern came from, but it was not guaranteed by the token ForceDAO actually integrated.
    • FORCE’s MiniMe implementation returned false on failed transfers instead of reverting, so the vault needed an explicit success check or SafeERC20 wrapper around the token pull.
    • Because that check was missing, the issuance side of the vault no longer enforced that backing assets had entered before shares were minted.
    • The withdrawal side remained economically live: once attackers held the unbacked xFORCE, they could burn it for the real FORCE already held in the vault and then sell that FORCE on the market.
  • Exploit path:
    1. An attacker called the xFORCE deposit / mint path with an amount of FORCE they did not actually control in full.
    2. The vault attempted transferFrom() against the FORCE token.
    3. FORCE’s MiniMe token returned false rather than reverting when the transfer failed.
    4. The xFORCE vault did not verify that return value, so execution continued as if the deposit had succeeded.
    5. The vault minted xFORCE shares to the attacker despite receiving no corresponding FORCE backing for that mint.
    6. The attacker then withdrew or redeemed those xFORCE shares against the real FORCE inventory already present in the vault.
    7. They sold the drained FORCE for ETH across market venues, while additional attackers repeated the same pattern until ForceDAO intervened.
  • What the attacker needed to be true:
    • The vault had to rely on raw ERC-20 transfer semantics instead of enforcing success with a safe wrapper or explicit require.
    • The integrated token had to use non-standard failure behavior, specifically return false rather than revert.
    • The vault had to mint shares before proving assets really moved.
    • The vault needed pre-existing FORCE reserves so the counterfeit xFORCE could cash out into real value.
    • External liquidity had to still exist for FORCE, so redeemed tokens could be sold for ETH.
  • Technical anatomy worth remembering:
    • This was a compatibility failure hidden inside a familiar pattern. xSUSHI-style vault logic looked battle-tested, but its safety quietly depended on stronger token semantics than ERC-20 universally guarantees in practice.
    • The exploit is also a clean issuance/redemption asymmetry case: the mint side accepted fiction while the redeem side still paid out reality.
    • Nothing about the attack required oracle manipulation, flash-loan complexity, or a second protocol. The bug sat entirely in whether failed transfer and reverted transfer were treated as equivalent.
    • ForceDAO’s own postmortem correctly framed the prevention lesson: either use a standard token with the expected behavior or wrap the token interaction with safeTransferFrom-style checks.
    • This is a useful historical cousin to later unbacked-mint incidents because the broken receipt invariant came from token-semantics mismatch rather than from inheritance drift, bridge message forgery, or decimal mistakes.
  • Representative transactions and addresses:
    • Whitehat address identified by ForceDAO: 0xf88a427c5bf29acf58497c0088cbf7ca9836b7b2
    • Blackhat address: 0x9d9c3695c54601929cd72d34a52935268eb9b00b
      • xFORCE mint transaction: 0xdf05020d5d3c3a975627ce29f24b4eb8ccb8807f9f9c9aa05e644c61fe5f0141
      • FORCE drain transaction: 0x3b60252b36d2de2930a64f360926bfcba44d12ff44719de3c6dd486b9dafe118
    • Blackhat address: 0xe29a07002c7be4299b51a2892799cc4a372994dd
      • xFORCE mint transaction: 0x7df2fe63dfb43676a13146060d36ded98779092e0f7c9fd46caf18b791d4b9fd
      • FORCE drain transaction: 0xe7be5bf25b0ea9fad2fd51021f4a51e5099cf4c91c2ffef94547072fe25ca8d1
    • Blackhat address: 0x0608576ea47b265f1f16b8b8383d0508f703a0cb
      • xFORCE mint transactions: 0x5a27ee4140741fce2dd21ae642a74e95bd3de0df17ba7ae5d9ffc475574135f8, 0x6202403f9fc418fcc464d714753ef49893c174a3da714784251ce03898b34f00, 0x37b44d5dbbe9c1dd75223e15977153234e8a4dbbbab2495cdcc531f44bf6e3d0
      • FORCE drain transaction: 0x2616ae9fb59e2cbae848208daa3d0f63530b74a8a4e5c6099ee1b858fdc732a8
    • Blackhat address: 0x00000b20f0f6a3a212aa6b85106709cd5941457c
      • xFORCE mint transactions: 0xc4abacc3987280fcd97a4dad1459c7a811550589357a9c5ec36f6b783a898106, 0xef10be2cbb33ff810cf07bd9195596556485f767744afbb93dfeb5717775ebb6, 0xf8352e968503efbbd0ad24173c87d5d9b009adf74bdfdf5df4519be6e4911e39
      • FORCE drain transactions: 0xef10be2cbb33ff810cf07bd9195596556485f767744afbb93dfeb5717775ebb6, 0x8aedc3d1eaef0d63f026dec48d845dfcba2d74211998acb5d19929e4bc020317
    • ForceDAO emergency treasury transfer used to stage vote-based mitigation: 0xb02206a51c6f3d836610a3b394c2c3f74acc22d57a8e9b6ae298ba87197752df
  • Response / mitigation:
    • ForceDAO published a postmortem the same day, accepted responsibility for the engineering oversight, and said only xFORCE had been affected.
    • The team highlighted a whitehat address that helped reduce additional losses.
    • ForceDAO said it moved 60M FORCE from the treasury multisig into a deployer wallet to create governance votes intended to burn FORCE balances still sitting in attacker-controlled addresses.
    • The protocol announced a snapshot and replacement-token / relaunch plan for affected community members.
    • The team also said it engaged two security firms to review the codebase and explicitly noted that the issue could have been prevented by using a standard token or safe transfer wrappers.

Why this incident matters

  • It preserves one of the clearest real-world examples of how ERC-20 compatible enough to call is not the same thing as economically safe for this accounting path.
  • It is also a compact vault-solvency lesson: if minting logic does not prove assets arrived, shares become counterfeit claims even when the redeem side is perfectly ordinary.
  • The case remains useful because the exploit path is mechanically simple. That makes it a strong teaching incident for auditors and protocol designers who otherwise tend to focus on more baroque flash-loan or oracle attacks.
  • It also belongs beside later unbacked-mint incidents like Meta Pool because both ultimately ask the same question: which exact line of code still guarantees the protocol received backing assets before it issues redeemable claims?

Pattern tags

  • False-return transfer semantics on an issuance boundary: the decisive break was not reentrancy or price manipulation, but a mint path that treated IERC20.transferFrom() call completion as if it proved successful asset movement.
  • Battle-tested-fork semantic drift: the vault inherited an xSUSHI-style shape whose safety depended on revert-on-failure token behavior, then deployed it against a MiniMe token that answered failure differently.
  • Issuance/redemption solvency asymmetry: the mint side accepted fiction while the burn side still honored those same shares against real FORCE already held by the vault.
  • Existing-reserve cash-out: the exploit only needed one missing receipt proof because there was already real FORCE inventory sitting behind the redeem path and live external FORCE/ETH liquidity to monetize the counterfeit shares.

Why the exploit worked

  • ForceDAO’s mint path implicitly authenticated the wrong object. It proved only that the transferFrom() call returned to Solidity, not that FORCE had actually moved into vault custody.
  • The MiniMe token implementation preserved a softer failure mode than the fork expected: insufficient allowance or balance could make transferFrom() return false instead of reverting, so the call stack stayed alive and the vault continued mint logic.
  • xFORCE issuance and redemption were economically coupled but logically checked by different standards. Deposit-side receipt proof disappeared, while redeem-side payout still treated every minted share as fully reserve-backed.
  • The bug was therefore not merely non-standard ERC-20. It was forked vault logic imported stronger token-semantics assumptions than the deployed asset actually guaranteed, and no wrapper, balance-delta check, or explicit require(success) re-established those assumptions.
  • Because the vault already held real FORCE and downstream market liquidity still existed, the exploit monetization path was immediate: mint counterfeit shares, redeem them for genuine FORCE, then dump FORCE for ETH.

Detection and audit pivots

  • Grep deposit, mint, stake, or vault-entry paths for raw transfer() / transferFrom() calls whose return value is ignored or whose success is inferred only from the absence of a revert.
  • When reviewing a forked pattern like xSUSHI, re-run the compatibility review against the actual token semantics being deployed, not just against the original pattern’s asset. The key question is whether the new asset preserves the same revert, callback, fee, and balance assumptions the inherited code quietly relies on.
  • Use negative-token mocks in tests: false-return transferFrom, fee-on-transfer, callback-capable, paused, and upgradeable proxy-backed assets. If a false-return token can still advance mint or share accounting, the receipt boundary is already broken.
  • Trace whether issuance and redemption enforce the same backing object. If the deposit side can mint from a weak receipt proof while the redeem side still burns against real reserves, the system is one semantic mismatch away from an unbacked-share drain.
  • Review whether pre-existing reserves make the bug instantly monetizable. A vault with only the new deposit at risk is bad; a vault with legacy inventory and live exit liquidity turns the same coding mistake into immediate theft.
  • Treat battle-tested wrappers as suspicious when they cross token families. Familiar vault code is often only as safe as the token behavior its original deployment implicitly assumed.

Failure-prevention checklist

  • Wrap token pulls in SafeERC20.safeTransferFrom()-style success checks or explicit require(success) logic. Never let share issuance proceed merely because the external call returned control.
  • Prove receipt before mint. Where practical, bind share issuance to observed post-transfer custody deltas rather than to nominal deposit amounts or call-stack liveness.
  • Re-review token semantics whenever reusing a vault or staking pattern with a different asset family. Same pattern is not evidence of same failure behavior under transfer errors.
  • Keep issuance and redemption symmetric about backing proof: if redemption is going to honor a share as fully redeemable, minting must have already established the same reserve backing to a stronger standard.
  • Maintain explicit incompatible-asset quarantine rules for false-return, callback-capable, fee-on-transfer, or otherwise non-vanilla tokens instead of relying on generic ERC-20 assumptions.
  • Add adversarial CI coverage for transferFrom() returning false, partial receipt, paused token behavior, and wrapper or proxy upgrades that can change transfer semantics without changing the token address.
  • Rehearse emergency responses for receipt-boundary failures: pause mint, isolate redeem paths if needed, snapshot affected holders, and prevent remaining legacy reserves from serving as a public exit pool for newly counterfeit claims.

Audit prompts

  • If transferFrom() returns false instead of reverting, what exact line stops minting or share credit from continuing?
  • What proves that the vault actually custody-holds new backing assets before it issues redeemable shares?
  • Which assumptions came from the inherited pattern, and where are those assumptions revalidated for the deployed token rather than merely inherited by copy-paste?
  • Could an attacker mint against zero receipt and then burn the resulting shares against pre-existing reserves already sitting in the vault?
  • Are tests covering only happy-path ERC-20s, or do they include false-return, fee-on-transfer, callback-capable, and mutable-token mocks?
  • If a token’s semantics change after listing or wrapper migration, what is the first safe action: pause minting, derecognize backing, replace the wrapper, or quarantine redemption?
  • Does the protocol measure actual receipt, or does it merely assume the token honored the request because no revert happened?
  • Would a reviewer reading only the token-admission docs understand that this path requires revert-on-failure semantics, or is that requirement buried in inherited code expectations?

Lessons that should already be standard

  • Call returned is weaker than assets arrived. Solidity control-flow success is not a reserve-backing proof.
  • Fork safety is conditional. Reusing a battle-tested vault pattern without revalidating token semantics is still a new integration risk, not free security inheritance.
  • Mint and redeem paths are one solvency object. If issuance checks become weaker than redemption checks, the redeem side turns the mismatch into immediate theft.
  • Safe transfer wrappers are not cosmetic style. They are often the exact line between soft failure stays harmless and soft failure becomes an unbacked-mint rail.
  • Existing reserves amplify semantic bugs. The most dangerous vault bugs are often the ones that let attackers print claims against assets that honest users deposited earlier.
  • Token-standard compatibility review should start from execution and accounting semantics, not from whether the interface compiles against IERC20.

Internal linkages

Control surface

Graph View

Backlinks