Level Finance Exploit — Duplicate-Epoch `claimMultiple()` Reward Multiplication

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-05-Level_exp in the evm-hack-registry mirror. Upstream DeFiHackLabs PoC: src/test/…/Level_exp.sol.

Vulnerability classes: vuln/logic/reward-calculation · vuln/logic/missing-check · vuln/input-validation/missing

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 under forge test, so this one was extracted). Full verbose trace: output.txt. Verified vulnerable source: src_referral_LevelReferralControllerV2.sol.

Key info#

TL;DR#

LevelReferralControllerV2.claimMultiple(uint256[] _epoches, address _to) (src_referral_LevelReferralControllerV2.sol:161-176) iterates over a caller-supplied array of epoch numbers and pays out the claimable reward for each entry — without checking that the array contains no duplicates.

By submitting the same epoch (13) 2,000 times in one call, the attacker is paid the per-epoch reward repeatedly inside a single transaction. In the live attack each claimMultiple call paid out ≈ 6,000× the legitimate single-epoch reward (claimable(13) ≈ 1.5378 LVL → call total ≈ 9,226 LVL). The attacker first inflated the reward base itself with (a) a DODO flash-loaned wash-trade loop through the Level Pool to mint trading points and (b) 30 sybil referral accounts to push their referral tier up, then drained 205,105.54 LVL over 11 claimMultiple rounds.

Background — what LevelReferralControllerV2 does#

Level Finance is a perpetual-DEX on BSC. The referral controller rewards two roles each epoch (an epoch is a ≥ 1 day window, :36):

• Traders earn tradingPoint proportional to volume; they get a discount-based rebate.
• Referrers earn referralPoint from their referees' volume; they get a rebateForReferrer.

Per-epoch points are converted to a claimable LVL amount in claimable() (:97-118):

uint256 rewardForTrading  = user.tradingPoint  * tiers[users[_epoch][referrer].tier].discountForTrader / PRECISION;
uint256 rewardForReferral = user.referralPoint * tiers[user.tier].rebateForReferrer / PRECISION;
uint256 reward = (rewardForTrading + rewardForReferral) / epoch.TWAP;   // LVL amount, priced by epoch TWAP
...
return reward > user.claimed ? reward - user.claimed : 0;              // only the un-claimed remainder

Higher tiers require both a minimum referee count and a minimum referral-point threshold (:78-87), and _updateTier() (:262-282) keys the tier off referralRegistry.referredCount(_user) — i.e. how many distinct addresses set you as their referrer. Both inputs are attacker-controllable: trading volume via wash-trading, referee count via sybil accounts.

Relevant on-chain state at the fork block (read from the trace):

The vulnerable code#

1. claimMultiple() — no duplicate check, pays each array entry#

function claimMultiple(uint256[] calldata _epoches, address _to) external {
    uint256 totalReward;
    for (uint256 i = 0; i < _epoches.length; ++i) {
        uint256 epoch = _epoches[i];
        if (epoch < currentEpoch) {
            uint256 reward = claimable(epoch, msg.sender);   // ⚠️ recomputed each entry
            if (reward > 0) {
                users[epoch][msg.sender].claimed += reward;  // ⚠️ updated, but see below
                totalReward += reward;
                emit Claimed(epoch, _to, reward);
            }
        }
    }
    LVL.safeTransfer(_to, totalReward);                       // ⚠️ one lump transfer at the end
}

src_referral_LevelReferralControllerV2.sol:161-176

The function never asserts the elements of _epoches are unique. A caller can pass [13, 13, 13, …] and the loop processes epoch 13 over and over.

2. Contrast with single claim() — same accounting, but only callable once per tx per epoch#

function claim(uint256 _epoch, address _to) external {
    require(_epoch < currentEpoch, "...: !epoch");
    uint256 reward = claimable(_epoch, msg.sender);
    require(reward != 0, "...: !reward");
    UserInfo storage user = users[_epoch][msg.sender];
    user.claimed += reward;
    LVL.safeTransfer(_to, reward);
    emit Claimed(_epoch, _to, reward);
}

:148-159

claim() pays exactly the single per-epoch reward (verified in the trace as 1.5378 LVL, output.txt L8095). claimMultiple() reuses the same claimable()/claimed accounting but, by looping over a caller-controlled length, amplifies the payout by the array length.

Root cause — why it was possible#

The defining flaw is the absence of a uniqueness/idempotency guard on the batch input, combined with reward accounting that does not collapse repeated entries into one:

1. No duplicate-element check. claimMultiple trusts _epoches to be a set; it is in fact a raw uint256[] the attacker fully controls. Passing 13 two-thousand times is legal.

2. The per-iteration claimed book-keeping does not suppress repeats inside one call. The trace shows the Claimed events for the looped epoch do not collapse to zero after the first iteration — they keep firing the full reward (the events alternate between the trading-side value 1.5378 LVL and the referral-side value 7.6889 LVL = 5×, ~3× the base on average, and the call transfers a fixed 6,000 × 1.5378 LVL = 9,226.73 LVL, output.txt L24137). The single lump safeTransfer(totalReward) at the end pays the accumulated multiple. Each batch call thus realizes ~6,000× the honest single-epoch reward.

3. The reward base was attacker-inflatable. Before claiming, the attacker maximized claimable(13) itself:

   • Wash-trading. A 300-WBNB DODO flash loan funds a tight WBNB↔USDT swap loop through the Level Pool (pool.swap(...) with the attacker as referee, Level_exp.sol:102-117). Each swap routes volume that the protocol's off-chain updater later converts into tradingPoint/referralPoint.
   • Sybil referees. createReferral() (Level_exp.sol:93-100) deploys 30 Referral contracts (15 pointing at the attacker EOA, 15 at the Exploiter), each calling setReferrer. This drives referralRegistry.referredCount up so _updateTier promotes the attacker into a higher rebateForReferrer tier.
   • Circular referral. The attacker EOA and Exploiter set each other as referrer (Level_exp.sol:72, :150), so both sides accrue referral reward from the same volume.

4. Epoch advancement is gated by distributor, but the attacker had that key for the test. The PoC pranks the real distributor 0x6023C6… to flip setEnableNextEpoch(true) and call nextEpoch() (Level_exp.sol:76-79), snapshotting epoch 13's TWAP so it becomes claimable. In the live incident the attacker simply waited for the natural epoch roll; nextEpoch() itself (:178-192) is permissionless once enabled.

Put together: an attacker manufactures a modest legitimate reward, then multiplies it by the batch-array length because claimMultiple has no defense against repeated epochs.

Preconditions#

• A claimable epoch exists (epoch < currentEpoch with epoch.TWAP != 0). The attacker drives nextEpoch() so epoch 13 is finalized.
• The attacker holds non-zero tradingPoint/referralPoint for that epoch, so claimable() > 0 — bootstrapped via the flash-loaned wash-trade loop and 30 sybil referees.
• The controller holds enough LVL to satisfy the inflated payouts (it did — it was the protocol's referral reward treasury).
• No special privilege is needed to call claimMultiple(); it is a public user function.

Attack walkthrough (with on-chain numbers from the trace)#

Why each claimMultiple([13]×2000) pays ~6,000× the base#

Inside one call, the Claimed events for the duplicated epoch alternate between the trading-side reward 1.537787891019941819 LVL and the referral-side reward 7.688939455099709097 LVL (exactly 5×), and the loop never zeroes the reward out — so the lump safeTransfer at the end equals a fixed 6,000 × 1.537787891019941819 LVL = 9,226.727346119650916 LVL (9226727346119650916000 / 1537787891019941819 = 6000.0, verified arithmetic). Across the 11 rounds the per-call total drifts up slightly (9,226.73 → 9,515.06 LVL) because the warp between rounds nudges the time-dependent reward terms; the dominant factor is always the ~6,000× array multiplier.

Profit / loss accounting (LVL)#

The 300-WBNB flash loan is fully repaid intra-transaction (Level_exp.sol:116), so the attack is essentially capital-free apart from gas — the entire 205,105 LVL is pure profit drained from the controller's reward reserve.

Diagrams#

Sequence of the attack#

Why duplicate epochs drain the reserve#

Reward base inflation -> multiplication#

Remediation#

1. Deduplicate / enforce monotonic epochs in claimMultiple. Require the input array to be strictly increasing (require(_epoches[i] > _epoches[i-1])) or track per-call seen epochs. A strictly-increasing requirement is the cheapest robust fix and makes duplicates impossible.
2. Make per-epoch claiming idempotent at the storage level. Have claimable() and the claim paths agree that once claimed >= reward for an epoch, the remaining claimable is 0, and ensure the same claimed slot read by claimable is the slot written before the next iteration — so a re-processed epoch in the same call returns zero. (The single claim() is safe; claimMultiple must inherit the identical guarantee even for repeated entries.)
3. Validate the reward base, not just the batch call. Tier promotion via referredCount and point accrual via trading volume are sybil/wash-trade-able. Use minimum holding periods, require organic (non-self-referential) referral graphs, reject circular referrer == referee chains, and source volume from settled trades rather than raw swap counts.
4. Cap single-call payouts. Bound totalReward per transaction relative to the user's legitimately accrued, un-claimed balance; a single call paying 6,000× a per-epoch reward should be impossible by construction.
5. General principle for batch functions: treat any caller-supplied uint256[]/address[] of "things to process once" as a potential multiset and explicitly deduplicate or constrain it.

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-05-Level_exp --mt testExploit -vvvvv

• RPC: a BSC archive endpoint is required (fork block 27,830,139 is from May 2023). Most pruned public RPCs will fail with header not found / missing trie node.
• Result: [PASS] testExploit().

Expected tail:

Ran 1 test for test/Level_exp.sol:ContractTest
[PASS] testExploit() (gas: 379641769)
  Attacker LVL Token balance after exploit: 205105.535540566780039638
Suite result: ok. 1 passed; 0 failed; 0 skipped

References: PeckShield — https://twitter.com/peckshield/status/1653149493133729794 · BlockSec — https://twitter.com/BlockSecTeam/status/1653267431127920641 · Level Finance referral exploit, BSC, May 2023.

Sources & further analysis#

Reproductions & code

• Standalone PoC + full trace: 2023-05-Level_exp (evm-hack-registry mirror).
• Upstream DeFiHackLabs PoC: Level_exp.sol.

Alerts & third-party analyses

• Original alert / thread: post on X.
• DeFiHackLabs incident explorer: search "Level Finance 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.