mDAO proposal - Archive delayed unstake tickets after 2 months

[defivan]

i totally agree that inactive staked SOL in Marinade`s contract need to be either staked to receive rewards and benefit from it, adding profit to Marinade itself as well, or held in the wallet to support the chain

[nope]

tldr; more rev to protocol and user while maintaining users ability to not wait when they come back AND strengthening msol peg

another idea (which is similar to above) if people are unwilling to do nothing or crank withdraw to the slow unstaker. would be after X time moving the sol to the unstake pool.

I think this has basically no downside for marinade or for the user (as the original proposal does) in 99.9% of cases, but has some upside for both.

1. marinade currently makes more protocol revenue per sol in it’s unstake pool than in it’s stake pool.
   for january
   protocol staking revenue: 1,512 mSOL
   protocol unstake revenue: 253 mSOL
   staking pool size: ~6.2m SOL
   unstaking pool size: 150k SOL (average was closer to ~200k for jan so will use that)
   protocol staking revenue per TVL: 0.2439 mSOL/kSOL (kSOL meaning 1000 sol)
   protocol unstaking revenue per TVL: 1.26500 mSOL/kSOL

obviously unstaking demand is not perfectly elastic but to maximize revenue unstaking revenue efficiency should match staking revenue.

2. depeg events reduce trust in LSDs. mSOL should want to maintain a reasonable peg to sol when trading on the open market, else it defeats the purpose of being liquid. this has happened a few times over the last year and increasing the size of the unstake pool would help with this.

3. save on emissions. currently 47% of emissions go to the unstake pool (not counting DND) and much of the rest goes to other msol based amms. if the unstake pool was much larger msol liquidity is deeply increased. with this idea the unstake pool could be 10x bigger than it is currently AND it could be done WHILE lowering or removing emissions to the unstake pool entirely

4. low/no downside to user. 99.9% of the time if a user came back after a while having ignored their ticket they will come back being able to instantly get their sol (exception would be if the unstake pool happened to have been highly utilized the epoch user happend to come back) and would have MORE sol.

[luciotato]

Learnings from the delayed unstake proposal

• Some token holders expressed concerns about establishing rules for abandoned tickets, when there was no specific rules before for the case.

• Advisors emphasized that the main problem is exactly that: Rules are not explicitly stated right now, so these new additions are problematic. Biggest problem is imposing a new delay of 1-2 days to the user, even if it is understable for a reasonable person that a ticked abandoned for two or more month can be subject to restaking, that rule was not explicitly stated beforehand

• Even if it’s not probable that a 1-2 day delay on a 2 or more months old ticket would warrant extreme measures from the user, e.g. trying legal remedies, it could create dissatisfaction and cause the user to lash on the project in forums and social media

Moving forward

Points to Improve the proposal

1. Extend the amount of time we provide between communicating the changes and applying them. Make sufficient effort in communication so all users holding abandoned tickets have enough time to claim before the new rules are applied.

2. In case of Archived Tickets, instead of imposing more delay on the user at unarchiving, offer an immediate claim in mSOL tokens, equivalent to the Ticket SOL value. e.g. a 1000 SOL archived ticket can be immediately claimed as 1000 SOL in mSOL (for example: 916 mSOL valued 1000 SOL at the moment of claiming)

3. State an specific usage for the extra treasury inflow created by the restaking, for example:

   3.1) use the extra mSOL revenue for MNDE buyback and burn

   3.2) use the extra mSOL revenue to add to Staked SOL and slightly improve mSOL APY

   3.3) reserve the extra mSOL revenue for slashing insurance

   3.4) other options proposed in this forum by the Marinade Community

[gekonn]

If I approach the topic on what is the ideal flow for the users, it would go something like:

1. user unstakes with clearly presented cooldown
2. cooldown period passes
3. user gets all SOL unstaked into their wallet

• Transaction fees can be prepaid or deducted from the unstaked amount
• Crank exists to send all the unstakes manually if bot fails

This current complexity should not be presented to the user at all. Also, extorting 100% fees is still legally dangerous.
If the above flow cannot be developed easily, let’s just re-mint mSOL with normal fee structure and store it for the user in the contract to claim. Alternatively, unstake and add it to liquid unstake pool, but that adds complexity on its own.

[luciotato]

Is important to note that, in our case, the user ordered an unstake, there’s no expectation of more rewards. The last instruction we received was to unstake and then the user vanished unexpectedly.

In the posts of this thread there’s multiple reasons why sending SOL to user’s wallet is not a good flow.

There’s no extorting of 100% fees, because the last order was “unstake”, so there are no expectations of more staking rewards.

As an improvement/options to move forward, what to do with the proceeding from re-staking (instead of becoming part of the treasury) is left for the community to decide:

• MNDE buyback program
• add to mSOL APY
• other options proposed by the community

Note 1: Current status for this is “no changes” to the protocol, and so it has no specific risk. I mean not moving forward is also an option.

Note 2: If we re-stake we need to do something with the staking-rewards. User is not expecting more rewards.

[gekonn]

On UX where I have expertise to contribute, there’s your single opinion

1. UX: It sounds better to make it automatic, but most things that sound good on paper are different on reality. What you would get if you do it automatically, is a lot of users angry because their SOL “is gone”. If you do it automatically, without user intervention, the user could get for example a 10 SOL inbound transfer in their wallet out of the blue, 2 days after they ordered the unstake, and mixed with any other transaction the user was doing at the time, they don’t even notice… the next day they remember they are waiting for a delayed unstake, they go to Marinade… and their delayed unstake ticket is nowhere to be found! so they get angry and go to Marinade discord demanding their SOL back… etc…

and 2 general agreements with it from Spleen and Rnyhse. There’s also been a disagreement from Nope. This leads me to believe UX approach can be successfully debated.

Obviously, optimal would be to conduct a user testing with the direct to wallet approach and compare it with the current state to give a more conclusive answer. But without having one ready, we can go about it from first principles. Here are the few statements that can serve as UX lens to compare these 2 approaches:

1. Intuitive wins
   No need to introduce new patterns where existing patterns work well:
   Sending funds directly to users wallet is how to world works now. In a business or governance, you don’t have to make a claim (unstake) and then confirm claim it again (withdraw). You get the money automatically to your bank account. Anyone who ever canceled a bank account can evaluate. Similarly you don’t cancel Netflix subscription in two steps or make an item return in two steps. The second (money return) is automatic these days.

2. Simple wins
   While the transactions spam is a valid concern, sending to a wallet AND communicating the status of unstake in Marinade app can be don, in line with a UX pattern on over communicating on important action. Users can both have it easy and have a space to go make a check.
   I suggest listing each delayed unstake and having states for each claim
   1/ unstake XY in progress, cooling down the stake, eta 2 days
   2/ unstake XY in progress, stake cooled down, will be sent in the next batch, eta 4 hrs
   3/ unstake XY finished, sent with Transaction ID, find your SOL in your wallet
   These states be simplified and visualized well.

Further reasons to keep it simple could be

• Marinade app can change and finding the claim now can be even more stressful for a user.
• DAOs/Multisigs unstaking will directly get the result, no additional coordination for the multisig holders to unstake and claim

Imo UX was a misdirection here. The standing reasons would be costs on implementing better UX and running + maintaining it, and development priority - here it’s up to the team to decide.

[nope]

@luciotato

In the posts of this thread there’s multiple reasons why sending SOL to user’s wallet is not a good flow.

i feel there were multiple reasons why it is good UX and why the reason (you only made 1 bullet point about it) it’s not good a flow to you were not impossible to solve/make good.

@luciotato

Is important to note that, in our case, the user ordered an unstake, there’s no expectation of more rewards. The last instruction we received was to unstake and then the user vanished unexpectedly.

if you are renting someone a house, then ask them to move out, but you go into a coma and wake up in 2 years and they just kept using your house. would you not expect that they would still owe rent for that time.

[defivan]

@gekonn

Intuitive wins
No need to introduce new patterns where existing patterns work well:
Sending funds directly to users wallet is how to world works now. In a business or governance, you don’t have to make a claim (unstake) and then confirm claim it again (withdraw). You get the money automatically to your bank account. Anyone who ever canceled a bank account can evaluate. Similarly you don’t cancel Netflix subscription in two steps or make an item return in two steps. The second (money return) is automatic these days.

totally agree on this point. its always the best and most useful way for a user to make one step than two of them, especially when talking to such a simple action as unstaking of assets. by implementing this “intuitive move”, we can change the attention of user from claiming different not so needed steps rather to possibly finding another LP to stake or any other action, which will benefit the platform

[luciotato]

Another option to consider moving forward is:

• extend the wait to 4 months
• re-stake to improve network censorship-resistance…
• but keep the full mSOL for the user (including staking rewards)

Example:

1. user delay-unstaked 100 SOL on January, and forgot about it or lost the keys
2. on May (after 4 months) Marinade automatically re-stakes the 100 SOL, minting 91 mSOL and holding them in the contract for the user
3. user comes back on December, and they can claim the 91 mSOL (that would be valued 100 original SOL + 8 months Marinade APY)

[defivan]

@luciotato

• but keep the full mSOL for the user (including staking rewards)

this statement will both improve the network censorship-resistance and the appreciation of users on choosing Marinade Finance as their staking platform