TL;DR;

This proposal recommends a mechanism that may limit damage to user funds in the case of an exploited vulnerability. If it passes, the IBC Rate Limit module developed by Stride Labs will be added to the Cosmos Hub.

Overview

As the Interchain ecosystem and economy grows in importance, it becomes increasingly important to ensure that each sovereign chain and their inter-connections are protected against exploits.

There are a number of different ways to achieve this; exhaustive testing, code audits and a variety of defensive measures can also be enacted. No matter what measures are taken, there will always exist a potential for misuse in any complex system. Therefore, it is prudent to have defensive measures in place as well, especially because code bugs, environment and library vulnerabilities can manifest themselves in unforeseen ways. This proposal seeks the community’s opinion about the integration of a defensive mechanism to reduce the impact of any exploited vulnerabilities.

Vulnerabilities that exploit user funds can always be rolled back if an appropriate governance vote has taken place, as long as the sandbox is an isolated blockchain. If funds can be on-boarded or off-boarded to other chains, then the instant a vulnerability is exploited, funds can be moved to other chains, beyond the reach of any governance claw back from the exploited chain. The mechanism to off-board funds would be via any bridges to other chains or via IBC support. A rate limiting feature would limit the amount of incoming and outgoing traffic from a particular network that matches a specific criteria.

Previous Exploits and Other Implementations

Examples of previous real or potential exploits on the Cosmos Hub and other ecosystems are shown below:

• Polynetwork Bridge Hack ($611 million)
• BNB Bridge Hack ($586 million)
• Wormhole Bridge Hack ($326 million)
• Nomad Bridge Hack ($190 million)
• Harmony Bridge Hack ($100 million)
• Dragonberry IBC bug

The rate limiting technique is a useful tool that is implemented in a variety of scenarios, including the area of financial transactions, for example on the Osmosis chain.

Proposal

We propose adding the Rate Limit module developed by Stride Labs to the Cosmos Hub. The module prevents massive inflows or outflows of IBC tokens in a short time frame (e.g., 24 hour window). Every rate limit is applied at a

granularity. For example, a rate limit could be added for on the Cosmos Hub <> Osmosis channel ().

Every rate limit will also have a configurable threshold that dictates the max inflow/outflow along the channel. The threshold is represented as a percentage of the total supply of the denom at the start of the time window, and it remains constant until the window expires. For instance, the rate limit for

on might have a threshold of 5% for both inflow and outflow. Given the total supply of 388M ATOMs, such a rate limit would reject any IBC transfer that would cause a net inflow or outflow greater than 19.4M ATOMs. Once the time window expires, the net inflow and outflow are reset to 0.

Initially, we propose the add the following (conservative) rate limits (for both inflow and outflow) with a 24 hour time window:

• 5% for
  uatom
  on Cosmos Hub <> Osmosis (
  channel-141
  ) – a net flow of 19.4M ATOMs / day
• 1% for
  uatom
  on Cosmos Hub <> Neutron (
  channel-569
  ) – a net flow of 3.9M ATOMs / day
• 1% for
  uatom
  on Cosmos Hub <> Stride (
  channel-391
  ) – a net flow of 3.9M ATOMs / day
• 1% for
  uatom
  on Cosmos Hub <> Kujira (
  channel-343
  ) – a net flow of 3.9M ATOMs / day
• 1% for
  uatom
  on Cosmos Hub <> Injective (
  channel-220
  ) – a net flow of 3.9M ATOMs / day
• 1% for
  uatom
  on Cosmos Hub <> Persistence (
  channel-190
  ) – a net flow of 3.9M ATOMs / day
• 1% for
  uatom
  on Cosmos Hub <> Secret (
  channel-235
  ) – a net flow of 3.9M ATOMs / day

These limits are conservative enough to avoid false positives – user transfers being rejected – while still providing an initial protection against exploits. The proposed values are based on the following back-of-the-envelope calculation: In the last 14 days, ~400.000 ATOMs were transferred out of the Hub on average per day, which is ~ 0.1% of the total ATOM supply, and most of this is transferred to Osmosis (more than 90%). This makes the suggested 5% limit large enough to avoid false positives.

Once these rate limits are added, both the inflow and outflow on these channels can be monitored (

) and the limits can be adjusted accordingly. Note that the Rate Limit module enables rate limits to be added and updated via governance proposals.

Proposal Outcomes

The following items summarize the voting options and what they mean for this proposal:

Upon a YES vote:

• The Rate Limit module developed by Stride Labs will be integrated into Gaia and rolled out in one of the next major releases.

Upon a NO vote:

• The Rate Limit module will not be added to the Hub and the discussions with the community will continue to find the best path forward to introduce the rate limiting feature that helps to protect user funds.

NO WITH VETO - A ‘NoWithVeto’ vote indicates a proposal either (1) is deemed to be spam, i.e., irrelevant to Cosmos Hub, (2) disproportionately infringes on minority interests, or (3) violates or encourages violation of the rules of engagement as currently set out by Cosmos Hub governance. If the number of ‘NoWithVeto’ votes is greater than a third of total votes, the proposal is rejected and the deposits are burned

ABSTAIN - You wish to contribute to quorum but you formally decline to vote either for or against the proposal

References

• This proposal references the existing Github Issue and the technical discussion.
• A CosmWasm implementation of the Rate Limit module can be found on the Osmosis chain.
• A specification of the Osmosis implementation of the Rate Limit module.
• A Cosmos SDK implementation of the Rate Limit module can be found on the Stride chain.
• The Rate Limit module developed by Stride was also ported into its own module that can be used by other chains, such as the Cosmos Hub.