Does it mean after this proposal has been passed, we will need to wait for another (estimated) ~21 days for Gaunlet’s proposed plan to pass as well before the fee switch turns on?
2 Likes
Will there be any slashing for stakers?
The MAKER DAO buyback model seems way more effective and efficient. Number goes up with very little earnings compared to the mcap of MAKER.
1 to 2%(me being optimistic) fee earnings is way too little to make anybody stake anything.
I mean even ETH staking gives way more return.
But the public is so hungry for action, that this still could get voted through.
2 Likes
The design looks well thought out. I share other’s excitement to see movement with the fee switch.
One of the interesting things about the design is how the rewards can be delegated to another address. I am imagining that the individual staking if desired could pass fees to an active delegator, charity address, family member, etc. I am curious how the claim function works for an address that is set that is not owned. Will that other address have to claim or is it claimed from the address staking/delegating and then it is sent to the designated address?
Is the WETH required to deposit and claim for the pool fee’s permanently chosen in the code? Or can this parameter be voted in the future?
Great job on getting the ball rolling on this!
This comment is intended to be purely from a governance delegate perspective. I speak personally but feel this sentiment is likely shared: I want the outcome of this proposal to increase the total amount of $UNI that actively participates in governance. This is accomplished by both shifting around stagnant delegations but more importantly, bringing in more delegators to the protocol. In short, I’m concerned the outcome of this will be delegators delegating to inactive “burn” addresses in order to earn yield and not actually increasing governance participation… or as much as we may think.
The first idle delegations part is easy; in order to earn yield, delegators will need to shuffle their tokens around and in the process of which be forced to reevaluate their current delegations.
As for the second point, after personally chatting with dozens of VCs while trying to vie for delegation, the two main reasons for rejection were:
- There’s no financial incentive for us to do so, and it’s not worth the burden of figuring out custody, operations, etc.
- We’re exposed to an undetermined more amount of legal risk.
This new vote easily solves the financial incentive question. However, just thinking if I were a fund, particularly one who hasn’t delegated Uni beforehand due to legal concerns, I would simply delegate to myself, or a vacant burn address. This would qualify me for yield, yet have little to no extra governance related legal risk. Because of this, I fear that delegations from many new delegators won’t exactly increase the number of active $UNI in play.
Some solutions to this that I can think of are:
- Implementing a whitelist of delegates that qualify delegators to earn rewards. (Recognized delegates)
- Delegators only earn yields if they delegate to an address that has voted in >1, >5, … etc. number of votes in the past. (Active delegates)
Both of these I’m sure require substantial extra developer work. I’m not sure if these are the best solutions, but I think the problem described is genuinely a real one.
Happy to hear what everyone has to say and any other possible “solutions.”
Update after irl GovSwap event discussions:
- The purpose of this isn’t to strengthen an existing group of delegates. Delegators are still 100% free to delegate to themselves or anyone they want. That delegated address just simply has to partake in governance at SOME level. From a fund perspective, I think voting once introduces very similar legal risks as voting twice, 3x, 10x, etc.
Therefore, it should be a trade off:
- Actually get involved in governance, bear some level of legal risk, earn yield
- Stay not involved in governance, no yield
Ccing some people who all chatted on this, wanna hear your thoughts 
: @eek637, @kydo, @Getty, @DAOstrat.C, @AbdullahUmar, @404DAO
7 Likes
Sorry, I was wrong. I clicked on vote link in this article (Uniswap Revitalization and Growth Proposal) which is something different.
1 Like
Also, may I ask if the stakers will be rewarded even if they don’t vote?
1 Like
I’m broadly supportive of the proposal, and can only agree that the preparation work is excellent.
At the same time, I do have concerns related to LPs, and can echo the sentiment from @kassandra.eth and others in the comments that the needs of UNI stakers should be balanced with the needs of the LPs. LP interests should be more widely represented in the DAO voting, otherwise we have a situation where there’s taxation without (sufficient) representation.
A longer blogpost with my thoughts: https://atise.medium.com/protocol-fee-sharing-and-the-future-of-uniswap-9c636afeef28
4 Likes
Thanks to @erek637, Devin, and the team at the Uniswap Foundation for all their hard work prior to this proposal. We think that incentivizing a more active set of governance participants is one of the most important things for the Uniswap Ecosystem moving ahead. We are generally supportive of this proposal. We continue to monitor certain active legal and regulatory matters involving DAOs, but absent any unforeseen developments that might impact the proposal, we intend to vote in favor of it.
One of the parts to highlight is the incentive alignment among UNI token holders, delegates, and builders that this proposal creates. By tying programmatic staking fees to delegation, the UF is elegantly addressing protocol economics and ecosystem vibrancy, and laying a strong foundation for greater decentralization.
Any change to the Uniswap protocol, like this proposal, introduces uncertainty and could lead to additional risks. As we have written about extensively, we believe the Uniswap DAO should continue to investigate the adoption of a formal legal entity structure in order to better position itself to handle such challenges. However, because this proposal solely relates to a protocol upgrade and does not yet contemplate turning on the fee switch, a conclusion on legal entity structure does not yet need to be reached.
Based on the technical architecture, we believe the trade-offs weigh in favor of establishing a programmatic fee structure to boost participation. The heart of decentralized networks is their ability to channel different stakeholders towards a common goal – in this case, sustainable, long-term Uniswap ecosystem growth. This is a positive step in that direction.
We look forward to engaging in thoughtful debate about this proposal among Uniswap DAO members and we encourage all members to independently assess the risks and benefits of the proposal prior to voting.
Porter and Miles
None of the above should be taken as investment advice or an advertisement for investment services; Some of the companies mentioned above are portfolio companies of a16z. Please see https://a16z.com/disclosures/ for more information.
A list of investments made by a16z is available at https://a16z.com/investment-list/.
11 Likes
Good question! UniStaker can be configured to distribute any ERC20, but we quickly narrowed in on three potential Payout Tokens.
- UNI
- Dollar-denominated stables (USDC, DAI, LUSD)
- WETH
Given UniStaker’s immutable nature (see our pending response to GFX), our primary concerns in choosing the Payout Token were:
- Introducing minimal incremental risk of censorship resistance
- Assurances of long-term liquidity
On those axes, WETH was a clear winner. It also comes with some nice composability benefits. I’m sure you’re already thinking about a wrapper contract that allows stakers to automatically harvest WETH and do something clever with it on Eigenlayer.
3 Likes
Hi Squirrel - Once we’ve deployed the contracts and assuming a successful vote to transfer ownership, we won’t be able to adjust the payout token. This decision was made for a number of reasons, foremost among them was a desire to minimize complexity in UniStaker. Such complexity would be required for the contract to properly account for receiving and paying out rewards in arbitrary tokens. That complexity would increase the risk of bugs being introduced to the contract.
3 Likes
There are 3 core reasons here: maintaining immutability as a core value, optimizing for security, and we still preserve the ability to experiment in the future.
One of Uniswap Protocol’s core defining characteristics is its immutability (Ethereum Values section here). Immutability is important for a protocol as an input to credible neutrality, which in turn maximizes stakeholder trust. Specifically, trust that a protocol and its underlying mechanisms won’t change (either for or against their interests). It creates stability (Gwart sums up this benefit nicely here).
An additional benefit we get from immutability is removing the risk of bugs being introduced, and user funds being hacked in the future. When you look at major protocols which have been hacked in the past, many have occurred due to bugs which have been introduced during protocol upgrades. While there are certainly tradeoffs to this approach, by removing setOwner we are optimizing for future security of stakers.
We believe that this proposal and its accompanying technical changes achieve many goals which have been voiced by delegates in the past, and cement those in the protocol. While the changes are immutable, they also allow for future experimentation to the extent it may be desirable. For instance, delegators are able to route their rewards (or, with the development of new contracts, a portion of rewards) to arbitrary addresses in the future.
3 Likes
Hey John, we have two thoughts here:
-
UNI token holders who stake will by definition have “skin in the game” for Uniswap’s success. This upgrade directly ties their delegation decisions to the Protocol’s growth and success. With this model we believe they are not only incentivized to delegate but to delegate to those whose efforts have the greatest positive impact on the Protocol.
-
There are separate initiatives which delegates might put forward to reward the kind of activity you mention. Doo from StableLabs recently put one such initiative forward here. We’re excited to see further experimentation around incentive programs for positive behavior from delegates.
3 Likes
Good thoughts here - we appreciate the time spent thinking it through. We’re also interested in hearing feedback from the broader community on this.
Our initial reaction is that this change would create limitations on future optimizations on protocol fees. While in the very short term this might not be a focus, we think it’s likely that governance would be interesting exploring optimizations to mitigate negative impact on LPs, and to bolster delegator rewards, which are likely to require different fee levels set on a pool by pool basis based on the characteristics of the given pool.
2 Likes
Thanks Uniswap Foundation and @eek637 for putting up an amazing proposal.
We are largely supportive of the outlined specs and think it’s a solid foundation towards promoting a stronger governance ecosystem.
We do have some general thoughts about the overall design. As a starting point, the current contracts are rather barebone, simple, straightforward, and highly immutable which is perfectly fine and intended.
But echoing what @gfxlabs said, we think it’s important for V3FactoryOwner.sol to be able to change the owner of UniswapV3Factory.sol; or at the very least allow for RewardReceiver to be updateable.
By having RewardReceiver updateable you can have additional contracts between both UniV3FactoryOwner and UniStaker which could allow for experimentation while maintaining the state of UniStaker.sol (no need for redelegations, unstaking, etc.).
This would provide the DAO with future optionality as to how they could allocate protocol fees towards efforts that could further strengthen Uniswap’s governance I.e., rewarding top/recognized delegates & their delegators.
Incentive designs and mechanisms are constantly evolving in DeFi and we wouldn’t want Uniswap to be locked into a system that meets the needs of the community now but maybe not in the future!
3 Likes
Great proposal!
Could we expect the protocol fee to be 100% distributed to UniStaker.sol?
1 Like
As an active LP on Uniswap on mainnet, I disagree with any proposal that will cut LP share of the fees and will vote against if the revenue share takes from LPs to give to tokenholders.
LPs are the ones risking the capital supplying liquidity and should get the proper reward for it
2 Likes
- Great advice, this advice will help make uniswap even greater.
re: the impact of a protocol fee on liquidity providers -
cc @kassandra.eth @kfx @mjc716 @research
This is an important topic that we will address in two points: on fee switch impact on LPs specifically, and then on the UF’s decision to reward delegators.
First, we want to acknowledge the concern that the protocol fee hurts LPs. That is true – all else equal, a protocol fee would lower LP returns. Based on Gauntlet’s recent analysis here, we expect the impact to be muted across the pools that they analyzed. And based on our previous discussions with Gauntlet, we would expect that any pool which has more negative impacts on TVL (which we would interpret as a negative impact on LP returns) than anticipated would have its fees turned off as a result.
Second, in designing this system we considered how to distribute rewards in a way which would best sustain the Protocol for the long term. Over time, market conditions will change, new versions of the Protocol will be developed, and the surface area of the Protocol’s business model may expand. Our proposal empowers Delegates to design incentive systems for any group of protocol stakeholders, liquidity providers included, and adjust those systems as conditions change. Delegates are the only stakeholder, with their privileges over the Treasury, who have the ability to design, observe, and adjust these types of incentive programs to optimize for the Protocol’s best interest.
With that in mind, we would welcome any LPs that want to become delegates to do so! Create a platform on Agora to get started.
5 Likes
@eek637 If this proposal passes, what’s the procedure to turn on the protocol fees?
- Does the admin need to call functions inside V3FactoryOwner() to adjust fee? If so, what’s the plan and ETA for turning on fee?
- Can each pool has separate protocol fee? If so, what’s the required step for turn on the fee per pool?
1 Like