# Treating of BLOCK_TIME as permanent will cause serious economic flaws in the oracle when block times change

Basin's MultiFlowPump hardcodes immutable BLOCK_TIME to cap price changes; when L2 block times change, the oracle caps too strictly or too permissively, enabling arbitrage or manipulation.

- Payout: Contest reward
- Severity: medium
- Program: Basin
- Credited: Trust
- Disclosed: 2023-10-05
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2023-07-basin-findings/issues/176
- Library page: https://bugbountylibrary.com/r/c4%3A2023-07-basin%3AM-08
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:source-review vuln:business-logic vuln:oracle-manipulation

**Target:** MultiFlowPump oracle price-capping logic in Basin Wells
**Root cause:** BLOCK_TIME is passed to the pump constructor and stored as immutable, used in every update to compute blocksPassed and thus the max price change in _capReserve(). It cannot be updated without redeploying the Well and migrating liquidity.
**Steps:**
1. Deploy a Well with a MultiFlowPump whose constructor BLOCK_TIME matches the chain's block time at deploy.
2. Chain block time later changes (e.g. Optimism Bedrock upgrade alters block generation).
3. On each pump update, `blocksPassed` is computed from the stale BLOCK_TIME, so `_capReserve()` caps price changes with the wrong interval.
4. If actual block time > assumed, caps are too strict and oracle price drifts from market; if actual < assumed, caps are too permissive and manipulation is easier.
**How found:** Code reading: noticed BLOCK_TIME is immutable in the pump and Well, then reasoned that L2 block times change (citing Optimism Bedrock) so the hardcoded value becomes stale, affecting _capReserve() behavior.
**Exploitation:** No direct exploit described; the flaw degrades the oracle's economic guarantees, creating arbitrage opportunities (too-strict capping) or weakening manipulation resistance (too-permissive capping) once chain block time diverges from the hardcoded value.
**Insight:** When an oracle or rate-limiter parameterizes time using block counts, check whether the assumed block time is immutable; on L2s block times change via upgrades, so hardcoded block-time constants silently break cap math.