Bridge rate-limiter / chain-pause as positive mitigant
Wormhole's assessment for RD-F-185 — scored gray on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
Bridge rate-limiter / chain-pause as positive mitigant | NTT framework implements configurable per-window outflow rate limiters (24-hour default window, per-chain configurable limits, queueing when limit exceeded). A `pauser` role exists in NTT deployments. Core Bridge (VAA-based messaging) does NOT have a rate limiter — messages are relayed one-by-one with no outflow cap. The positive mitigant applies only to NTT integrations, not the Core Bridge itself. For protocols using NTT (including W ...
Sources #
- Curator noteExtracted from 02-governance-admin.md — RD-F-185; no URL citedretrieved 2026-04-28
Methodology #
Determine whether the bridge implements a per-window outflow rate-limiter (and at what cap), and whether the protocol team can trigger a chain-level or validator-set emergency pause.
See the full factor methodology and distribution across all protocols →