Markdown

https://dev.to/rdin777/starknet-btc-staking-how-to-extract-rewards-with-zero-collateral-and-why-the-team-ignored-it-fo

https://farcaster.xyz/rdin777/0x6cb74961

https://dev.to/rdin777/securing-starknet-fixing-gas-dos-logic-flaws-with-ai-assisted-auditing-2a5

Starknet BTC Staking - Critical Vulnerability PoC 🛡️

If this research helped you, please consider giving it a ⭐ Star.

🚀 Stay Updated

Found this research useful?

• Star ⭐ this repo to keep track of it.
• Follow me on GitHub for more DeFi security research.
• Fork it if you want to run your own experiments.

☕ Support the Research

If you appreciate the work and want to support further security research:

Wallet Address (ETH/EVM): 0xBDDD7973D0DE27B715A4A5cbdb87d0DF78757b3A

Executive Summary

Technical analysis and Proof-of-Concept (PoC) for a Critical Logic Bypass in the BTC Staking Attestation module. This vulnerability allows for reward extraction without actual BTC collateral.

Status: Unpatched / Public Disclosure due to lack of technical engagement from the team.

---

🚨 The Vulnerability: Ghost Staking

The root cause is an insecure reliance on get_block_hash_syscall within Attestation.cairo. Since block hashes are public, any network participant can forge attestation data.

Impact:

• Reward Theft: Attackers can siphon up to 25% of rewards with zero BTC collateral.
• Economic Manipulation: Manipulation of the MintingCurve inflation metrics.

---

🛠️ Proof of Concept (PoC)

The vulnerability is verified through local simulation using snforge and exploit.js.

1. Cairo Integration Test

Demonstrates reward allocation to an empty staker address.

cd ghost_staking_audit
snforge test tests/test_ghost_stake.cairo
2. External Exploit Script
Simulates the attestation forgery logic.

Bash
node scripts/exploit.js
📅 Disclosure Timeline
March 21, 2026: Submitted report to the team. Dismissed as "AI slop".

March 22-24, 2026: Requested technical review; offered private PoC access. No response.

March 24, 2026: Public disclosure to protect user funds and ecosystem integrity.

Researcher: rdin777

## 🛡 Recent Audit Findings

### [H-01] Gas Denial of Service via Unbounded Loop
**Severity:** High
**Vulnerability Type:** Denial of Service (DoS)

**Description:**
The contract iterates through all registered tokens in a single transaction within the \`update_rewards\` function. There is no pagination or limit on the number of tokens.

**Impact:**
An attacker can bloat the token list by calling \`add_btc_token\`. As shown in the PoC, the gas cost increases linearly. With enough tokens, the transaction will exceed the **Starknet Block Gas Limit**, preventing any user from interacting with the rewards logic.

**PoC Results (starknet-foundry/snforge):**
- **Base state (1 token):** ~13,840 L2 gas
- **Attacked state (500 tokens):** ~8,047,846 L2 gas 🚀

---
*Research and PoC developed by rdin777*

---

## 🛠 Latest Updates (April 17, 2026)

### Fixed: Logic Vulnerability & Storage Inflation
During further auditing, a **Duplicate Token Registration** bug was identified. This allowed an attacker to register the same token multiple times, artificially inflating the loop size even with a single malicious contract.

**Changes implemented:**
- Added `token_registered: Map<ContractAddress, bool>` to track unique assets.
- Integrated `assert` validation in `add_btc_token` to prevent double-registration.
- Refactored imports to use modern `starknet` core library syntax.

### 📊 Security Verification Results
All tests passed successfully, confirming both the vulnerability and the fix:
1. `test_duplicate_token_registration`: **PASSED** (Confirmed: attempt to add duplicate now panics).
2. `test_unbounded_iteration_gas_limit`: **PASSED** (Confirmed: 500 unique tokens consume ~9.8M gas).

**Status:** The contract is now protected against internal redundancy attacks.

🛡️ Finding #5: Precision Loss due to Integer Division
Severity: High
Category: Math / Logic Error

Description:
In staking_math_v2.cairo, the reward calculation performs division before multiplication. Since Cairo handles only integer math, any result of (duration * rate) / supply that is less than 1 will be rounded down to zero.

Vulnerable Code:

let reward_increase = (duration * rate) / supply * 1_000_000_000_000_000_000;
Proof of Concept (PoC):
The mathematical PoC in src/staking_math_v2.cairo demonstrates that even with a significant duration, if the total_supply is large enough, the reward_per_token remains 0, effectively "stealing" rewards from users.

Recommendation:
Always perform all multiplications before divisions to maintain maximum precision.