When 1 Means Both 1 Wei and Token ID #1: Inside the OMNI404 Exploit

BitsLab
@0xbitslab · Sep 14
3
112
4,020

1. Background & Event Overview

In the evolving landscape of Decentralized Finance (DeFi) and Non-Fungible Tokens (NFTs), hybrid token standards combining ERC-20 and ERC-721 functionality (such as ERC-404 and its variants) have gained significant traction. These protocols aim to offer both the fluid liquidity of fungible tokens and the uniqueness of NFTs within a single contract architecture.

However, an exploit targeting the hybrid token project OMNI404 (O404) on September 11, 2026, highlighted a critical and insidious vulnerability in smart contract design: Interface compatibility does not imply semantic compatibility.

By exploiting Uniswap V3's exact-output swap mechanism alongside flash loans, the attacker acquired full-unit tokens ($1 \times 10^{18}$ units) at negligible wei-level costs, ultimately draining approximately 2.4 WETH of liquidity from the Uniswap V3 pool. At the core of the exploit was Semantic Overloading of a single uint256 parameter within the contract's transfer(address, uint256) function.

2. Root Cause Analysis: Semantic Ambiguity of uint256 and Conditional Branching

In standard Ethereum Request for Comments (ERC) specifications, interface parameters carry precise domain semantics:

  • ERC-20 Specification: The amount parameter in transfer(address to, uint256 amount) represents the raw number of minimum token units (Wei) to transfer.
  • ERC-721 Specification: The tokenId parameter in transferFrom(address from, address to, uint256 tokenId) represents the unique identifier of a specific NFT.

As a hybrid token contract, OMNI404 attempted to override and extend the standard ERC-20 transfer function to handle both modes simultaneously. This design introduced a severe semantic collision:

2.1 Implicit Numerical Classification and Fixed Transfers

Within OMNI404’s transfer(address recipient, uint256 value) implementation, the contract applied hardcoded conditional checks based on the value of value:

  1. When $value \le 50$: The contract interprets value as an ERC-721 tokenId.
  2. Underlying Action Mismatch: When the code classifies the input as a tokenId, it does not merely update NFT ownership or deduct tokens proportionally. Instead, inside the internal _transfer() logic, it forcibly transfers a fixed amount of $1 \times 10^{18}$ units (i.e., 1 full ERC-20 token) to the recipient.
  3. Flawed NFT State Calculation: The minting and burning of internal NFTs were not driven by independent state logic, but were dynamically calculated based on integer quotient differences of account balances before and after the transfer divided by the token unit base:

2.2 Table of Semantic Discrepancies

The table below illustrates the inconsistent semantics generated by the same Solidity function interface across different input value ranges:

3. Attack Mechanism: Accounting Discrepancies in Uniswap V3 Exact-Output Swaps

As an Automated Market Maker (AMM), Uniswap V3 relies on underlying tokens strictly adhering to standard ERC-20 behavior: after invoking transfer(to, N), the recipient's balance should increase by exactly $N$.

The attacker targeted the gap between Uniswap V3's exactOutput / exactOutputSingle swap routines and OMNI404's dual-semantic handling.

3.1 Step-by-Step Attack Execution

  1. Constructing Small Output Swap Requests: The attacker initiated an exactOutput swap on the Uniswap V3 pool, requesting an extremely small output amount of OMNI404 tokens, such as $value = 1$.
  2. Uniswap V3 Internal Accounting: Based on current concentrated liquidity ticks and pricing formulas, Uniswap V3 calculated that delivering 1 Wei of OMNI404 required the user to pay a microscopic (near-zero due to rounding) amount of WETH.
  3. Cross-Contract Call and Semantic Divergence: Uniswap V3 executed the transfer logic by calling transfer(recipient, 1) on the OMNI404 contract.
    Uniswap V3 Expectation: The pool recorded that it disbursed only $1$ Wei of tokens, decreasing its internal token reserve record by $1$.
    OMNI404 Execution: OMNI404 caught $value = 1 \le 50$, interpreted the caller's intent as transferring Token ID #1, and consequently transferred $1 \times 10^{18}$ Wei (1 full token) to the attacker.
  4. Looping Exploitation & Liquidity Drain: The attacker repeatedly issued calls with parameters $value \in [1, 21]$, acquiring substantial amounts of full OMNI404 tokens at negligible WETH costs. They then sold the accumulated OMNI404 tokens back to the pool via standard exactInput swaps to extract WETH and repay flash loans, draining 2.4 WETH from the pool.

4. Key Takeaway: Interface Compatibility Does Not Imply Semantic Compatibility

The OMNI404 case serves as a textbook example of architectural pitfalls in Solidity development.

4.1 Syntactic Masking

At compile time, OMNI404 fully conforms to the function signature specified by the standard ERC-20 interface:

Any third-party DEX protocol analyzing the contract through static analysis or ABI verification would identify OMNI404 as a compliant ERC-20 token. This is Interface / Syntactic Compatibility.

4.2 Violation of Semantic Invariants

However, composability in DeFi relies on Semantic Invariants. Standard ERC-20 protocols operate under an implicit algebraic invariant:

OMNI404 broke this invariant without modifying the interface signature. When input values fall within a specific range ($value \le 50$), the actual balance change jumps to a constant $10^{18}$. When a third-party protocol calls an overloaded function using standard ERC-20 semantics, systemic failure becomes inevitable.

5. Automated Auditing & BitsLab AI Cross-Contract Semantic Reasoning

Detecting such vulnerabilities—which span contract boundaries and combine numerical branching, interface overloading, and AMM accounting state mismatches—is challenging for traditional static analysis tools that rely purely on pattern matching.

This represents a prime application for BitsLab AI Cross-Contract Semantic Reasoning.

5.1 Reasoning Workflow

An advanced AI smart contract auditing system (such as BitsLab AI) detects such hidden vulnerabilities through a three-stage reasoning process:

1.Interface Invariant Extraction:The AI engine automatically identifies standard protocol interfaces (e.g., ERC-20) and derives formal property specifications:

2. Symbolic Execution & Piecewise Branch Detection:The AI symbolically executes the transfer function to trace control flow, identifying piecewise conditional logic tied to input x:

3.Cross-Contract Compositional Reasoning:The AI simulates interaction paths with common DeFi protocols (such as Uniswap V3 exactOutput swap rules), uncovering the contradiction:

6. Conclusion & Recommendations

The OMNI404 exploit provides crucial security takeaways for smart contract developers and auditors:

  1. Avoid Parameter Semantic Overloading: Hybrid token designs should strictly separate ERC-20 and ERC-721 interfaces. NFT transfers should utilize dedicated functions like transferNFT(uint256 tokenId) or standard safeTransferFrom, rather than overloading amount in transfer.
  2. Standardize Hybrid Token Protocols: Adopt community-vetted standards (such as ERC-7634) that maintain clear, unambiguous state changes and event emissions.
  3. Leverage Semantic-Level Automated Auditing: Prior to deployment, protocols must utilize tools like BitsLab AI cross-contract semantic reasoning to evaluate mathematical and logical invariants across composable DeFi scenarios, preventing situations where "1 means both 1 Wei and Token ID #1".