PoolStakeBalanceUpdate and Reward Management about solido HOT 7 CLOSED

Hey @enriquefynn

I have attempted a detailed spec at https://github.com/ChorusOne/solido/blob/585944b1517e5cb2c43f7b918b93063d0d8d18cd/docs/dev-docs/fee-management.md

Let's catch up on a call tomorrow (6 May) to iterate this based on your feedback.

from solido.

Why does the stake pool need a cut on rewards / rewards authority?

The way I understand it, two things can change the stake pool balance:

• Deposits and withdrawals by Lido.
• External effects (staking rewards earned by the pool, penalties).

Lido can track how much it deposited and withdrew, so it can track assumed_stake_pool_balance, which is equal to true_stake_pool_balance - external_change. In DistributeFees, we can tell Lido the current true stake pool balance, so Lido knows the change due to external effects (which is hopefully positive).

If we only reset the assumed_stake_pool_balance to its true balance and do nothing else, then the exchange rate SPT/LSOL will go up, so effectively all rewards got distributed over LSOL holders. If we want to take an X% cut of the rewards, then Lido can mint new LSOL corresponding to X% of the SPT change, and distribute that to the accounts you mentioned (insurance, treasury, etc.). You could even make the distribution depend on the sign of the change: if the SPT change was positive, distribute as you mentioned, if it was negative, then only distribute the (negative amount of) LSOL to the insurance fund. (And if the balance of the insurance fund was insufficient, mint only as much negative LSOL as possible, and then the remaining loss gets collectivized.)

from solido.

Right.

That is another approach (infact, that was the original approach until @joncinque implemented Fees As A Percentage of Staking Rewards) - let me come back to that discussion - but first a clarification ...

What are you referring to in stake_pool_balance : are you talking about Stake Pool Tokens (SPT) or SOL in Stake (including the SOL earned as Staking Rewards)?

Note : If we switch off the Fees in the Stake Pool Program - the SPTs would not increase over UpdatePoolTokenBalance - only the SPT/SOL exchange rate will change (as a result of the change in Total SOL in Stake)

from solido.

What are you referring to in stake_pool_balance : are you talking about Stake Pool Tokens (SPT) or SOL in Stake (including the SOL earned as Staking Rewards)?

I was assuming that it’s measured in SPT, and that the balance goes up when rewards come in. But now that that’s not the case you can replace all SPT references in my comment above with SOL-at-stake, and measure the stake pool balance in SOL.

from solido.

Correct, so we already have code in the Stake Pool program - that updates the stake pool balance (in terms of SOL) - and can optionally distribute fees as Stake Pool tokens (unless Fee is set to zero).

With this approach, I am aspiring to use existing Stake Pool code as much as possible - and hence wrapping over the Stake Pool reward mechanism.

In general, when we caught up with Anatoly early on in the design process, we agreed that we will re-use Stake Pool code as much as possible. (as it is the more mature / likely to be more audited code).

Specifically for Fee Management, do you think there is a strong advantage to deviating from this approach? If yes, let's walk through the pros/cons once and consider it :)

I will list the pros for above approach (Approach 1)

Approach 1 : Leverage Stake Pool Rewards Mechanism

• We don't have to write additional code for computing latest Stake Pool Balance
• There is separation in which party has to concern itself with what exchange rate
  • the Stake Pool Program has to concern itself with the SPT/SOL exchange rate
  • the Lido Program has to concern itself with the LSOL/SPT exchange rate

Approach 2 : Switch off Stake Pool Rewards Mechanism

from solido.

Specifically for Fee Management, do you think there is a strong advantage to deviating from this approach? If yes, let's walk through the pros/cons once and consider it :)

The way the stake pool rewards and our reward distribution approach work became a lot clearer to me over the past few days, through reviewing the related PRs. My current thinking is this:

• It does make sense to split rewards into two: fees, distributed in stake pool tokens or stSOL, and the remainder of the rewards, that implicitly get distributed through the value increase of the tokens. The computation for how many tokens to mint for fees is not entirely trivial, the current version of the stake pool gets it wrong, but this will be fixed.
• The fees distributed in tokens are easy to split, no tricky computations here.
• The combination of both with need to exist somewhere though, I don’t have a strong opinion on whether it should live in Lido or the Stake pool, but given that the first part is already in the stake pool, it makes sense to keep it there, and it does indeed simplify the Lido code.

the Lido Program has to concern itself with the LSOL/SPT exchange rate

Lido has to concern itself with SOL too, because it receives deposits in SOL.

from solido.

Right, it has to concern itself with the SOL/LSOL rate - but that's at the time of deposits.

For fee management, the exchange rates in consideration are
a) SPT/SOL exchange rate - when the Stake Pool program distributes rewards, it takes care of this

b) LSOL/SPT exchange rate - the Lido Program can concern itself with just this (in the context of Fee Management) - given that the Stake Pool program takes care of the SPT/SOL exchange rate.

from solido.