BMX: An attacker with two addresses in different finalizeEpoch tally batches unstakes 1000e18 s

Source & credit. Reproduction of a public audit finding curated by AuditVault — the original finding: 62809-h-2-users-voting-weight-can-be-double-counted-when-finalize. The historical source/toolchain is unavailable; this entry is documentation only and claims no executable Forge PoC.

Vulnerability classes: vuln/unfair-mint

Reproduction: a faithful minimal reproduction of the vulnerable finding — the vulnerable function is reproduced verbatim (marked @>) with faithful minimal doubles; local deploy, no fork.

Root cause#

An attacker with two addresses in different finalizeEpoch tally batches unstakes 1000e18 sbfBMX from an already-tallied address and restakes it to a not-yet-tallied one, so the same balance is counted twice — a voting option's weight is inflated to 2000e18 (2x the real 1000e18 stake), crediting 1000e18 phantom vote weight to the attacker's chosen option.

SOLIDITY

            if (userVoteWeight[ep][voterAddr] > 0) continue;

            //@audit current balance is used for voterAddr
            uint256 bal = SBF_BMX.balanceOf(voterAddr); // @> live balance read at tally time — enables cross-batch double-count
            if (bal == 0) {
                // queue for removal instead of removing now

Why it's exploitable here#

Attack path#

flowchart TD S0["Load epoch tally state"] S1["Batch through voter list"] S2["Read live balance during tally"] S3["Credit balance to option"] S4["Mark tally finished"] H["An attacker with two addresses in different finalizeEpoch tally batche"] S0 --> S1 S1 --> S2 S2 --> S3 S3 --> S4 S4 --> H

Marked-line walkthrough (Playground)#

The EVM Playground pins each step to the exact executed source line in 0x671d353a77…:

L84 — Load epoch tally state: Loads the epoch's tally storage that accumulates each option's vote weight.
L86 — Batch through voter list: Iterates voters in bounded batches — the multi-transaction tally that makes the double-count possible.
L97 — Read live balance during tally: Root cause: reads a voter's live staked balanceOf mid-tally, so an attacker can move the same balance to an untallied address and have it counted twice.
L103 — Credit balance to option: Adds that read balance to the voter's chosen option's accumulated weight.
L108 — Mark tally finished: Flags the epoch tally complete once the cursor has processed every voter in the list.
L119 — Pending removals list: Setup: loads the epoch's pending voter-removals list.
L157 — Per-option weight storage: Setup: the mapping that stores accumulated vote weight per option.

PoC#

Registry (Foundry, local deploy — verbatim vulnerable source + harm-asserting test + negative control):

BASH

cd 62809-h-2-users-voting-weight-can-be-double-counted-when-finalize_exp
forge test -vvv

The browser Playground replays the same synthetic opcode-for-opcode and measures the harm: An attacker with two addresses in different finalizeEpoch tally batches unstakes 1000e18 sbfBMX from an already-tallied address and restakes. Both gates are green (registry forge test PASS + Playground _verify-poc VERDICT: PASS).

Sources & further analysis#

Reproductions & code

No executable Forge reproduction is claimed; the historical source/toolchain was unavailable for this finding.
AuditVault finding: 62809-h-2-users-voting-weight-can-be-double-counted-when-finalize.
Upstream DeFiHackLabs PoC directory: src/test.

Alerts & third-party analyses

DeFiHackLabs incident explorer: search "BMX: An attacker with two addresses in different finalizeEpoch tally batches unstakes 1000e18 s".
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.

Source-level debugger — step opcodes and Solidity in sync