Upload Persistence LiquidStakeRate Contract and Osmosis-Pool-Ratesync Contract for Redemption Rates

Proposal

This proposal aims to upload two contracts– 1) LiquidStakeRate Contract and 2) Osmosis-Pool-Ratesync Contract on the Osmosis chain to ensure trustless handling of scaling factors for stkToken Stableswap pools and enhance the reliability of stkToken price oracles when integrated with platforms like Levana or Mars’ protocol within the Osmosis ecosystem.

Context

The Persistence LiquidStakeRate Contract employs an on-chain module and interchain account (ICA) mechanism to facilitate the decentralized provision of redemption rates for Persistence’s stkTokens on the Osmosis chain.

The Osmosis-Pool-RateSync Contract leverages the functionality of the LiquidStakeRate Contract to streamline the updating process of scaling factors for stkToken Stableswap pools, including the stkATOM/ATOM pool. This automation eliminates the need for manual intervention and ensures trustless execution of updates, enhancing efficiency and reliability within the ecosystem.

The above contracts and the RateSync Module under these contracts are audited by Hexens.

Details

Persistence’s liquid staking mechanism operates through stkTokens, representing staked tokens managed by the Persistence Core-1 chain. Users can redeem their stkTokens for a corresponding amount of the underlying token at any given time based on the stkATOM redemption rate. This redemption rate, often referred to as the c-value, liquid-stake-rate or exchange rate, signifies the ratio at which a single stkToken can be exchanged for its underlying token. For instance, on the Persistence chain, 1 stkATOM may be redeemed for 1.24 ATOMs, indicating a redemption rate of 1.24 for stkATOM.

The LiquidStakeRate Contract leverages the Persistence LiquidStakeRate Module and ICA to relay redemption rates for Persistence’s stkTokens onto the Osmosis chain, ensuring decentralized dissemination of this critical information.

Additionally, traditional Stableswap pools maintain a fixed 1:1 ratio between the two tokens, which is suitable for USD stablecoins. However, Osmosis Stableswap pools offer the flexibility of adjusting this ratio continuously through a scaling factor. This feature is particularly relevant for stkToken Stableswap pools, where stkTokens appreciate in value relative to their underlying tokens over time.

Despite fluctuations in the market price of stkATOM relative to ATOM, the true value is determined by this redemption rate. For instance, consider the current redemption rate of stkATOM to ATOM, set at 1:1.24. The LiquidStakeRate Contract would transmit this redemption rate to Osmosis, where the Osmosis-Pool-RateSync Contract would utilize it to dynamically adjust the scaling factor or concentration ratio of the stkATOM/ATOM Stableswap pool.

Presently, updates to the concentration ratios of several stkToken Stableswap pools are managed manually through a multi-sig address controlled by the Persistence Labs contributors. The introduction of the Osmosis-Pool-RateSync Contract automates this process, ensuring timely adjustments without the need for human intervention.

We kindly request the Osmosis Community feedback on this proposal before it goes on-chain.

Next Steps

  • Take community feedback into account (if any)

  • Submit the Osmosis governance on-chain proposal for uploading these contracts

  • If the contract upload proposal passes and after the contracts are successfully uploaded, submit another governance proposal for transferring the Scaling Factor Controller of the stkToken pool from the Persistence multisig to the Osmosis-Pool-RateSync Contract

Contract information

Code repository: Github - GitHub - persistenceOne/ratesync-contracts

Commit hash: 93a9ca2529542654e8f2799a347083499095151f

Compiler version: cosmwasm/optimizer:0.15.0

Checksum:

  • LiquidStakeRate: 33d4183a9bc09e59274e83b9c9f3e8c2b58c0fdcda7e0974e375721597d6f337

  • Osmosis-Pool-RateSync: 6ca74ff9e4bce522e60cd0f60f3eb67dab3e2d27ed7f768ba8ba650afa35a385

Target on-chain proposal date: March 16th

4 Likes

Just to be sure to understand it correctly; it would effectively function the same way like Stride is updating the redemption rates I guess?

1 Like

Dear Osmosis Community,

This forum post is to share some important updates regarding the Ratesync Module contract, which we successfully deployed on the Osmosis mainnet last week following the Osmosis Proposal 758 approval.

Key Update: After the deployment, we received feedback highlighting the necessity for the contract to support the inverse of the value exchange rate (c-value) for stkATOM integration on Levana. In response, we’ve implemented changes in the contract to facilitate queries for both the exchange rate and redemption rate. These modifications are documented in this PR: fix(contract): Add changes for c value to redemption rate conversion by nabaruns · Pull Request #10 · persistenceOne/ratesync-contracts · GitHub

Moving forward, we have two potential paths to ensure these updates are integrated efficiently:

Contract Migration: This approach involves migrating the current contract, enabling the updated functionalities while retaining the same contract address for seamless Levana integration.

New Contract Deployment: Alternatively, similar to our previous procedure, we could deploy a new contract and initiate it through a store code governance proposal.

We are eager to hear your thoughts and preferences regarding these options.

Thank you for your continued support.

Contract information

Code repository: Github - GitHub - persistenceOne/ratesync-contracts

Commit hash: 7a4283beddd295eb9d06fefcbdad5c550cfa64ab

Compiler version: cosmwasm/optimizer:0.15.0

Checksum:

  • LiquidStakeRate: d236b94e91966ce710df5c0129b1352eb2d3404c30726fe936e255cb95fe1fe7

  • Osmosis-Pool-RateSync: c2653b4a954fbadcdd00e6cf548d0fb2760006f3e03722b6f92a0f9102a74a02

Is the address from Persistence not whitelisted?

A lot of the projects with the need like the ones from Persistence are covered via a whitelisted address which enables you to upload changes to the contracts when necessary.

Would that not be a more efficient route? Such that the address is whitelisted and the contract can be changed afterwards as a result?