# Zero sentinel amount accounting bugs

Zero or sentinel amounts treated as full amount, or zero-value paths that move real funds

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

## How it works
A parameter's zero value means two different things in two places. One contract documents `0` as "use the full eligible amount" (a sentinel); another reads the same number as a literal quantity. The two interpretations disagree, so the amount actually moved is not the amount the accounting math assumed. The broken assumption is that a parameter carries one meaning across every contract that reads it. When a wrapper forwards the caller's number instead of the realized balance change, or a stub returns default zeros instead of passing inputs through, bookkeeping drifts from reality: tokens are forwarded, burned, or left frozen for the wrong quantity.

## Where it shows up
- Wrappers that forward a caller-supplied amount instead of measuring balance before/after an external call.
- Downstream contracts documenting `0` as "full eligible amount" while an upstream caller reuses that field for its own payout math.
- Stub or intentionally-unused interface functions returning default zeros instead of passing inputs through.
- Entry points that omit an ordering/range invariant (e.g. `lower < upper`) that downstream math assumes, so a degenerate input collapses a difference to zero.

## How to review
For each amount parameter, find every reader and confirm they agree on what zero means. The invariant: the quantity moved must equal the quantity the accounting math used, and any sentinel must be resolved to a concrete number before payout, mint, or burn. For wrappers, require the payout to derive from the measured balance delta, not the caller's claim. For stub hooks, confirm inputs are passed through rather than zeroed. For range math, check that ordering invariants enforced in helpers are also enforced at the public entry point, including equal and inverted boundaries.

## Variants seen
- Receiver forwards `tapAmount`; zero means "exercise all" downstream, so the full exercised TAP stays frozen [E2](https://bugbountylibrary.com/r/sherlock%3A2024-02-tapioca%3AH-12.md).
- Empty `redeemParams` returns zero reclaim, burning tokens for no payout [E3](https://bugbountylibrary.com/r/c4%3A2023-05-juicebox%3AM-03.md).
- Missing `lower < upper` check lets equal ticks mint liquidity for zero tokens and farm inflated fees [E1](https://bugbountylibrary.com/r/c4%3A2024-08-superposition%3AH-03.md).

## Impact and severity
Outcomes ranged from frozen user funds [E2](https://bugbountylibrary.com/r/sherlock%3A2024-02-tapioca%3AH-12.md) to tokens burned for zero payout [E3](https://bugbountylibrary.com/r/c4%3A2023-05-juicebox%3AM-03.md) and inflated fee farming [E1](https://bugbountylibrary.com/r/c4%3A2024-08-superposition%3AH-03.md). Severity is high where the zero path moves real value; worse when the sentinel is documented downstream but ignored by the wrapper, since normal usage silently triggers it.

## Evidence
- E1: https://bugbountylibrary.com/r/c4%3A2024-08-superposition%3AH-03.md
- E2: https://bugbountylibrary.com/r/sherlock%3A2024-02-tapioca%3AH-12.md
- E3: https://bugbountylibrary.com/r/c4%3A2023-05-juicebox%3AM-03.md