OrderBook
First Flight #43
Beginner FriendlySolidity
100 EXP
View results
Previous Next
Submission Details
Impact: high
Likelihood: low
Invalid

OrderBook is incompatible with rebasing / fee-on-transfer ERC-20s and tokens that execute hooks or callbacks, leading to stuck orders or unexpected control-flow

0xsyntellect

Root + Impact

Description

  • Normal behaviour

    The contract assumes an exact 1:1 correspondence between the value passed to safeTransferFrom / safeTransfer and the amount that actually moves. It also assumes token transfers perform no additional logic beyond moving balances.

  • Specific issue

    1. Rebasing or fee-on-transfer tokens

      • A seller deposits _amountToSell, but the token’s transfer tax or rebase logic reduces the balance that arrives in the contract.

      • The order records the nominal amount, yet the contract custodies less.

      • When buyOrder later calls safeTransfer for the recorded amount, the transfer under-flows and reverts, permanently locking the order and any USDC paid.

    2. Tokens with hooks / callbacks (ERC-777 or ERC-20 with _afterTokenTransfer)

      • During any transfer, arbitrary code can execute and re-enter OrderBook while its state is mid-update, causing logic to run on an inconsistent snapshot (e.g., double purchase or griefing).

      • These token behaviours are common in today’s DeFi landscape (e.g., stETH rebases, reflective tokens, ERC-777).

//Proof-of-Concept (summary)
//Fee-on-transfer path
​
//Owner whitelists a 2 % tax token.
​
//Seller lists an order for 100 tokens. The contract receives only 98.
​
// Buyer calls buyOrder ⇒ safeTransfer(100) reverts, freezing the order and the buyer’s USDC.
​
//Callback path
​
//Owner whitelists an ERC-777 token.
​
// During safeTransfer, its tokensToSend hook re-enters buyOrder while state is half-updated, enabling a second purchase before order.isActive is cleared.

Risk

Likelihood:Low

  • Reason: Only possible when owner whitelists such tokens

Impact:

  • Impact: Orders become unfillable (capital stuck) or re-entrancy creates unexpected executions and draining of funds

Proof of Concept

//Proof-of-Concept (summary)
//Fee-on-transfer path
​
//Owner whitelists a 2 % tax token.
​
//Seller lists an order for 100 tokens. The contract receives only 98.
​
// Buyer calls buyOrder ⇒ safeTransfer(100) reverts, freezing the order and the buyer’s USDC.
​
//Callback path
​
//Owner whitelists an ERC-777 token.
​
// During safeTransfer, its tokensToSend hook re-enters buyOrder while state is half-updated, enabling a second purchase before order.isActive is cleared.

Recommended Mitigation

Token whitelist policy – restrict to well-audited known tokens; document that rebasing and ERC-777 tokens are unsupported.
​
Balance-check pattern – after each incoming transfer, verify that the contract’s token balance increased by exactly the amount that actually received and set variables accordingly
​
nonReentrant & CEI – guard external calls and move state changes before interactions to neutralise callbacks in amendSellOrder and buyOrder functions via following CEI pattern and/or nonReentrant modifier
Updates

Lead Judging Commences

yeahchibyke Lead Judge
6 days ago
yeahchibyke Lead Judge 5 days ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.