If Uniswap goes this route, we need to put serious thought into what happens if the token price goes up or down. Token prices can see large movements for reasons beyond the control of the DAO. Service providers are paying their bills in fiat, so if the token price drops 2/3rds they can run into issues. Meanwhile, if the token 3xes then token holders may feel they are overpaying. I have seen both scenarios play out at other DAOs.
It would be beneficial to establish up front how these large swings will be handled, either throughout the year or during yearly reevaluations..
Firstly wanted to say I’m glad this proposal is happening and it’s definitely a step in the right direction.
I was a bit confused by one of the implementation details though. Why are we burning 100M of UNI tokens from the DAO treasury, which the DAO controls anyways? If the goal is complete alignment, shouldn’t we first at least burn the amount that Uniswap Labs collected in frontend fees over the last few years? Paid by labs. That seems cleaner to reverse SEC’s shenanigans.
Retail always loses to “pros.” That would still be happening even outside of this proposal. What’s the solution? Open question to anyone here. What can be done so that the playing field is level?
Calldata executes the expected outcome, with some informational findings.
The simulation and tests of the live proposal can be found here.
To verify locally, clone the repository, check out commit 5c4ccc9, and run:
forge test --match-path "src/uniswap/proposals/93 - UNIfication/*" -vv
Findings
Vesting Contract - Immediate 5M UNI Claimable
The proposal approves 40M UNI to the UNIVesting contract at 20M UNI/year, distributed quarterly. On January 1st, 2026, Uniswap Labs can immediately claim 5M UNI. If no more approvals are passed, the last tranche is in Oct 2027.
While the DAO (which in the contract is Party A) will sign the Agreements once the proposal gets executed, as verified in our tests, other parties have not signed yet.
The following reflects the views of L2BEAT’s governance team, composed of @kaereste and @Manugotsuka, based on our combined research, fact-checking, and ideation.
We voted FOR.
Before the vote, our research team reviewed the on-chain payload and validated the function calls against the published spec. We did not find issues that would prevent us from supporting this initiative.
We supported the proposal in the temperature check and we support it onchain, we believe it’s a step in the right direction for the Uniswap entities.
I strongly support the direction of this proposal. Turning on protocol fees and creating a model where UNI accrues value directly from protocol usage is a long-overdue step for Uniswap.
I particularly appreciate the decision by Uniswap Labs to eliminate interface, wallet, and API fees and instead align its success purely with the success of the protocol itself. This creates a much clearer incentive structure where all stakeholders.. LPs, builders, users, and UNI holders benefit from increased usage and growth.
That said, there are trade-offs and potential risks in any major structural change of this magnitude, and those downsides should not be ignored. However, when weighed against the long-term benefits of sustainable value capture, stronger alignment, and a clearer economic role for UNI, the advantages of this proposal clearly outweigh its disadvantages.
At this stage in Uniswap’s evolution, a decisive shift like this is necessary. I believe this proposal represents the right step forward for the protocol and the ecosystem as a whole.
Wanted to come back to this proposal because of the value this brings to token holders.
Wanted to bring up the idea of Staking $UNI tokens or having a pool strictly for this. Now I do not know how this would work or have the captivities to figure it out. But would definitely be an added plus to what uniswap has been doing and increase token value!
The UNIfication roadmap outlined here highlights a massive paradigm shift, especially regarding the goal to accelerate developer adoption via a zero margin Uniswap API and expand RWA partnerships.
As Labs scales this self serve developer portal and targets institutional grade asset onboarding, what are the team’s current thoughts on integrating privacy-preserving components, such as execution layer privacy tools or hybrid zero knowledge proof architectures, directly into the API and v4 hook frameworks? Providing native, compliant privacy options could significantly de-risk and accelerate the onboarding of those enterprise ecosystem players and RWA partners.
Uniswap Labs has not signed
Signed (using hal2001.eth, great for transparency)