# RToken can manipulate distribution to avoid paying DAO fees

RToken governance can set a self-reverting RSR distribution target to accumulate RSR in rsrTrader, then re-split at a new ratio to pay ~1% DAO fee instead of 10%.

- Payout: Audit contest
- Severity: medium
- Program: Reserve
- Found by: RadiantLabs
- Disclosed: 2024-10-03
- Write-up quality: 6/10
- Original: https://code4rena.com/reports/2024-07-reserve#m-01
- Library page: https://bugbountylibrary.com/r/c4%3A2024-07-reserve%3AM-01
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:business-logic vuln:fee-bypass

**Target:** RToken Distributor / BackingManager distribution ratio
**Root cause:** The RSR/RToken split ratio is computed twice (BackingManager then Distributor) and can be changed in between; adding RSR itself as a destination makes distribution revert, letting RSR accumulate in rsrTrader under one ratio and be redistributed under another.
**Steps:**
1. Set distribution so rsrTotal == 0 before DAO fees are added.
2. Add RSR token itself as a distribution target (RSR cannot transfer to itself, so distribution always reverts).
3. Let ~10% of revenue accumulate as RSR in rsrTrader over time.
4. Change distribution so rTokenTotal == 0 and add a non-zero rsrDist destination (e.g. stRSR).
5. Remove RSR as a target and call `rsrTrader.distributeTokenToBuy()`.
6. Only 10% of accumulated RSR goes to DAO (~1% of total revenue); repeat.
**How found:** Reading the two-stage ratio computation (BackingManager split then Distributor split) and noticing RSR self-transfer reverts, enabling a state where the ratio changes between the two calculations.
**Exploitation:** Governance configures Distributor destinations to trap RSR in rsrTrader via a self-reverting RSR entry, waits for revenue to accrue, then reconfigures the ratio and triggers distributeTokenToBuy so the DAO fee applies only to the small accumulated RSR rather than total revenue.
**Escalation:** Repeatable cycle across revenue epochs to compound fee avoidance.
**Insight:** When a ratio is computed in two places with mutable config in between, look for a way to make one distribution path revert so value parks in an intermediate contract and gets re-split under a different ratio.