Barter DAO: A one-time signed order authorizing a single 100-makerToken fill is replayed after the mak

Source & credit. Reproduction of a public audit finding curated by AuditVault — the original finding: 63501-replay-attack-via-balance-based-nonce-mixbytes-none-barter-d. Standalone Foundry PoC and full write-up: 63501-replay-attack-via-balance-based-nonce-mixbytes-none-barter-d_exp in the evm-hack-registry mirror.

Vulnerability classes: vuln/theft · vuln/access-control

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#

A one-time signed order authorizing a single 100-makerToken fill is replayed after the maker's balance recovers, filling it twice and draining 200 STOLEN-MAKER to the attacker EOA from one signature.

        signed[orderHash] = true;
    }

    function approveToken(MiniToken token, address spender, uint256 amount) external {
        require(msg.sender == owner, "not owner");
        token.approve(spender, amount);

Why it's exploitable here#

A one-time signed order authorizing a single 100-makerToken fill is replayed after the maker's balance recovers, filling it twice and draining 200 STOLEN-MAKER to the attacker EOA from one signature.

Attack path#

Marked-line walkthrough (Playground)#

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

1. L105 — EIP-1271 magic value: Setup: the EIP-1271 isValidSignature magic return value used to validate the maker's signed order.
2. L107 — Signed-order registry mapping: Setup: maps an order hash to whether the maker signed it — tracking validity, but not one-time consumption.
3. L109 — Signer contract constructor: Setup: initializes the maker/signer contract.
4. L115 — Mark order as signed: Records an order hash as authorized; this flag stays true, so the same signature keeps validating on repeat fills.
5. L118 — Re-approve enables replay: Root cause: fill eligibility is gated by maker balance/allowance as an implicit nonce, so re-approving here lets one signed order fill twice.
6. L166 — Consumed-order guard mapping: Declares a per-order consumed replay guard, but the fill path leans on maker balance instead, leaving the order replayable.
7. L171 — Hash the order: Computes the order's hash used to look up its signed/consumed status when filling.

PoC#

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

cd 63501-replay-attack-via-balance-based-nonce-mixbytes-none-barter-d_exp
forge test -vvv

The browser Playground replays the same synthetic opcode-for-opcode and measures the harm: A one-time signed order authorizing a single 100-makerToken fill is replayed after the maker's balance recovers, filling it twice and draini. Both gates are green (registry forge test PASS + Playground _verify-poc VERDICT: PASS).

Sources & further analysis#

Reproductions & code

• Standalone PoC + full trace: 63501-replay-attack-via-balance-based-nonce-mixbytes-none-barter-d_exp (evm-hack-registry mirror).
• AuditVault finding: 63501-replay-attack-via-balance-based-nonce-mixbytes-none-barter-d.
• Upstream DeFiHackLabs PoC directory: src/test.

Alerts & third-party analyses

• DeFiHackLabs incident explorer: search "Barter DAO: A one-time signed order authorizing a single 100-makerToken fill is replayed after the mak".
• 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.