Process for: RFC --> TC --> GP

Those are valid arguments. Thank you for providing the additional reasoning and explanation.

As such, I believe we should most likely put this up for another consultation vote.

Thanks again for taking the time to defend your position clearly and concisely.

1 Like

given this explation that could be reasonable to only use LSU. by the way that will reduce the total voting power. At the beginning of this new voting process there should be the highest participation possible and that does not mean that RFC/GP will be approved so easy. More, we could also think about RFC/GP that will require LSU only and other LSU/XRD given that there will RFC of various type (protocol improvement, gateway improvement, dapp grants, wallet improvement, validator etc etc)

At this point, I believe most relevant points have somehow been voiced by someone commenting in here.
All valid, that’s what a discussion is about and so thank you for that.

We do have a chicken and egg though: how are we going to vote on using XRD direct or smtg else?

How is the community do the voting of the voting method if it doesn’t have an agreed voting method to start with?

In this, I do believe we can’t escape using XRD direct to select the voting method :sweat_smile:
There is no way around it, if we want the selection to be legit and enforceable.

Much to my dismay, I think we might need to use the FND’s consultation to do this :sweat_smile:
Currently, it’s probably the only trusted-enough way to pull it out, so we can have this locked down and build from it.

Else we’ll be paralyzed in this, and that’s a no go.

Time to hit Adam with it?

1 Like

Using all kinds of XRD (unstaked, LSUs, LSULP) makes the most sense to me.

Snapshots indeed kind of prevent anyone from buying XRD to vote with, and then selling it immediately after voting. If a DAO administrator is needed to elevate a TC to a GP, no one knows the exact timestamp a vote going to start (except the DAO admin). Thus, to vote you basically need to always hold XRD (or derivative).

You might even want to include DeFi positions (e.g. LSULP/XRD LP positions). But doing that would become difficult, because every time you add an accepted source of voting power, you’d need to pass a proposal and change the snapshotting logic. So I’d say to not do that for now.

2 Likes

Yeah, makes sense that the two ā€œbaseā€ forms fit the bill: XRD and staking LSU.

So, how we go abouut this? this is smtg that we need voited out and closed afas … @Peachy can we approach Adam and the FND to use the consultation app for this?

And, for now, the snapshot logic would only allow LSUs from too 100 validators?

Snapshots can enable all and any of it:

XRD-only

Validator Staking LSU-only (with filtering to only top 100 validator set LSUs)

Both XRD and Validator Staking LSUs - Validator Staking LSUs can easily be converted to their XRD-equivalent value, as Octo explained.

Any other asset we may choose to use, fungible or non-fungible, in a mix or not.

I got your point regarding taxes, but using LSU is to ensure there is a stronger commitment into the network success.

Your point regarding XRD usage in defi is also valid and important, we need this usage. But the other side of the coin (and I beleive what Peachy means) is it also signal an opportunistic behaviour (ie: can be dump easily), as opposed to LSU (it can still be dump, but with a discount).

What if we consider both LSU and XRD holdings, but with a weight ? like LSU x1.2 and XRD x1 ?

1 Like

why restrict the vote to top 100 validators only ? It would be another headwind for new validators to gain stake ? As a member of the DAO, why would I stake in a non top 100 validator and have my vote ignored ?

The top 100 validators are in the top 100 because of the stake they have.

I suggested that because anyone could spin up their own validator to only get LSUs from it to then vote with them but have no intentions of actually having that validator support the network.

1 Like

Because rn, in Babylon, any validator bellow rank 100 is not participating in consensus, i.e., it’s doing nothing for the network and as such, staking to them also does not get you any rewards.
It’s utterly useless.

They are trying to reach top 100…. Also the 100 cap is purely arbitrary and should be removed when xian. I think it will be an added hurdle for these nodes to acquire more LSU from stakers if there is no vote attached.

in this case, instead of restricting the ability to vote from the top 100 validators, why not using a min threshold of LSU holdings ? for instance if less than 500k LSU holding, a wallet cannot vote. This way, it does not matter to which validator the LSU is staked to.

If we go for a XRD+LSU option for voting, this becomes void and pointless - simpler, less costly.
And it seems there’s a lot fo support for that mixed choice as well.

In Xi’an, that same 100 limit (or some other) will still exist, but per shardgroup.
What you have now is exactly that, btw, it just happens that we have only ā€œone shard-groupā€.

It’s not feasible to have an unlimited number of validators for a shard-group, as the consensus and communication overhead becomes dominant of performance and a bottleneck.
Hyperscale acknowledged that and was built for fast local shard-group consensus whilst optimizing cross-shard latency and load - both Dan’s legacy code and Foxy’s new rust code are heavily focused on that.

LSU are just wrapped XRD. There value in XRD can be easily calculated. Also since ā€œLiquidā€ Staking Units can be bought and sold I don’t think they signal a stronger commitment to network success.

1 Like

So here’s a question i have. If we use XRD for voting, when people start depositing their XRD on Centralized exchanges, they end up having Huge amounts of coins. Isn’t that a Risk for governance?
I don’t need to have XRD, I just convince enough people to deposit to my app, or whatever, and then I vote as I want with it? Coinbase, Binance, etc. can manipulate the governance easily without having skin in the game.

Generally I think LSU’s add more friction and commitment, even if LSUs are as well liquid, but you can find less LSUs on the market than you would find XRD flying around everywhere.

Regardless of what we choose, I think we need to simplify this nomenclature of naming these proposals from:

RFC > TC > GP…… to something more simple like:
Radix Voting: Phase 1, Phase 2, Phase 3…… and attach the naming explanation after.

Phase 1: Forum Post + Debate
Phase 2: Validation (Collect Minimum Votes)
Phase 3: Major Vote from All Community…….

Phase 4: Implementation (if Phase 3 is passed)

This is self explanatory without having to dig into details. Because with these TC, RFC, GP, it’s hard to remember which one is first and last, atleast for me, but I can imagine many will have this issue.

If you want smooth Participation and Engagement, we should reduce jargon as much as possible.

1 Like

snapshot should be done at the phase 1 ā€œforum posting timeā€.
So before discussions, no major mouvements based on the different arguments.
resources to be snapped: XRD and LSU

I like how Fox put it - Telegram: View @radix_dlt

Exactly. So if you attribute some voting power to a user because they have an NFT showing a lending position… and then you also count liquid XRD… then you are double counting

IMHO it’s not worth counting anything other than XRD/LSUs.

What’s not framed in the question is the fact that it will take 100x more effort and neverending quibbling and maintenance to support defi positions in all their current and future permutations.

On the other hand we could just use a simple model which requires no maintenance and will basically end up at the same division of weights anyway

Guess Foxy is way more effective than me communicating stuff ahah.
As l long as ppl realize it before voting, it’s all good.

I’ll say it again, even if some are already fed up with me on this: Validator Staking LSUs are not a clear cut as well, depends on where they are held.

But at least they only have one edge case :sweat_smile:

Initially I would think liquidity XRD/LSU should be counted along with LSULP. LSULP reduces some integration friction with raw LSU. They are easier to integrate into a dapp. They should be treated as LSU for voting as there used to be a large amount of LSULP holders. They used to be the largest contributer to TVL on defilama anyways Not sure about now. Eventually the DAO should be open to integrating XRD being utilised in large dapps. If Radix has a healthy DeFi ecosystem in the future, large amounts of XRD will be tied up in various dapps. This is will cause friction with users who are heavy DeFi users and also want there say in governance. I have seen this happen with other DAOs and voting. Snapshots should be sophisticated enough to figure out DeFi position. It doesn’t have to be with this way to start, but should at least be considered for the future.

1 Like