Treasury Delegation Round 2 Ideas - Expiring Delegation

Should treasury-sourced delegation expire? How? Lots of things to consider.

I think a good first effort will be simple. Eg there may lots of cool things we could do with dynamically decaying delegation but that’ll require lots of dev work to get done, and have many more inputs to consider when designing the program.

As a starting point, what if we started with two rosters of delegates. Roster A’s delegation would expire in 12 months, Roster B’s delegation would expire in 18 months. 2 months before those delegations were set to expire, an election could be held for the next Roster (C…N). All subsequent Rosters would have 12 month terms.

In my mind, this precludes granting any delegates tenure and eliminates the conflict of interest inherent in delegates having to vote to revoke their own delegation. What am I missing?

1 Like

Twelve months seems a bit short. Delegation periods of two, three, or even four years would still allow for periodic ‘new blood’ while reducing overhead and giving delegates more time to plan ahead.

1 Like

let me try to counterbalance this.

With the reward program for delegates, there is enough energy to actively manage expectation on a 12 months short expiration for delegations, and potentially we could iterate with different rules accotdingly to both what we learn and how the landscape changes.

1 Like

Any delegations from the DAO should have a maximum term of 12 months. We would also be in favor of a minimum of 3 months so new delegates have a defined period to prove their worth to the DAO. Of course, the DAO should have the ability to revoke the delegation at any time, but having an automated term would be ideal.

This could be accomplished by modifying the Franchichasier contract.

Why not add a time weighting? So

@GFXlabs wrote

maximum term of 12 months … minimum 3

And @kfx

Delegation periods of two, three, or even four years would still allow for periodic ‘new blood’

… can be both accomplished by "lend"ing delegate platforms either (hypothetically) 1M for 1 year or 0.25M over 4 years (or just a marketing boost of 4M for one quarter). If you think of it akin to a small business loan, you are basically boosting social trust according to a criteria to give delegates time to assemble a sustainable voting constituency. Some platforms (eg veto any wasteful R&D) would get instant kudos from VCs where others like regulatory compliance (boring) need long-term conviction voting.

As others mentioned, as long as there are ways to mitigate potential voting power cliff , expiring voting power might be sensible

1 Like

delegateWithExpiry(address, duration) is definitely a good idea and I think there needs to be more research on this.

However just a heads up, current delegate() and delegateBySig() is on the main UNI contract. So a lot of effort would need to go into the upgrade.

There are also other methods such as blockDelegations() that are worth exploring where a User who has stepped back or is blocked is unable to have tokens delegated to them.

I would also echo @_JoJo in that the duration period does not need to exceed 12 months, especially as a starting point. Having delegation periods of several years without any need for voting or an election to ensure continued involvement of a delegation seems sub-optimal - especially as these elections will hopefully not be particularly burdensome or costly

3 Likes

Interesting, I see the main arguments for shorter delegations are desire to experiment, expectation that the delegates need to prove their worth to the DAO, and fear that they will become inactive with time.

I suppose the DAO should not delegate to unworthy/unaligned organizations or individuals in the first place, but if that happens, an emergency vote of no confidence can be called outside the normal process.

As for inactivity, ideally we would have some way how to see the voting activity of an address on-chain, from the upgraded Franchiser contract, so that DAO treasury delegates who have become inactive can be automatically removed. Brevis or similar coprocessors could help. A less ideal alternative would be to have an off-chain solution for the same.

For longer delegation periods I see these arguments:

  • from a delegate’s standpoint, reduced uncertainty about whether it will continue to be able to post proposals and meaningfully contribute to quorum after the initial 12 months
  • reduced campaigning overhead for re-election, and other overheads for the DAO
  • precedents from other delegations - to my knowledge, third party tokenholders tend to delegate for 3 years or longer. In addition, these parties exercise almost no control / quality assurance over their delegates, while the DAO would do that.

The first two points are especially important for non-professional delegates such as developers and other aligned actors that we want to attract to the program.

2 Likes

any changes would be on the franchiser contract that we use to manage the delegations, not the token!

Oh interesting. Thanks for clarifying. Is there a link to that contract?

When I delegate from agora, the txn points to https://etherscan.io/address/0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984 which is what I was basing things off.

Yep!

Franchiser contracts (freshly audited) here
Deployed franchiser factory here
original franchiser repo (where ^^ was deployed from) here

And in our recent audit, OpenZeppelin wrote up a good description of how it works, you can read their report here.

2 Likes

We see the value in introducing an expiration date to delegations—preferably 12 or 18 months rather than multiple years. However, we suggest having the possibility of renewing the delegation to the same entity should these individuals bring positive contributions to the ecosystem. This could be done by introducing pre-defined renewal criteria (e.g. >80% voting on proposals, authored passed proposals, led positive-sum initiatives, etc) required to qualify for the renewal, and a vote to confirm the extension of the delegation period.

1 Like

Interested to hear how others feel about delegate voting power decaying. The parameters would need some experimentation but the goal would be to achieve a balance where:

  • Voters form a small “habit” in re-delegation and are maybe rewarded for doing so
  • The interval would need some experimentation eg. Every month is too often, 12 months is too long. Every 3 months seems sensible?
  • Delegates are naturally held more accountable given every quarter they are evaluated based on last three months performance. (non-issue for good actors)
1 Like

We believe that 12 months’ delegation period is appropriate considering the rhythm of DAO activities. We need continuous evaluation of delegates who are receiving delegation during these periods.

As GFX has mentioned, we should allow the DAO to revoke delegations and establish an environment where delegates can be continuously evaluated during their delegation period.

Additionally, we agree with a planned operation to start the next round two months before the current treasury delegation expires, to prevent sudden changes in voting power from disrupting the smooth progress of DAO governance.

It’s also important to consider delegates who declare not to continue to serve due to various reasons. We could do the “revoking” voting every time, but how about asking delegates to self-delegate a certain amount of the token as a commitment to be qualified and revoking it automatically if the self-delegated token is undelegated? In this way, the DAO may not need the “revoking” voting if the delegate acts accordingly by the rule.

This is a great way to manage expiring delegation on top of whatever hard limit (12 or 18 months) is decided for this iteration of this experiment. Simply removing delegate who fall below a certain threshold say 70% over the past 3 months and redelegate those tokens to active delegates would allow systematic increase in delegation to high performing delegates.

I also support a planned approach when it comes to implementing this with the aim of having this change executed onchain before the existing version expires in order to ensure that the DAO remains resilient towards failing to meet quorum requirements.

1 Like