FireBird Reward Farming

1. Incident Overview TL;DR

On Polygon block 48149138, an attacker-controlled helper contract exploited FireBird Finance's reward-mining flow with a zero-fee Balancer flash loan and a sequence of reversible swaps. The exploit did not need privileged access: the attacker could call the FireBird router, the SwapFeeReward contract through the router, and the reserve-fund maintenance functions as a normal external user. The root cause was that FireBird credited claimable HOPE mining rewards from router-computed gross amountOut before swap settlement and without requiring irreversible trading cost. Because the credited balance in SwapFeeReward was durable and later withdrawable into HOPE, reversible round trips created real attacker value. The exploit transaction increased the attacker's claimable reward balance by 34000469691515236029599 raw HOPE units.

2. Key Background

FireBird's router at 0xb31d1b1ea48ce4bf10ed697d44b747287e785ad4 integrates directly with SwapFeeReward at 0x5ada95d0fcd624a1b3339eaa0dd8c57ddfa31bb6. During each swap hop, the router computes amountOut and forwards it to SwapFeeReward.swap(...). That reward contract tracks claimable mining proceeds in an internal _balances mapping and later lets users realize them through withdraw(), so an increase in rewardBalance(account) is economically meaningful. Separately, the reserve-fund proxy at 0x5d53c9f5017198333c625840306d7544516618e4 exposed collectFeeFromProtocol() and sellTokensToUsdc() under the checkPublicAllow modifier while publicAllowed was true, making reserve maintenance available to any caller.

Key victim-side code confirms those properties:

// FireBirdRouter._swap
if (swapFeeReward != address(0)) {
    ISwapFeeReward(swapFeeReward).swap(msg.sender, input, output, amountOut, path[i]);
}
pairV2.swap(amount0Out, amount1Out, to, new bytes(0));

// SwapFeeReward.swap
uint256 quantity = getSwapReward(input, output, amount, pair);
_balances[account] = _balances[account].add(quantity);

// FirebirdReserveFund
modifier checkPublicAllow() {
    require(publicAllowed || strategist == msg.sender || owner() == msg.sender, "!authorised nor !publicAllowed");
    _;
}
function collectFeeFromProtocol() public checkPublicAllow { ... }
function sellTokensToUsdc() public checkPublicAllow { ... }

3. Vulnerability Analysis & Root Cause Summary

The vulnerability is an incentive-accounting failure in which reward issuance was tied to gross reversible swap flow instead of net economic cost. FireBirdRouter called SwapFeeReward.swap before pair settlement, passing in the router's precomputed amountOut for that hop. SwapFeeReward.swap treated that value as valid fee-generating volume, calculated a reward quantity, and immediately increased _balances[account]. No invariant required the user to end the sequence with an irreversible loss, and no guard blocked same-transaction round trips. The reserve fund compounded the issue because its public maintenance functions let an unprivileged caller refresh supporting liquidity conditions during the same exploit sequence. Under those conditions, any attacker with temporary liquidity could recycle principal while accumulating durable reward claims. The violated invariant is that claimable mining rewards must be bounded by real, non-recoverable trading cost.

4. Detailed Root Cause Analysis

The exploit pre-state was the public Polygon state immediately before block 48149138, including the FireBird router, the SwapFeeReward proxy, the reserve-fund proxy with publicAllowed=true, and the WMATIC-HOPE and WMATIC-USDC FireBird pairs. The attacker first deployed helper contract 0x22b1a115b16395e5ebd50f4f82aef3a159e1c6d1 in transaction 0xf9b690fed6f592b2e13a16f79ae1adb6a2769d178ef090820163f3c4b601509f; collector data attributes that deployment to EOA 0x8e83cd1bad00cf933b86214aaaab4db56abf68aa.

In the exploit transaction 0x96d80c609f7a39b45f2bb581c6ba23402c20c2b6cd528317692c31b8d3948328, the helper contract borrowed 286000 WMATIC from the Balancer vault and entered a loop that alternated WMATIC-to-HOPE swaps with HOPE-to-WMATIC reversals. Each rewarded WMATIC-to-HOPE leg caused the router to call SwapFeeReward.swap(msg.sender, input, output, amountOut, pair) before pair settlement. Because SwapFeeReward derives mining quantity from that router-supplied amount and writes directly into _balances[account], the reward side effect persisted even though the attacker could reverse the trade and recover principal. The reserve-fund public entrypoints were then used to collect fees and sell accumulated tokens into USDC, refreshing side-market conditions needed for continued capital recycling.

The resulting profit signal is visible in the focused state diff for SwapFeeReward storage. The beneficiary mapping slot moved from 37024173998326376983005 to 71024643689841613012604, a deterministic delta of 34000469691515236029599.

{
  "address": "0x5ada95d0fcd624a1b3339eaa0dd8c57ddfa31bb6",
  "pre_decimal": 37024173998326376983005,
  "post_decimal": 71024643689841613012604,
  "delta_decimal": 34000469691515236029599
}

That delta is the exploit predicate: the attacker finished the transaction with materially higher claimable HOPE inside SwapFeeReward, and that balance was directly withdrawable into minted HOPE. The exploit therefore converted protocol incentive inventory into attacker-controlled value without requiring privileged roles or attacker-only artifacts.

5. Adversary Flow Analysis

The attacker flow was a two-transaction ACT sequence on Polygon. First, the attacker EOA deployed a helper contract that would hold approvals, receive the Balancer flash loan, and become the reward-balance beneficiary. Second, the helper contract executed the exploit transaction. The transaction input and trace show the helper invoking its own exploit entrypoint, drawing Balancer flash liquidity, opening a WMATIC-USDC side leg, repeatedly farming HOPE rewards through WMATIC-HOPE round trips, invoking public reserve-fund maintenance between cycles, and finally returning to WMATIC to repay the vault.

At a high level, the sequence was:

1. Deploy helper contract.
2. Borrow WMATIC from Balancer.
3. Swap part of WMATIC into USDC for side liquidity positioning.
4. Repeat:
   - swap WMATIC -> HOPE through FireBird, which credits SwapFeeReward;
   - call reserve-fund public maintenance;
   - swap HOPE -> WMATIC to recover principal.
5. Sell reserve-fund-managed tokens into USDC and recycle back into WMATIC.
6. Repay Balancer.
7. Keep the increased claimable HOPE reward balance.

Because every required action was publicly callable and the state transition was proven on-chain, the strategy satisfies the ACT adversary model.

6. Impact & Losses

The measurable loss was the creation of 34000469691515236029599 raw HOPE reward units in favor of the attacker helper contract. With 18 decimals, that represents durable claimable mining inventory that could be withdrawn into HOPE tokens. The direct impact was dilution and drainage of FireBird's reward program rather than theft of custodial user balances. The affected victim components were the FireBird router, SwapFeeReward, and the reserve-fund maintenance paths that supported the loop.

7. References

1. Exploit transaction: 0x96d80c609f7a39b45f2bb581c6ba23402c20c2b6cd528317692c31b8d3948328 on Polygon.
2. Helper deployment transaction: 0xf9b690fed6f592b2e13a16f79ae1adb6a2769d178ef090820163f3c4b601509f.
3. FireBird router verified source at 0xb31d1b1ea48ce4bf10ed697d44b747287e785ad4.
4. SwapFeeReward verified source at 0x657cd9d31caf187c6be9f1f53770eea2bb175710.
5. FirebirdReserveFund source at 0xd01224268a0f2ff5659a14af96051701070a1211.
6. Focused SwapFeeReward balance diff proving the profit predicate.
7. Collector metadata and trace artifacts for the seed exploit transaction.