[Proposal] bLuna upgrade

Community Initiatives
1

TLDR

This proposal is about the upgrade of bLuna — the main bAsset of Anchor protocol.

The main points of upgrade:

  1. The user can not delegate to a specific validator. A new contract is added, the Validators Registry, that keeps the list of approved validators and picks the next most suitable validator to delegate to. This aims to distribute the stake evenly across all validators. (see Section 1)
  2. The new token is added: stLuna. It is interchangeable with bLuna (see Section 5) and corresponding rewards are re-staked. This token is made for better integrations across the ecosystem. (Sections 2—4)
  3. The possibility for contracts administrator to re-delegate Luna across validators so it could be fixed the current distribution imbalance in an artificial way rather than waiting for it to be fixed in a natural way. (see Section 1)
  4. The possibility to take the Lido fee (initially set to 0%) from the rewards.

All these points are aimed to increase the decentralization of the protocol and its utilization in the ecosystem.

bLuna is maintained by Lido and is, strictly speaking, not under Anchor governance. Given that:

  1. Wast majority of bLuna (9x%) is in Anchor protocol
  2. The majority of Anchor protocol collateral (88%) is bLuna
  3. The changes to the bLuna smart contracts code are pretty significant

We decided to have a double governance vote on this upgrade, as both protocols are co-dependent at this point in time. Double governance is not a tenable solution for all the future decisions around bLuna/stLuna contracts and other bAssets, hence this proposal will be followed in the near future by the one that will discuss and set the terms on which bLuna is integrated with Anchor and clean demarkation of governance power between Anchor and various bAssets maintainers.

Section 0. The proposal

The bLuna is the main bAsset in Anchor protocol:

  1. It has a ~88% of Total Collateral Value (the other 12% is bEth).
  2. bLuna TVL is ~2.8B USD (~68M Luna).
  3. ~20% of staked Luna is staked with bLuna.

While it is quite useful in Anchor protocol, it has a bunch of peculiarities such as uneven distribution and design decisions making it unwieldy to integrate with other DeFi protocols. To solve those peculiarities we propose the upgrade of the protocol. The main points of the upgrade are present above.

The code of contracts implementing all of the features is already written and the audit is made by Oak Security.

The current proposal consists of two parts:

  1. Transfer contracts ownership to multisig of 7 participants (with the threshold of 4) which include the representatives of:
    1. Anchor Protocol
    2. Delphi Digital
    3. Chorus One
    4. P2P Validator
    5. DSRV
    6. Staking Fund
    7. Everstake
  2. Upgrade contracts code to the new version.

The benefits of the upgrade are described below.

Section 1. Stake flattening

The new version of protocol keeps delegations to be distributed evenly between all the validators in the whitelist (point 1 in the list above). The user won’t have the ability to choose a validator. Such behavior should make both the protocol and Terra ecosystem become more decentralized.

Because of the huge delegation distribution imbalance (~60% of overall Luna staked with bLuna delegated on top-2 validators), it’s hard to fix it in a “natural” way (only with new delegations). So it made the possibility to make an artificial stake flattening (point 3 in the list above). All current delegations could be distributed between the validators evenly after the new version of protocol deployment. The details of the process are going to be put on the governance decision in the nearest future. The main idea here is to make the process not instant but prolonged in time so it would be more comfortable for validators.

The main question one could ask is that users choose a validator while minting bLuna and now their decision of choosing a validator will be ignored. The answer is that:

  1. Generally, bLuna minter and holder are different (because the purpose of the protocol is to make staking liquid).
  2. Minted bLuna tokens aren’t tied to the selected validator and all bLuna holders share risks together anyway.

Section 2. stLuna is more usable for DeFi protocols

The bLuna’s rewards have to be claimed by the users manually while interacting with the special smart contract. Any DeFi protocol which wishes to have an integration with bLuna (i.e. for landing) needs to deal with claiming rewards mechanism. It makes the integration process more complex and opaque.

Making the rewards being automatically re-staked (instead of claiming it manually) makes the stLuna token more usable in DeFi protocols. Integration became much easier because any other protocol doesn’t have to deal with rewards: stLuna underlying Luna amount just increasing with time (in case there are no slashing events).

Section 3. stLuna is good for liquidity pools

The rewards claiming mechanics also cause liquidity pools to be not so pretty for users. While bLuna is locked in the liquidity pool, rewards are distributed to the pair’s smart contract. That means that users are losing their rewards while staking pair to LP.

Because of that, the LP for bLuna is thin. That leads to a possible losing peg between bLuna and Luna. An example is liquidations on Anchor protocol that lead to a lot of bLuna-Luna exchanges made on TerraSwap. Because the cap was too small for such an amount of deals, bLuna price dropped to 0.88 Lunas for 1 bLuna.

bluna-luna
bluna-luna2022×818 95.7 KB

Anchor protocol made actions to prevent such a situation, but other DeFi protocols could skip it and keep bLuna/Luna peg brittle.

With stLuna, such a problem doesn’t exist because of the same reason described for DeFi protocols integrations. While stLuna and bLuna are interchangeable, it makes bLuna liquidity better (see Section 5 for details).

Section 4. stLuna works well with bridges

While bLuna token is passed through the bridge, the actual bLuna token is locked on Terra’s side of a bridge, while a wrapped version of bLuna is minted on the other’s chain side of a bridge. While bLuna is locked on the bridge smart contract, rewards are distributed to the bridge’s smart contract address. So rewards are not passed through the bridge automatically and the additional code should be written to support such a functionality implicitly. With stLuna, no rewards need to be passed through the bridge. One can easily get the stLuna/Luna exchange rate and understand how many Lunas he or she can get for the amount of wrapped stLunas he or she has.

Section 5. Instant bLuna-stLuna conversion

Because bLuna and stLuna are ruled by a joint set of smart contracts, it is possible to convert bLuna to stLuna and vise-versa with one smart contract call. It means that bLuna holders don’t need to unbond their Luna or sell bLuna through a market to get stLuna: they can make the exchange directly with the smart contract with no commission (except transaction fees). Same for holders of stLuna that want to get bLuna.

The big thing is that because stLuna and bLuna are interchangeable, there is no need to keep LP for both tokens: the LP for stLuna is enough to have to provide liquidity for both tokens. Even if there are no pairs for bLuna/Luna is present, the bLuna could be instantly swapped to Luna in two possible ways:

  1. With two separate transactions: the first one converts bLuna to stLuna (user pays for gas only) and the second one swaps stLuna to Luna on DEX.
  2. With one transaction made with helper contract, which makes two swaps in a row.

The webapp with the necessary functionality to make bLuna-Luna swap handy is to be released.

3 Likes
2

The quirks of bLUNA had caught might attention but I was unaware an alternative was being developed. Kudos.

1 Like
3

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

Are we replacing bLuna with stLuna?

1 Like
5

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
6

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

1 Like
7

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
8

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
9

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
10

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

1 Like
11

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
12

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
13

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?

1 Like
14

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
15

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
16

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
17

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
18

@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
19

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
20

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
21

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