Proposed Initial Governance Structure for the RadixDLT DAO DUNA (RDD)

Governance Radix Community DAO
1

I’d like to call a simple vote (with commentary) to see if the community is onboard with the proposed governance structure. A simple yes/no vote will suffice. If you have additional comments/concerns, please note them as a reply to this message.

Worth repeating: We don’t want to burden ourselves by making this too complicated at first (i.e. let’s get running then iterate as needed) so keep that in mind when deciding. Also, any of the numeric values below are my initial recommendations and can be changed later through the governance process itself.

Membership in the DAO:
Individuals that own and control validator-staked LSUs and/or validator-owner stake LSUs

Planned Improvement Process:
Below is the expected normal process to be followed for proposals that the community decides are necessary and important.

Note: In the interim (until tooling is enabled to manage this process) we will be utilizing the consultation.radixdlt.com app to manage the general voting process. Granted, the existing consultation app measures votes based on a member’s XRD holdings instead of just their staked LSU holdings, but for the purposes of moving forward quickly the RAC (see Radix Accountability Council (https://radixtalk.com/t/proposed-radix-accountability-council-rac) will work with the Foundation to set up any proposals they feel are needed during this transition time period.

  1. Anyone, both Members and non-Members, can create a topic for a recommended improvement in the governance channel on RadixTalk. These are considered a Request for Comment (RFC).

  2. Once the details of the RFC have been mostly solidified, the creator can either make a simple poll in RadixTalk to gauge the community interest or create a non-binding poll in the (to be developed) “Temp Check” (TC) system.

  3. The TC poll will provide a weighted vote based on a snapshot of the quantity of XRD within each Member’s LSUs that they own (or have delegated to them) at the time of the poll’s creation.

To create a TC poll the initiator will need to own (or have delegated to them) a minimum of 0.5M LSU-equivalent XRD. (around $600 at today’s price) at the time the poll was created. Each poll will run for a minimum of 7 days, but no longer than 21 days (to account for holidays).

  1. If the TC poll passes a simple majority (with a 100M XRD minimum quorum), then a formal recommendation can be made in the (to be developed) Request for Proposal (RFP) system.

If, however, the TC poll fails then the creator probably needs to repeat the process and engage in further convos to a) refine the proposal to satisfy the larger community; b) petition more people in the community to vote (if the quorum hasn’t been reached); c) provide more clarity and/or details; or d) abandon the idea at this time.

  1. Creating a poll in the RFP system will require the initiator to own (or have delegated to them) a minimum of 2M XRD ($2400 at today’s price). The poll is open for a min 7 days / max 21 days.

  2. If the RFP vote passes a simple majority (with a 500M XRD minimum quorum) then the Radix Accountability Council (RAC) will engage to ensure that the execution of the RFP happens within a reasonable time period.

  3. If, however, the RAC determines that the approved RFP violates the goals, charter and/or principles of the RDD e.g. illegal, unworkable…etc. They have, at their discretion, the option NOT to execute the RFP. However, the RAC is legally required to provide a justification for why a given RFP will not be executed.

Normally, these objections to an RFC should happen much earlier in the process (steps 2 or 3 above). However, if it is the will of the community to execute the RFP then the final vote must be at, or higher, than 75% approval and with a 1.5B XRD minimum quorum (which is roughly 35% of the total XRD staked currently).

If the RAC still refuses to execute the approved RFP then they are legally bound to follow the “No-confidence” process whereby the community will immediately begin the selection process for a different group of RAC members.

  • I agree with the general governance structure.
  • I DO NOT agree with the general governance structure.
0 voters
5 Likes
CLOSED: Proposed Radix Accountability Council (RAC)
2

The only thing that i change is the time for vote . for simplification i will go to a fixed amount . 7 days. Easy and enoght from my point view.

3

@Peachy please check out what I shared here Naming / Terminology

1 Like
4

Yeah, I like it.
I believe the only adjustment to the above would be the RAC:
From: Radix Accountability Council
To: Radix Administrator Council

I borrowed the Accountability group name from Uni’s DUNA, but let’s stick with the legal boilerplate for less confusion.

1 Like
5

Can you share more on how you landed on “council” vs just adding an “s” to Administrator?

From skimming the definitions in the DUNA pdf is uses “member” and “administrator”.

From how the conversation has gone it seems like the administrators will be the ones on the multi-sig and be responsible for executing the proposal.

6

No problem. It was primarily borrowed from Uni’s structure: Uniswap Accountability Committee (UAC)

The link below provides a solid summary for the various entities and roles with the Uni system of governance.

From the reading you’ll see 3 entities: UL(Labs), UF(Foundation), and UAC(Committee).

Based on our current size, I don’t believe we need such a complicated structure initially so I’m suggesting we roll all 3 of the entities and their various duties and responsibilities into the RAC (our UAC).

If we decide later (or if Cowie suggests segregating them) then we can propose that structure, but I don’t want to over complicate things if we don’t have to.

3 Likes
7

First of all, Thank you Peachy, Jon and all for taking this initiative !

All good for me and voted, but we need to also specify how should we handle the address exclusion list ?

1 Like
8

Thanks!

I’d propose revising the Membership requirement (as currently listed below)

to:

This is covered in the DUNA legislation
|

image
image841×555 13.3 KB

1 Like
9

Are we going to take on tracking all the LSUs / XRD that comes from those block listed accounts? Meaning if we block account ABC but the person behind that account wants to vote - they could send XRD to a different account they control then get LSUs and vote?

1 Like
10

  1. Never let perfect be the enemy of good (enough). We won’t be able to stop all of the shady efforts that people will try, but we CAN give it our best effort to do so.

  2. If the Administrators (or community) feel that a vote was somehow rigged based on such shady efforts they can, as part of their responsibility, choose to void an RFP from execution until such time as a new RFP can be presented after potentially removing certain bad actors.

  3. Also remember the timing: The person can’t merely move them quickly to a new wallet. They would have to
    a) Unstake existing XRD from validators (7 days)
    b) Claim them
    c) Restake on new validator(s)
    d) then have that completed by the time the RFP vote is presented

    It’s not perfect, but it does imply they’d need to be highly proactive to insert themselves into any specific vote.

3 Likes
11

Except if they happened to stake to a good validator … they can use C9’s and other equivalent option for “instant unstake” … get the liquidity immediately minus the very small fee, stake in the new validator … and there we go.

I have posted about this in TG initially.
Either all vals get support from said options (impossible, I believe, since it’s related to trust and risk management) … or we find a way to avoid this and level the playing field:

Make sure that any two votings have at least 8 days between them, is one way - *voids the advantage from staking to instant-unstake enabled validators*
Have proof-of-personhood as second requirement for voting - *but I have no idea how and if we any way to do this already.*

Also the moral hazard related to those platforms enabling the instant-unstake feature:

We need to make sure they can’t abuse the custodial temporary ownership of the LSUs to vote!

This would effectively mean double voting with same XRD/LSU and, worst, moral fraud, as although technically correct they are the owners of said LSUs at that time, they would know they would be abusing those votes.

I also mentioned that all of this would be minimized or perhaps even eliminated, regarding the platforms, if:

Snapshots for voting are immediately taken at proposal’s submit time
We actively exclude from snapshots any holders that are not simple wallets, i.e, programmatic/component containers and vaults.

Problem at large, though … is the actual possibility of censorship to begin with.
I don’t think we should enable any kind of blacklisting, it can backfire bad.
Instead, we must just make damn sure there are no loopholes and no edge cases to voting to begin with!

1 Like
12

If the snapshot is taken at the time of voting as you say, the LSU can’t be in the hands of two wallets simultaneusly. Even with Caviar’s instant unstake. Plus not sure there is enough liquidity to make a difference for the vote anyway.

As for the blacklisting, yeah, we have to be careful to don’t dig our own grave as they say, but from a regulatory point of view I think you need it, even if it’s more on the surface and can’t be really enforced technically. Current foundation has to comply also, so not sure how things would change here.

1 Like
13

Just to repeat Cyril’s message….Really impressed with all who have contributed these last couple of weeks, but a hearty pat on the back to Peachy and Jon Eric. You guys are saving this project like those jet ski surfer rescuers at Nazare. Feel a bit guilty about just hanging on to jet ski after getting wiped out on the big wave but delighted to give you as much support as I can. :heart_eyes:

7 Likes
14

To create a TC poll the initiator will need to own (or have delegated to them) a minimum of 0.5M LSU-equivalent XRD. (around $600 at today’s price)

Creating a poll in the RFP system will require the initiator to own (or have delegated to them) a minimum of 2M XRD ($2400 at today’s price)

Both of these complicate things immensely if you’re going the snapshot route. I would propose:

  1. Everyone can create a TC.
  2. Member(s) of the RAC can elevate a TC to an RFP.

You might think that this will create an enormous amount of spam TCs. I don’t think that’s an issue any more than spam RFCs. Only problem that I might see is a TC goes unnoticed, passes, and now the RAC needs to elevate it to a TC. My solution for that would be that the RAC can demand one extra revote if they deem the TC unsufficiently promoted. If after the revote, it passes and the RAC still refuse to elevate the TC to an RFP, they are legally bound to follow the “no-confidence” process.

Delegating this TC → RFP elevation duty to the RAC also reduces another problem: manipulating voting power through LSU borrowing. When someone knows they can promote a TC to an RFP on demand, and voting power is measured at the time of RFP creation, they can easily manipulate their voting power by borrowing LSUs only for when the vote starts. If the RAC can trigger the promotion at any time, this will be a lot more difficult.

1 Like
Process for: RFC --> TC --> GP
15

Not sure why taking a snapshot of a given epoch would be so complicated. Wouldn’t the system just recognize when a TC was created and then snapshot the given epoch at that time (not perfectly, but close enough)?

I’m ok with your proposed work around and would probably simplify it even further: The RAC would be the ONLY ones with authority to graduate any and all TCs to RFPs (i.e no automatic graduations), but I’d still like to understand the technical challenge for why we can’t limit it to certain holders based on their holdings (or delegated holdings).

Thanks!

16

The technical challenge is that you have to push the snapshot to ledger trustlessly, which isn’t possible.

We want TCs to be on-ledger, right? But, only votes (for, against, etc.) are recorded on-ledger, not voting power (which you would like to measure to be able to create a TC/RFP). The entire point of using snapshots to calculate voting power is that the calculations necessary to determine a vote’s result can still happen off-ledger (in a reproducible manner using on-ledger data, to still make it trustless). These two cannot easily be reconciled. You cannot easily push voting power to ledger trustlessly.

17

AFAIK, in Radix, we don’t really enjoy the same as EVM world? Meaning, not sure any node or arquive/gateway has all the relevant info at any given time?

So far, we are completely reliant on the FND’s “centralized” gateway APIs for this , so no, a “snapshot” in Radix is a very different beast from the EVM and Bitcoin world, I sus, but not certain.

18

Right … it’s not a clear cut, as I imagine it. Unless we implement a specific blueprint to host this? But since calculations and any validation/filtering/etc are done off-ledger … is it even worth it?

I wonder if we can’t really have an RE-supported way of accomplishing this … but I’m no dev.

19

Got it. That makes sense.
Thanks!

20

@Peachy @octo @projectShift @Vlad when you have time can you please review this Process for: RFC --> TC --> RIP

I wrote this in response to how the snapshot idea is getting complicated and a lot of the edge cases are being discovered.

2 Likes