This proposal implements a new IBC Rate Limit contract onchain which enables the delegation of responsibility for setting and maintaining IBC Rate Limits

IBC Rate Limits

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.

This upgrade to the IBC Rate Limits contract was funded by the Osmosis Grants Program in Batch 21 and adds Role Based Access Control (RBAC) to the existing contract.

Role Based Access Control

RBAC allows different addresses permissions to carry out maintenance tasks on the rate limits in use on Osmosis while still giving governance oversight of all changes and maintaining the rights to carry out these adjustments itself.

The Roles available are:

AddRateLimit & RemoveRateLimit & EditPathQuota Allow new Rate limits to be set, removed and edited based on an IBC channel and denomination pair. This is the current mechanism used by governance-based rate limit management.

ResetPathQuota Allows the rate limit tracking for a path, consisting of an IBC channel and denomination pair, to be refreshed whilst maintaining the setting of the limits.

GrantRole & RevokeRole Grants and removes these roles from another address.

SetTimelockDelay & RemoveMessage Sets a delay before changes to settings will be executed within the rate-limiting contract, remove message being the ability to cancel these messages before execution.

This would allow the delegation of roles to a less secure signing address while maintaining a veto ability for any changes it may make.

ManageDenomRestrictions Restricts a denomination to transfer along only a specific IBC channel, this is important for fee agreements as it allows chains with bridging agreements to retain routing hub status for their bridging mechanism.

An example of these roles being split would be utilizing a higher security subDAO that sets limits with a voting period of a few days and a lower security, higher member count subDAO that can more rapidly reset the rate limit quotas after review.

It is initially proposed that a selection of these roles be added to a single subDAO which will be proposed once this contract has migrated. Osmosis governance retains full rights to perform any of these tasks or revoke these permissions and is the only entity able to migrate the contract.

Benefits

Variants of USDT have been regularly hitting the caps as the composability of Alloyed USDT has seen Osmosis become more of a routing hub for cross-chain arbitrage transactions.

Other legitimate transfers, such as an LP unwinding qATOM have resulted in caps being hit and needing to go through Osmosis governance to be removed.

The ability to check when rates have been hit and quickly reset the quotas if the activity is not due to a security event is a considerable improvement over the eight-day Osmosis DAO governance timeline. As limits are set on one-day and seven-day windows, resetting the quota has never been feasible.

Caps are currently set at relatively high values of 25% net flow per day and 50% per week. While this removes the possibility of a full token drain, as recently occurred on Terra, the looser caps allow the loss of more tokens during a security event. Allowing a subDAO to control these caps allows for fine-tuning of the limits to be closer to normal usage with minimal impact when these are hit during high-volume market events.

Caps are also only set on assets with around 200k of liquidity on Osmosis due to larger movements triggering rate limits to be hit with little actual volume. Due to the responsiveness of the subDAO, rate limits can be set on assets with lower liquidity onchain, increasing coverage of the security provided by the limits.

Concerns

If an address that has been granted roles that create or edit rate limits or denomination restrictions is compromised, it can be used to perform griefing attacks by creating overtly strict rate limits impacting user experience.

If an address that has been granted roles that edit, reset or remove rate limits is compromised, it can be used in tandem with a protocol exploit to bypass rate limits.

Forum Thread: https://forum.osmosis.zone/t/ibc-rate-limiting-v2-upgrade-contract-and-delegate-management-to-a-subdao/3090