# Unvalidated address in accounting

Caller-supplied token or bidder address trusted in balances, rewards, or auctions without registry or code check

_Area: DeFi accounting and math bugs. Seen in 2 disclosed reports; latest 2026-02-05. Updated 2026-10-25._

## How it works
Accounting code takes an address from calldata or config and treats it as a real, trusted counterparty: a token whose transfers move value, a bidder whose bid is real debt, a recipient that exists. Nothing checks the address against a registry, a code-existence test, or the contract's own records. The books are then updated on the strength of that address, so a fake or arbitrary address inflates balances, rewards, or debt that later settle against real assets.

## Where it shows up
- Deposit/addRewards/auction-init functions taking an asset or bidder address straight from the caller [E1](https://bugbountylibrary.com/r/h1%3A684092.md)[E2](https://bugbountylibrary.com/r/c4%3A2025-08-gte-perps-and-launchpad%3AH-06.md)
- Accounting updated before or independent of a real token transfer (transferFrom may be a no-op) [E2](https://bugbountylibrary.com/r/c4%3A2025-08-gte-perps-and-launchpad%3AH-06.md)
- Downstream settlement contracts trusting values written by an upstream initiator [E1](https://bugbountylibrary.com/r/h1%3A684092.md)
- ERC20 transferFrom that does not validate the destination [E3](https://bugbountylibrary.com/r/dhl%3A20240215-miner.md)
- No whitelist, registry lookup, or `code.length` check on the address

## How to review
For every address that feeds a balance, reward, or debt update, ask: is this address proven to be the intended, registered counterparty before the books change? The invariant: accounting may only move on value that actually moved, from an address the contract itself vouched for. Check that (a) the asset/bidder is validated against a registry or known set, (b) the accounting update is tied to a verified transfer or a verified bid, and (c) settlement contracts re-validate values they consume rather than trusting the writer [E1](https://bugbountylibrary.com/r/h1%3A684092.md)[E2](https://bugbountylibrary.com/r/c4%3A2025-08-gte-perps-and-launchpad%3AH-06.md). For tokens, confirm transferFrom checks `to` [E3](https://bugbountylibrary.com/r/dhl%3A20240215-miner.md).

## Variants seen
- Auction initiator accepts arbitrary bid/lot with no access control; settlement trusts the bid and issues free funds [E1](https://bugbountylibrary.com/r/h1%3A684092.md)
- Reward deposit accepts arbitrary quote token; fake token's no-op transfer inflates rewards per share, draining real tokens [E2](https://bugbountylibrary.com/r/c4%3A2025-08-gte-perps-and-launchpad%3AH-06.md)
- Token transferFrom omits destination validation, enabling pool drain via callback loops [E3](https://bugbountylibrary.com/r/dhl%3A20240215-miner.md)

## Impact and severity
High to critical: full drain of collateral [E1](https://bugbountylibrary.com/r/h1%3A684092.md), all quote rewards [E2](https://bugbountylibrary.com/r/c4%3A2025-08-gte-perps-and-launchpad%3AH-06.md), or a Uniswap V3 pool [E3](https://bugbountylibrary.com/r/dhl%3A20240215-miner.md). Severity rises when the trusted value is consumed by a separate settlement contract, widening the blast radius beyond the entry point [E1](https://bugbountylibrary.com/r/h1%3A684092.md).

## Evidence
- E1: https://bugbountylibrary.com/r/h1%3A684092.md
- E2: https://bugbountylibrary.com/r/c4%3A2025-08-gte-perps-and-launchpad%3AH-06.md
- E3: https://bugbountylibrary.com/r/dhl%3A20240215-miner.md