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
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
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.
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.
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?
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 ?
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.
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.
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.
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
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.
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.