# Staking indexer doesn't support the spending of multiple Staking transactions

Babylon staking indexer's getSpentStakingTx returns only the first spent staking UTXO per Bitcoin tx, leaving other spent stakes marked unspent in the offchain DB.

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

**Target:** Bitcoin staking indexer (indexer.go)
**Root cause:** getSpentStakingTx loops over tx inputs but returns on the first matching staking UTXO, so a single Bitcoin transaction spending multiple staking outputs only updates one staking record.
**Steps:**
1. Staker creates multiple staking transactions (multiple staking UTXOs).
2. Staker spends all of them in one Bitcoin withdrawal transaction via the timelock path (unbonding path is protected by Covenant signers enforcing 1-in/1-out).
3. Indexer's HandleConfirmedBlock calls getSpentStakingTx(msgTx), which returns only the first matching staking tx and input index.
4. handleSpendingStakingTransaction marks only that one staking tx as spent/withdrawal; remaining spent staking txs stay 'unspent' in the offchain DB.
**How found:** Code review of getSpentStakingTx: noticed the early `return stakingTx, i` inside the input loop, meaning only one staking transaction can be resolved per spending tx; cross-checked HandleConfirmedBlock which handles a single returned staking tx.
**Insight:** When auditing indexers, check functions that resolve 'the' referenced entity from a transaction's inputs/outputs—Bitcoin txs can spend many UTXOs, so any single-return resolver silently drops the rest and desyncs offchain state.