Summary: The IBC Rate Limit Module is a small but useful choke point. It intercepts IBC transfer packets, hands the decision to a governance-selected CosmWasm contract, and blocks flow when quotas trip. That keeps quota logic out of consensus code while preserving a hard policy gate in the transfer path.
What it does:
Inserts a minimal middleware layer into IBC transfer flow so outgoing and incoming packets can be checked before completion
Forwards packet data to a configured CosmWasm contract using standardized sudo hooks such as send_packet, recv_packet, and undo_send
Lets governance set or clear the contract address that defines the active rate-limiting policy
Blocks transfers when the contract reports a rate-limit breach and undoes accounting when sends later fail
Allows the active policy implementation to change without a chain upgrade, since the contract can be replaced by governance
In Neutron’s reference implementation, supports time-based, quota-driven throttling keyed to denom/channel paths and net-flow accounting
Key claims:
The Neutron docs are explicit that the module itself is minimal middleware, not a full risk engine. Its only durable consensus-level control surface is packet interception plus a governance-managed contract address parameter.
That split is the most important thing to preserve analytically. The chain decides that every transfer must pass through the middleware, but the contract decides what “safe enough” means.
The overview page makes the motivation unusually concrete by anchoring the design to past bridge hacks and to the idea that a partial depeg is far preferable to a total loss. This places the module in a safety-throttle lineage rather than a throughput-optimization lineage.
The how-to docs show a stark governance lever: clearing the contract address disables rate limiting entirely and returns the module to transparent pass-through behavior. So the emergency posture is not merely “change a quota,” but potentially “remove the risk-control layer from the path.”
The current contract repository is analytically useful because it reveals the specific choices hidden behind the generic module framing: discrete time windows rather than rolling ones, net-flow tracking to avoid ping-pong DOS griefing, per-denom path quotas implemented now, channel-value heuristics, and explicit TODOs around better rolling-window design.
The module is therefore useful in the corpus because it separates three things that are often blurred together in bridge-safety conversations: packet interception, quota-policy computation, and governance authority over the live safety policy.
It also exposes a broader tradeoff worth reusing elsewhere: the system openly sacrifices liveness in extreme demand conditions to buy human reaction time after exploits or bugs. That makes it a useful comparison point for other issuer-side caps, bridge circuit breakers, and emergency pause designs.
Whitepaper: No standalone whitepaper surfaced in this pass. The strongest primary materials were Neutron’s module documentation and the official neutron-org/rate-limiter-contract repository collected in ../whitepapers/ibc-rate-limit-module-primary-sources-2026-05-11.md.