OUSD can transfer more than the displayed balance — rounding/precision loss

Source & credit. Reproduction of a public audit finding curated by AuditVault — the original finding: 18213-ousd-allows-users-to-transfer-more-tokens-than-expected-trai. Standalone Foundry PoC and full write-up: 18213-ousd-allows-users-to-transfer-more-tokens-than-expected-trai_exp in the evm-hack-registry mirror.

Vulnerability classes: vuln/arithmetic/rounding · vuln/arithmetic/precision-loss · vuln/logic/missing-check

Reproduction: self-contained synthetic Foundry reduction; see output.txt.

Key info#

Field	Value
Loss	A holder can transfer one token more than `balanceOf` reports
Vulnerable contract	`OUSD._executeTransfer`
Attacker EOA	`0x1111111111111111111111111111111111111111`
Attack contract	`OUSD` via `Exploit`
Attack tx	`Exploit.run()`
Chain / block / date	Ethereum model · block 0 · 2021-01
Compiler	`solc 0.8.24` (synthetic)
Bug class	Rounded credit deduction without a pre-balance check

TL;DR#

Rebasing credits can make the token-facing balance larger than the credit deduction for a transfer. Flooring creditsDeducted before validating the token amount lets a three-token transfer succeed when only two tokens are visible.

Background#

The AuditVault sequence changes supply and mints across users before exercising the transfer invariant. This local reduction uses the same credit/token rounding relationship without claiming a live exploit.

The vulnerable code#

SOLIDITY

uint256 creditsDeducted = value * creditsPerToken / 1e18; // @> floors first
creditBalances[msg.sender] -= creditsDeducted;

Root cause#

The implementation validates only the rounded credit amount, not the exact token balance that users and integrations observe.

Preconditions#

creditsPerToken is fractional due to rebasing.
The caller can transfer through the credit-based ERC-20 path.

Attack walkthrough#

The synthetic state gives the attacker one credit at 0.5 credits/token, displaying two tokens.
transfer sends three tokens while deducting one credit.
The Proof event at output.txt:377 captures the over-balance transfer.

Diagrams#

flowchart TD A[Fractional creditsPerToken] --> B[balanceOf floors to 2] B --> C[transfer three tokens] C --> D[creditsDeducted floors to 1] D --> E[Invariant violated]

Remediation#

Check the exact token balance before credit arithmetic, use a rounding direction that cannot undercharge, and test transfer invariants with property-based fuzzing.

How to reproduce#

BASH

cd evm-hack-registry/18213-ousd-allows-users-to-transfer-more-tokens-than-expected-trai_exp
forge test -vvvvv

Sources#

Reference: https://github.com/trailofbits/publications/blob/master/reviews/OriginDollar.pdf

Sources & further analysis#

Reproductions & code

Standalone PoC + full trace: 18213-ousd-allows-users-to-transfer-more-tokens-than-expected-trai_exp (evm-hack-registry mirror).
AuditVault finding: 18213-ousd-allows-users-to-transfer-more-tokens-than-expected-trai.

Alerts & third-party analyses

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