Proposal #157
Passed on 28 Feb 2022 with 99.6% of the votes for yes.
Yes
99.6%
100.0% without abstain
Veto
0.0%
of votes cast
Ended
28 Feb 2022
99.57%
of votes cast
0.41%
of votes cast
0.02%
of votes cast
0.00%
of votes cast
This proposal proposes that the chain elect to do a software upgrade to the [Hidden link] software tag of the Osmosis codebase on block height 3401000, which is estimated to occur on February 28, UTC 8:00PM. Block times have high variance, so please monitor the chain for more precise time estimates.
This upgrade adds the following features:
See more in the [Hidden link]
All nodes will require 64GB of memory. This must consist of a minimum of 32GB of RAM, while the remaining 32GB can be swap. For best results, use 64GB of physical memory. Note that this is double the recommendation for the Boron upgrade. Also note that the inclusion of wasm means that nodes must use amd64 to run.
Please refer to the following setup instructions on how to add swap (if needed), and how to configure cosmovisor to automatically switch binaries for this upgrade: [Hidden link].
Namely, configure cosmovisor to auto-restart. (Please note, you should install the v1.0.0 release of cosmovisor) Then either auto-download binaries or manually build & copy the osmosisd [Hidden link] binary to .osmosisd/cosmovisor/upgrades/v7/bin/.
If you do not wish to use cosmovisor, be prepared to upgrade at around 8:00PM UTC, February 28th if this proposal passes.
The Osmosis blockchain will halt when network reaches the halt height. Cosmovisor, if configured properly, will then switch the binary used to v7.0.0, and the chain will proceed post upgrade.
The proposal targets the upgrade proposal block to be 3401000, anticipated to be at Monday February 28th 8:00PM UTC. This uses a 1 day average block time of 6.46 seconds per block, derived from the Mintscan block explorer. Note that block times have high variance, so keep monitoring the time.
The upgrade is anticipated to take approx 120 minutes, during which time, there will not be any on-chain activity on the network.
In the event of an issue at upgrade time, we should coordinate via the validators channel in discord.
There is a testnet which full nodes can sync to, to test that they have setup cosmovisor correctly on a new node. See #testnet-announcements and #testnet-discussion channels in the Osmosis Discord.
In this upgrade"s superfluid module, you can stake LP shares for specific governance-approved pools. A "superfluid discount factor" parameter exists for the superfluid module to ensure stability in the early rollout of superfluid staking, the superfluid discount factor parameter is set to 50% in this upgrade. This parameter can be adjusted by Osmosis governance.
The user can designate one superfluid validator to delegate to for each superfluid enabled liquidity pool.
Here is an example for how it would work with ATOM-OSMO pool:
Condition
Result
100 OSMO * (1-DISCOUNT_FACTOR) = 90 OSMO.5% slash due to double signing, then 5% of your LP shares (5 OSMO, 2.5 ATOM) get sent to the community pool. Note that slashing amount does not take into account the risk factor parameter, and slashes the entire amount of superfluided LP shares. In essence, effective slashing rate increases to the lower the risk factor is set to.Lets now suppose the spot price in the pool changes during this epoch to be 1 ATOM = 1 OSMO, and your LP share changes to being (75 OSMO, 75 ATOM). Upon the next epoch, the effective staked OSMO amount will be calculated as 75 OSMO * (1-DISCOUNT_FACTOR) = 67.5 OSMO to reflect the change in the underlying OSMO amount of the LP token.
As the amount of OSMO backing the LP share increased (hence increasing the effective superfluid staked amount), the staking rewards will also increase.