osmosis

Prop 763: Osmosis v24 Software Upgrade

This is a proposal to do a software upgrade to the v24.0.0 software tag of the Osmosis codebase on block height 14830300, which is estimated to occur on Thursday, April 11th, UTC 15:00. Block times have high variance, so please monitor the chain for more precise time estimates.

Upgrade Features

This upgrade primarily consists of fixes and improvements for the Osmosis codebase.

Please see the Full Change Log for a complete list of optimizations and any API changes.

User-facing upgrades include:

3 Second blocks, Implementing IAVL v1.0

The optional v23.0.6-iavl-v1 upgrade implemented a trial reduction to 4 seconds, with partial validator uptake. This has reduced block times to an average of 4.5s from 5s in v23.

This incremental reduction is part of an ongoing push to reduce block time on Osmosis to 1.5s to improve user interaction responsiveness.

This is partially backed by the implementation of an upgraded data structure for persistent storage, IAVL v1.0

Burn Mechanism for ProtoRev

ProtoRev accumulates OSMO, ATOM, and USDC by performing arbitrage on each swap performed on Osmosis against other pools.

Approved in Proposal 710, any OSMO obtained from this will now be burned by sending it to the Null address, reducing the maximum supply of OSMO over time from the 1 billion cap.

Approved in Proposal 709, any non-OSMO assets will be sent to the Community Pool to be used for further initiatives.

Fee Token Whitelist permissioned Address

Delegates control of the Fee Token Whitelist to a subDAO, allowing rapid addition of new listings to those accepted as fees on Osmosis.

Osmosis currently accepts 128 different tokens as payment for the transaction fee, which are then converted to OSMO at epoch for onward distribution to stakers.

These must undergo the standard five-day governance period, which causes friction with new listings. By delegating maintenance of this list to a subDAO, these tokens can be added concurrently with the listing process.

See this forum post for more details.

IBC Wasm Module Added

The IBC Wasm module enables the addition of new light clients for Osmosis, this allows the ability for custom light clients to be added by governance to allow IBC to extend past Cosmos SDK based chains and will play a pivotal role in realizing the vision of IBC as the TCP/IP for blockchains.

ICA Controller Added

Enables Osmosis addresses to perform crosschain transactions with a greater number of previously unavailable chains, such as the Cosmos Hub, Stride, and Noble.

Max Gas per Transaction increased to 60 million

CosmWasm uploads have encountered issues with the previous limit; this change allows each transaction to be far larger if required, allowing more complex contract uploads to occur.

Minimum Epoch Distribution

Approved by Proposal 733, this adds a minimum epoch reward value for Classic pool incentive distribution. This reduces the calculations to be performed at Epoch and, therefore, the time taken to process this block.

Uptime Incentives Redistribution

Uptime Incentives were implemented in v23 and set to one minute by default across Osmosis in Proposal 757. Positions modified under the one-minute duration forfeit the incentives for that period. These are now redistributed to other Liquidity Providers in the pool rather than transferred to the Community Pool.

Getting Prepared for the Upgrade

To build the binary, be sure to install golang 1.21. NOTE: Golang versions lower than this will not work.

As always, we recommend validators utilize 64GB of RAM. Since state migration is relatively negligible in this upgrade, it is possible to get away with less, but it is still not recommended. If you are unable to have 64GB of RAM, at a minimum, have a total of 64GB of swap set to prevent out-of-memory errors.

If using Cosmovisor, manually build & copy the osmosisd binary to /cosmovisor/upgrades/v24/bin/.

If not using Cosmovisor, wait for your node to halt at the upgrade height, then install and run the v24.0.0 binary.

IAVL Migration

If possible, please migrate to IAVL v1 in advance of the upgrade date to minimize the time taken for the v24 upgrade to be completed.

The preferred method is to download a pure v1 database from here under the IAVL v1 section (scroll down) or Polkachu, then run the minor release v23.0.8-iavl-v1.

Details of Upgrade Time

The proposal targets the upgrade proposal block to be 14830300, anticipated to be on Thursday, April 11th, UTC 15:00. Note that block times have high variance, so keep monitoring the time. See the countdown HERE.

The upgrade is anticipated to take approximately 30 minutes, during which time there will be no on-chain activity on the network.

In the event of an issue at upgrade time, we should coordinate via the validators channel in Discord to come to a quick emergency consensus and mitigate any further issues.