Discussion on Migration of stkATOM from Ethereum to Persistence Core-1

[maajid]

Fellow stkATOM holders on Ethereum,

This is a discussion post to gather feedback for Migration of the current implementation of pSTAKE for liquid-staked ATOM on Ethereum (to be referred as stkATOM(ERC-20)) to the Persistence Core-1 chain (to be referred as stkATOM). Upon sufficient discussion with the community, a proposal incorporating all the feedback and suggestions will be created on the pSTAKE Snapshot space for the community to vote on.

Background

pSTAKE was early to liquid staking, with stkATOM(ERC-20) being the first implementation of a liquid-staked representative of ATOM. Back in 2021, the pSTAKE team decided to issue these tokens on the Ethereum chain due to the following reasons:

1. Absence of IBC in the Cosmos Ecosystem
2. No DEXs to bootstrap liquidity for staked ATOM in Cosmos
3. Lack of a DeFi ecosystem in Cosmos

Going ahead with the issuance on a Cosmos-based chain or the Cosmos Hub would not have achieved the true potential and promise of liquid staking.

Post the Mainnet launch of stkATOM(ERC-20); users were able to stake their ATOM to help secure the Cosmos Hub and receive liquidity on their stkATOM(ERC-20) via the stkATOM(ERC-20)/ETH pool on SushiSwap at the same time. But this breakthrough brought certain tradeoffs for our users:

1. stkATOM(ERC-20) issuance and burning on Ethereum was expensive
2. With the dual token model of stkATOM(ERC-20), manual claiming of staking rewards was expensive
3. Ethereum transactions were slow, thus degrading the user experience
4. Integrations with high-quality Ethereum-based protocols were a challenge, thus limiting further use-cases for stkATOM(ERC-20)
5. The reluctance of ATOM holders to use their assets in the Ethereum ecosystem due to high fees
6. The security risk of using the MPC pBridge (although well audited and secured by top PoS validators) to migrate between chains

These drawbacks were foreign to our users as they were accustomed to low fees, fast transactions, and a seamless user experience in the Cosmos Ecosystem. Despite this, stkATOM(ERC-20) managed to hit the following milestones at its peak:

1. $39M+ in TVL
2. 6,406 ATOM stakers on pSTAKE
3. $33M pool liquidity in stkATOM(ERC-20)’s pool on SushiSwap

But since then, the developments in the Cosmos Ecosystem have been exponential with AMMs and DEXs like Osmosis, Crescent, SifDEX, JunoSwap, Borrow and Lending protocols like Umee, Mars, Hard, and DeFi Infrastructure and Smart Contract platforms like Secret, Juno, Kujira, Evmos and many more.

To tackle the above-mentioned issues and offer our users a better liquid staking experience, we proposes the following Migration.

Migration of stkATOM(ERC-20) to Persistence Core-1

Migration Introduction

What does Migration mean?

The transfer of underlying staked ATOM from the Cosmos MPC bridge wallet address of the current implementation to the new staking wallet address within Cosmos.

Why is Migration necessary?

In the absence of Migration, there will be two existing stkATOMs that won’t be fungible as the underlying implementations, validator delegations, custody mechanisms, etc., would be different. The Migration will overcome the before-mentioned drawbacks of stkATOM(ERC-20) and will empower our users with an IBC-native stkATOM that leverages the Cosmos tech stack and the vibrant ecosystem.

Parameter	stkATOM(ERC-20)	Post Migration stkATOM
How it works	User deposits ATOM with pSTAKE to mint 1:1 pegged pATOM. User interacts with Ethereum Smart Contract to burn pATOM which issues 1:1 pegged stkATOM	User deposits ATOM with pSTAKE to mint stkATOM on the Persistence Core-1 chain
Token Model	Dual Token	Single token Exchange Rate (cToken)
Custody	Semi-custodial because of the MPC pBridge	Non-custodial solution powered by Inter-Blockchain Communication, Interchain Accounts, and Interchain Queries
Security Risks	Protocol-level and MPC pBridge	Protocol-level
DeFi Utility	Very limited	Persistence’s role as the liquid staking hub along with integrations with established protocols in Cosmos will drive high utility to stkATOM
Validators	6 MPC pBridge and PoS Validators	More decentralized—to be defined but will still be at least 3-4 times larger than the validator set of stkATOM(ERC-20)
Staking Rewards	13.5% APR	Will match rewards on-chain
Rewards’ Claim	Manual claim of staking rewards in the form of pATOM	No need to claim rewards as they will directly accrue to stkATOM and will be auto-compounded
Chain Fees	Very high	Very low
Security Measures	Audited by ConsenSys Diligence, Oak Security, and Trail of Bits	Audited by Halborn at launch with more audits in future, Bug-Bounty Programs and On-Chain tracking

The Migration of stkATOM(ERC-20) to stkATOM will transfer merits such as enhanced UX, low-cost and fast transactions, higher security, IBC interoperability, and more excellent utility to our existing users.

Migration Overview

We want the entire Migration process to be as frictionless and seamless as possible for our users. In line with that, we suggest the following three options to go ahead with the Migration. After sufficient discussion, the best possible way with all feedback points will be put as a pSTAKE governance proposal.

Option 1: Create a Migration utility

The first way is to build a Migration utility from scratch that goes live on the pSTAKE web app.

Steps involved

1. Finalize a Migration start date

2. Give our users a month or two to unbond all their assets before the Migration start date should they not wish to go through the Migration utility

3. Pause deposits on the pSTAKE interface and smart contracts such that no more stkATOM(ERC-20) is minted to ensure no more Migration liability is added to the protocol

4. Change the pATOM reward rate to 0% to not issue any more staking rewards to users, disincentivize users from holding stkATOM on Ethereum and ensure no pATOM is issued that is not backed by actual ATOM rewards (Please note users will not be losing out on any of their rewards - the complete mechanism is explained below)

5. Collect pATOM reward data: The data of all pATOMs that are not minted by users yet (unclaimed staking rewards) will be collected and stored in a database and mapped to users’ ERC20 addresses

6. Upgrade smart contracts to pause transfers of pATOMs to other addresses: All unclaimed pATOM rewards will still be mapped to users’ ERC20 address’, and the underlying ATOMs in the native chain deposit address will be allocated directly to the users. All claimed pATOMs would be required to be redeemed for ATOMs. Please note that the pATOM contracts would not be paused to allow users to withdraw their staking rewards

7. Unbond ATOMs to start the Migration unbonding period: After completing all the above steps, a transaction to unbond all ATOMs from the designated deposit wallet address (DDW address) will be created and signed by all the pBridge validators to ensure no further rewards get generated. Any transaction that deposits any new ATOM in DDW address would be reverted to the depositor’s address directly

8. Cover our protocol users’ staking rewards in the 21-day unbonding period: The pSTAKE treasury will use its ATOM holdings to cover the rewards that should have been generated had the above step 7 not taken place

   1. At the exact time of the proposal voting period end (assuming the proposal passes), a snapshot of the Total Value of stkATOM(ERC-20) (referred to as stkATOM(ERC-20) TVL) and user balances will be recorded

   2. The 21-day reward for the stkATOM(ERC-20) TVL at the last existing reward rate before changing it to 0 would be calculated

   3. The staking rewards per user would be automatically added to their staked balance when the pSTAKE protocol stakes underlying ATOMs on Cosmos via the new designated deposit wallet address (NDDW address). The rewards would be added to our users’ balances in proportion to their stkATOM(ERC-20) holdings

      For example, if the stkATOM(ERC-20) TVL is 500,000 ATOM, then the total rewards that pSTAKE will reimburse to our users will be → 500,000*13.5%*21/365 = ~3884 ATOM. This will be distributed to the users on a prorated basis.

9. Move unbonded ATOMs to the NDDW address: Upon successful undelegation of ATOMs, funds (stkATOM(ERC-20) TVL + 21-day staking rewards) will be moved to pSTAKE’s NDDW address. The pATOM rewards already claimed by our users can still be withdrawn to their native chain wallet. Thus, they will remain unstaked and on the bridge / DDW address. Users can claim them back into their Cosmos Hub wallet when doing the Migration

10. Stake all ATOMs with the new implementation (stkATOM) on Persistence post product launch: All the ATOMs transferred to the NDDW address will automatically get staked, and new stkATOMs would be minted and issued to a defined Persistence address. This address (Migration stkATOM holder address) will temporarily hold the newly minted stkATOMs on the Persistence chain for all the stkATOM(ERC-20) holders. Users would have to make a transaction on a Migration UI page on the pSTAKE app that burns stkATOM(ERC-20) and transfers stkATOM from the Migration stkATOM holder address to an address provided by them

Pros

1. Users would have sufficient time before the Migration process starts, which gives them an option to unstake should they not wish to go ahead with the proposed migration flow
2. Code for the Migration utility would be highly optimized to cost lesser gas fees versus performing the same actions individually
3. Users would perform a single transaction to migrate their stkATOM(ERC-20) to stkATOM resulting in a frictionless user experience
4. The pSTAKE protocol would retain its power users who believed in ATOM liquid staking and pSTAKE right from the start
5. Users won’t miss out on staking rewards during their 21-day unbonding period

Cons

1. Extra engineering efforts for the pSTAKE team (note that the development of this utility has already been started and will be audited in anticipation of this option being the most viable one)

Timeline

The proposed Migration flow has two vital events that influence the timeline:

1. A one or two-month period for users who do not wish to go with the Migration flow to unbond their assets
2. 21-day Migration unbonding period

Migration at stkATOM launch

This means our users would be able to have their stkATOM(ERC-20) transferred to stkATOM on the new product launch day itself. It would require a buffer of ~50-80 days before the launch of stkATOM. This means fixing a launch date ~7-11 weeks prior. This might not be feasible and carries risk due to the following reasons:

1. It is tough to predict, let alone fix a launch date that early
2. In the event of a delay in launch due to any reason, the pSTAKE protocol would end up holding unstaked ATOM of users
3. The current development of stkATOM is only a few weeks from launch (no confirmed launch date yet)

Migration post stkATOM launch

This means our users would be able to have their stkATOM(ERC-20) transferred to stkATOM a few weeks after the new product launch. We think that this option is more secure and feasible for the following reasons:

1. No dependency or connection with the stkATOM launch
2. Sufficient time to discuss the Migration and for the two above-mentioned vital events to take place
3. No risk of custodying users’ ATOMs in any case

Keeping the security of our users’ assets in mind and giving them a choice to go ahead with the Migration or not, we propose that the Migration happen post stkATOM launch.

A proposal for the Migration will be posted after incorporating feedback from all stakeholders. If all stakeholders are well aligned, this can be done as early as two weeks from writing this post. If the proposal passes, it will give users a fixed amount of time (one or two months) before the Migration start date to unbond their assets if they do not wish to go ahead with the Migration. After which, steps 3-10, as mentioned above, would be followed. This would mean that our users receive their stkATOM 2-6 weeks post-launch, depending on the time for vital event 1 mentioned above.

Risks

1. Call Failures

   There might be a possibility that a call from the Migration UI to a smart contract fails in one of the operations mentioned above in the Migration steps (possibly because of gas). If a call fails, all state changes are reverted to before the transaction, and the gas is burned. If this happens, you would have to redo the transaction

2. Migration stkATOM holder address

   The Migration stkATOM holder address will temporarily hold the newly minted stkATOMs on the Persistence Core-1 chain for all the stkATOM(ERC-20) holders. This introduces a risk of custody. Hence, this address will be a multi-sig wallet to help mitigate centralization and custodial risk

From a stkATOM(ERC-20) user’s perspective

Option 2: Leave it to our users

Steps involved

1. pSTAKE launches the new product (stkATOM)
2. Users manually unbond and wait for the 21-day unbonding period
3. Users transfer their underlying ATOM back to Cosmos to stake with pSTAKE to mint new stkATOM

Pros

1. Users will have complete control over what they want to do

Cons

1. Turndown of the old product will be delayed
2. Users would miss out on staking rewards during the unbonding period

Risks

1. A delayed turndown could introduce security risk that might not be mitigated due to a shift in priority to the new product (stkATOM)
2. Unchained Security, a middle layer logic provider in the MPC pBridge, was acquired by Coinbase some time ago. They have given us an extension of 1 year on their service before they shut down all their existing operations. If all our users do not manually unbond their stkATOM(ERC-20) by then, the pSTAKE protocol will have to bear with the additional risk associated with the MPC pBridge

Option 3: Wait for Liquidity Staking Module by Iqlusion

Liquidity Staking Module will allow converting staked ATOM into liquid staked shares without unbonding.

Steps involved

1. pSTAKE launches the new product (stkATOM)
2. Wait for the liquidity staking module by Iqlusion to go live
3. Users convert their stkATOM(ERC-20) into liquid staked shares
4. Users stake these shares to receive stkATOM

Pros

1. More economical for the pSTAKE team
2. Users won’t miss out on staking rewards during their 21-day unbonding period

Cons

1. Major external dependency
2. Unclear timeline as to when the liquidity staking module would go live
3. Requires a chain upgrade

Risks

1. LSM will not be a battle tested feature from the get-go
2. Unchained Security, a middle layer logic provider in the MPC pBridge, was acquired by Coinbase some time ago. They have given us an extension of 1 year on their service before they shut down all their existing operations. If LSM does not go live by then, the protocol will have to bear the additional risk associated with the MPC pBridge

Conclusion

With this, we have highlighted what Migration is, why it is necessary, and possible options for how and when it would take place. We intend this post to be an open discussion with all stakeholders involved—our users, validators, and the Cosmos community members to provide their inputs to finalize a flow and timeline for the Migration of stkATOM(ERC-20) to stkATOM.

We would like to express that we are leaning towards the proposed Migration utility (Option 1) as it provides a one-click frictionless experience for our users and reimburses for missed staking rewards without compromising security. We believe these extra efforts from an engineering perspective will be a much smoother approach than the other two options and will be the most viable path for the Migration of stkATOM(ERC-20) to Persistence Core-1 chain implementation.

We hereby look forward to your feedback.

[proofofjk]

It seems like either Option 1 or Option 2 would be the ideal paths as then pSTAKE can take matters in their own hands.

Would it be possible to just track the users who have staked with old stkATOM and compensate them as they go through Option 2? It seems like Option 2 is the quickest to market which I think is critical.

[Iryna_Everstake]

We see the first option, which involves building a Migration utility, as the most efficient one from the users’ perspective. Extra engineering efforts must be worth the smooth user experience it will bring.
Even if something doesn’t go smoothly the first time, we believe that the Persistence team will resolve it asap and with minimum harm to the customers as they have a proven record of community first approach.

[cryptofit]

I think option 1 would be good for users, smooth UX plus users’ won’t miss out on staking rewards.Could you confirm if the new stkATOM minted and staked on pSTAKE will accrue staking rewards right after migration or will users miss out on these rewards after migration until they burn stkATOM(ERC-20) and claim for transfer of new stkATOM?

[roz_the_ghoul]

Option 2:
Do you have a good idea of who the users are? institutional? retail? Is most stKATOM in large quantities or smaller pieces? If there is a large known entity that is using it and could easily be contacted, it could be an easier route to take.

Option 3:
I wouldn’t count on the HUB to release anything in general. I’m not saying they are unreliable, but that is completely out of your control. If the LSM is never implemented then you’re out of luck.

Option 1:
This is probably the best option, but I think implementing the native stkATOM before launching the Migration tool would incentivize users to do it themselves instead of waiting. You may run into a situation where 50% of the users decided to unbond and transfer to the new native staking before the tool is complete which will give the team some extra time.

[maajid]

Noted. Thanks for the feedback.

No, users won’t be missing out on staking rewards on their newly minted stkATOM as it will follow a single token exchange rate (cToken) model. What this means is that staking rewards will accrue as a change in the exchange rate of stkATOM to ATOM. The burn transaction of stkATOM(ERC-20) will simply allow users to claim their proportionate stkATOM on Persistence without missing out on any staking rewards during the entire migration process.

[maajid]

Thanks for the feedback.

We agree that Option 2 would be the quickest to market in terms of execution as there won’t be any additional engineering efforts apart from the launch of stkATOM on Persistence. But this would also introduce some drawbacks:

1. A system to track individual unstaking of stkATOM(ERC-20) & corresponding staking of ATOM to mint stkATOM on Persistence for 2300+ holders of stkATOM(ERC-20) could be a problem logistically
2. Users might end up paying a whole lot in fees as opposed to going through a single click migration in Option 1
3. Not having a set and early deadline for Migration would expose stkATOM(ERC-20) to more risks, as highlighted in Option 2

Option 1 would ensure these drawbacks never come to life, and at no given point of the Migration would our users miss out on any staking rewards (during the unbonding period or any possible time interval after the unbonding is done and before a user claims their stkATOM). Although time is of the essence here, we don’t want to compensate on security and, at the same time, provide a smooth Migration for our users.

[maajid]

Appreciate your feedback.

Concerning Option 1:
By analyzing the stkATOM(ERC-20) Token Holders’ data on Etherscan, we can see that there a lot of individual holders. The top 100 holders collectively own 78.78% of stkATOM. This means that ~22% of the supply is distributed among ~2200+ holders. Another data point to highlight is that only ~40 addresses have 100+ stkATOM(ERC-20).

Concerning Option 3:
Completely agree. Although this option is more economical to pSTAKE, the biggest con is the external dependency on the HUB, as you rightly pointed out.

Concerning Option 1:
We think the key here is how long after the launch of stkATOM on Persistence is the Migration completed. If users can claim their stkATOM by burning their stkATOM(ERC-20) within two to three weeks after the launch, not only would they not have missed out on any staking rewards during this time, but they also have no security risk associated with there being a direct connection with the Migration & the launch of stkATOM on Persistence as highlighted in the ‘Migration at stkATOM launch’ section in Option 1.

[redmarauder]

As a stkATOM holder, I feel that Option 1 would be the best possible way for the Migration. Is there any estimate on how much gas fees would it cost? And when would the proposal for Migration be put up?

[maajid]

Thanks for your reply! Given that feedback so far has been positive about option 1, we are considering moving forward with it and will have more updates soon, including on timelines.

With regards to the gas fees, with a very conservative estimate of max. 5 mill gwei for the entire migration (all transactions included) we’d be looking at around 0.006 ETH per user or a little under $8 at the current exchange rate of ~$1300 / ETH.

[gandzi]

hi,
What happened to my STK Atom when I didn’t source unbonding on time. I didn’t do that at all. Only now I realized that the site: https://app.pstake.finance/wrap does not work https://app.pstake.finance/wrap. Please help.

[Vishal8798]

Hi there,
Kindly go through this tweet.
https://twitter.com/pStakeFinance/status/1631290283726864391?t=pUpOpQzjgaKL0f6A5Qpwog&s=19
Thanks.

[ayo]

Hi I checked out the migration utility, but it says i have 0 tokens, even though on metamask and other viewers it says I have about 30 or so stkatom erc-20 tokens or so. Just to confirm the address is 0x44017598f2af1bd733f9d87b5017b4e7c1b28dde?

[madhursatija]

Hey @ayo, can you please share your wallet address. If you are not comfortable here then please send a DM on telegram ID: @madhursatija

[ayo]

Hello, I tried to message you on telegram but it says I need premium? maybe you have a discord?