[Proposal] bLuna upgrade

So I read the whole thing, but my smooth brain had trouble comprehending part of it.

Are we replacing bLuna with stLuna?

1 Like

No, not at all. stLuna is just added to bLuna as an alternative representation of staked Luna. So while bonding your Luna with Lido you can choose what type of asset you want to receive: bLuna or stLuna. Or you can exchange any amount of your bLuna to stLuna (and vise-versa) directly with a Lido’s smart contract (and no DEX’es are needed for it). So the upgrade of the contract will be completely smooth for all bLuna holders and bLuna will continue to work, there are no plans to replace it.

1 Like

Okay gotcha, thank you for clearing that up for me!

1 Like

Is there going to be a mechanism that qualifies the validators that the bLuna will be staked? If so, what will that be? Uptime, Community Engagement, Etc. My main concern is that if this mechanism doesn’t exist, this upgrade can be taken advantage of.

2 Likes

bLUNA validators have been whitelisted. I imagine stLUNA would function in much the same way, with the stake being spread over all whitelisted validators.

1 Like

Yes, we have a draft of the document with the requirements for the validators — it will be published in the nearest future. For now, rules are based on performance mostly (rates of skipped blocks and missed oracle votes), because it’s the thing the amount of the rewards is dependent on. But we are also now working on improving the participation of our validators in Terra governance.
It’s just not the part of the current proposal just because it’s already a pretty big one

1 Like

That’s correct, bLuna and stLuna are both based on exactly the same set of validators.

1 Like

what is the fee, what are the limits. and who gets to decide.

does this remove the ability for the ANC governance to remove tokens from Lido.
What protections are there for ANC stakeholders.
Do we need to/should we have the ability to approve contract upgrades?

2 Likes

The open-ended fee in the proposal needs to be addressed. Allowing the proposal to pass as currently worded “Adding the possibility to take the Lido fee (initially set to 0%) from the rewards.” is too vague. There should be another vote to determine that fee.

Also should there be a fee, since the premium Lido makes on the staking return is in a sense a fee paid by Anchor.

2 Likes

There are currently some good validators that contribute a lot to the Anchor Protocol community users and if generally the validator will get more staking with them because of their contribution, eg Terra Bites, Smart Stake, etc… If users can’t delegate to them, then there is no incentive for validators to provide value added services? It is good to not let users choose validators as there has always been a concern for balance among the validators so that no validator gets the majority votes. How can there be continuous incentive to validators who value add to the community?

2 Likes

what is the fee, what are the limits. and who gets to decide.

Our thinking is that Anchor has to have a set of requirements for bLuna that Lido is obliged to meet on the risk of delisting. Lido gets to decide the Lido fee, but it has to do so within a framework of standards for bAssets that Anchor is free to set.

Zero percent fee after the upgrade is specifically to allow Lido and Anchor to work out a set of standards on bAssets that works for both.

does this remove the ability for the ANC governance to remove tokens from Lido.
What protections are there for ANC stakeholders.

I’m not sure I understood your question properly. Do you mean the bLuna unbonding mechanics (that is remains the same) or do you mean an ability for Anchor to de-list Lido’s collaterals (bLuna/bEth)?

Do we need to/should we have the ability to approve contract upgrades?

Regarding the question about contracts upgrades: the answer is the same as above (no double-governance, but a set of terms). We think Anchor should have a “you have to be at least this tall” approach to whitelisted tokens but should not interfere in the nitty-gritty details of the relevant project’s operations, exactly like it works with other DeFi lending protocols.

1 Like

The fee size is a separate question and not the topic of that vote. As I said in my answer to @PFC, there will be another vote regarding rules for bAssets.

Lido doesn’t make any revenue from bLuna currently, it doesn’t have a fee in any sense. We maintain the bLuna (and stLuna) protocol by supporting the set of validators (monitoring their performance and keeping it high), keep the protocol decentralization, and work on protocol utilization (integrations in other protocols/providing liquidity).

1 Like

That’s the good point. But if you take a look at the current distribution, you’ll see that Smart Stake has only ~1.5% of current bLuna delegations. So in practice, the change we’re proposing now will actually be in favor of these node operators. Many users are most likely to delegate their Luna’s to the validator with a larger amount of stake rather than analyze validators’ community participation, which is bad for decentralization.

In the long run, the stake distribution rule should be more nuanced than “flat distribution” (we’re working on that but it’s not simple). “Let the user choose on bonding” is not a better option, though - strictly worse in practice.

3 Likes

Thinking about the Nakamoto coefficient and the top 7 validators containing 25% of voting power; if bLUNA/stLUNA will be evenly distributed across all validators for staking, that doesn’t fix the voting power problem. Would it be possible to distribute evenly among the bottom 80% of validators?

1 Like

@kai - double governance, this sounds exciting to me!

I am glad the team has acknowledged Lido’s product and user behavior influence in Anchor. This [stLuna] seems more like a bLuna complement than an upgrade.

A few questions for you and the team:

  1. Is there an upper bound on the Lido fee? I agree this should be discussed by the Lido team but needs more shaping before being passed as is.

Second question regards this distribution below:

Is there a way to fix this by limiting the amount of delegation a single validator can receive? Or are you able to re-delegate as a validator?

Finally, addressing stLuna’s better fit in DeFi and for LPing - will this deter the use of bLuna overall? If so, would it create further deviation from the peg and spur a stLuna-bLuna arbitrage?

1 Like

In the end, we really hope LUNA and UST can truly go Decentralized so that it will always run on its own and all the nitty gritty issues can be ironed out. Of course in the perfect sense, Decentralization doesn’t exist but close enough.

1 Like

Yeah, you’re right that the distribution flattening of bLuna won’t fix the distribution imbalance in the whole Terra ecosystem. Nonetheless, that’s the first step and the Nakamoto coefficient will increase. Lido is worried about decentralization so our next steps will be aimed to keep it high.

However, the distribution of the delegations amounts to the bottom 80% is not the best solution here. Decentralization here faces stability. We can’t whitelist validators that have lower performance because it would harm the users’ yield. Also, whitelisting a lot of validators increases slashing risks a lot.

Finding a trade-off between decentralization and performance is a complicated task and Lido is working on that on each protocol Lido is running on. Further steps are to be made here, but this proposal is only about the first one.

1 Like

Is there an upper bound on the Lido fee? I agree this should be discussed by the Lido team but needs more shaping before being passed as is.

Smart contracts have no technical limit for the Lido fee. As referred in the proposal, we are going to make a separate vote on bAsset managing and that’s the place where the fee is going to be discussed.

Is there a way to fix this by limiting the amount of delegation a single validator can receive? Or are you able to re-delegate as a validator?

Limiting the amount of delegations is a bit more complicated solution than making the delegations distribution even: both on the technical and the organizational sides. So it requires more things to be done to implement it, but the current imbalance is an issue we already have and need to solve. As mentioned in the answer to smallfoot, this flattening solution is not the ideal one, but it’s a step in the right direction. Limiting the amount of delegations (e.g. not by the absolute value but by the rate) could be a part of the future design of delegation distribution.

Finally, addressing stLuna’s better fit in DeFi and for LPing - will this deter the use of bLuna overall? If so, would it create further deviation from the peg and spur a stLuna-bLuna arbitrage?

The other way round - it will improve bLuna-Luna liquidity and peg. Since bLuna and stLuna are just different representations of the same thing so it would be not the right thing to say that bLuna’s use will be deterred. So since stLuna is simpler for integrations and bLuna/stLuna liquidity is essentially infinite (because they are interchangeable), bLuna became more attractive to use. bLuna liquidity becomes more stable with stLuna pairs in LPs.

1 Like

What happens to the Luna-bLuna LP. Is a new pool opened with Luna-stLuna? How will that be affected?

given the advantages of stLuna, why would we still need bLuna or in another word, what’s the advantage of bLuna over stLuna ?