Proposal #1058
100.0% of the decisive votes say yes, with turnout at 62.0% of the 30% quorum. If voting closed now it would pass. The largest voter, Keplr, says yes with 13.4% of the power.
Turnout
62.0%
quorum 30%
Yes
100.0%
100.0% without abstain
Ends in
23h 33m
04 Nov 2026
99.99%
62.00% of all power
0.01%
0.01% of all power
0.00%
0.00% of all power
0.00%
0.00% of all power
Reached: 30% of the voting power had to vote.
Yes needs over 50% of the votes that aren't abstain.
Veto at 33.4% or more rejects it and burns the deposit.
This proposal updates the IBC Rate Limit contract administered by Osmosis governance.
The IBC Rate Limit module is a safety control implemented in [Hidden link], intended to protect assets on Osmosis in the event of security issues with:
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.
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.
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.
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.
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.
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.
Source: [Hidden link]
Commit [Hidden link].
Checksum: 43073f26b1552749c1f86c80302bc97a1b551e8ef8738c7acbe6b5574d64ddd2
Compiler: cosmwasm/workspace-optimizer:0.12.10
Forum Thread: [Hidden link]
Validators and delegator accounts, counted one vote each.
17 of 30 validators voted, 100% yes. 911 delegator accounts voted on their own, 97% yes.
Each validator's vote, by voting power.
17 validators voted, together 61.7% of the voting power.
