Hello @skilesare
In my opinion, this is only applicable in limited situations.
A DAO that needs to accept votes must allow update calls from authenticated users, not just canisters. You can apply a rate limit per principal ID, but any bot can create infinite principals and keep draining.
A global rate limit is even worse: what looks like protection becomes a larger vulnerability. Once the global cap is reached, the attacker prevents any legitimate caller from making additional calls, effectively freezing the canister, including governance proposals. The same applies to ledgers, as already pointed out by this user, to which no one has responded: Critical! Cycle draining attacks on token canisters by design they must accept calls from non-canisters. Additionally, considering that the direction we seem to be taking is to increasingly encourage pure vibe coding, all of this exposes even more risks, maybe simple ones, but still very real. For example, a vibe developer might forget to ask the AI to implement cleanup logic for rate limits, causing memory usage to grow indefinitely. And we all know that, at least for now, AI on its own does not proactively suggest these kinds of protections.
The real issue is architectural, and Mission 70 will make it more problematic by raising the defender’s cost without raising the attacker’s cost.
Every known mitigation has a hard limit on its scope:
- Proxy / canister-only access: works for B2B services but not for DAOs, ledgers, or any user-facing app. And a proxy that accepts ingress is just the next drain target.
- Proof of Personhood gating (WorldID, DecideID, etc.): only viable where forcing every user through identity verification is acceptable. Useless for permissionless ledgers and adds heavy UX friction.
- PoW puzzles on ingress: raise attacker cost but don’t cover many scenarios; they break time-sensitive operations, are hostile to light clients, and are bypassable with cheap compute.
- Reverse gas / capability tickets (ICRC-2 prepay, ticket dispensers): technically work, but adopting them as a universal pattern would fundamentally change how apps are built on IC and erode one of its main UX advantages (free interactions from the user’s perspective). It would push ICP closer to the EVM development model and degrade mass adoption.
- Stake-gated calls / VP thresholds / similar approaches: effective for governance but inapplicable wherever the canister must serve non-stakers.
Used in synchrony, these can partially harden a specific canister, but it’s application-level patchwork; every team reinventing the wheel and getting different pieces wrong. What seems to be missing is a protocol-level or at minimum DFINITY-blessed uniform mechanism: ideally ingress-attached cycles at the protocol layer, or a standardized “cycle-bonded ingress” pattern with a reference implementation, so that protection doesn’t depend on each developer’s individual security expertise.
Correct me if I’m wrong, but until that exists, “best effort with overlapping mitigations” is what every canister exposed to public ingress is reduced to.