[RFC] Reserve Delegates Plan Proposal

Governance & Research
1

Reserve Delegates Plan Proposal

Summary:

A look at Nevin’s recent update and governance comments. Main issues of decentralized governance. Governance should go through governance and RSR holders should ultimately decide.

ABC Labs’ Update and Why This Proposal

In a recent X post by @nevin.freeman around the RSR Health there was a section dedicated to RSR Governance:

“Rather than replacing one person with another, we’re moving toward a broader-based model, distributing delegated governance power across roughly 20 credible community participants focused on the largest RTokens and DTFs. We’re setting up a coordination mechanism (broadcast group for vote alerts) with the expectation that delegates vote consistently or risk losing their delegation. This is a meaningful shift from concentrated to distributed community governance.

On the broader RSR governance side: the community call surfaced a clear frustration that team-controlled RSR could historically determine the outcome of governance votes, making community participation feel pointless. I hear that, and we’re working on delegating company-held RSR voting power to engaged community members so that governance outcomes genuinely reflect broader stakeholder input. Griffin and Max have begun the operational planning for this, identifying the right set of delegates, working through the wallet logistics (delegation requires separate wallets since voting power can only be delegated 100% per wallet), and I’m designing the coordination workflow. This is actively in progress as of just yesterday.”

This little summary includes multiple important insights into what ABC Labs envisions for the future of RSR governance.

My first note here is that although this above update was written after a conversation with a group of Reserve community members, the section of governance is written from a perspective of ABC Labs deciding what will happen, not from the perspective of having discussed it and seeking consensus on a way forward. This is in contrast to the language used when it comes to the Milestone based RSR unlocks for instance. It is too little information to speculate, but it is worth pointing out since the last months have been dominated by the community demanding more transparency and involvement. On a personal note, I am not saying I disagree with Nevin’s idea of delegated governance, I do think governance specifically needs broad input and a RSR vote to implement, not a ABC Labs top-down implementation.

“we’re moving toward a broader-based model” ABC Labs wants to/will make Reserve move to a different model.

“We’re setting up a coordination mechanism (broadcast group for vote alerts) with the expectation that delegates vote consistently or risk losing their delegation.”

Governance can be done in many ways, and loads of experiments have been done or are on-going. The above is a very minimal and not 100% abuse proof measure and introduces the questions of who decides and who checks. More on governance suggestions later.

I am speculating that, as the above excerpt is split in two and Nevin continues with saying “we’re working on delegating company-held RSR voting power to engaged community members” he means that ABC Labs envisions 2 different delegation structures. 1 for “the largest RTokens and DTFs” and 1 for general Reserve governance.

“we’re working on delegating company-held RSR voting power to engaged community members so that governance outcomes genuinely reflect broader stakeholder input. Griffin and Max have begun the operational planning for this, identifying the right set of delegates”

Again, this is going to be decided by ABC Labs it seems. Now the issue of course here is that it is hard to argue that the community should decide where ABC Labs would delegate ABC Labs’ RSR. It is ABC Lab’s RSR after all. This does not take away the issue that even with delegation, it might not take away the threat of team centralization within governance, as the team could revoke its delegation whenever it wanted on its own terms. Especially if it is the team that comes up with the framework for delegation.

As I personally feel compelled to make Reserve a success, as I want index DTFs to thrive, for me and my family and a steady future, I immediately wrote about my willingness to talk with Max and Griffin within the Reserve chat. So far nobody reached out, which made me realize I should write this forum post.

To end my introduction regarding Nevin’s X update, let’s end it with a reflection on his own words:

“This is actively in progress as of just yesterday.”

This was written on the 15th of February. So I will say that it’s fair to assume the above was a simple first look into what the team wants, and perhaps the actual roll-out would be more cooperative and informative.

But if the goal is to have community involved governance, then why wait? This is the reason why I am sharing my own delegated governance plan here today to help shape the Reserve governance direction bottom up.

DAO Community Governance Issues and the Way Forward

DAOs have been around since the days of Dash and earlier even Bitshares. Successful DAOs are up for debate. The main issues I have encountered in my 11 years in crypto are:

  1. The team has an unbalanced power compared to the community.

    1. It owns the official channels, it hires the mods and can therefore ban and dominate discussions, it owns the largest stake of supply, it writes the code, etc. Personally I therefore believe governance to be an unsolved problem within crypto and prefer teams to deploy permissionless code and earn fees instead of creating governance tokens. Why am I writing this post? Reserve already has token governance and it is the main protocol building out DTFs that I personally hope to own for the next decade. I want Reserve to succeed and if it has token governance, I want to help it to be a passable, hopefully good, type of governance.

  2. Governance existing has not stopped teams or other groups of stakeholders from bypassing governance completely.

  3. Voter apathy or lack of knowledge.

  4. Governance structure resulting in loads of written text and spent time and bickering, but it being unclear how much it benefited the protocol’s direction and success.

There are a lot more minor issues and the history of DAOs is extensive, but the above should suffice.

To solve the above problems, Reserve should aim high. What does good governance look like? Let’s go point by point.

  1. If Reserve creates governance where participation is impactful, it over time will give rise to more RSR holders and therefore a more distributed governance base. For now ABC Labs is the big holder and that won’t change any time soon, so them delegating is likely the best first step, even if it will maintain the power imbalance. If done decently well, it hopefully will inspire more independent RSR holders in the future.

  2. ABC Labs should commit to RSR holders voting on protocol decision making. Budget spending has been suggested by community members. General sentiment is that of a community wanting to have more of a voice and a conversation instead of being spoken to. My suggestion specifically would be that any governance changes should go through… governance. Even if it is a suggestion from ABC Labs that would clearly give the community more of a say such as delegates. To commit truly to governance, do it all the way. As JMG said elsewhere in the forum: “If ABC/CC delegates RSR to community members, should locked RSR holders approve those delegates after an open competition for the roles? Why or why not?”

I would even go one step further and say that the whole idea of delegates and governance improvements should go through a governance process. Typically this would mean a forum discussion, a formal proposal and then a vote.

  1. A delegate group that has checks and balances will perform better than governance without one. Good tools exist out there to help monitor delegates. I like curiahub.xyz, but even karmahq is better than nothing. Another possibility would be to give top DTF holders veto power as is done within the Lido Dual Governance where stETH has this capability. This would mean RSR holders set the terms, but large stakeholders that are not interested in daily governance still have a voice. Likely a topic on its own but worth mentioning here.

  2. Oh the irony. I just suggested that even letting the idea of delegates should go through the forum and governance and here I am about to write about not having too much bureaucracy. I will stand by it as I believe the problem mentioned earlier to be of a different nature. Committing to governance from the first step is different to creating overly drawn out processes and requirements.

How Delegated Reserve Governance Could Look Like

Below is an incomplete list of attributes of Delegated DAO governance that I as a long time crypto researcher and DAOist believe to be positive for productive outcomes. I encourage everyone to add more detail and their experience to this framework and to make the upcoming Reserve Delegates experiment a combined team and community effort.

  1. Delegates should represent the RSR holders. RSR holders include ABC Labs and every other holder. Anyone should be able to become a delegate. This should be an open process with RSR holders ultimately deciding.

  2. Delegates must also be able to be voted out again. Of course this could be done through literally delegating RSR, but a cleaner way would be regular voting. Regular could mean every 3 months, it could mean every 6 months or 1 year. As someone who has been a member of DAO councils, every 3 months was a good time to get rid of non-active members. Tooling like https://curiahub.xyz can help inform RSR holders.

  3. Governance is not solved. Some DAO experiments therefore use what they call Governance Seasons in which they continuously iterate on the process. Again I would say 3 months is a good time duration. Especially the first year. If it works well, governance could vote to extend seasons.

  4. Delegate work is work. Delegates should be compensated. What the fair compensation would be is a tricky question. This topic itself has paralyzed other DAOs (Arbitrum has gone through a whole cycle of debate and iterations recently). I do not have the perfect answers here but I can share some insights

    1. There are 4 types of delegates.

      1. Some delegates simply show up out of interest, compensation or not. Thank God for the good Samaritans. Likely still incentivized by their bags of course, but still.

      2. Most put extra time into their delegation work because they had motivation for their bags plus felt they had to deliver quality in return for the compensation.

      3. Others will vanish when incentives are gone and are only voting and writing AI slop rationales to maintain quorum for their pay.

      4. Lastly there are the delegates that get voted in and then become ghosts. Sometimes immediately, sometimes halfway. There are always a bunch.

    2. The above tells me that trying to create frameworks with requirements mainly hurts i and ii, as these do not need requirements to do the work, and will have to deal with the low quality slop of iii. Regular RSR voting on delegates will shift out iii and iv without creating unneeded bureaucracy and oversight.

    3. On the point of oversight. One way of rewarding delegates could be retroactively, based on productive contributions. A lovely idea but difficult in practice, as who would decide? Again inviting endless bickering and debate on who got what. In the end the cleanest oversight is RSR voting.

    4. As this is a new experiment, what can be done however, is have the first Governance Season be a pilot season in which delegates get rewarded after the season is done, and where the iv ghost delegates get none. Perhaps so effective, this could become standard practice.

    5. If over time certain delegates out perform, which would be to be expected, Reserve could look into some form of delegation based reward bonus, where delegates with more delegated RSR get rewarded more. Devil is in the details here, so for the first pilot I would advise against.

Simply following the above 4 principles of RSR holders deciding on who is a delegate on a regular basis and deciding on governance iterations while delegates get compensated for their work with possibility of being voted in again or not, will give a clean base for Delegated Reserve Governance to kick off.

Next Steps

The above could be implemented fairly easy as a formalized RSR vote already and probably would be decent for a governance pilot, but of course that is just my opinion.

I invite Max, Griffin, Nevin and everyone else who feels called upon regarding DAO governance, and also everyone who felt left out in the past within Reserve governance to reply to this post and move this delegate idea forward, together.

6 Likes
2

I do not know the handles of Max or Griffin, @nevin.freeman please tag them.

3

Hey Zeb, Thanks for the thoughtful proposal.

Wrt delegate programs, we’re also in touch with ABC Labs and are looking to help them design a program, as we have for Rootstock Collective, 1Inch and others.

The most important thing about a successful delegate program is first to define what success looks like.

What is the role that delegates should play in the RSR ecosystem?

  • Is it governance security, i.e. having a watchful eye open for malicious proposals and voting them down, as well as helping good proposals pass?
  • Is it community engagement, bringing in new participants and shepherding others along?
  • Or is it risk management?
  • Is it optimizing liquidity or distribution?

There are many things that are a good fit for delegates.

In our experience, simple programs often work the best. This might be counterintuitive because from the lens of administration, more administration is always the solution. But it is important to keep these programs simple, so delegates don’t spend a lot of time jumping through arbitrary hoops.

Another important thing to consider is how delegates are selected. This can be done by voting, for instance. Or it can be done with contests, like Confetti or other community activations.

Again, choosing the right method depends on the goals the Reserve ecosystem is pursuing with the delegate program.

One specific challenge specific to Reserve is that it is actually a DAO factory. A delegate with voting power in eUSD does not necessarily need to have voting power in ETH+ and vice versa.

This could be overcome by creating index DTFs of stRSR positions for each delegate giving RSR holders a way to delegate across a certain basket of DTFs and get yield on that basket. Or it can also be just as is, with people delegating to specific delegates on a specific DAO. The latter, of course, adds a little bit of complexity, but also affords more granularity.

As always, everything has trade-offs.

Thank you so much for your thoughtful proposal and also for putting yourself forward. I think Reserve is really blessed with passionate community members such as yourself, and affording them a more formal engagement in the ecosystem is a good way to honor their commitments.

4

Governance Delegation: Summary of Our Recent Call and Open Questions

I hosted a call recently with @zeb, @Raphael_Anode, and @blue to talk through how a governance delegation program could actually work for Reserve. This is a summary of what we discussed. I’m posting it here so the broader community can take things forward from this point. This post is mostly auto-generated based on our call transcript.

Who Was on the Call

Zeb has been in crypto since 2014 and spent roughly nine years doing fundamental research at a crypto fund. He was an early participant in The DAO, has been active in governance at Index Coop (served on three councils), Balancer (co-founded their sub-DAO system and served as grants lead), MakerDAO, and Kyber, among others. He came to Reserve through CMC20, which caught his attention as the first reasonable permissionless crypto index product he’d seen. His primary motivation is making index products work well because he sees them as the most sensible approach to long-term wealth preservation in crypto, and Reserve currently looks like the best candidate to deliver that.

Rafael is with Anode, which grew out of StableLab, one of the first professional governance services companies in crypto. StableLab was founded by two former MakerDAO contributors and was among the first professional delegates. Rafael has deep experience with how delegation programs work in practice across multiple protocols, including what goes right and what goes wrong. Anode has been working with Reserve under a grant focused on governance facilitation: hosting governance calls, improving forum structure, and proposing governance improvements.

Nick (Blue) has been organizing the DRF (Decentralized Reserve Faction), a community group that now has around 15 members and meets monthly. He’s been tracking governance dynamics across DeFi broadly and thinking about how lessons from other protocols apply to Reserve. The DRF chat is active almost daily, with members sharing research, analysis, and ideas.

The Big Picture: Why This Matters Now

I shared my view that in the near term, finding product market fit is the priority, and nothing else matters if we can’t do that. But governance is part of the product. How our tokens are governed affects whether people trust them enough to hold them.

In the long term, for the vision of asset-backed currency that’s truly neutral and globally governed, governance design is a huge unsolved problem. I think the fact that Reserve has a factory for DAOs, where each RToken is its own DAO, is actually an advantage here because we can run different governance experiments in parallel across different products.

I was candid about the history. The team at ABC Labs made an explicit decision to prioritize growth over decentralization, on the logic that if we can’t find product market fit and grow the thing, decentralized governance of nothing doesn’t matter. That led to governance delegation and community involvement being deprioritized. We also ended up concentrating too much delegated power in a single community champion, which created problems. That was a mistake, and the frustration people feel about it is legitimate.

The simplest, most obvious thing we can do right now is delegate ABC Labs tokens to a broader set of committed community members so they have real voting power.

Key Discussion Points

Community members vs. professional delegates. There was strong consensus on the call that delegates should primarily come from Reserve’s existing committed community rather than outside professional delegates. Nick raised a concern I think many share: the community has watched multiple waves of paid outside contributors cycle in and out, and bringing in professional delegates who don’t really care about Reserve would make people even more jaded. Rafael added useful context from his experience: professional delegate compensation across DeFi has collapsed to $200-300/month, making it essentially unviable as a business. He also noted that the quality of early MakerDAO delegates, who were deeply ingrained community members with diverse skills, was excellent and rare, and that he sees similar quality in Reserve’s committed community.

What delegates would actually do. Rafael emphasized that the very first question in any delegation program is: what do we want delegates to do? Right now, the answer is straightforward: vote on RToken/DTF governance (basket changes, parameter updates, contract upgrades) and ideally explain their reasoning. That’s it for now. Over time, as things like veRSR or protocol-level governance come online, the scope could expand to include things like directing RSR platform fees, managing the protocol contract registry, and voting on milestone-based emissions. But we should start simple.

Optimistic governance changes the picture. The ABC Labs team has an optimistic governance system currently in audit. Once released, it reduces the burden on delegates significantly because routine proposals from whitelisted proposers go through automatically unless someone vetoes. Delegates would mainly need to pay attention and veto bad proposals rather than actively voting on every routine change. Rafael made an interesting observation that optimistic governance is in some ways more democratic than voting on everything, because it avoids the fractionalization that comes from politicizing every decision while still giving people the ability to block anything genuinely harmful.

Which RTokens/DTFs to delegate on. This is a practical question we didn’t fully resolve. We have many DTFs now, some big, many small. Do we delegate across all of them? Just the big ones? Just the ones a given delegate is interested in? One possibility the team has discussed is building a single vote-locked DAO contract where you can vote lock RSR once and have it govern multiple index DTFs simultaneously, which would be much more efficient than staking separately on each one. This is technically feasible for index DTFs (where there’s no slashing risk, unlike yield RTokens where you’re making a risk decision per product). It’s worth noting that in order to transition to a setup like this, we would need the stakeholders who are involved in any given index RToken to be comfortable with it, it would require some herding of cats, but once that work had been done, it would improve the efficiency of the system overall.

How to determine delegation amounts. I floated an idea: rather than giving every delegate a flat amount, what if we delegate a multiple of whatever they’ve already vote-locked or staked on their own? So if someone has staked X amount of RSR on a given RToken, they’d receive something like 5x or 10x of that in delegated voting power. This would naturally filter for people who already have skin in the game, scale delegation to existing commitment levels, and answer the question of “which RTokens” organically (whichever ones they’ve already chosen to stake on). We’d want some minimum tenure requirement too, like having been staked for at least three months, to avoid gaming. The group had mixed reactions. Some liked it. Zeb noted it’s one interesting approach among several worth exploring.

Should there be an RSR vote to set up the program? Zeb proposed that any protocol-level governance changes should be voted on by RSR holders, not just decided by ABC Labs. His view: if RSR holders are eventually getting power over Reserve as a protocol, they should vote on whether the delegation structure itself is the right direction. He sees this as setting a good precedent. He drew a distinction though: the selection of individual delegates doesn’t necessarily need a full RSR vote (ABC Labs holds enough RSR that the people we’d want would likely be voted in anyway), but the structural decision of how the program works should involve the broader holder base.

Compensation. This got a fair amount of discussion without a clear resolution. The default position we landed on is probably no compensation, at least to start. Rafael shared cautionary experience: introducing compensation attracts mercenary participants, and at Arbitrum, 50% of the delegate compensation budget ended up going to the people managing the compensation program rather than to delegates themselves. That said, Zeb pointed out that governance participation does take time, so some form of compensation is reasonable. One idea I raised: rather than paying delegates from the treasury, what if the staking/governance revenue generated by the delegated RSR simply flows to the delegate? This would mean delegates only earn if the products they’re governing are actually generating revenue, which aligns incentives. The group noted a potential problem with this approach at scale: if large RSR holders in the future see delegation as losing their staking income, it could discourage delegation. For now, since it’s ABC Labs voluntarily forwarding revenue from our own staked position, that concern doesn’t apply. But it’s worth thinking about for the long-term design.

Delegate rotation and accountability. Rafael shared that delegation in practice is extremely sticky. At Uniswap, delegates publicly announced they were stepping down and their delegation decreased by less than 5%. MakerDAO addressed this by spinning up new delegate contracts annually: your old delegation stopped counting after one year, forcing active re-delegation. Zeb suggested even shorter terms for a first iteration, maybe three months, to keep people engaged and active while the program finds its footing. He also raised the idea of automatic undelegation if a delegate fails to vote on, say, three consecutive proposals.

RToken holder veto power. Nick raised a concern about delegates governing DTFs they don’t actually hold. Zeb suggested a model inspired by Lido, where holders of the RToken itself could have veto power over governance decisions, separate from RSR governance.

Next Steps

  • Rafael is going to draft a rough first proposal for how delegation could work and post it in this thread for comment. He has recent experience designing a delegation program for Rootstock and will share a distilled version as a starting point.
  • Nick is raising this topic at the next DRF meeting this week to get input from that group on the open questions below.
  • I’ll follow along and weigh in, and Griffin and Max on the ABC Labs side will flag anything that’s logistically impractical from a token ops perspective. They are not responsible for designing this program, but they will have to operationalize it on the ABC Labs end, so we need to make sure that we’re not designing something that’s going to be a total nightmare for them.

The goal is for the community of involved RSR holders to figure out what the program should look like. ABC Labs will handle implementation once a plan is ready.

Open Questions for the Community

  1. How should delegates be selected? Should ABC Labs choose from known community members? Should there be an RSR snapshot vote? Some combination? What criteria matter most: length of involvement, existing stake, demonstrated governance participation, specific skills?

  2. Which RTokens/DTFs should be included? All of them? Only those above a certain TVL threshold? Only the ones a given delegate is already staked on? Should we start with just a few large ones and expand over time?

  3. How should delegation amounts be determined? Flat amount per delegate? A multiple of their existing stake? Scaled by RToken size? What’s the right balance between giving delegates meaningful power and not over-concentrating it?

  4. Should delegates be compensated? If yes, how? Fixed payment from treasury? Share of staking revenue from delegated tokens? Nothing upfront, with compensation introduced later if the program proves valuable? What does Rafael’s experience across other protocols suggest is the least problematic approach?

  5. What accountability mechanisms should exist? Term limits (three months? six months? one year?) with required re-delegation? Automatic undelegation after missed votes? Public vote rationale requirements? How do we keep this lightweight enough that it doesn’t become its own bureaucracy?

  6. Should the delegation program structure itself be put to an RSR snapshot vote? Or is this something that can be designed collaboratively and implemented without a formal vote, given that it’s ABC Labs voluntarily delegating its own tokens?

  7. Should RToken holders have separate veto power over governance decisions affecting the products they hold, independent of RSR governance?

Looking forward to what you guys come up with. We can start simple, learn from how it goes, and iterate.

3 Likes
5

Thank you Nevin for taking the time for a call. Happy I kickstarted the convo with this thread and looking forward to see where it would go towards.

Ai notes, so no offense taken for minor differences.

He drew a distinction though: the selection of individual delegates doesn’t necessarily need a full RSR vote (ABC Labs holds enough RSR that the people we’d want would likely be voted in anyway), but the structural decision of how the program works should involve the broader holder base.

I actually do believe delegates should be voted in by RSR. And since ABC Labs has a lot of RSR, they do not need to be fearful of their candidates being left out. But it’s imo a better system if all RSR gets to vote/delegate. This allows for unaccounted for additions to the delegates.

Also

The default position we landed on is probably no compensation, at least to start.

Is not where we landed on all four of us, but was given as a suggestion by Nevin after we talked on the topic. Plus as already mentioned in my starter post, I support the idea of the first iteration not getting any compensation. And that RSR holders could vote for retroactive funding afterwards. Imo it’s to be discussed further and I think, as I said in my post, plus as Raphael also echoes, the simpler the better. What that looks like should be talked about by the broader community in, for instance, this forum thread.

To further kickstart this thread, let me personally answer the 7 questions given:

How should delegates be selected? Should ABC Labs choose from known community members? Should there be an RSR snapshot vote? Some combination?

Imo there should be an open platform for delegates to come forward or being asked to come forward, where RSR holders then chose to delegate towards. As ABC Labs has a lot of RSR, this likely will mean the community members they were thinking of get delegated to, and perhaps some extra ones as well. Could this invite professional delegates to try to sneak in? Yes, but I think its unlikely to become an issue as the first iteration imo should not get rewarded outright anyway.

What criteria matter most: length of involvement, existing stake, demonstrated governance participation, specific skills?

I prefer not to have an opinion here, although each are to me important. Let RSR delegators decide. Criteria means oversight, oversight means work.

Which RTokens/DTFs should be included? All of them? Only those above a certain TVL threshold? Only the ones a given delegate is already staked on? Should we start with just a few large ones and expand over time?

No strong opinion here. Although below a certain amount of TVL I think the DTF creator is basically the most incentivized person to work on it, so a certain threshold of TVL could make the plan less work heavy for ABC Labs and RSR holders.

How should delegation amounts be determined? Flat amount per delegate? A multiple of their existing stake? Scaled by RToken size? What’s the right balance between giving delegates meaningful power and not over-concentrating it?

Another idea for the compensation to still be connected to performance of the RToken/DTFs (which I do like) could be to take some % out of the platform fees from the DTFs towards the delegates instead of % of earnings of delegators (since they might be incentivized not to delegate due to this setup).

Should delegates be compensated? If yes, how? Fixed payment from treasury? Share of staking revenue from delegated tokens? Nothing upfront, with compensation introduced later if the program proves valuable? What does Rafael’s experience across other protocols suggest is the least problematic approach?

The reality is that a delegate ‘should’ be spending more time than the average community member on this governance. Which means it becomes more than just internal motivation, and then it means its work. So I think DAOs will always converge to some form of compensation. And the best way is to tie it to success of what is governed. For the rest I already gave some ideas on this earlier in this message.

What accountability mechanisms should exist? Term limits (three months? six months? one year?) with required re-delegation? Automatic undelegation after missed votes? Public vote rationale requirements? How do we keep this lightweight enough that it doesn’t become its own bureaucracy?

As mentioned, at the start I would suggest 3 months. Reserve governance like this will be new, I bet the first group of delegates will be motivated and having a check-in after 3 months has been the right timeline in other DAOs that I was participating in. Other than that I would try to steer away from oversight committees, groups and requirements as much as possible. Automatic undelegation after missed votes is something I suggested, tbh, don’t know if its been tried on a smart contract level, but seems like a clean way of dealing with the undelegation issue.

Should the delegation program structure itself be put to an RSR snapshot vote? Or is this something that can be designed collaboratively and implemented without a formal vote, given that it’s ABC Labs voluntarily delegating its own tokens?

Since I argue for RSR holders in general to be able to delegate as well, I would say yes. Sets the right tone.

Should RToken holders have separate veto power over governance decisions affecting the products they hold, independent of RSR governance?

I came up with this one, so, shocker. Yes.

1 Like
6

can we request a delgate to help in the dtf governance in case the final decision does not assign a delegate to a specific dtf?

can we also have delegates in terms of key specialists or specific areas of expertise so it is clear that in case of any questions who the go to delegate is and all dtfs could ping the right delegate for example (but not only) basket composition, rtoken liquidity issues, rebalancing proposals, dtf mandate compliance? if delegates are champions of specific items, all dtfs could tap into the expertise.

7

Thank you @blue, @nevin.freeman and @zeb for taking the time to explore the topic of delegation. As part of StableLab and now Anode I helped oversee and design a couple of delegate programs. What I learned is: Keep it simple and grow from there!

This seems so simple and straightforward that it might be discounted, but I argue that this is the perfect starting place. Everyone knows what’s expected and active community members are already voting anyway.

@zeb pointed out that required rationales often lead to posting of two-liners or AI slop. But they can also surface valuable insights, as I have seen at Aave, ZKSync and Rootstock lately. In the end two-liners and AI slop tell a delegator as much as not posting anything: namely, that the delegate doesn’t care and undelegation should happen sooner rather than later.

This is a very interesting “complication” to the delegate program. (I’m using complication like a watchmaker here: more is difficult to pull of, but can be beautiful and good)

What skills is the community most in need of, now?

In the medium-term I see delegates becoming more of a board of directors in joint-stock corporations. That fits well with optimistic governance too.

  • If ABC Labs participates in the election it could be said that delegates are hand-picked, so why bother in the first place. Of course it’s their prerogative to delegate their tokens to who they want to. But if a vote is to be held for the community it would probably be better for ABC Labs to abstain.
  • Elections are always beauty contests, no matter how you dice it. Is this the best way to select delegates? One look at the state of governments worldwide casts serious doubt about that. Reserve is different. Is it different enough?
  • Elections also pitch constituencies against each other. See red/blue states, etc. This can be avoided by gamifying the process with tools such as cconfetti.win to make it less serious and more engaging.
  • What “objective” measures are there to select delegates? Voting history, Amount of stRSR, Forum statistics, rToken holdings, useful skills like @sagix.io mentioned, what else?

I propose a short “test program”. In Rootstock we started out with the “Shepherds” before going full delegate mode. This can be instructive because it surfaces design issues early and allows easy course correction. When delegates have to approve changes to the delegation program by voting, some measures that are unpopular with delegates can have a hard time passing. This can make changes to a delegate program harder over time.

I will post a distilled version of our Rootstock Collective Delegate Program design adapted for Reserve within the day.

Also adding this excellent resource we at StableLab made. An extensive overview of DAO delegation: Introduction | The DAO Delegation Handbook V1

1 Like
8

Proposed plan for simple MLD (minimal loveable delegation) rollout

  • Create a list of DTFs where stRSR is delegated. At the minimum (> $1m mcap)
    • ETH+
    • eUSD
    • USD3
    • bsdETH
    • CMC20
    • LCAP
  • Identify how much total stRSR to delegate per DTF (how much is needed to ensure quorum is met with aligned actors)
  • Align on the method for selecting delegates
    • Voting on Snapshot across the ecosystem (not on-chain but easy and reflects voting power across DTFs)
    • Delegate race / contest (can be fun and engaging, also takes cross-DTF voting power into account
    • Hand-picked by ABC Labs
    • “Objective criteria”. Here I suggest voting history and tenure to reward committed members
    • Specific skills needed by the ecosystem at this moment
  • Specify delegate requirements and consequences for not meeting them
    • Suggest: 90% voting participation, at least one forum update per month in a delegate thread
    • Undelegation if requirements aren’t met for two months, with a warning after one month.
  • Get clarifty on compensaton: This can be a token amount, a “rev share” of the delegated tokens or access to paid tasks by DTF curators or ABC/CC.
  • Set a duration for delegation (1 year, 6 months, inital 3 mo, then 6/12)
  • Create forum category for delegate threads and delegate introductions
  • Select delegates and delegate voting power
  • Monitor delegate performance (Anode’s job)

Monitoring in optimistic voting scenarios becomes more tricky. How do we know someone is paying attention? I’ll think deeper about this and will update this when I find something.

As a quick, non-binding vibe check, four forum polls:

How would you like to have delegates selected?

  • Snapshot voting
  • A contest or delegate race
  • Handpicked by ABC/CC
  • Objective criteria
0 voters

Do you support delegate compensation

  • Yes - compensate
  • No - don’t compensate
0 voters

If you voted for compensation, which way do you prefer?

  • Revenue share of delegate tokens
  • RSR tokens - fixed amount
  • Cash tokens - fixed amount
0 voters

For how long should tokens be delegated before mandatory re-delegations (which can be to the same accounts)?

  • Initial 3 months, then six months
  • Six months
  • Twelve months
  • Infinite, until undelegation
0 voters

Which DTFs would you like to see delegation on that are not listed here?
Are there other ways to select delegates you would like to see?

3 Likes
9

Thanks for the meaningful discussion you have had on this important topic. Lots of other things to do (that probably and rightfully have priority over this), but it seems there is a relatively simple way to address the issue of centralization (of voting power) and it is an excellent signal this is addressed/resolved in pragmatic way. I really welcome Raphael’s post just above this one and I have provided my input on how to progress there through the voting polls. I would like to add that ABC Labs recently demo-ed new functionality (an early version at least) for the Reserve app that clearly lists governance proposals across all DTFs on one page. I think that would be very welcome as it makes it easier to see which proposals require voting on. Of course delegates would have to take responsibility themselves to track what’s going on on the forum wrt governance proposals, but this new Reserve app functionality would definitely be helpful to make sure delegates don’t overlook a proposal that needs voting on.

2 Likes
10

The DRF should set up a DRF-comprised multisig that anyone can delegate to. That is, the DRF should use a multisig to collectively govern multiple RTokens/DTFs, and a delegator would know that the DRF is a governor that is not controlled by a single entity.

3 Likes
11

I really like this idea. The DRF is already made up of members who’ve proven they deeply care about the project and delegating to a group of trustworthy individuals who can discuss and collectively vote on proposals (while prioritizing the protocol’s/holders’s best interests) might feel more compelling and robust than delegating to just one person. The DRF would become some sort of “delegate council”.

2 Likes
12

I believe the $1M threshold is appropriate, anything smaller than that should be primarily founder driven until then as you mentioned. I also like the idea of optimistic governance as well. It definitely makes the flow of the voting process smoother and creates less busy work with the delegates. Non-vetoes should still have to be explained in a forum thread, but having an automatic way of monitoring these while ensuring for quality is the tricky part as these would be key to making un-delegation decisions. Though in a sense, explaining a non-veto essentially becomes explaining a vote for the positive and therefore a vote in and of itself, just not on-chain. So forum posts just become a different way of counting votes and participation. Just spitballing here.

13

Thanks for getting this community discussion started @zeb and to you Nevin for quickly moving the conversation forward, arranging a call and summarising it here.

N.B @nevin.freeman I really do enjoy these auto-generated summaries and find value in the both when used to summarise team activities and focuses on X and in this format when pushing a specific topic forward. Please keep them up!

I’m very much in favour of a delegate programme as I’ve pointed out previously in the RSR Health discussion. I shelved the idea after some of Nevin’s comments around favouring PMF and growth over decentralisation which I interpreted to be quite hardline. I happy to read his comments from the follow-up call and see that this view has maybe softened, or this I misinterpreted them in the first place!

I do acknowledge that there is a lot going on in the ecosystem, and ABC probably can’t allocate a lot of time to this and appreciate the comments from @zeb and @Raphael_Anode. I’m pretty reassured with their ongoing stewardship that we can curate a delegate programme which while minimal and self-policing by design will still be able to stand-up to trails and tribulations of governance.

To add my 2 cents…

  • I agree that a trail programme is the best course of action. A programme that doesn’t involve the use external platforms or invitations to professional delegates from outside of the ecosystem. To me this adds additional bloat which will result in additional spend (RSR selling) and mercenary SPs who probably leave when any paid incentives dry up. Maybe this outside tooling and input can enter at a later stage as the programme scales out.

  • While I do this a programme mandate and methodology should be ratified via onchain vote. I feel given these are ABC Labs tokens, once the programme has been ratified they should be able to independently operate how they please within it’s parameters including delegating RSR stake. I feel ABC should retain the prerogative to delegate their tokens where they want, removes the issue around ABC hand picking delegates in a community vote and abstaining from community votes. Agree with Raph that elections are a beauty contest, pitch delegates against each other and introduce unnecessary criteria, oversight and work.

  • With regards to what DTFs to include, I have a pretty strong opinion that index DTFs should NOT be included in the initial programme. From my experience when governing these products the governance flow isn’t sufficiently decentralised on the largest index DTFs for a delegate programme which includes these to exist. Currently, for LCAP a basket rebalance proposal is posted and voted on prior to the benchmark being made available to the public forcing governors to completely rely on third party trust that the rebalance is correct. I discuss this with Raph on the most recent GovOps call who correctly pointed out that a governor can directionally work out the allocations given they are based on asset market cap and that a delegate on index DTFs are also a line of safety against malicious proposals. However, given this major governance flaw during rebalances, I wouldn’t be comfortable with a formal programme involving index DTFs at this time. As it amounts to blindly voting through rebalance proposals, under normal circumstances. This is the reason why I have omitted index DTFs from my own delegation platform.

  • With regards to delegate amount and compensation, I really think we should leave this up to ABC Labs given it’s their stake that’s being delegated. That being said, I’d like to ratify some very loose parameters in the onchain vote, these could be as simple as one delegate not receiving more than a certain percentage of total DTF voting power and the delegation programme not being over a certain percentage of total voting power for each DTF. I also agree that delegates should be retrospectively compensated for the work and think Raph’s criteria work, 90% voting participation and rational expressed in delegate threads. In order to minimise overhead, I think compensation should be either a flat fixed rate or fixed compensation based on delegated amount. The latter may help with programme expansion as ABC Labs can state we have 100m we want to delegate and a $10k comp budget, resulting in each delegate earning $100 per 1m delegated. As the programme expands and more delegates join the delegated amount per delegate drops, each delegate earns less (for less responsibility) and the programme expenditure remains constant. RSR token comp makes the most sense to me.

  • As previously discussed I like Raph’s current model for accountability (>90% participation), it’s easy to measure and track and leaves no ambiguity. Given I’ve discussed retrospective compensation keeping cycles at a quarterly cadence. Six months feels a little too long esp. when a delegates circumstances may change and they wish to leave the programme but are locked in for another 5 months etc. Agree that we should steer away from oversight committees, but maybe could tap a warden to generate a quarterly report on delegate participation rates which ABC labs can then use to given delegation for the next quarter. Maybe this could rotate every quarter or @Raphael_Anode could pick it up as I imagine as gov facilitator he wouldn’t want to participate in the delegation programme. To make this job easier and to improve transparency we could also specify that ABC Labs can only delegate to wallets with an ENS e.g Ham-delegation to improve transparency in the Register UI.

  • While I agree that automatic undelegation and DTF holders having veto powers are interesting ideas and things though should be explored further. However, given these both require some degree of technical or governance lift I think we should avoid incorporating them into the programme pilot. Focussing on what and who we have in the short-term.

  • Regarding optimistic governance, agree it does muddy the waters slightly. Although, I think there is currently only a minor role for it on the yield protocol - used for eUSD Revenue Share Proposal Updates. If we decide to remove index DTFs from the pilot then I think i’d be happy for the programme to go ahead as planned and for delegates to only vote and comment when issues arise but will think further on this also.

Quite a long 2 cents here… I’d be happy for join the next call regarding a delegate programme if one does occur. Alternatively i’m sure me and Raph will be discuss these points further on the weekly GovOps call and welcome anyone to join if they want to discuss it further publicly.