Prop 855: IBC Rate Limiting v2 - Delegate management to a subDAO
This proposal delegates the setting of IBC Rate Limits to a subDAO: osmo186stuv8d8wt38a7n3mfldmjw34u0srq2p7sjhz84sdv38nefua0s0ysu5l
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, detailed below. 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.
IBC Rate Limit Controller
The IBC Rate Limit Controller is a 3/6 multisig comprised of participants across the Cosmos who have three responsibilities:
- Set quotas appropriately for the majority of token value secured on Osmosis so that quotas are not hit during standard usage but limit abnormal usage.
- Range Explorer’s IBC Workbench aids in this by enabling the modeling of token flows for each token compared to existing and potential rate limits.
- This requires the roles of
AddRateLimit,RemoveRateLimitandEditPathQuota
- Respond to the quotas being approached during abnormal volume and decide whether to maintain or reset the quotas after analyzing the reason for the abnormal volume.
- Example: High volume caused by an exploit means that the Rate Limits respond appropriately and must be left in place. High volume caused by market volatility or whale movements is legitimately abnormal and the quotas should be reset.
- This requires the role of
ResetPathQuota
- Maintain protocol revenue-sharing agreements with bridges as new assets are enabled for each route without requiring a governance proposal for each.
- This requires the role of
ManageDenomRestrictions
- This requires the role of
SubDAO members at founding:
- Noble
- Osmosis Foundation (x3)
- Range Security
- Skip