[PROPOSAL 890] [PASSED] Signaling Proposal: IBC Rate Limiting

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…

Excerpt (1191 of 6256 characters). Read the whole post on the forum ↗

Would there be a way to set the limits per channel via governance proposals, in case community would want to change these?

Yes, this is why we’ve started with very conservative settings. We’d be happy to change these even in the initial signaling prop.

btruax: 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 `ChannelID + Denom` granularity. The proposed safety module design is super simple, and it’s an absolute necessity for the Hub’s defenses. Concerning the proposed limitation thresholds, we suggest slightly higher barriers for our esteemed AEZ partners, @Stride and @Neutron , enabling an increase in the 24-hour limit to 7.8M ATOMs/day. • 5% for `uatom` on Cosmos Hub <> Osmosis (`channel-141`) – a net flow of 19.4M ATOMs / day • 2% for `uatom` on Cosmos Hub <> Neutron (`channel-569`) – a net flow of 7.8M ATOMs / day • 2% for `uatom` on Cosmos Hub <> Stride (`channel-391`) – a net flow of 7.8M ATOMs / day We are also wondering if there are plans to include similar restrictions for other tokens currently held inside the Hub. Presently, we are holding 65,896,156, and it might be wise to consider implementing restrictions for these tokens as well. image 2808×640 81.1 KB Source: Mintscan Lastly, we wonder if the 24-hour…

Excerpt (1198 of 2041 characters). Read the whole post on the forum ↗

@Govmos Thanks for the feedback. Concerning the proposed limitation thresholds, we suggest slightly higher barriers for our esteemed AEZ partners, @Stride and @Neutron , enabling an increase in the 24-hour limit to 7.8M ATOMs/day. We believe that the 1% limit is already very conservative – in the last 7 days, the Stride-Hub channel had a net flow of around `1.3M$` worth of tokens, while the Neutron-Hub channel had a net flow of around `1M$` (cf. Mintscan ). Not sure how accurate this data is (it seems that different explorer show different data), but this is two orders of magnitude under the current limit of `3.9M ATOMs / day`. Once the rate limit module is in production, we can closely monitor these channels and update the limits based on more accurate data. Also keep in mind that increasing these per channel limits, would increase the overall limit of how much of the total ATOM supply can be transferred out of the Hub. With the current suggestion, that’s 11% per day. Given that ~63% is locked, this means that around of 1/3 of the total liquid ATOM supply could be transferred out of the Hub per day. We are also wondering if there are plans to include similar…

Excerpt (1191 of 3052 characters). Read the whole post on the forum ↗

mpoke:

Also keep in mind that increasing these per channel limits, would increase the overall limit of how much of the total ATOM supply can be transferred out of the Hub. With the current suggestion, that’s 11% per day. Given that ~63% is locked, this means that around of 1/3 of the total liquid ATOM supply could be transferred out of the Hub per day.

ou are absolutely correct in pointing that out. Our recommendation was based on the entire supply of ATOM, not taking into account the significant share of illiquid tokens. With this information in mind, we would like to retract our proposition, and the initial 5-1-1% seems appropriate. We will edit the original post to remove this part.

mpoke:

I do believe that a few month of collecting data would give us the confidence to reduce the 5% limit to something much smaller, e.g., 1%.

We have always advocated for a data-driven approach, and therefore, we fully align with that vision. Thanks for your valuable contribution to this discussion!

At first glance this seems like a good idea, and was just about to vote yes, but when I thought about it a bit more, and from the POV of a user of the infra (speaking for myself here and not Stakecito), it actually seems like a pretty bad idea that would:

1. Inhibit liquidity, limiting the free flow of assets between chains and affecting arbitrage opportunities which are vital for market efficiency.

2. Could result in transactions being denied due to exceeding the set thresholds, negatively impacting the user experience for folks transacting

I also question the effectiveness of rate limiting to address vulnerabilities. I don’t see how this adequately addresses the root causes of vulnerabilities, it could also still be circumvented by attackers.

Then there’s the question of governance overreach, with the community having to regularly vote on adjusting rate limits to keep up with evolving network dynamics, potentially leading to governance fatigue

At this time too in the market. Idk, just seems weird to me personally to impose rate limits. I understand the reasons why, just wondering if we should maybe wait for better solutions.

Edited to say: Aaah I see Osmosis has IBC rate limiting too (which I’ve never actually felt as a user). Still question this approach though. Earlier today I saw a tweet that said IBC isn’t audited nearly enough. Maybe instead of imposing restrictions on users, that and thorough testing should be done. We will vote yes on this though.

At Umee we implemented very efficient IBC rate limiting. It uses oracle data to do USD value based quota. However it’s easy to adapt it for % based quota.

//github.com/umee-network/umee/tree/v6.4.0-beta1/x/uibc

@Winfred Thanks for the feedback. from the POV of a user of the infra (speaking for myself here and not Stakecito), it actually seems like a pretty bad idea that would: • Inhibit liquidity, limiting the free flow of assets between chains and affecting arbitrage opportunities which are vital for market efficiency. • Could result in transactions being denied due to exceeding the set thresholds, negatively impacting the user experience for folks transacting I agree that there is a risk that rate limits can affect user experience. That’s the reason we proposed very conservative limits for now. Also, we plan to monitor the net flow on these channels and update the limits accordingly. It’s very unlikely that the traffic between the Hub and Osmosis for example will increase 100x over night, so we don’t expect the UX to be affected. Aaah I see Osmosis has IBC rate limiting too (which I’ve never actually felt as a user). Exactly Then there’s the question of governance overreach, with the community having to regularly vote on adjusting rate limits to keep up with evolving network dynamics, potentially leading to governance fatigue We do not believe that the…

Excerpt (1196 of 2490 characters). Read the whole post on the forum ↗

Hi @robert.zaremba. Thanks for sharing. What’s the advantage of an USD value based quota over a % based quota? Also, what’s the advantage of the Umee design over the Osmosis design?

It’s all about the risk assessment. Do you want to measure it in USD value or in amount of tokens.

Our implementation has two fold quota:

• per token in USD value. Currently $1.7m / 12h
• total outflows in USD value. Currently $2.2m / 12h

Our quota window is also a param - we can increase or decrease it (eg from 12h to 24h).

Note, that total outflows quota (sum of token values) is impossible with the approach presented in OP (because how do you comapre 1atom outflow to 1usdc outflow?).

Winfred:

it actually seems like a pretty bad idea that would:

1. Inhibit liquidity, limiting the free flow of assets between chains and affecting arbitrage opportunities which are vital for market efficiency.

First of all, thank you for providing the rationale behind your concerns, this kind of feedback is vital to strike the best final decisions on any matter. You’re absolutely right to mention the risk this could pose to arbitrage opportunities which we expect to be a core functionality of ATOM in the greater Cosmos. Nevertheless, we have to remember that limiting the uATOM IBC flows on the Hub itself won’t affect the LSTs behavior. Afterall, they are the most suitable liquid form of ATOMs to perform such arbitrages. With this dual form we can ensure the best of both worlds. The capital (ATOM) remains safe and protected with the rate-limit, while the money (stATOM, stkATOM,…) can move freely in the whole Cosmos without those restrictions (unless LST providers decide to use rate-limits themselves).