Full Report
Bridges are an important piece of the blockchain ecosystem. Being able to move assets from one chain to another is a necessary requirement in the modern web3 space. However, doing bridges securely is difficult to do. In Cosmos, interblockchain communication (IBC) allows for Cosmos blockchains to talk together in a standardized format. In this article, the authors discuss bridge security and how to make IBC more secure. Most security is put into the pre deployment of applications, such as pentests, code review and more. However, equal importance needs to be on the post-deployment protections. The authors mention four different mechanisms for on-chain post-deployment: circuit breakers, rate limits, settlement delayers and redundancy. Circuit breakers simply pause a system when certain conditions occur or manually. This acts as a kill switch to be able to stop functionality when something bad is happening. The Cosmos SDK circuit module is a good example of this but it must be manually done and it's per message. Rate limits disable functionality once a threshold has been passed. This can be a value rate limit such as a dollar amount or a volume rate limit. The second one is similar to API rate limits. This helps to limit the damage of attacks but doesn't prevent them entirely. Delayers impose a delay window between certain transactions. This allows for incident response a time window to revert things if they are malicious. For instance, a 1hr delay may be imposed on a transaction of $1M or more. This is common on governance proposals but can be used in other places as well. Bridge Redundancy Protocols are a consist relay of message over several bridge protocols. If one is effected by a bug, that doesn't matter! To me, having diversity in software is good, like how JumpCrypto is making an alternative validator for Solana. The focus of the article was how the Osmosis blockchain implemented rate limiting on IBC. They have a rate limit on the amount of token assets that can be moved into the ecosystem. This is done with by static periods and net flow of assets moving. This rate limiting is implemented in a CosmWasm smart contract that interacts with the IBC middleware package as a wrapper around ICS20. To be more specific on the Cosmos side, the rate limits are implemented on a given channel and denom. This allows for a standard transfer to occur between two blockchains, without interfering with others. These rate limits measure the inflow and outflow of tokens on a given channel. These are setup in different intervals but appear to be configurable. There are other examples of rate limiting. On the Stride Cosmos SDK blockchain, they do IBC rate limiting based upon the amount of tokens transferred on a channel for a 24 hour window. The Wormhole governor, after a large hack in 2022, implemented functionality as well. They have two types of transactions: small and large. A large transaction has a finality delay of 24 hours while both transaction types of a daily quoted of funds that can be sent. Overall, good post on different on chain protections can be done to reduce the risk.
Analysis Summary
# Best Practices: Post-Deployment Bridge Security & IBC Rate Limiting
## Overview
These practices address the critical "unsolved problem" of bridge security in the Web3 ecosystem. While pre-deployment audits are mandatory, they are insufficient for defending against zero-day implementation bugs. These guidelines focus on **post-deployment defense-in-depth**, specifically emphasizing on-chain risk mitigation techniques to minimize financial impact during an exploit.
## Key Recommendations
### Immediate Actions
1. **Deploy Emergency Circuit Breakers:** Implement a "kill switch" (like the Cosmos SDK circuit module) that allows authorized roles to pause specific message types or entire bridge functionalities manually.
2. **Define Asset Thresholds:** Identify high-value "denoms" (tokens) and channels; establish the maximum acceptable loss for these assets within a 24-hour window to inform initial rate limit settings.
3. **Active Monitoring:** Set up real-time alerts for failed proof verifications or unusual spikes in transaction volume, which often precede a larger exploit.
### Short-term Improvements (1-3 months)
1. **Implement On-chain Rate Limiting:** Deploy a rate-limiting wrapper (e.g., Osmosis CosmWasm contract/IBC middleware) that restricts token inflow and outflow based on static time intervals and net flow.
2. **Introduce Settlement Delays:** Establish a mandatory "timelock" window (e.g., 1–24 hours) for transactions exceeding a specific dollar value to allow incident response teams to intervene.
3. **Governance Integration:** Connect circuit breaker and rate limit configurations to a DAO governance timelock or a trusted multisig for emergency adjustments.
### Long-term Strategy (3+ months)
1. **Bridge Redundancy Protocols:** Transition to a multi-bridge architecture where messages are relayed across diverse protocols, ensuring a single bug in one library (e.g., IAVL Merkle proof flaws) does not compromise the entire system.
2. **Software Diversity:** Use diverse validator client software and multiple independent bridge implementations to reduce systemic risk from common-mode failures.
3. **Dynamic Adaptive Limits:** Mature from static rate limits to dynamic models that adjust based on network volatility and real-time threat intelligence.
## Implementation Guidance
### For Small Organizations
- **Standardized Tooling:** Utilize existing CosmWasm smart contracts for rate limiting rather than building custom logic.
- **Manual Intervention:** Focus primarily on manual circuit breakers and community-monitored multisigs to keep overhead low.
### For Medium Organizations
- **Automated Rate Limits:** Implement the Osmosis-style net flow model per channel and denom.
- **Incident Response Plan:** Define clear "if-then" scenarios: if a rate limit is hit, who is notified, and what is the criteria for resuming operations?
### For Large Enterprises
- **Defense-in-Depth Hierarchy:** Layer redundant bridges with settlement delays for institutional-sized transfers.
- **Formal Verification:** Apply formal verification specifically to the post-deployment safety modules to ensure the "safety net" itself doesn't contain bugs.
## Configuration Examples
* **Osmosis IBC Rate Limits:** Static time window (e.g., 24h) + Net Flow % (e.g., max 10% of total supply can leave the chain in 24 hours).
* **Stride IBC Rate Limits:** 24-hour quota for total tokens transferred on a specific channel.
* **Wormhole Governor:**
* *Small Transactions:* Standard processing + daily quota.
* *Large Transactions:* Mandatory 24-hour finality delay.
## Compliance Alignment
- **NIST Cybersecurity Framework:** Aligns with **Respond (RS)** and **Recover (RC)** functions by providing technical controls to mitigate impact.
- **ISO/IEC 27001:** Supports **Annex A.12.6** (Management of technical vulnerabilities).
- **CIS Controls:** Aligns with **Control 11**: Data Recovery and **Control 13**: Network Monitoring and Defense.
## Common Pitfalls to Avoid
- **"Set and Forget" Limits:** Rate limits that are too tight can stifle legitimate growth; limits that are too loose fail to stop high-speed exploits.
- **Centralization Risks:** Avoid giving a single entity unmitigated power to trigger circuit breakers without transparency; use multisigs or decentralized monitoring.
- **Ignoring Net Flow:** Only tracking "outflow" can be bypassed; tracking "net flow" (Inflow minus Outflow) provides a more accurate picture of asset drain.
## Resources
- **IBC Protocol Documentation:** hxxps[://]www[.]ibcprotocol[.]dev/
- **Cosmos SDK Circuit Module:** hxxps[://]docs[.]cosmos[.]network/
- **Range Security Blog:** hxxps[://]www[.]range[.]org/blog
- **Osmosis IBC Rate Limit Contract (GitHub):** Search for "osmosis-labs/ibc-rate-limiting"