This proposal suggests allowing the Marinade team to adjust the liquid unstake pool fee model for the next six months.
What is the rationale behind the proposal?
The latest reports showing unstake volume during the black-swan event and even business-as-usual show the Marinade’s unstake pool not to be operating capital efficiently and that the fee model could be reworked. As such, the team would like to test a couple of iterations of changing the existing fee model. This would be made after properly analyzing and backfilling the historical data to make informed decisions. Every change would be announced and communicated. To prevent voting fatigue with each model update, the proposal would grant the team the power to change liquid unstake pool parameters for a limited time.
It’s hard to say, but the change might not be only tweaking the minFee, maxFee, and liquidityTarget parameters. It could be looking into another equation to price the SOL against unstaked mSOL. Once we validate the new base model works better, we’ll have better idea of the following tweaks to test the performance. Maybe even a single change is everything that will be required. I think the team would much rather backfill the historical data, but if the backfill won’t tell the whole story, some adjustments might be needed to see it in action.
Does that mean the original fee model was not scaleable? Since this voting gives power to marinade to have multiple iterations, have a couple of questions:
Do we have an end-date to this (6 months) and revert back to the current fee model after the duration?
Will there be a fresh vote with the new fee changes (if a good alternative was found)? Does the community have the right to accept / reject the fee-change?
I think those are both fair points and could be included in the proposal:
Marinade team has 6 months to run experiments and try different models.
In 6 months, Marinade will either organize a vote to settle on a new model to be accepted by the mDAO, or revert back to the old model if a better model hasn’t been identified.
Well, I dont have high expectations, but as a current liquidity provider (shrimp size) I would like it to be as high as possible . I am used to see it around 3-4% (without staking).
But I assume the higher the APY the more attractive for liquidity providers.
No issues with giving the team some room for experimentation in order to optimize the fee model, but would it be possible to outline the anticipated changes and expected timeline/duration for said changes beforehand?
Surely you have a general idea of what adjustments you’d like to try and tentative plan going in, right? (ie if X occurs, we’d like to try Y, and so on and so forth)
Thank you all for your points. They’re reasonable. Let us use the rest of Q1 to plan this project in more detail and develop a more specific proposal with outlined changes before putting it to a vote.
We have created a new council vote in the Realms to set liquid staking parameters as follows:
Min fee: 0.01 %
Max fee: 9 %
Liquidity target: 106 k SOL
This means the pool would now be considered “full” with minimum fee (0.01 %) and would therefore start to be utilized by smaller trades.
After 3000 SOLs are traded, the fee would grow roughly to 0.3 % at which point the pool’s utility would be smaller (big fee => fewer swaps)
Under normal operations, around 3300 mSOL are usually cleared from the pool daily (if there is mSOL to clear). This change could make the pool advantageous even for small trades on any given day, therefore being more rewarding to LPs.
These changes are the first small experiment as part of this project and we expect to quickly iterate further - before (perhaps) coming up with a different model.
. I am used to see it around 3-4% (without staking).