IBC Rate Limiting v2 - Upgrade contract and delegate management to a subDAO

Proposal Discussion
1

Proposal 1 - IBC Rate Limiting v2 - Upgrade contract

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.

Proposal 2 - 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, RemoveRateLimit and EditPathQuota
  • 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

SubDAO members at founding:

  • Noble
  • Osmosis Foundation (x3)
  • Range Security
  • Skip
2 Likes
2

I think this is a good step. Going through governance in case of emergency is just to slow, even with an expedited path. We need hands on the buttons when needed, and that can only be done when it is managed through a non-governance route.

The people involved in the subDAO are involved enough for the largest part as I can judge, thereby securing the best interest for the chains.

3

Potential Risks of IBC Rate Limiting v2 Upgrade

While the proposed upgrade introduces faster response times and improved rate limit management through subDAO delegation, there are several critical risks that could negatively impact the Osmosis ecosystem:

  1. Reliance on SubDAO Governance

    • Delegating key responsibilities to a subDAO introduces additional layers of decision-making, which can reduce the transparency and oversight provided by the main governance process.
    • While subDAOs can act more quickly, this speed comes at the cost of reduced accountability. If the subDAO makes mistakes or is not well-structured, the platform could face disruptions or mismanagement of rate limits.

  2. Trade-off Between Security and Speed

    • Faster resets of rate limits by the subDAO could lead to rushed decisions, increasing the chance of errors or improper adjustments. This could expose Osmosis to vulnerabilities, especially during volatile market conditions.
    • Even though the intention is to enhance responsiveness, there is a risk that too much flexibility in managing limits could result in security gaps, as critical checks might be bypassed or overlooked in favor of speed.

These risks highlight the challenge of balancing efficiency with security. While the idea of delegating tasks to a subDAO seems practical, the governance process must ensure strict oversight to prevent mismanagement and unintended consequences. Ensuring that proper safeguards are in place will be crucial to maintaining both the stability and security of the system.

Personally, I voted against this change and recommend others do the same, as the risks of decentralizing control in this way could outweigh the potential benefits, especially if not carefully monitored.

4

It’s disappointing to see the majority supporting this upgrade. While faster responses may seem like a benefit now, in the long run, this change will reduce the level of decentralization by shifting control to a subDAO.

Decentralization is a key factor in building trust and resilience in blockchain networks. Weakening governance oversight could harm the Osmosis ecosystem by introducing management risks and unclear accountability. As decentralization erodes, so too does the value of OSMO tokens, which rely on a strong, community-driven governance model.

5

In essence I agree with you, but on the other hand we also see a lot of validators who are not doing research on what they vote in the first place. On top of that it has to be noted that the players in subDAOs matter as well. If there are some random people present in a DAO I would certainly agree, but in this case there are representatives who have a stake in making Osmosis a success in the long run.

I do believe that on the longer run we should review this kind of decisions, but at this point in time I think they are necessary to make sure the protocol is evolving in the right direction.

6

On behalf of the PRO Delegators validator, we support this proposal.

Our support is grounded in the practical need for the IBC rate limit as a critical tool for safeguarding the chain against both coordinated attacks and unexpected events (such as the Terra collapse, for those who recall). If such mechanisms had been implemented then, some of the adverse effects of that liquidity crisis on the Osmosis chain could have been mitigated. We acknowledge that incorporating a committee-based decision mechanism may raise some concerns over decentralization in the longer term.

We agree that this presents a trade-off. However, given the proven commitment and expertise of the teams managing the multi-sig, we believe this change provides a net benefit for the chain at this time. In the future, as automated safeguards evolve, we can consider removing the need for human intervention in these matters.

Thank you for reading,
Govmos
pro-delegators-sign