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?
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?
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
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
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:
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.
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:
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.
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’
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.
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.
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.
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’
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.
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.
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.
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
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
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.
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.
Of course, the DAO should have the ability to revoke the delegation at any time, but having an automated term would be ideal.
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.
Of course, the DAO should have the ability to revoke the delegation at any time, but having an automated term would be ideal.
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.
any changes would be on the franchiser contract that we use to manage the delegations, not the token!
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.
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:
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.
As others mentioned, as long as there are ways to mitigate potential voting power cliff , expiring voting power might be sensible
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.
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.
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.
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
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
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.
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.
Of course, the DAO should have the ability to revoke the delegation at any time, but having an automated term would be ideal.
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.
Of course, the DAO should have the ability to revoke the delegation at any time, but having an automated term would be ideal.
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.
any changes would be on the franchiser contract that we use to manage the delegations, not the token!
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.
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:
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.
As others mentioned, as long as there are ways to mitigate potential voting power cliff , expiring voting power might be sensible
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.
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.
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.
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.
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.
