Governance tools and processes needed

Governance Radix Community DAO
1

I believe the governance app we need is very similar in model and scope to what Uniswap already has (i.e. don’t try to reinvent the wheel), but adjusted to meet our needs.

I’ve read what @bayesien posted here https://t.me/radix_dlt/965486 and I do appreciate the thought put into it, but we’ll need to dig into this more to understand if their tool can be adjusted to fit what I believe we need (as shown below) or maybe our solution can incorporate some of those suggestions (now or later) after we get up and running.

****Governance App(website)***

A place to post RFPs and have people vote on proposals based on their validator-staked holdings (LSU). The LSU needs to be shown as the XRD-equivalent quantity of XRD.

The app needs to allow members to delegate their vote to others as well (by % of their LSU XRD holdings so they can delegate to more than 1 person if they so desire).

Also, when someone delegates their stake to others it has a time limit of effectivity. So if I delegate stake to 5 people (e.g. 50% to 1 person and 10% to 4 others) then those delegations expire after 1 year (or whatever we decide). This ensures that delegators can’t just “set it and forget it”. This also requires those with delegated power given to them keep tabs on how their constituents view their behavior as their governance representative.

The app needs to show the history of RFP voting activity (numbered sequentially) so that we can use that as a reference number (archive) of prior activity.

See example from Uniswap. Not exactly what we need, but quite close and has a very clean interface.

https://vote.uniswapfoundation.org/

This is their default page with the RFPs voted on.

If you go to the “Voters” tab at the top shows how people delegate to anyone that is a member.

https://vote.uniswapfoundation.org/delegates

Sadly, Uniswap’s model only lets you delegate 100% to 1 person (not what we want).

Their sorting (based on our needs) must show sorting for our needs as well:

A. who has most voting power based on their combined LSU XRD staked (personally staked + delegated to them)

B. who has most voting power based on their own personal LSU XRD staked

C. who has most voting power based on amount of LSU XRD stake delegated to them for voting

We’ll also need similar filtering and viewing options as well.

The “info” tab is also quite useful and we’d want something similar for our DAO LLC
https://vote.uniswapfoundation.org/info

Effectively, their solution is quite simple and easy to follow and, I believe, is something we would benefit from as well:
High-level process:
https://gov.uniswap.org/t/community-governance-process-update-jan-2023/19976

Basic process:

  1. A forum post for RFC (request for comment).
  2. If it passes the initial RFC vote then it moves to official RFP vote.

Not sure on the min. values to allow for an RFC and those graduating to an RFP vote (for Uni it’s 1M UNI), but this page is quite helpful as a guideline for us to mirror.

For RFCs, I propose our governance forum would be the one on RadixTalk I recently had Mattia create for us (https://radixtalk.com/c/governance/radix-community-dao/).

I’m not sure if RadixTalk can integrate “voting” on RFCs, but we will need something like that as well.

***Treasure App***
A place for holding assets that can be sent via M-of-N user approvals with the approvers being limited to a set of users holding a specific badge or nft (dont care which). These “N” users (i.e. administrators) would be selected based on the RFC/RFP process in the governance process.

Their time in that role is bound to 1 year (or whatever we decide) and/or they are subject to removal/replacement if the community gets support (via RFC/RFP process) to replace them with a different member. Basically, all administrators must remain above-board and hold the North Star of driving the success of Radix as their primary goal.

Additionally, for each transfer of assets out of the app it needs to have an mandatory field available that is populated with the relevant RFP number from Governance app above. This way the payments are tied to a specifically approved RFPs for complete end-to-end tracking. No RFP = No Payment! This app must be read only/visible for everyone that is not an administrator.

11 Likes
2

for this are you talking about XRD and or USDC?

things like paying for cloud services and day to day things won’t go through the RFC / RFP process right?

3

basic cloud services to maintain , off course not

4

My next comments would be:

  • How long would it take to build this?
  • Who can build this
  • Is this the final form of what we want?
  • Can we get by with caper.network?
  • Can we get by with CrumbUp.io?
5

Hello, given what I have read on the high-level process that could be quite easy.. RFC, off-chain vote, on-chain vote and then execution.

It would be very useful also to see the treasury

6

Thanks for getting this convo started here. RadixTalk is a great place for focussed talk, to keep important information from being burried and fragmented.

This is almost exactly how I would imagine it going, so I’m happy we’re aligned. Couple remarks:

1. How do you envision the governance process?
Do we want to have trustless execution of the outcome of a proposal, or we leave it to the DAO’s administrators / managing members? I personally feel the latter is fine, and easier. Since this idea would include a legal wrapper around the DAO, the DAO’s administrators can be forced to execute the proposals to their best capabilities.

That approach simplifies the voting process. The smart contracts can just record which members (accounts) voted for / against, and the vote’s results can be calculated off-chain. If we open source the tool we use to count votes, every vote’s outcome can be reproduced and audited.

If the smart contracts need to be aware of how many voted for / against, we need to make sure tokens cannot be transfered after voting, and we need to somehow lock them, which I feel is a bigger barrier of entry.

2. Using LSUs is interesting, I imagine that means unstaked XRD is not counted towards a member’s voting power?

3. Delegation is interesting, and possible, but would require all DAO members to hold some kind of Membership NFT. That’s okay?
For example, in your proposed vision you mention this as a requirement:

A. who has most voting power based on their combined LSU XRD staked (personally staked + delegated to them)

B. who has most voting power based on their own personal LSU XRD staked

C. who has most voting power based on amount of LSU XRD stake delegated to them for voting

This is an awesome idea. I don’t think it’s a good idea to keep track of ALL people that hold LSUs, and rank them. If we only check users with a Membership NFT, that makes it a lot easier. It’s a nice identifier as well, instead of just using account addresses.

4. This goes a bit deeper into the implementation, but have you already thought about how we prevent “proposal spamming”?
We don’t want the governance app to be flooded with proposals. We could require the user to lock up some XRD to propose. Curious to hear if you have other ideas on this one.

1 Like
7

i believe that when someone stake a amount for example of 10000 XRD or whatever then these Membership NFT is create and linked to his account. Then he could delegate or not his vote. But at least we need a minimum of xrd staked. And for the proposal , the user need to have really more in staking to could do at least x5 and be locked for the time of voting the proposal . EJ 1 week.

8

  1. Let’s keep it simple for now. DAO admins can ensure the execution gets completed. For code changes, that should be rather straight-forward. For other non-code change activities those milestones will need to be included in the RFP so everyone can follow along to ensure they happen.

  2. LSU staked on validators only is all that matters. No unstaked XRD count. No XRD in liquidity pools count. No XRD engaged in lending apps count. Security of the network means you have the network’s interests as longevity as your overarching goal.

  3. Not sure on this one, but it might make more sense to just set a threshold for LSU-XRD quantity needed to join (so as to eliminate dusts accounts from voting). Maybe 10k XRD staked initially (which can be adjusted down when price rises). That gets us above the “crab” level (if all of those are staked on a validator (not likely).
    Radix Ecosystem

    image
    image560×315 22 KB

  4. Yeah, read it again. We’ll need some way to submit and vote on RFCs (like Uniswap does) before they can graduate and get posted to RFPs. Specifically the steps listed in order below the initial graphic here
    Community Governance Process Update [Jan 2023] - Governance-Meta - Uniswap Governance

    image
    image758×904 43.4 KB

9

1 believe that 1m is far away , 1/4 is enoght . im on the net for a very long time and dont have these amount of 1 -2 m

10

Those were UNIs values. I’m not advocating for them, but merely to show as an example of using thresholds for formal votes (both for RFCs and RFPs)

1 Like
11

Ah thanks, now I understand, there are 3 phases:

  1. RFC, completely off-chain
  2. Temp check, on-chain “vote” on whether the proposal has merit
  3. RFP, with on-chain voting

To do a temp check, you need some XRD. Which is good because we prevent spamming on-chain stuff.

We discussed “counting” votes off-chain, and then the multi-sig can execute passed RFPs. We then need a similar kind of structure for passing the temp check. The amount of votes for passing a temp check needs to be counted off-chain, and if it should pass an admin / multi-sig member needs to transition the proposal from temp check to RFP. So this is not an automatic / trustless step (because the smart contracts don’t know the amount of votes).

If we want to make it trustless / automatic, we need to lock the tokens used to vote on a temp check somehow while the temp check is in progress.

Either works for me, but probably the former is easiest. We could make it so only little (maybe only one) people with multi-sig access need to be present to transition an RFC to an RFP after passing a temp check.

12

Now you’re getting it. :wink:

Yeah, no need to “lock” tokens as we might have several RFPs at the same time being voted on. Only check for them is that the LSU needs to be present BEFORE the RFC or RFP vote. Basically, so you can’t just see a proposal you’d like to vote on and then stake a shitload and then vote and then unstake (which still needs 7 days).

Maybe something that looks at the current epoch when a “temp check” is made. All LSUs (within the qty of XRD threshold that fall on or before that epoch) are included and allowed to vote (unless they’ve been pre-delegated to someone else obviously).

Moving it from an RFC to an RFP should be fairly straight forward as well with a similar system for who can/can’t vote. No need for it to be automatic either. Someone(s) moving them forward is also reasonable (for now).

2 Likes
13

Maybe just make a Weekly voting round and if you have more Proposals per week you just bundle them in one voting session, so basically the LSU can be used anyway just for that voting round.

This would also make the voting process more predictable, people know that they have to vote every week, or bi weekly, etc. Because engagement is also a problem. If you have them randomly having to check their voting you will lose a ton of people.

1 Like
14

A decent idea, but the problem with that is that it could potentially combine 2 or more RFPs (or RFCs) into 1 mega vote. That’s one of the bad things Congress does already e.g. Mega Bills; Omnibus…etc.

Doing it that way can lead to “pork” spending as you’ll get bad stuff included with good stuff because you have to vote for all-or-none.

I think if we have the voting system provide an email notification system (like RadixTalk does) then that should remove most of the lack of communication and awareness/notification.

I’ve used the https://snapshot.org voting method many times in the past for a couple of ETH projects, but they lacked a basic notification system (email) which caused the very problem you pointed out. It is probably due to some worry about privacy, but I’m sure there’s a way to unlink fear and just have a “sign up here with an email address if you want to be notified of new RFCs or RFPs”…etc.

15

Yeah but what I’m proposing is not to vote yes/no to all 5 proposals let’s say in a Session.

You basically vote them individually, 1 by 1, in a sort of wizard.

So you can have:
Proposal 1: Yes
Proposal 2: No
Proposal 3: Yes
etc….

So it’s not like in congress where you either accept all, or reject all.

Seems more efficient to me to have this multitasking.
For extreme conditions you can call an emergency individual Proposal, but from an administration perspective it’s easier I think, and also solves the locking issue of the LSU per Session, instead of per Proposal.

**1 Session = Multiple Proposals. = Lock All Voter LSU for that Session.

**
More than that you already have this in the current foundation App, where we were asked now to vote for 2 things, when to stop incentives campaign, and how to vest the tokens. The only thing would be the LSU locking so you avoid double voting.

As for notifications we can use NOTIX by avaunt to notify members of Proposals maybe?
Or talk with the Wallet team to add push notifications so then the devs in charge of the wallet can push them so all users get Mobile Notifications.

16

I think this is enough: The amount of votes for passing a temp check needs to be counted off-chain, and if it should pass an admin / multi-sig member needs to transition the proposal from temp check to RFP.

17

I suppose that each type of voting (RFC / RFP) could require different rules, for example you can vote on RFC if your LSU level is enough and that vote will count also if you vote over two o three different proposal, while instead your LSU amount is locked on every RFP. For example with 10000 3rd you can vote on multiples RFC, but only on one RFP

18

Locking would go in the form of an NFT I assume. So you’d put all your LSUs inside of an NFT, basically. There is no issue using that NFT on separate proposals. The NFT would have some data field locked_until which is the latest deadline timestamp of all the proposal you’ve voted on.

But as I said, if we just allow a multi-sig member to elevate a Temperature Check to an RFP if the off-chain count passes, no need to do any kind of locking.

1 Like
19

My first version of a possible Treasure App blueprint: GitHub - nemster/dao_wallet: This blueprint is a wrapper implementing M-of-N multisignature around an Account.
It’s missing proper tests and there are a couple of TODOs but I tested it in Stokenet and it worked just fine.

Basically multiple members must invoke the same method with the same parameters for it to have an effect.

As an example, one member executed this:

CALL_METHOD
    Address("account_tdx_2_128mw0skkp0qdjn067spw08wkmlq9k6gsd2ggmp02k8m4vdl64wz8az")
    "create_proof_of_non_fungibles"
    Address("resource_tdx_2_1n2lth9xmqc4y0fq7cmkfl77wqxx2exa0r7zer6s4es6wwrhmqcdaet")
    Array<NonFungibleLocalId>(NonFungibleLocalId("#3#"))
;
POP_FROM_AUTH_ZONE
    Proof("member_proof")
;
CALL_METHOD
    Address("component_tdx_2_1cp33uq8qc8q9r68hlravkmc3pjxk0guscmxtu3t9x4jjvjh3ez3wx5")
    "mint_member_badge"
    Proof("member_proof")
    "make John Smith a member"
    Address("account_tdx_2_12yhyz54cyr35lpgepf6ug0fnalqcnuf36py8lcp672jtmmfxanmygl")
;

but only when another member executed this:

CALL_METHOD
    Address("account_tdx_2_129rs7cjt9qftkvnuv8xlvv658ervtzfqx7gju8vrjndqgv78kcw9ua")
    "create_proof_of_non_fungibles"
    Address("resource_tdx_2_1n2lth9xmqc4y0fq7cmkfl77wqxx2exa0r7zer6s4es6wwrhmqcdaet")
    Array<NonFungibleLocalId>(NonFungibleLocalId("#2#"))
;
POP_FROM_AUTH_ZONE
    Proof("member_proof")
;
CALL_METHOD
    Address("component_tdx_2_1cp33uq8qc8q9r68hlravkmc3pjxk0guscmxtu3t9x4jjvjh3ez3wx5")
    "mint_member_badge"
    Proof("member_proof")
    "make John Smith a member"
    Address("account_tdx_2_12yhyz54cyr35lpgepf6ug0fnalqcnuf36py8lcp672jtmmfxanmygl")
;

the account account_tdx_2_12yhyz54cyr35lpgepf6ug0fnalqcnuf36py8lcp672jtmmfxanmygl received a freshly minted member badge.

I’m open to any proposal about possible improvements.

20

Here is an idea

Screenshot 2026-01-15 at 2.42.41 PM
Screenshot 2026-01-15 at 2.42.41 PM1487×1100 117 KB

4 Likes