# Unvalidated init parameters overflow or takeover

Caller-supplied initial values accepted without bounds, later multiplied or compared, causing overflow or forced liquidation

_Area: Smart contract access control and control flow. Seen in 4 disclosed reports; latest 2024-08-17. Updated 2026-10-23._

## How it works
A factory or pool-creation path accepts caller-supplied numeric configuration (initial balances, virtual reserves, ratios, fees) and stores it without bounds. The assumption that breaks is that these values are "just initial state" and safe to trust. Later code multiplies or compares them, so an extreme value either overflows a fixed-width result or makes every position unhealthy. The unsafe value is committed at creation time, before any downstream check runs.

## Where it shows up
- `createPair`/`initialize`/constructor taking `uint` config with no min/max validation.
- Initial values that feed multiplications in later functions (reserve math, liquidity bootstrap, ratio recomputation).
- Risk parameters (margin/maintenance ratios, fees, min amounts) with only a downside limit and no upside cap.
- Privileged setters for those parameters with no timelock.
- A predicate checked only at settlement/withdrawal but not at the earlier deposit/bond step.

## How to review
For each caller-supplied initial value, trace every later use. The invariant: for every multiplication `a*b*...` reachable from stored config, the product of the maximum accepted values of each operand must fit the result type width; otherwise reject at input. For risk parameters, require two-sided bounds and a timelock before a privileged actor can move them. For time-decaying values, the same predicate that gates settlement must also gate the earlier deposit, or a cancel/refund path must exist. Check that a created pool can always complete its lifecycle (takeover, settle) for any accepted input.

## Variants seen
- Extreme risk parameters with one-sided limits let a coordinator force mass liquidation and harvest fees [E1](https://bugbountylibrary.com/r/sherlock%3A2024-08-perennial-v2-update-3%3AH-2.md).
- Unvalidated pair init values overflow `k*bootstrapEth` in `takeOverPool`, permanently locking the pair [E2](https://bugbountylibrary.com/r/sherlock%3A2024-03-goat-trading%3AM-5.md).
- Ratio validated only at `settleAuction`; bond accepted earlier, then settlement always reverts and bond is burned [E3](https://bugbountylibrary.com/r/c4%3A2021-12-defiprotocol%3AM-07.md).

## Why fixes fail
Adding a check only at the later use (settlement) leaves the earlier deposit path open, so funds still lock [E3](https://bugbountylibrary.com/r/c4%3A2021-12-defiprotocol%3AM-07.md). Capping one parameter but not the product of several still allows overflow [E2](https://bugbountylibrary.com/r/sherlock%3A2024-03-goat-trading%3AM-5.md).

## Impact and severity
Permanent lock of pool funds [E2](https://bugbountylibrary.com/r/sherlock%3A2024-03-goat-trading%3AM-5.md), loss of a bonder's bond [E3](https://bugbountylibrary.com/r/c4%3A2021-12-defiprotocol%3AM-07.md), and mass liquidation of all users with fee harvesting by a trusted role [E1](https://bugbountylibrary.com/r/sherlock%3A2024-08-perennial-v2-update-3%3AH-2.md). Severity is high where funds are irrecoverable; worse when the actor is privileged and no timelock gives users time to exit.

## Evidence
- E1: https://bugbountylibrary.com/r/sherlock%3A2024-08-perennial-v2-update-3%3AH-2.md
- E2: https://bugbountylibrary.com/r/sherlock%3A2024-03-goat-trading%3AM-5.md
- E3: https://bugbountylibrary.com/r/c4%3A2021-12-defiprotocol%3AM-07.md