Introduction
Many developers migrating from Solidity to Cairo often overlook the fact that Starknet has its own unique gas limits and execution architecture. In this article, I will demonstrate how the absence of loop boundaries can transform a standard smart contract into a "gas bomb" that is impossible to defuse.
The Vulnerability
While auditing a staking protocol, I identified a classic but critical vulnerability: an Unbounded Loop. The contract maintains a list of tokens eligible for rewards, and the core logic iterates through this entire list in a single transaction.
Rust
// Simplified logic from the audited contract
fn update_rewards(ref self: ContractState) {
let mut i: u32 = 0;
let count = self.btc_tokens_count.read();
while i < count {
let _token = self.btc_tokens.read(i);
// Reward calculation logic resides here...
i += 1;
};
}
The flaw is evident: the update_rewards function has no upper bound. As the number of registered tokens grows, the gas required to execute this function increases linearly until it hits a hard limit.
The Attack Scenario
Lack of Access Control: The add_btc_token function is public, allowing any user to register a token.
Storage Bloating: An attacker repeatedly calls this function, filling the storage with hundreds of dummy token addresses.
Denial of Service (DoS): When a legitimate user or admin attempts to trigger update_rewards, the transaction fails consistently with an Out of Gas error.
Proof of Concept (PoC)
Using Starknet Foundry (snforge), I developed a test suite to measure the impact. The results are staggering:
Token Count Gas Consumption (L2 Gas) Status
1 Token ~13,840 ✅ Normal
500 Tokens ~8,047,846 ⚠️ CRITICAL (DoS)
Once the gas cost nears the Starknet block gas limit, the contract becomes "bricked." Users will be unable to claim rewards or withdraw their assets because the reward calculation is a mandatory prerequisite for these actions.
Mitigation Strategies
To prevent such vulnerabilities, developers should:
Implement Pagination: Instead of processing the entire list, handle tokens in batches (e.g., 50 tokens per transaction).
Enforce Access Control: Restrict token registration to an Owner or a DAO-governed role.
Adopt a Pull-over-Push Pattern: Allow users to trigger updates for specific tokens individually rather than forcing a global state update.
Conclusion
In Web3, security is not just about preventing logic errors; it’s about understanding the constraints of the underlying infrastructure. This case serves as a reminder that gas efficiency is directly tied to protocol availability.
Research and PoC developed by rdin777
Check out the full repository here: github.com/rdin777/starknet-staking_audit1
Top comments (0)