FloorDAO Exploit — Self-Donated Rebase Inflates the Staking `index`, Over-Paying gFLOOR Redemptions

Source & credit. Exploit reproduction, trace data, and analysis adapted from DeFiHackLabs by SunWeb3Sec — an open registry of reproduced on-chain exploits. Standalone Foundry PoC and full write-up: 2023-09-FloorDAO_exp in the evm-hack-registry mirror. Upstream DeFiHackLabs PoC: src/test/…/FloorDAO_exp.sol.

Vulnerability classes: vuln/logic/reward-calculation · vuln/arithmetic/precision-loss

Reproduction: the PoC compiles & runs in an isolated Foundry project at this project folder (the umbrella DeFiHackLabs repo contains many unrelated PoCs that do not whole-compile, so this one was extracted). Full verbose trace: output.txt. Verified vulnerable sources: FloorStaking, sFLOOR, gFLOOR.

Key info#

TL;DR#

FloorStaking is an OlympusDAO-V2 fork. Stakers can hold their position either as sFLOOR (a rebasing token, balance grows each epoch) or as gFLOOR (a non-rebasing "wrapped" token whose FLOOR value is tracked by an ever-growing index). The exploit abuses the index:

1. The attacker flash-borrows essentially the entire FLOOR supply (152,089.8 FLOOR) from the FLOOR/WETH UniV3 pool and stakes it into FloorStaking choosing _rebasing = false, receiving gFLOOR priced at the current index.
2. The attacker immediately calls unstake(..., _trigger = true, _rebasing = false). The _trigger = true flag makes unstake call rebase() (Staking.sol:178-179).
3. rebase()'s reward math is epoch.distribute = FLOOR.balanceOf(staking) − circulatingSupply (Staking.sol:233-239). Because the attacker just deposited ~all FLOOR, the contract's FLOOR balance vastly exceeds the staked (sFLOOR) supply, so the attacker's own principal is booked as a giant "reward" and distributed to sFLOOR holders on the next rebase — bumping the index.
4. gFLOOR → FLOOR redemption is balanceFrom(g) = g · index / 1e18 (gFLOOR.sol:114-116). The attacker minted gFLOOR at the old index but redeems at the new, inflated index, so it withdraws more FLOOR than it deposited.
5. Repeat 17×. The index climbs 3.509e9 → 3.881e9 (≈ +10.6%) and the attacker walks away with 14,606.1 FLOOR of pure profit after repaying the flash loan + fee, then swaps it for 40.15 WETH.

The root flaw is the OlympusDAO "staking principal vs. reward" confusion: rebase() cannot distinguish new staked principal from yield earned by the treasury, and unstake lets the caller trigger that rebase in the same transaction after loading the contract with borrowed principal.

Background — FloorDAO's OlympusDAO-V2 staking#

FLOOR (9-decimal) can be staked for one of two receipt tokens:

• sFLOOR — a rebasing token (9 decimals). 1 sFLOOR ≈ 1 FLOOR, and balances grow each epoch as the treasury distributes rewards. Internally it tracks "gons"; rebasing multiplies everyone's gon balance up.
• gFLOOR — a non-rebasing governance token (18 decimals). Its FLOOR value is tracked by an index. The conversions are
  • mint (FLOOR → gFLOOR): balanceTo(a) = a · 1e18 / index (gFLOOR.sol:123-125)
  • redeem (gFLOOR → FLOOR): balanceFrom(g) = g · index / 1e18 (gFLOOR.sol:114-116)

The index itself is derived from sFLOOR rebase growth — gFLOOR.index() simply forwards to sFLOOR.index() (gFLOOR.sol:105-107, sFLOOR.sol:279-281). Each rebase grows sFLOOR._totalSupply, which grows the index, which raises the FLOOR redeemed per gFLOOR.

On-chain state at fork block 18,068,772 (read from the trace):

The vulnerable code#

1. unstake lets the caller trigger a rebase in-line, then redeems gFLOOR at the new index#

FloorStaking.unstake:

function unstake(address _to, uint256 _amount, bool _trigger, bool _rebasing)
    external returns (uint256 amount_)
{
    amount_ = _amount;
    uint256 bounty;
    if (_trigger) {
        bounty = rebase();              // ⚠️ attacker-controlled: fires a rebase NOW
    }
    if (_rebasing) {
        sFLOOR.safeTransferFrom(msg.sender, address(this), _amount);
        amount_ = amount_.add(bounty);
    } else {
        gFLOOR.burn(msg.sender, _amount);             // burn gFLOOR
        amount_ = gFLOOR.balanceFrom(_amount).add(bounty); // ⚠️ priced at the POST-rebase index
    }
    require(amount_ <= FLOOR.balanceOf(address(this)), "Insufficient FLOOR balance in contract");
    FLOOR.safeTransfer(_to, amount_);
}

2. rebase books contract FLOOR balance minus staked supply as "reward to distribute"#

FloorStaking.rebase:

function rebase() public returns (uint256) {
    uint256 bounty;
    if (epoch.end <= block.timestamp) {
        sFLOOR.rebase(epoch.distribute, epoch.number);   // apply LAST epoch's distribute → grows index
        epoch.end = epoch.end.add(epoch.length);
        epoch.number++;
        if (address(distributor) != address(0)) {
            distributor.distribute();
            bounty = distributor.retrieveBounty();
        }
        uint256 balance = FLOOR.balanceOf(address(this)); // ⚠️ includes attacker's just-deposited principal
        uint256 staked  = sFLOOR.circulatingSupply();
        if (balance <= staked.add(bounty)) {
            epoch.distribute = 0;
        } else {
            epoch.distribute = balance.sub(staked).sub(bounty); // ⚠️ principal mis-booked as reward
        }
    }
    return bounty;
}

The protocol's intended invariant is "FLOOR held by the staking contract beyond the staked sFLOOR supply is yield the treasury earned, so distribute it." That assumption is false the instant a user deposits, because the deposit transiently makes balance ≫ staked. The deposit path (stake, Staking.sol:88-115) pulls the FLOOR in before anyone can re-measure, and _rebasing = false mints gFLOOR whose redemption value is governed by the very index this surplus will inflate.

3. The conversion asymmetry that turns the index bump into profit#

// gFLOOR.sol — mint at index_old, redeem at index_new
function balanceTo(uint256 a)   returns (uint256) { return a * 1e18 / index(); }  // deposit
function balanceFrom(uint256 g) returns (uint256) { return g * index() / 1e18;  } // withdraw

If index rises by factor r between deposit and withdraw, then balanceFrom(balanceTo(a)) = a · index_new / index_old = a · r > a. The extra FLOOR is paid out of the contract's balance, i.e. ultimately out of other stakers' and the treasury's FLOOR.

Root cause#

rebase() defines reward as contractBalance − stakedSupply. This conflates two economically opposite quantities:

• Treasury yield (FLOOR minted/sent to the staking contract as genuine reward) — should be distributed.
• User-deposited principal (FLOOR a staker just transferred in) — must not be distributed; it is owed back to that staker.

Because stake() transfers principal in and unstake(_trigger=true) re-runs rebase() in the same call, an attacker can:

1. Spike contractBalance with borrowed principal,
2. Have rebase() book that spike as a reward and grow the share index, then
3. Redeem gFLOOR minted at the old index for FLOOR valued at the new index.

Four design facts compose into the exploit:

1. _trigger is caller-controlled and permissionless. Anyone can force a rebase at the exact moment the contract is loaded with their own principal.
2. Reward = balance − staked is a snapshot of attacker-manipulable state. Flash loans let the attacker make balance arbitrarily large for one transaction.
3. gFLOOR mint/redeem use the live index with no per-position index anchor. A position minted at index_old is redeemed at index_new; the protocol never records the index at which a given gFLOOR was created, so it cannot detect that the redemption over-pays.
4. The flash-loan source is the very pool that holds the WETH prize. The attacker borrows FLOOR from the FLOOR/WETH pool, profits in FLOOR, repays FLOOR + fee, and swaps the surplus FLOOR back into the pool's WETH — all atomically.

Preconditions#

• The staking contract must hold less FLOOR than it can be flash-spiked with, and the attacker must be able to make contractBalance > circulatingSupply after depositing — satisfied by flash-borrowing ~all FLOOR. The PoC's loop only proceeds while balanceAttacker + balanceStaking > circulatingSupply (FloorDAO_exp.sol:63) — i.e. while there is enough surplus to keep inflating the index.
• epoch.end <= block.timestamp so that rebase() actually advances an epoch and applies the previous epoch.distribute. In the live attack the epoch boundary had naturally passed; the PoC relies on the fork being past epoch.end at block 18,068,772.
• A FLOOR flash-loan source. The FLOOR/WETH UniV3 pool provides one via flash(), and conveniently also holds the WETH that becomes the realized profit.
• No warmup obstacle: stake(..., _claim = true) with warmupPeriod == 0 sends the receipt immediately (Staking.sol:96-97).

Step-by-step attack walkthrough (ground-truth numbers from the trace)#

The attacker contract takes a FLOOR flash loan and, inside the callback, runs a 17-iteration stake→unstake loop, each iteration nudging the index up. All figures below are read directly from output.txt.

Iteration 1 (representative — output.txt:63-230)#

The index ratio 3,815,252,590 / 3,509,076,800 = 1.08725 exactly matches the FLOOR-out / FLOOR-in ratio 165,360,032,398,453 / 152,089,813,098,498 = 1.08725 — confirming the entire gain is the index inflation, to the wei.

The 17-iteration loop (FloorDAO_exp.sol:57-73)#

Each subsequent iteration re-stakes the (now larger) FLOOR balance and unstakes after another triggered rebase. The surplus shrinks as the index converges, so the per-epoch rebaseAmount tapers:

Final index 3,881,166,370 vs start 3,509,076,800 ⇒ ≈ +10.6% cumulative inflation.

Cash-out (output.txt:3275-3308)#

• After repaying the flash loan (flashAmount + fee1, fee = 1% = 1,520,898,130,985 FLOOR — output.txt:72-end of flash) the attacker retains 14,606,145,072,279 = 14,606.15 FLOOR (:231,:3271).
• It then swaps that FLOOR into the same UniV3 pool: Pool::swap(..., false, 14606145072279, ...) returns 40,146,353,823,753,349,478 = 40.146 WETH (:3275-3308).

Profit / loss accounting#

The 14,606 FLOOR profit is drawn from the staking contract's FLOOR balance — i.e. treasury reserves and other stakers' principal — because the inflated index made the contract pay out more FLOOR than the attacker ever deposited.

Diagrams#

Sequence of one stake → unstake cycle#

Why the rebase over-pays (state view)#

Index inflation vs. the gFLOOR round-trip#

Remediation#

1. Never derive "reward" from a raw balance snapshot. rebase() must compute distributable yield from an explicitly accounted source (treasury transfers, a dedicated reward escrow), not from FLOOR.balanceOf(this) − stakedSupply. As written, any FLOOR transferred in for any reason — a deposit in flight, a donation, a flash-loan spike — is mistaken for yield.
2. Do not let unstake/stake trigger a rebase that prices the same call's redemption. Either remove the caller-controllable _trigger rebase, or snapshot the index before processing the user's principal and use that snapshot for the mint/redeem in the same transaction.
3. Anchor each gFLOOR position to the index at which it was created (or require a warmup/epoch delay between stake and unstake), so a position minted at index_old cannot be redeemed at index_new within the same transaction.
4. Settle deposits net of any in-flight rebase. stake already does _amount.add(rebase()) for the rebase bounty; the deeper fix is to ensure the deposited principal is excluded from the reward base used to compute the next epoch.distribute.
5. Add a sanity invariant: total FLOOR redeemable across all sFLOOR + gFLOOR holders must never exceed FLOOR.balanceOf(staking); a single-transaction index move large enough to break this should revert. (This is the same class of bug that hit OlympusDAO V2-fork stakers historically.)

How to reproduce#

The PoC was extracted into a standalone Foundry project (the umbrella DeFiHackLabs repo has many unrelated PoCs that fail to whole-compile under forge test):

_shared/run_poc.sh 2023-09-FloorDAO_exp --mt testExploit -vvvvv

• RPC: an Ethereum archive endpoint is required (fork block 18,068,772, Sep 2023). foundry.toml points mainnet at an Infura archive endpoint; any archive node serving historical state at that block works.
• Result: [PASS] testExploit().

Expected tail (from output.txt):

Ran 1 test for test/FloorDAO_exp.sol:FloorStakingExploit
[PASS] testExploit() (gas: 4864916)
Logs:
  floor token balance after exploit: 14606.145072279
  weth balance after swap: 40.146353823753349478

Suite result: ok. 1 passed; 0 failed; 0 skipped

References: FloorDAO post-mortem — https://medium.com/floordao/floor-post-mortem-incident-summary-september-5-2023-e054a2d5afa4 · PeckShieldAlert — https://twitter.com/PeckShieldAlert/status/1698962105058361392

Sources & further analysis#

Reproductions & code

• Standalone PoC + full trace: 2023-09-FloorDAO_exp (evm-hack-registry mirror).
• Upstream DeFiHackLabs PoC: FloorDAO_exp.sol.
• Attack transaction: view on explorer.

Alerts & third-party analyses

• Original alert / thread: post on X.
• DeFiHackLabs incident explorer: search "FloorDAO Exploit".
• Web3Sec X hacked database: search.
• Rekt leaderboard: search.
• Solodit incident search: search.

These dashboards index community alerts tweets, post-mortems, and independent write-ups. Reach them through the protocol name above to cross-check this reproduction against other analyses.