Rebasing Token

Overview

The rebasing token detector identifies contracts that store token balances in internal accounting variables (e.g., deposits[user]) without handling the possibility that the underlying token’s balance may change between transactions due to rebasing. Tokens like stETH, AMPL, and other elastic-supply tokens adjust holder balances automatically — a contract that records a deposit of 100 stETH and later returns 100 stETH may be giving back more or fewer tokens than the vault actually holds.

Sigvex looks for patterns where a contract records balanceOf values in storage and later uses those stored values for transfers or comparisons, without re-reading the actual balance.

Why This Is an Issue

When a vault or lending protocol stores deposits[msg.sender] = amount during deposit and uses that stored amount during withdrawal, it ignores any rebasing that occurred between those two events. For positive rebases, the protocol accumulates phantom profit (users can withdraw less than the vault holds). For negative rebases, the protocol becomes insolvent (users try to withdraw more than exists).

How to Resolve

// Before: Vulnerable — stores absolute balance
function deposit(uint256 amount) external {
    token.transferFrom(msg.sender, address(this), amount);
    deposits[msg.sender] += amount;  // Absolute amount — ignores rebasing
}

// After: Fixed — use share-based accounting
function deposit(uint256 amount) external {
    uint256 balanceBefore = token.balanceOf(address(this));
    token.transferFrom(msg.sender, address(this), amount);
    uint256 actualDeposited = token.balanceOf(address(this)) - balanceBefore;
    uint256 shares = totalShares == 0 ? actualDeposited : (actualDeposited * totalShares) / totalBalance();
    shares_[msg.sender] += shares;
    totalShares += shares;
}

Detection Methodology

1. Balance storage pattern: Identifies SSTORE operations that store values derived from balanceOf return data or calldata amounts.
2. Stale balance usage: Detects subsequent SLOAD of the same slot followed by use in transfer/transferFrom calls without a fresh balanceOf check.
3. Token type heuristic: Applies higher confidence when the contract interacts with known rebasing tokens or accepts arbitrary token addresses.

Limitations

False positives: Contracts that only support non-rebasing tokens and document this restriction may be flagged. False negatives: Contracts that wrap rebasing tokens in non-standard interfaces may not be detected.

Related Detectors

• Balance Accounting — detects balance assumption mismatches
• Decimal Mismatch — detects precision mismatches between tokens

References

• EIP-4626: Tokenized Vaults
• OpenZeppelin ERC-4626 Implementation