Full Report
This is part 3 of a series about IBC (interblockchain communication) token rate limiting. They have a nice dashboard that shows all of the rate limits on Osmosis. In this article, they attempt to make some improvements to IBC rate limits. Right now, the rate limits must be approved via a governance proposal. This means that new tokens don't have limits and that's a bummer. So, they recommended including a default rate limit when it's a new token on chain. This PR is still open though. The next issue they tackle is boundary attacks. The way that the rate limit is designed is using periods instead of a running time box. So, an attacker can transfer all of the tokens they can at the end of a period then a bunch more at the beginning of the period. The period is reset within the execution of a given transaction. Instead, they recommend using a automatic period rollover for the rate limiting for A) security and B) usability. They implemented this by resetting the limit within the EndBlocker once the period has ended. This is still susceptible to boundary attacks though. So, they have a two period averaging algorithm. The idea behind this is to calculate the average values of the capacity between two periods. They decided to add a decay on the earlier periods in order to make it more user friendly on UIs. Again, there is an open PR for both of these changes. Another idea is to add notional value rate limits. However, this requires Oracles in order to do correctly, which has its own security risks. Depending on where the values are coming from, they can be manipulated or have times of volatility. Having speed bumps or timelocks can allow for action to be taken. The same thing can be done for large transactions - simply delaying them for some static amount of time can allow for actions to take place. To make life better for big parties, having conditional bypasses can be good as well. For instance, a sender based allowlist, transaction type or whatever else. However, doing this can open things up to an attack if they can be abused. Overall, these seem good; it's awesome having it documented though. Wormhole has a rolling time period to prevent boundary issues. Additionally, there are notional values that are used from CoinGecko too. The research was good but it's a bummer that most of the PRs haven't been merged into the project.
Analysis Summary
# Best Practices: IBC Token Rate Limiting
## Overview
These practices address the security vulnerabilities inherent in Inter-Blockchain Communication (IBC) token transfers, specifically focusing on the "empty window" problem where new tokens lack protection, and "boundary attacks" where fixed-time windows allow double the intended outflow during period rollovers.
## Key Recommendations
### Immediate Actions
1. **Enable Automatic Quotas:** Implement a "fail-secure" default where every new IBC channel/token is automatically assigned a baseline rate limit upon creation, rather than waiting for manual governance approval.
2. **Fix Manual Resets:** Eliminate manual period resets within transaction execution; shift the reset logic to a system-level process (e.g., `EndBlocker`).
### Short-term Improvements (1-3 months)
1. **Implement Rolling Windows:** Transition from static time periods to rolling time boxes (or a Two-Period Averaging algorithm) to prevent attackers from exhausting limits at the end of Hour 1 and the start of Hour 2.
2. **Large Transaction Delays:** Introduce mandatory time-locks or "speed bumps" for transactions exceeding a specific volume threshold to allow for manual intervention.
### Long-term Strategy (3+ months)
1. **Notional Value Rate Limiting:** Move from token-count limits to USD-denominated limits using Oracles (e.g., CoinGecko) to account for price volatility across different assets.
2. **Conditional Bypass Framework:** Develop a secure allowlist for trusted senders or specific transaction types to maintain high usability for institutional partners without compromising general floor security.
---
## Implementation Guidance
### For Small Organizations
- focus on **Automatic Registration**. Small teams often lack the governance bandwidth to monitor every new token. A 30% daily / 60% weekly default limit provides immediate "lazy" security.
### For Medium Organizations
- Implement **Averaging Algorithms**. Use a two-period average with a decay function. This balances security with UX, as it prevents sudden "hard" walls that block legitimate users during period transitions.
### For Large Enterprises
- Focus on **Value-based Latency and Conditional Bypasses**. Integrate robust Oracles with safety buffers (to prevent price manipulation attacks) and implement sender-based allowlists for high-volume, verified treasury movements.
---
## Configuration Examples
### Default Rate Limit Registration (PoC)
The following logic ensures no token path is left "un-throttled":
rust
// Example of default path initialization
let path_msg = PathMsg::new(
path.channel.clone(),
denom,
vec![
QuotaMsg::new("daily", 86400, 30, 30), // 30% daily limit
QuotaMsg::new("week", 604800, 60, 60), // 60% weekly limit
]
);
add_new_paths(deps, vec![path_msg], env.block.time)?;
---
## Compliance Alignment
- **NIST Cybersecurity Framework (ID.RA):** Asset Assessment and Risk Analysis for cross-chain flows.
- **ISO/IEC 27001:** Specifically addressing "Network Security Management" and "Information Transfer."
- **CIS Controls (Control 13):** Data Protection and monitoring of large data (value) exfiltration.
---
## Common Pitfalls to Avoid
- **Governance Lag:** Relying solely on manual voting to apply security controls to new assets.
- **The "Double-Dip" Boundary:** Using fixed windows (e.g., exactly at 00:00 UTC) which allows an attacker to execute 100% of the limit at 23:59 and another 100% at 00:01.
- **Oracle Dependence:** Implementing notional (USD) limits without "circuit breakers" for the Oracle itself; if the price feed is manipulated, the rate limit can be neutralized.
---
## Resources
- **Wormhole Implementation Reference:** Review for rolling time period logic.
- **Osmosis Rate Limit Dashboard:** Reference for real-time monitoring of active quotas.
- **Range Security GitHub:** `https://github[.]com/teamscanworks/ibc-rate-limits/pull/5` (Defanged link)