This proposal signals that Osmosis adopts wstETH via Neutron as the canonical version of wstETH.
Details
This proposal signals that wstETH minted via Neutron will be the canonical version of wstETH in use on Osmosis, replacing the current version that arrives as a representative of the token minted on Ethereum via the Axelar bridge.
wstETH currently exists on Osmosis via Axelar, however the bridging fees for token movements have led to this not being widely adopted within the Cosmos despite the increasing prevalence of Liquid Staked Tokens in the ecosystem.
wstETH on Neutron is minted as a wrapper contract that will serve as a bridge agnostic anchor for wstETH across the Cosmos. Initially, this will be integrated with Axelar as the provider and may be upgraded into a multibridge solution in the future without changing the denomination.
For further information on the technical implementation of wstETH on Neutron see this forum post.
Canonical status sets the following agreement:
Default Asset List – assets will be unprefixed in the app.osmosis.zone default asset list, e.g. wstETH with all other bridges’ assets being bridge1wstETH, bridge2wstETH, etc. Osmosis DAO requests that allied/friendly front-ends do the same, though any front-end is free to make its own decisions.
Osmosis Incentives – the DAO commits to prioritizing the Canonical Bridge assets, incentivizing them earlier and more heavily than the comparable assets of non-canonical bridges. In general, canonical pools should earn substantially more incentives per dollar of liquidity than their counterpart pools–under the base incentives model, not necessarily counting external incentive matching.
Target on-chain date: Latest of 11th September or Neutron wstETH launch
This is a good move, as it supports the standard Cosmos version of this token.
But what about taking it a step further and recognizing Neutron wstETH as the canonical version of ETH? For context, the canonical version of ETH is currently axlWETH.
The benefits would be: Neutron wstETH would require fewer OSMO incentives, since there would be no hurdle rate due to forfeited staking rewards. And if all OSMO incentives currently going to axlWETH went to Neutron wstETH instead, then there would be enough liquidity for Mars to support wstETH as collateral. And that’s a much more desirable collateral than sxlWETH.
The downsides would be: reliance on Lido.
But zooming out, wstETH is undoubtedly more attractive to hold and use than any form of unstaked ETH - since it earns staking rewards. And it’s looking like the default version of ETH on Neutron will be wstETH. So basically, it could end up that Neutron’s ETH liquidity is more attractive than Osmosis’ ETH liquidity, and so all DeFi involving ETH on Neutron could be more attractive than ETH DeFi on Osmosis.
So all things considered, I think Neutron wstETH should be the canonical version of ETH on Osmosis.
Very much a fan of using the Neutron wstETH as canonical, since it is in direct cooperation with Lido to get it natively on Cosmos (will it even be a full fledged wrapped version? or more stETH?)
Regarding making wstETH the canonical version in general; I wouldn’t go there. Some (no clue how many) people just hold ETH on the Ethereum network as well without going to a stETH version. So there is a need for plain, regular, normal ETH. Let’s just keep it at that on our side as well
The plan for canonical ETH on Osmosis is to create a transmuter pool with axlwETH and whwETH, and use the LP share of that pool as a canonical Osmosis ETH.
This helps ensure less bridge risk and lower overall fees. The Neutron version of wstETH will be bridged over from Axelar and deployed on Neutron (at least initially), meaning people wishing to migrate from wstETH on Ethereum to Neutron will be subject to Axelar’s exorbitant fees.
They might find it preferable instead to use Osmosis ETH to convert to wstETH by swapping from ETH potentially after bridging over via wormhole and adding liquidity to the transmuter pool. This would be nearly 10x cheaper than going via Axelar per the below screenshots. Having strong depth for wstETH / osmo.ETH still makes sense here, as well as having depth for osmo.ETH in general, as fewer people will be likely to bridge over using wstETH than one of the other sources of ETH, imo.
At any rate, definitely support this proposal as written. the extent of wstETH usage over ETH usage can be decided at a later point.
So yeah, Lido staked version is definitely the better alternative. 22% of ETH staked is crazy high compared to LST on Cosmos. Atom is currently at ~1% liquid staked. Still, I wouldn’t go with the LST version as the representation of ETH.
wstETH is not priced at 1 ETH. As it collected staking rewards, it’s price slowly drifts upwards, and thus framing that as the canonical ETH would be very confusing.
On top of that, it would be hiding not just the risk of Lido, but also the primary risk that staking derivatives somewhat dangerously try to downplay, the slashing risk!
Making users hold the slashing risk but calling it ETH (and thus not informing them of that) seems wrong to me.
Agreed that the slow drift upward would cause UX issues.
But bridge risk is much more serious than slashing risk, and Osmosis currently makes users hold bridge risk while calling it “ETH.”
In the same way that Osmosis currently calls axlWETH just “ETH” and thereby obfuscates bridge risk, it seems to me that it would be no different to call wstETH “ETH” and obfuscate the slashing risk.
My assumption here is that bridge risk and slashing risk are both very minimal.
And not to forget; we as “techies” are in the space right now and already confused by the prefixes.
If we want to breach markets outside the Cosmoverse and even beyond that to onboard crypto-noobs we must make the experience as smooth as possible. A lot of these people will simply not know / care about bridge risks and just want the easiest solution possible. Limiting risks and such should happen on protocol level. 99,5% of all people who will use crypto in the future will not know or understand the involved risks and should not be bothered with it imo.
