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