# StakingScriptData in the btc-staking-ts library allows stakerKey to be in finali- tyProviderKeys

btc-staking-ts StakingScriptData lacks a check preventing stakerKey from also appearing in finalityProviderKeys, letting users build invalid staking transactions they then fund and sign.

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

**Target:** btc-staking-ts library StakingScriptData / buildSlashingScript
**Root cause:** StakingScriptData.validate() checks key lengths but never verifies that stakerKey is distinct from entries in finalityProviderKeys, so a slashing script can be built where the staker key doubles as a finality provider key.
**Steps:**
1. Instantiate `StakingScriptData` with `stakerKey` equal to one of the `finalityProviderKeys` (e.g. user registers own finality provider and reuses its pubkey as staker key).
2. Constructor calls `validate()`, which only checks `PK_LENGTH` for staker and finality provider keys, so it returns true.
3. Call `buildScripts()` → `buildSlashingScript()`, which concatenates single-key staker script, 1-of-N finality provider script, and covenant script without dedup check.
4. Pass scripts to `stakingTransaction()` (used by simple-staking dApp); transaction is produced successfully.
5. User funds and signs the staking and pre-signed slashing transactions believing them valid, but the resulting stake is unexpectedly invalid.
**How found:** Code review of StakingScriptData constructor and validate(): noticed validate only enforces PK_LENGTH on staker and finality provider keys, then traced buildSlashingScript to confirm no cross-check that stakerKey is absent from finalityProviderKeys.
**Exploitation:** Not an attacker-driven exploit; the flaw causes a user to self-generate and fund an invalid staking transaction. If the related stakerPk==finalityProviderPk slashing issue were unpatched, the same key overlap would let the finality provider signature alone complete the slashing transaction, enabling instant slashing of the staker's funds.
**Escalation:** Severity rises to high if the companion 'instant slashing when stakerPk==finalityProviderPk' bug is unpatched, since the overlapping key lets a single signature satisfy both staker and finality provider roles in the slashing script.
**Insight:** When a script combines role-specific keys (staker, finality provider, covenant), audit for missing distinctness checks between key sets; overlapping keys can collapse multi-party signing requirements into a single signer.