Skip to main content

Ether/Token Leaking

What it detects​

This detector identifies scenarios where ether or tokens leave a smart contract without a corresponding and accurate update to internal accounting, such as user balances or protocol liabilities. These leaks typically result from faulty transfer logic, missing checks, or incorrect destination addresses.

Common causes include:

  • Transferring funds without updating bookkeeping variables
  • Sending tokens to unintended recipients (e.g., address(0), contract itself, or attacker-controlled address)
  • Mistaking msg.sender or tx.origin for a validated recipient
  • Not validating or limiting the amount being transferred

These bugs can silently drain the contract over time or cause catastrophic loss in a single transaction.

Typical symptoms​

  • Contract balance decreases unexpectedly
  • Total supply of tokens doesn't match circulating tokens or user balances
  • Tokens or ether are permanently locked or sent to non-recoverable addresses
  • Accounting mismatches between expected and actual fund flows

Solidity snippet (v0.8.25)​

pragma solidity ^0.8.25;

contract Leak {
    address public treasury;

    function pay(address to) external payable {
        // sends ether but forgets to deduct from user accounting
        // no authorization check on 'to', allowing anyone to specify any recipient
        payable(to).transfer(msg.value);
    }
}

Why it matters on EVM​

Because the Ethereum Virtual Machine is immutable and lacks native recovery mechanisms, any accidental or unauthorized transfer of ether or tokens results in a permanent loss. These leaks can damage user trust, create protocol insolvency, or be exploited by attackers to siphon funds.

Consequences include:

  • Protocol insolvency due to mismatched balances
  • Users being unable to withdraw their full entitled amounts
  • Fund losses that cannot be reversed, even with administrative action
  • Reputational harm and legal risks for teams and DAOs

Preventing leaks requires strict validation of transfer logic, careful use of msg.value and transfer()/send()/call(), and consistent internal state updates that mirror fund movements.