# IBC Rate Limiting v3 - Upgrade contract **URL:** \ **Category:** DApps / Tooling\ **Created:** [October 27, 2026, 1:43pm UTC](https://forum.osmosis.zone/t/ibc-rate-limiting-v3-upgrade-contract/4184 "2026-10-27T13:43:32Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![JohnnyWyles](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.osmosis.zone/johnnywyles/32/3114_2.png) [@JohnnyWyles](https://forum.osmosis.zone/u/JohnnyWyles)\ **Post date:** [October 27, 2026, 1:43pm UTC](https://forum.osmosis.zone/t/ibc-rate-limiting-v3-upgrade-contract/4184/1 "2026-10-27T13:43:32Z")
This proposal updates the IBC Rate Limit contract administered by Osmosis governance. # IBC Rate Limits The IBC Rate Limit module is a safety control implemented in [v13](https://daodao.zone/dao/osmosis/proposals/370), intended to protect assets on Osmosis in the event of security issues with: - Osmosis - A counterparty chain - IBC Rate limits allow only a specified 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 adds absolute limits, corrects how tokens routed through another chain are handled, and hardens the administrative messages, while maintaining all previous functionality and state. # Upgrades ## Absolute Limits Until now, a limit could only be expressed as a percentage of the asset’s supply on Osmosis at the start of each window. On a low-supply asset that rounds to nothing, it doesn’t hold its value when supply changes quickly, which is why no limit was in place on nBTC when 40 BTC of counterfeit tokens were minted against a supply of under 2 BTC. A limit can now also be set as an absolute amount of the asset, on its own or alongside a percentage. When both are set, a transfer must satisfy both. The percentage still applies to the net flow, so assets moving out and back don’t consume the limit. The absolute amount applies to the gross flow in each direction, independent of flow the other way. ## Tokens Routed Through Another Chain The contract decided whether an incoming token was returning to Osmosis by checking that its IBC path started with the counterparty’s channel ID, without requiring a separator after it. A channel numbered 8 therefore also claimed tokens whose path started with channels 80 to 89, which belong to other chains. Any such token was rejected as if a rate limit had been reached, at any amount, whether or not a limit existed. The check now requires the full channel ID, and it uses the counterparty’s port as the IBC transfer module does, so a token returning from a counterparty contract that speaks IBC from its own port is recognised as returning. ## Administrative Hardening The administrative messages used by the IBC Rate Limit Setting subDAO are validated more strictly. A change that names a limit which does not exist, restricts an asset to no channels, or contains a misspelt field now fails at execution rather than passing silently. Percentages above 100 are honoured as written when an absolute limit is set alongside them, and channel restrictions match an asset in either of its spellings. The contract also accounts for transfers that fail or time out more precisely, and it stops keeping an empty entry for every asset and channel it has ever seen. The roughly 780 entries already left behind are harmless, and this upgrade clears them after a housekeeping message anyone can call in small batches. # Benefits Bridged assets with an external mint authority and a small supply on Osmosis can carry a limit that means something, set in the asset’s own units rather than as a share of a supply that an incident can inflate. The absolute limits are opt-in and will be proposed separately through the IBC Rate Limit Setting subDAO, starting with those assets. Tokens forwarded to Osmosis through a third chain are no longer rejected on channels whose number is a prefix of another channel’s, which has blocked stATOM and stINJ arriving from Injective for the Stride redemption flow. Mistakes in subDAO proposals fail at execution instead of passing silently, so a typo cannot leave a limit unchanged or unprotected without anyone noticing. # Concerns This migrates the live safety contract in place. The contract was reviewed in several independent rounds during September and October 2026, with every finding resolved before the bytecode was finalised, and the contract’s own test suite and the chain’s IBC middleware test suite pass against the exact bytecode in this proposal. The upgrade was rehearsed twice: on the Osmosis testnet (osmo-test-5, code 13378) through testnet governance, and on a fork of mainnet state with the exact proposal message, where the migration reported the expected results, every configured limit, role and restriction was unchanged afterwards, the Injective stATOM transfer that mainnet rejected was accepted, and the administrative changes behaved as described. All configured rate limits, the roles held by the IBC Rate Limit Setting subDAO, and the channel restrictions carry over unchanged, and existing limits behave exactly as before. Osmosis governance remains the only entity able to migrate the contract. Absolute limits count gross flow, so repeated legitimate round trips consume them and a tightly set bound will be reached by legitimate bursts before anything else. They should be sized well above an asset’s normal volume per window, and the IBC Rate Limit Setting subDAO can reset a limit that legitimate activity has reached. # Verification Source: [osmosis/x/ibc-rate-limit/contracts/rate-limiter at main · osmosis-labs/osmosis · GitHub](https://github.com/osmosis-labs/osmosis/tree/main/x/ibc-rate-limit/contracts/rate-limiter) Commit [`b4e727c8917d44dc3029fc33e59f71d3b3954d1f`](https://github.com/osmosis-labs/osmosis/commit/b4e727c8917d44dc3029fc33e59f71d3b3954d1f). Checksum: `43073f26b1552749c1f86c80302bc97a1b551e8ef8738c7acbe6b5574d64ddd2` Compiler: `cosmwasm/workspace-optimizer:0.12.10` **Target Onchain Date** : 30th October 2026