Appreciate the update @DonOfDAOs and glad to see the treasury delegation proposal being stewarded forward by the UAC. Will there be an option to not choose any delegate in the list of options?
The IDV proposal does not clarify its stance on VP concentration amongst top delegates. We have seen tally’s impementation of staking rewards lead to heavy centralisation in other DAOs eg: rari, obol Since this is a concern cited by the UAC in its research and there is a suggestion to cap max delegation at 2.5M in the treasury delegation proposal, it would be helpful to have some parameters in the IDV proposal as well. It would be great if the IDV framework targets a ‘max’ delegation for each delegate and dynamically adjusts the APR based on how ‘far’ any given delegate is from that ‘max’ value, eg: delegators to delegates with 500K VP receive more APR than delegators to delegates with 1M or 2M VP etc…
Another helpful tip for the token holder is to delegate to a custom vault which auto balances delegations between delegates to maximize APR for the token holder.
TD:
If I’m understanding your question properly, this would be achieved by abstaining or not voting.
IDVs
We fully intend for the program to evolve over time, whether through refining delegate credentialing, experimenting with alternative APR models, integrating with third-party solutions, or adopting any other adjustments the DAO prefers. We’ll maintain open lines for feedback (both in one-on-one conversations and during community calls) so that iteration is community-led.
The current v1 design prioritizes speed, simplicity, and general delegate agreeability in effort to solve the immediate quorum deficit; the systemically critical issue. A flat APR keeps flows simple, predictable, consistent with respect to emission per delegated UNI, and uniform across delegates. Introducing dynamic APR creates greater complexity in payment flows, inter-delegate dynamics and delegator behavior, which we believe is better suited for experimentation once the baseline program is live.
That said, some measures (such as caps) can be introduced with relatively little complexity, and we are open to exploring those adjustments sooner. Our general stance is to work with the DAO to launch the simplest, agreeable version to address the immediately critical issue.
To be clear I don’t mean to discourage your ideation on end-state solutions. It is very valuable and highly encouraged. More so, my point is that we’d like to address the problem and then see these nuances deliberated in evolution of the program once live (hence our commitment to build and maintain). And, its worth noting, that we will likely benefit collectively from being able to leverage the live feedback loop as we iterate vs speculate/estimate the optimal structure pre-launch from an infinite set of possible structures.
We are strongly in favour of treasury delegation. While we do not see this as a long-term solution, it is a necessary step to increase the voting supply to a level that allows ordinary proposals to reach quorum reliably.
The recent vote on establishing Uniswap Governance as DUNI demonstrated that the community is both capable and willing to mobilise for proposals with significant impact. This is a healthy sign for Uniswap governance overall, but it also highlights the importance of building a consistent base of regular voters who can support the many “ordinary operational” proposals that have underpinned the protocol’s growth over the years. Treasury delegation offers a practical way to achieve this.
We support UAC’s suggested path forward and, at the same time, echo @SEEDGov’s recommendation that adding objective eligibility requirements for delegate candidates is likely to provide better results. We believe it is fair to include objective requirements in the application as suggested, determining the baseline for qualification to the election. Clear criteria—such as the suggested 75% voting participation—help set a fair baseline and ensure reliability from those receiving delegated funds.
On the IDV proposal, we view this as a more experimental but promising initiative. Running a 12-month pilot with @EventHorizon seems like a sensible way to test its effectiveness.
In parallel, we believe initiatives such as DUNA and UVN could significantly strengthen Uniswap governance and participation in the medium term. Until then, an IDV pilot provides a valuable opportunity to drive results in the shorter term.
We would like to inform the community that we have voted in favor of the GLI — Treasury delegation Round 2 proposal for the following reasons, as expressed in our delegation thread:
And we have voted against the GLI — Incentivized Delegation Vaults proposal for the following reasons, which we have already outlined in this debate:
hey @cp0x - the latest information we have as UAC is what was shared in the FFG #2 summary:
A16z, a participant of the FFG, clarified that the token delegations they retracted in June are due to internal structural changes. Whether the retracted voting power will be redelegated or not is still unclear, and no timeline for potential redelegation was provided.
ScopeLift has voted against the delegation vaults proposal on Snapshot. There are two distinct reasons for this.
First, there’s not currently enough clarity on the technical implementation of what’s being proposed. I respect the work of Event Horizon, and to their credit, when I reached out to ask questions, they were extremely responsive and helpful. They open sourced the distribution contracts at my request, and are working to provide more information and documentation. I suspect that in short order, we can get to a point where we have the requisite transparency on the technical details, and therefore assess the technical soundness of the proposal.
Secondly, and separately, I’m not convinced that the tradeoffs around IDVs are the right ones for the DAO, and it’s not clear to me from the conversation in this thread that they were sufficiently weighed.
As one example of this, it’s generally framed as a benefit that the token holder does not have to do anything to receive rewards, such as registering or depositing the tokens in a staking contract. However, it’s not obvious to me this is a net benefit for the DAO. A token holder who claimed at the airdrop, delegated to a “big name” they recognized, and has never so much as thought about Uniswap DAO since then, will receive the same rewards (if there delegate has remained active) as someone who is regularly engaged with the community, voting on proposals and/or changing their delegation based on their delegate’s behavior. Is this definitely what the DAO wants? Would some proof of “liveness” be a beneficial feature?
There are several other points like this that could be discussed. I don’t mean to elucidate each one in this particular post, but simply to call attention to the fact that the pluses and minuses of IDVs seem under discussed.
I want to acknowledge that I’m guilty here of something that has frustrated me in other contexts: I missed this discussion completely in the forum, until very recently, and am hopping in to play catch up now that a vote is actually live. It’s very possible that a number of discussions of these kinds of tradeoffs were had in other contexts, like UAC calls, that I was unaware of. I think this fragmentation of effort—where various members of the DAO don’t know what others are doing—is a structural issue with decentralized governance, but I do still feel bad for contributing to this negative dynamic in this case. I also still feel obliged, now that I am aware of the proposal, to raise my concerns and vote according to the information I have available.
I also want to acknowledge that I don’t have a totally unbiased view. ScopeLift built the UniStaker contracts, which sought to incentivize delegation through the distribution of protocol fees rather than treasury tokens. While the context is different, the UniStaker contracts could still serve this purpose, and it’s not clear to me if they were considered, and if they were, why they weren’t chosen. I will point out that UniStaker is not a product of ScopeLift’s, but rather an open source codebase we were given a grant by the UF to write. We don’t stand to benefit directly from the adoption of UniStaker by the DAO, (though perhaps indirectly it would be redound to our benefit reputationally).
While I acknowledge I can’t claim to be totally unbiased when I ask “why isn’t the DAO using UniStaker for this purpose?”, I still think it’s a question worth asking, and to the extent it was discussed at some point, I would love to understand the answers.
So, to reiterate, ScopeLift is voting against the IDV proposal for two main reasons: a lack of technical clarity and a need for a better understanding of the tradeoffs around the mechanism chosen. It’s possible ScopeLift’s vote will change between now and an onchain proposal if these concerns are addressed.
Finally, I want to reiterate again that I respect the work Event Horizon has done here, and have total confidence they’ve acted in 100% good faith. My current skepticism about the proposal has nothing to do with my opinion of EH as a team—quite the opposite.
I’m still mulling this proposal, but currently I’m leaning towards a voting no. As Ben mentioned above I should have also been more engaged earlier in the process, but it’s can be hard to keep up.
In transparency I’ve also been a strong believer in Unistaker and thought via a protocol that we at Tally worked on, that this problem could be solved more elegantly via Unistaker itself via open permission-less infrastructure built on top. In the process of working with a number of DAOs we learned quite a bit around the problem space.
Solution–Problem Mismatch
The problem as mentioned really is insufficient, engaged quorum. IDVs pay for passive delegation and require no proof of liveness, deliberation, or accountability. A wallet that never revisits governance earns the same as an active steward. That raises raw turnout without improving decision quality—at best cosmetic quorum, at worst lower‑signal votes. In this case raw turnout might just be count of votes, but fewer actual participants.
Entrenchment & Capture Risk
Rewards scale with existing delegate size and longevity, creating a positive‑feedback loop that entrenches incumbents and incentivizes delegate blocs to coordinate. This has been a major concern that we’ve encountered talking with other DAOS. This positive feedback loop increases concentration and reduces contestability—the opposite of resilient governance.
Treasury Inefficiency (No Durable Asset Created)
IDVs emit UNI continuously to rent temporary voting power. When emissions stop, alignment decays. The DAO spends scarce runway without creating a durable capability, product, or asset. Any program that requires perpetual emissions to sustain a metric should face a very high bar. It’s unclear to me if we’ve met that here. Uniswap is already pursuing mechanisms to attract UNI (e.g., UVN). IDVs would compete head‑to‑head in an APY race for the same token, fragmenting strategy and forcing the DAO to outbid itself. We should probably opt to pick one lever, not subsidize competing ones, or even wait a bit to see what happens with the A16z delegations and the Fee Switch (which might naturally bring in a new cohort of participants)
Hello @bendi and @dennisonb , collectively, the staker team. I appreciate your acknowledging the conflict of interest.
That said, I am surprised that the landing point of your team is to work against a solution that resolves a systemically critical crisis the DAO is facing (a $200M quorum deficit) out of personal product preference and the conjuring of competitive analysis. I’m also a bit confused why this discussion materialized only after the community supported and aligned with IDVs through temp check, and not during the ~2 months of forum discussion and multiple community calls. Ultimately, that is your choice, but the health of the DAO is critical, and deepening entrenchment and delay don’t serve the DAO or the community.
To establish the landscape: The UF has made no public forward progress on Unistaker for over a year. I would imagine that they have their reasoning. In part, I would imagine, this is rooted in the added complexities, level of protocol integration, and regulatory consideration required for staker. Simultaneously, Tally has made no efforts to collaborate with the DAO directly except perhaps this message explicitly in response to IDV’s direct DAO/community engagement.
In contrast, IDVs emerged from inception through direct communication with and voting of the DAO itself. The solution is intentionally lightweight, low-protocol commit/integration, and is designed to stop an acute issue.
The crux being, IDV’s, a simple, DAO-supported, and most importantly, immediately viable solution, not predicated on hypothetical requirements, is likely the better tool for resolving the DAOs complete bottleneck it faces today than an intentionally shelved product, contingent on uncertain protocol decisions, operated outside the direct discussion of the DAO.
I would encourage the Tally team to recognize that IDVs in no way change the future of staker or the pre-existing blockers it faced (e.g. if it were viable, it would be live after over one year of effort, and if it becomes viable through UF, it still can be). But, we can help the DAO become functional today, and further extending a greater than year-long delay in preference of staker, at the expense of the DAO, is only at odds with serving the best interest of the DAO and community.
This is untrue. IDVs are created for a select number of trusted, community-supported delegates with proven track records. Inclusion or exclusion, as well as all required metrics, are freely created or changed by the DAO and enforced by the UAC. In fact, several teams have already reached out and begun discussions about how they could support in the credentialing, reward distribution, and delegate metrics capturing, and participation enforcement portions of the program (these teams include Blockful, Curia, and Lighthouse). Should IDVs pass, these discussions will be hosted publicly, facilitated in community calls and forums. We see this as a multi-team, community-wide initiative. Tally is welcome to join the community in building this.
Beyond the above fact, that IDV recipients are beholden to valuable contributions. The DAO is $200m beneath quorum. If one truly considers the health of the DAO, quorum itself is far from a cosmetic issue.
As a first note, the idea that rewards ‘entrench’ delegates permanently is at odds with your latter statement that rewards lead to fickle, transient delegators. Either direct emissions lock delegators in (thereby durably increasing quorum) or they only support delegations so long as they are emitting (in which case adjustments to rewards, inclusion of new delegate IDVs, and changes made by the DAO and UAC would allow the DAO to granularly manage and distribute voting power). The former solves quorum with a single round, the latter allows for evolution of the program to give the DAO great power in ensuring productive and equitable distribution of VP.
IDVs are fully capable of including more delegates as they meet eligibility requirements. These requirements and potential for eligibility incentive quality contribution directly.
It is our understanding that staker relies on protocol-level fee distribution which has not been confirmed yet. Should unistaker not receive distributable protocol fees, it does not function. IDVs rely on treasury emissions, which are both reasonably small and guaranteed to be available now, when the DAO urgently needs it, in particular.
Unlike staker, and in our opinion superior to staker, IDVs are intentionally low-commit and directly managed by the UAC and DAO. While unistaker requires systemic commitment, difficult unwind, and higher effort change and interaction, the IDV program can address quorum today, be guided manually and directly by the DAO, and begin to sunset the very day UVN launches (should the DAO prefer this route to potentially synergistic approaches). This has already been addressed, though. I have full faith in the collective intelligence of the DAO to find a solution, quite possibly sunset, that does not bid against itself.
Should the community decide that lever to be IDVs, I would hope the Tally team would not begrudge the decision. To reiterate, halting solution progress for the DAO on the basis of hypotheticals suitable for staker, is strictly worse for the DAO.
Ultimately, this is not to say that there isn’t a future implementation of staker possible. Uniswap Foundation may decide it is viable at a later date. At that point, the IDV program, again, is in the full and manual control of the DAO, and can be sunset or synergized as deemed fit, similarly to considerations around UVN.
I think it is important not to miss the moment, so as not to end up in a situation where, due to the lack of quorum, we cannot resolve any issue
I also think it is important that the quorum is not reduced - this is an important and correct decision, in my opinion
I think this experimental solution is a good way out of the current situation
As I understand it, direct staking will be subject to legal problems, especially in accordance with DUNA
Also, I want to say that it is certainly important to check the contracts and this must be done before the on-chain vote is received, and at the moment we are voting for the initial decision - the technical part can be checked in parallel
I also think it is important that the quorum is not reduced - this is an important and correct decision, in my opinion
The distribution of 10 million UNI has already been carried out and this mechanism works, especially with restrictions of 2.5 (although it seems to me that this parameter can be reduced)
I have a question after the community call - how will the quorum of on-chain voting take place if we are gathering delegations for this quorum?
What are the possibilities?
This will indeed be a challenge. As we’ve seen in the recent vote for DUNI, it is possible to activate non-regular voters on critical proposals. The UAC and @DonOfDAOs are reaching out to these delegates, hoping to get their engagement on the GLI proposals.
There were reports that there would be an application form for Treasury delegation Round 2 earlier this week.
I may have missed something, but I don’t see it.
Hi all, late to the party here. I think i have a grasp on how this would work, but wanted to confirm. Can you list concisely where there are centralized points of control in the IDV system?
Asset Custody: The full emissions pool is retained within a UAC-controlled SAFE wallet. The UAC will transfer UNI as needed to the distribution contract. This means the vast majority of UNI at any given point will be retained by the UAC, as with many other initiatives.
Asset Distribution As mentioned above, the assets held in UAC custody are transferred to the distribution contract on an as-needed basis. Once loaded to this contract, rewards are sent directly to the recipient wallets.
Parameter Change: The DAO may elect to make changes to emissions variables, namely APR. This can be done by either Event Horizon or the UAC. Event Horizon has no preference toward retaining this capacity itself. Rather, it would be useful for the UAC to have the option to offload the technical change work to EH. That said, this can be reduced down to just UAC if generally preferred.
Can you walk through how these amounts will be calculated?
Also, and apologies if i missed a clarification on this, but my initial read led me to believe that which delegates have vaults is also gated. Is that correct?
Calculations: Rewards will be calculated by scaling an annualized fixed-rate APR to a daily rate. Each day, when the reward distribution is run by the contract, it will iterate over every delegate and perform the following process for each of their delegators:
Check that the IDV delegator is still delegating using the ERC20Votes function ‘delegates()’. If a delegator is no longer actually delegating, then the function will return either an address of zero, or a different address. In either of those two scenarios no reward will be distributed.
Check the balance of the delegator
Calculate the delegator’s reward amount using the following equation:
Delegate Inclusion: Delegates must be approved and added. The first batch will be done via snapshot vote. Changes can be made by the DAO via the UAC in the same way APR adjustments can be made.