# Consensus on staking transaction status can be bricked in case of Bitcoin reorg greater then configurationDepth

Babylon staking indexer reuses stale IsOverflow status after a Bitcoin reorg deeper than confirmationDepth, so providers disagree on whether a staking tx is active, breaking consensus.

- Payout: Contest reward
- Severity: medium
- Program: Babylon
- Credited: dontonka
- Disclosed: 2024-08-04
- Write-up quality: 6/10
- Original: https://cdn.cantina.xyz/reports/cantina_competition_babylon_may2024.pdf#3.2.5
- Library page: https://bugbountylibrary.com/r/cantina%3Ababylon_may2024%3A3.2.5
- Tags: domain:web3 impact:integrity kind:contest platform:cantina sev:medium tech:go technique:source-review vuln:accounting-error vuln:business-logic

**Target:** Babylon staking indexer (indexer_store.go, handleNewBlock/Bootstrap)
**Root cause:** On reorg bootstrap, ProcessStakingTx looks up the existing staking tx by hash and reuses storedStakingTx.IsOverflow instead of re-evaluating overflow against the new chain ordering; duplicate detection also skips re-saving.
**Steps:**
1. Set ConfirmationDepth=3, StakingCap=10 BTC; two staking providers follow divergent Bitcoin nodes.
2. Chain A: bB Alice 9 BTC, bD Bob 1 BTC, bE George 2 BTC (overflow). Chain B: bH Paul 2 BTC, bI Bob 1 BTC (overflow).
3. SP1 indexes Bob as active; SP2 indexes Bob as inactive/overflow.
4. BTCNode2 reorgs to the longer chain; handleNewBlock fails parentHash check and triggers Bootstrap.
5. Bootstrap re-processes blocks; ProcessStakingTx finds Bob's tx by hash, hits ErrDuplicateTransaction or reuses stored IsOverflow=true.
6. SP2 keeps Bob inactive while all other SPs mark it active — consensus broken.
**How found:** Code review of indexer_store.go: noticed the stored IsOverflow value is reused on re-processing rather than recomputed, and reasoned through a divergent-chain scenario where a tx flips active/inactive across a reorg.
**Insight:** When an indexer caches derived state (overflow/eligibility) keyed by tx hash, reorg replay will silently reuse stale classifications — check whether re-processing paths recompute derived flags or trust the store.