IBC Rate Limits review

Proposal Discussion
1

This proposal expands IBC rate limits for net movements on assets to a broader array of tokens on Osmosis and reviews the current rate limits.

Background

The IBC Rate Limit module is a safety control implemented in v13, intended to protect assets on Osmosis in the event of security issues with:

  • Osmosis
  • A counter-party chain
  • IBC

Rate limits allow only a specified net percentage change in the quantity of an asset on Osmosis within a specified period.

Slowing down the rate of security incidents allows validators more time to respond, investigate, and take any required action. It either caps the rate at which exploited tokens generated elsewhere can be sent to Osmosis for disposal or prevents unusually high amounts of tokens on Osmosis from being removed.

Current IBC Rate limits were approved in Proposal 427 and can be monitored on the Range Dashboard.

These limits currently cover 37% of non-OSMO liquidity; this proposal expands this to 84%.

Proposed Values

Current Denominations - Adjustments

To be tightened to net flows of 25% per day and 50% per week from 30% and 60%.

ATOM - ibc/27394FB092D2ECCD56123C74F36E4C1F926001CEADA9CA97EA622B25F41E5EB2

WBTC.axl - ibc/D1542AA8762DB13087D8364F3EA6509FD6F009A34F00426AF9E4F9FA85CBBF1F

ETH - ibc/EA1D43981D5C9A1C4AAEA9C23BB1D4FA126BA9BC7020A25E0AE4AA841EA25DC5

USDC.axl - ibc/D189335C6E4A68B513C10AB227BF1C1D38C746766278BA3EEB4FB14124F1D858

STARS - ibc/987C17B11ABC2B20019178ACE62929FE9840202CE79498E29FE8E5CB02B7C0A4

JUNO - ibc/46B44899322F3CD854D2D46DEEF881958467CDD4B3B10086DA49296BBED94BED

CRO - ibc/E6931F78057F7CC5DA0FD6CEF82FF39373A6E0452BF1FD76910B93292CF356C1

Current Denominations - Removals

To be removed due to lower liquidity levels, which cause the daily caps in raw assets to be lower than expected.

EVMOS - ibc/6AE98883D4D5D5FF9E50D7130F1305DA2FFA0C652D1DD9C123657C6B4EB2DF8A

DAI - ibc/0CD3A0285E1341859B5E86B6AB7682F023D03E97607CCC1DC95706411D866DF7

New Denominations

To be set at net flows of 25% per day and 50% per week.

TIA - ibc/D79E7D83AB399BFFF93433E54FAA480C191248FC556924A2A8351AE2638B3877

AKT - ibc/1480B8FD20AD5FCAE81EA87584D269547DD4D436843C1D20F15E00EB64743EF4

USDC - ibc/498A0751C798A0D9A389AA3691123DADA57DAA4FE165D5C75894505B876BA6E4

AXL - ibc/903A61A498756EA560B85A85132D3AEE21B5DEDD41213725D22ABF276EA6945E

INJ - ibc/64BA6E31FE887D66C6F8F31C7B1A80C7CA179239677B4088BB55F5EA07DBE273

milkTIA - factory/osmo1f5vfcph2dvfeqcqkhetwv75fda69z7e5c2dldm3kvgj23crkv6wqcn47a0/umilkTIA

QSR- ibc/1B708808D372E959CD4839C594960309283424C775F4A038AAEBE7F83A988477

USDT - ibc/4ABBEF4C8926DDDB320AE5188CFD63267ABBCEFC0583E4AE05D6E5AA2401DDAB

FET - ibc/5D1F516200EE8C6B2354102143B78A2DEDA25EDE771AC0F8DC3C1837C8FD4447

DYM - ibc/9A76CDF0CBCEF37923F32518FA15E5DC92B9F56128292BC4D63C4AEA76CBB110

SCRT - ibc/0954E1C28EB7AF5B72D24F3BC2B47BBB2FDF91BDDFD57B74B99E133AED40972A

WBTC factory/osmo1z0qrq605sjgcqpylfl4aa6s90x738j7m58wyatt0tdzflg2ha26q67k743/wbtc

PICA - ibc/56D7C03B8F6A07AD322EEE1BEF3AE996E09D1C1E34C27CF37E0D4A0AC5972516

DYDX - ibc/831F0B1BBB1D08A2B75311892876D71565478C532967545476DF4C2D7492E48C

CUDOS - ibc/E09ED39F390EC51FA9F3F69BEA08B5BBE6A48B3057B2B1C3467FAAE9E58B021B

STRD - ibc/A8CA5EE328FA10C9519DF6057DA1F69682D28F7D0F5CCC7ECB72E3DCA2D157A4

qATOM - ibc/FA602364BEC305A696CBDF987058E99D8B479F0318E47314C49173E8838C5BAC

SAGA - ibc/094FB70C3006906F67F5D674073D2DAFAFB41537E7033098F5C752F211E7B6C2

New Denominations - Stride LSTs

Stride Liquid Staked Tokens are being treated differently as Stride also has rate limits set at more strict restrictions than Osmosis.

These limits will be set to slightly stricter levels than the other Osmosis limits, however higher than the limits on Stride.

stOSMO - ibc/D176154B0C63D1F9C6DCFB4F70349EBF2E2B5A87A05902F57A6AE92B863E9AEC - 20% per day, 50% per week (Stride - 15% per day

stATOM - ibc/C140AFD542AE77BD7DCC83F13FDD8C5E5BB8C4929785E6EC2F4C636F98F17901 - 20% per day, 50% per week (Stride - 15% per day)

stTIA - ibc/698350B8A61D575025F3ED13E9AC9C0F45C89DEFE92F76D5838F1D3C1A7FF7C9 - 20% per day, 50% per week (Stride - 10% per day)

Justification

The 24-hour period was chosen to allow validators across time zones to act on any questionable behavior detected while resetting frequently enough that extreme market conditions can be reflected on Osmosis.

The seven-day backup period was chosen in case the 24-hour period was not sufficient for validator action to occur.

The limits should be well outside peak usage so as not to affect users using the exchange normally. The limits were initially set at 30% per day and 60% per week. These reductions happen after there have been only triggers of the rate limit cap due to abnormal movements.

End Proposal Text
Note: This is unrelated to the work being carried out by Range in Grant Batch 21 but acts as a stopgap measure as IBC rate limits had not been expanded to the much wider collection of assets since their initial implementation.
Setting these directly by governance has been tested on Edgenet and was unavailable before the upgrade to Gov v1 earlier this year.

Target Onchain Date: 1st May 2024

1 Like
2

Hmmm, this makes me wonder on a couple of things;

  • should the Rate Limiter not be set on a protocol level and not on an asset level? In the end these additions bring it to a 84% coverage, but that still means 16% is not covered (which is around 1/6 of the liquidity)
  • why remove assets at all? If it is not harmful, maybe it is better to keep them?
  • why is it better to differentiate on an asset-basis? Would a one-size fits all solution not be better for clarity?
3

The limits are set on Denom and Channel but are also percentage-based rather than on a raw number, which means that there isn’t a one-size-fits-all solution.

For example, USDC has 44M of tokens onchain; the 50% limit means that 22M can, therefore, be net moved per day.
The bottom of this selection is STRD, which has 7.9m of tokens onchain and allows 3.95 M transfers a day.
DAI has 478k tokens onchain liquidity, meaning the 50% limit only allows 236k net movements per day.

Therefore, a percentage-based rate limit disproportionately hinders the movement of low-liquidity tokens and is probably not as tight as it could be for tokens with many holdings compared to the liquidity in use for tokens such as USDC. We eventually want to set custom limits for each rather than the more blanket setting in place right now, which acts as a safety rail - this is part of the Range work mentioned above.

There was recently an issue where someone legitimately tried to move a few hundred thousand DAI at once, triggering the rate limit—therefore, we need a lower boundary for the moment until we have more advanced rate limit practices.

2 Likes
4

It will never (I think) be possible to come up with a proper algorythm which is able to distinguish a real transfer vs a scam one. It will always be the case that there are a few false positives imo. Or you have to do it manually, but even then the chances are bigger for mistakes.

Regarding the percentage-based rate limits which could be higher for low liquidity assets. I assume you refer to the fact that the imposed risk is smaller, because there is simply less total value to be moved wrongfully?
That can also be tackled with a tiered system, although that would mean that it still has to recognize based on assets.
I also referred with the protocol level that currently even with this expansion a 16% of the TVL is at risk. I am aware that this also is a lot longer tail consisting of many assets, making it less attractive. But finding a method which works for all TVL instead of having to adjust manually (and through governance) would be a more poka yoke imo.

5

What is the reason for the inflow limits? I can imagine a few potential reasons but I’m curious to know if there is any specific or major one.

1 Like
6

Nothing specific, but protection works both ways,
Outflow would be something like a minting or draining bug on Osmosis that is then moved to another chain for disposal—for example, ATOM being moved to Cosmos Hub to then be sold on a CEX.
Inflow would protect against something like a minting bug on another chain being deposited on Osmosis and then used to buy/pump other tokens. It would then become more difficult to rectify the value loss on the origin chain since it would have already left and been disposed of. I think this is particularly relevant with the IBC re-entrancy bug disclosed recently. However, this itself didn’t prompt the review as it was already being worked on, and I was just working out how to interact with the contracts properly.

Side note - Gov v1 has been a HUGE upgrade for functionality. We updated the rate limits in a software upgrade last time with a signalling proposal before hand since each governance interaction was one proposal. This is executing 27 messages at once in a single proposal, and directly interacting with the contract!

2 Likes
7

Nice, sounds good.

Do you know who is running this ibc.range.org page? I think it’s missing quite a bit. Seemed like saga was at the daily limit earlier but I can’t even see that one there.

8

It’s Scanworks. I asked them to update after this proposal passed and nudged again today. By the sounds of things, the new limits should be showing in the next day or two.
New routes need manually adding, but adjustments to existing ones show up automatically.

1 Like
9

Most are visible now - it looks like SAGA either had sufficient net reversal to lower below the cap again from a spike, or didn’t hit the cap at all.

Only one of the WBTC/WBTC.axl and USDC/USDC.axl limits aren’t visible at the moment but have reported this to them also. Think it is probably cause they both call the routes “WBTC” and “USDC”. Might have to do a further prop to remove/add new paths rather than modify the existing ones, just to future-proof the naming schemes.

1 Like