Bridge rate-limiter / chain-pause as positive mitigant
M^0's assessment for RD-F-185 — scored yellow on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
HubPortal (Wormhole NTT) implements rate-limiter via Wormhole NTT built-in per-window transfer caps. Portal Lite (Hyperlane) — no explicit rate-limiter confirmed from available source review. whenNotPaused modifier exists in Portal.sol (pause mechanism present). Partial positive mitigant: Wormhole NTT rate-limiting on Ethereum hub portal; Hyperlane rate-limiter not confirmed.
Sources #
- EtherscanHubPortal Proxy — EtherscanHubPortal: AccessControlUpgradeable, UUPSUpgradeable; Wormhole NTT architecture provides per-window rate limitsretrieved 2026-05-16
- Portal.sol — m0-foundation/m-portal GitHubPortal.sol GitHub: whenNotPaused modifier present; no explicit rate-limiter value confirmed for Hyperlane pathretrieved 2026-05-16
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 →