Uniswap Revitalization and Growth

Proposal Discussion
1

Someone recently asked me what I would do to significantly improve the state of Uniswap if I had unlimited resources.

Firstly, we need to set a clear objective: increase Uniswap’s market share.

How can we increase Uniswap’s market share?

  1. By supporting the latest emerging EVM chains and securing Uniswap a dominant position early
    • For example, Monad, Linea, Scroll, Polygon zkEVM, Bera, Taiko, etc
  2. By further investing in current deployments where Uniswap is not a dominant player
    • For example, Binance Smart Chain, zkSync, Base, etc

Since Uniswap v3 launched, little has been done to drive the growth of any Uniswap v3 deployments outside of Polygon, Optimism, and Arbitrum. Of which, each strongly benefited from early mover advantages. Today, there are 13 deployments of Uniswap v3. Many of the new deployments are newer chains that, while today, don’t have the usage seen on Arbitrum, Polygon, or Optimism; one or multiple of them will likely grow to be as big or bigger.

On each of these deployments, Uniswap is currently the underdog. We’re competing against Uniswap v3 & v2 forks and other concentrated liquidity protocols, which often have more focused resources for marketing and distribution than Uniswap and often boast close relationships with the chain’s team.

The good news is these chains are still generally nascent. So, if Uniswap acts quickly, it can take the lead spot and likely hold it thereafter, thanks to its robust ecosystem of tooling and support.

What would a good plan of action include?

We develop a Uniswap v3 onboarding package!

  • $250k in allotted UNI to dedicate to kicking off the liquidity incentivization on the chain for 3 months (with frontloaded rewards) and 4-5 key pools to incentivize.
    • Classic pairs like ETH-USDC, WBTC-USDC, USDC-USDT, and one local pool.
    • An APY of 10% and $250k allocated across three months would incentivize $10M in liquidity.
  • A partner protocol/app to execute the UNI rewards program live from day one.
    • Let’s bring back the Uniswap v3 staker or pick a partner to handle the allocated rewards.
  • A Uniswap v3 frontend live from day one.
    • Oku is already leading this effort for zkSync, Scroll, Rootstock, Boba, Moonbeam, and soon Polygon zkEVM.
      • For Oku to support a new chain, it’s $45k for the initial integration and $5k/month for 12 months. This covers getting the new chain onto the frontend, the Oku API (free), our cloud costs for hosting the API, our global system for quoting, node requests, and DevOps maintenance.

Once governance decides on a standard package, when a new chain wants a deployment, we can include this package approval and roll-out as part of the governance proposal. This also ends the current status of rubber-stamping deployment proposals and provides a reason for new chains to seek the support of Uniswap governance proactively. Also, delegates can vote on which existing deployments should receive an onboarding package.

Uniswap could quickly take the lead on 5-10 chains without spending more than $2.5m. If one of these chains grows into a major player (like Arb/Op/Poly), it will have paid for the entire program multiple times over (assuming the fee switch is someday turned). Providing a modest onboarding package helps Uniswap diversify and develop new markets without waiting to see which chains become long-term relevant - at which point it is often too late or too costly to get market share.

I’m posting this as a discussion topic. If you support this or a version of this idea, please reply here or give me a ping, and based on support, I’ll consider fleshing this initiative out further.

24 Likes
2

Love the initiative and focus on core KPI of market share. Downstream of that is volume. Would be supportive of standardizing a process for launching new chains.

6 Likes
3

Great idea! The cost is low considering the goals.

If I am understanding the package correctly, there will be two different functions 1. The front-end UI options and 2. The staking contract, and who will run it

  1. I remember the Uniswap UX having the staking options. Although it was not used very long. Is it possible to fork this staking UI into Oku or other UI’s looking to provide staking access? This gives option to a recommended frontend as part of the package, but also opens up to new teams looking to break into the Uniswap V3 trading user interface space. It would help with directing users to a lower cost trading interface on newer chains.

  2. The backend staking contract would be a Uniswap Foundation/protocol/app package that can be plugged into from Multiple UI’s. Perhaps the chain chooses the staking contract manager?

5 Likes
4

It’s a very interesting idea. We would suggest that the amount of UNI is allotted based on a percentage of TVL and Trading volume on the chain but with caps.

For example if X chain launched 3 months ago and has $100m TVL + $40m Average Daily Volumes through AMMs, then Y% of UNI is allocated.

Reasoning behind this is that until deployment happens, it’s more likely than not that the chain has grown exponentially and thus the set amount of $250k could be not impactful at all.

We also agree on focusing those incentives into “blue-chip” pools.

8 Likes
5

this is a great idea!

there is really no reason that uniswap should be losing market share to generic forks across different chains. another major area where uniswap wins is through a powerful brand. a lot of newer chains have DEXs from anonymous teams, and rug pulls have become very common across a lot of these chains, especially when looking at something like zksync.

the proposed incentive program, along with the accountability committee, can really drive uniswap’s dominance further. one thing to consider is the question of who would be in charge of managing this program - would it be added to the accountability committee’s duties? would it be a separate working group?

regardless, at surface level i like this program and its goal. we at blockworks research are eager to help out in any way possible in getting this across the finish line :saluting_face:

7 Likes
6

This is a nice initiative to attract new users from these new Layer 2s. For the distribution, I suggest Uniswap utilize Merkl for fairer and better distribution of the $250K $UNI incentives

5 Likes
7

I’m a big fan of this idea. To date, I think Uniswap has largely relied on brand recognition to drive market share. I think we can do more. I’m supportive of making co-incentives a standard part of chain deployments.

I think it’s worth considering a parallel program designed to co-incentivize growth on existing chains like Arbitrum where there is still significant market share to be had and a clear opportunity for Uniswap to acquire significant grants for this purpose e.g. https://snapshot.org/#/arbitrumfoundation.eth/proposal/0x8112be08246466f870d0b91590fe99211f73d15cfdadac62ff3f1e6b2f74869a

8 Likes
8

Great idea that could indeed be a good way to drive Uniswap’s growth on emerging chains!

Jumping in to mention that Angle Labs has Merkl available to help the DAO distribute rewards, in line with @Jl_Defiedge’s recommendation above!

Briefly, Merkl is currently used to distribute approx. 1.8M ARB to Uniswap Arbitrum pools, 50+ Uniswap v3 pools have been incentivized through Merkl by various protocols and on various chains, 8+ liquidity managers have been integrated to Merkl to manage liquidity on Uniswap v3, and Merkl is today the most familiar, easy, and straightforward way to incentivize liquidity on Uniswap.

In case this initiative goes forward,feel free to reach out with any question or ask directly here. Happy to help and see this type of proactive developments!

5 Likes
9

Love the initiative but aren’t we better off waiting to do this on v4?

2 Likes
10

Thank you everyone for the support. Seems like this idea has some legs!

@TimeRows Uniswap did create the Uniswap v3 Staker Contract, but I don’t believe it has been used by the DAO before. We need something that can quickly go to new chains and low-friction for users and developers. I will do more research on options, but I think Merkl, which is like a gen2 generalized rewards system for Uni v3, is probably our best bet. Their system doesn’t require staking; it’s proven, and they are already on some of the newer chains that would be good for deploying this onboarding package.

@0xkeyrock.eth I think for the purpose of this package, we should assume the chain doesn’t have meaningful TVL or trading volume because the idea is to deploy this onboarding package at the chain launch or close to it. For example, Polygon zkEVM has a nascent DeFi ecosystem today, but that won’t be the case in April. It would be ideal to deploy this package ASAP before it ramps up to secure Uniswap’s position. Maybe there could be a follow-up package after this onboarding package that would be later developed for chains the DAO wants to further invest into.

@0xpibblez My goal is to create a package that is as concise and objective as possible to minimize the human management required. That said, we’ll likely need a multisig to do the off-kick transactions that start incentives on new deployments, but once started, the ongoing work should be non-existent. Perhaps the Accountability Committee can assume that role or one of the other existing multisigs.

@Jl_Defiedge Yeah, I think Merkl is a good option. I’m going to do more research as well.

@Frisson Good call out on Arbitrum. Maybe the UADP can take the lead there. cc @Juanbug @AbdullahUmar

@BlockAdopter Great point. I’ll reach out.

@Figu3 Uniswap v4 (by my guess) is 3-8 months away. Let’s use that time to secure Uniswap a solid position at emerging chains before v2/v3 clones secure their first mover advantages so that when v4 is ready, we’ll be in a great spot to roll it out across the ecosystem.

8 Likes
11

Yeah this is a great idea. @AbdullahUmar and I have been keeping a close eye on the LTI’s and will certainly look to apply for something.

5 Likes
12

I’d support such a incentive package. For what it’s worth, the benefits from a $ spent on incentivizing liquidity on a fledgling chain is likely to be much higher than from the same amount spent on an established one.

However, I think it would be better to do a brief survey of the available options for the frontend and the reward distribution system. It would help to make a more informed decision, and identify any shortcomings / blockers in the existing offers. Maybe foundation can arrange it?

On the potential new Arbitrum incentive program, as @BlockAdopter mentions, the DAO is currently already running an incentive program on Arbitrum, where 1,779,950 ARB tokens (>$3M in the current prices) are distributed to liquidity providers. I’m sure there are some lessons to be learned from that before starting a new one.

6 Likes
13

Very supportive of this initiative - i love the framing of a deployment vote changing from a rubber stamp to an action with an actual cost. Let me know if there’s anything I/the UF can do to help.

6 Likes
14

I do think one thing to do note is once the incentive runs out , how to continue to be competitive.

Another is also whether it makes sense to spread to all mainnets and L2s but rather focus on 2-4 viable chains and really push toward those selected chains.

3 Likes
15

@kfx, thanks for the support.

Regarding the reward distribution options. Setting aside a custom build, there aren’t too many options. Merkl seems to have the most flexible one because it doesn’t require users to stake their position. Merkl runs an off-chain program once an hour to direct incentives. Since it’s an off-chain calculation, they can allocate rewards more easily and efficiently than in an on-chain program.

Another important thing to remember is the ease of integrating new chains. When I spoke with them about this idea at the end of last week, they were excited and said that going to new EVMs is not too hard for them. They need a one-time setup fee of €20k for going to an entirely new chain and €10k for a new Uniswap v3 instance on a chain they have support for.

It’s also worth noting that other projects on the new chain looking for a liquidity incentive management system could use Merkl and Uniswap v3.

If there is a particular avenue you think should be explored, feel free to post it here.

As for frontend options, I’m biased, of course, but I think Oku is in its own category. The other Uniswap v3 frontends tend to be much simpler and generally rely on other infrastructure. With Oku, we’ve built it to be entirely standalone, and we have a lot of experience deploying the core protocol and the necessary periphery contracts for new deployments. Outside of Uniswap Labs, I don’t think more than a few other folks have that experience. Lastly, we only support Uniswap v3 on Oku. Most other interfaces support competing DEXs.

@Doo_StableLab Good question. My hope is that three months of incentives and the deployment of Merkl and Oku will give Uniswap a good hold. Obviously, when incentives end, we can expect a drop in liquidity, but the hope is it’s not substantial. Perhaps in the 3rd month, the DAO can discuss further incentives if delegates think it would be useful. It will be easier since Merkl and Oku will already be live.

4 Likes
16

A few delegates have mentioned adjusting the incentive amount for the Onboarding package. I had initially suggested $250k, mostly because I thought it was a reasonable minimum for the program.

In my initial post, I estimated that $250k in incentives, distributed over three months at a reward rate of ~10%, would incentivize approximately $10M in liquidity for three months.

The below poll is to collect a quick sample of opinions from delegates on what they think a good amount is.

Uniswap v3 Onboarding Package Incentives
  • $250K
  • $500K
  • $750K
  • $1M
0 voters
4 Likes
17

Thanks for the writeup @getty! Some more thoughts.

I think it’s important to everyone to see that the options we select for the package are the best available options at the moment, not because of personal ties to delegates or other reasons. You have put forward a clear rationale why Oku and the Merkl protocol are good options suitable for the task. What would make most sense to me is to invite anyone to come forward with any alternatives they offer / could support with votes (perhaps in this thread itself). If there are alternatives, we vote for them. If there are not, we go with Oku & Merkl protocol.

Re: compensation. Would the 20k+10k EUR fee be additional to the 3% cut Merkl takes from the rewards? If the DAO distributes $1M rewards on a chain then Merkl already gets $30k in fees, which already sounds like a reasonable compensation for their integration efforts, which I imagine aren’t too extensive?

Re: pools to incentivize. Maybe leave the exact pools to the chain itself, as well as the reward distribution settings. (Merkl needs to be told the % of rewards proportional to the fees collected / % for token0 in the pool / % for token1.) The DAO could put some only basic constraints, like that no more than 20% of the incentivizes should be spent on small-cap token pools, to avoid any shenanigans where they spend all of it to pump their own token.

Re: amounts. I’m not going to unconditionally support e.g. $1M for any chain. It’s not super hard to set up you own rollup already now, and it’s getting easier by the day. There will be many low-effort L2 and L3 popping up. The reward amount could be tied with some KPI the chain has to hit, either a minimum TVL upfront, or some minimum growth during the program, for a tiered distribution. On the opposite side, distributing even $1M on Arbitrum will be a drop in the bucket; IMO better to aim this incentive package to newer chains and go for dedicated grants on these larger chains, looking for external incentives to attract.

Also, should we allocate some initial budget for the program, like $10M, allocate it on first-come-first-serve basis, and then re-evaluate the results?

7 Likes
18

GM. Thanks for the quick reply.

I agree it’s important for the process to be open. I welcome anyone in the ecosystem to post other avenues for delegates to consider for both the frontend or the reward system.

Regarding the Merkl compensation. The one-time setup fee of €20k for going to an entirely new chain and €10k for a new Uniswap v3 instance on a chain they support were based on $250k of incentives. Since we’re discussing increasing the incentives, I spoke with Merkl about updating their pricing. They have offered a 25% discount on their base 3% fee for incentives distributed between $2.5m-$5m, a 50% discount on incentives distributed between $5m-$10m, and a 75% discount on all incentives above $10m in a 365-day period.

For the pools to direct incentives toward, ETH-USDC 0.30%, WBTC-USDC 0.30%, and USDC-USDT 0.01% would be the three anchor pools; then, a fourth pool could be considered if there is a popular chain-specific asset. For example, if we were to deploy this program on Polygon, a MATIC-USDC pair would be a good idea. Generally, we should stick with blue chips.

As for the Merkl configuration, I’ve been trying to gather some data points as there doesn’t seem to be a “best” configuration. Currently, the Uniswap Arbitrum Merkl incentives use a 1%-1%-98% (token0-token1-fees), which heavily directs liquidity toward the most actively contributing liquidity positions. That may be good for blue-chip pairs like the ones I’m suggesting. If you or other delegates have thoughts on the configuration, it would be great to exchange notes.

Now, for amounts, when in doubt, we should default to less rather than more for the program’s inception, but then, in exchange, we should be liberal in deploying the program. If we default with a lower amount, like $250k or $500k, but then decide for a specific chain to go with a higher number, it’s easier to go up rather than down.

You’re right that creating a new chain has never been easier. So, it will be key that delegates decide which chains make sense to deploy this onboarding package and which do not. Although, we should be hesitant to set hard rules like a TVL requirement. I suggest we leave it to chains to make their pitch to the DAO and for delegates to conduct their due diligence. Ultimately, this package is meant to be easily deployable to new chains, but changes could be made on a chain-by-chain basis.

2 Likes
19

Thanks for starting this discussion @getty; we agree with an incentive program to bootstrap liquidity on promising chains deploying Uniswap. This could strengthen our position where we are not the leading protocol in these chains’ early stages of growth. Some initial thoughts:

Incentive Amounts

Regarding the amount discussed, a higher incentive would allow chains to add more pools, extend the incentive period or raise the incentives on specific pools as the chains see fit. For this reason, we support up to the 750k option, but as a maximum amount to be requested.

Assuming a deploying chain is not guaranteed liquidity for bootstrapping, and there will be a request process, it is appropriate that the deploying chain specify an amount that is right-sized for them with a specific plan in place for its utilization. The goal here is to increase the efficiency of the funding while encouraging the recipient to provide clear intentions for its use.

Management of Requests

Would you be open to this decision being tasked to a smaller group or attached to the incumbent chain’s deployment proposal? Not to expand their scope, but for the sake of simplicity we would be comfortable if the existing Uniswap Deployments Accountability Committee had some discretion or authority here.

To mitigate spam or any misuse of funds, we suggest a pre-defined list of pools that would be valuable in attracting liquidity for Uniswap ahead of time. This list would also have the added benefit of streamlining decision-making and serve as a guide for the deploying chains.

Distribution of Funds

karpatkey has experience working with Gnosis Chain bootstrapping AMM pools and pairs. In addition, we would happily serve this initiative as a non-custodial layer between the incentives protocol (like Merkl) and the DAO-related wallets. With the use of the Zodiac protocol and its role modifiers, it is possible to grant specific permission for a manager who will act on the DAO’s behalf when interacting with external protocols.

4 Likes
20

Thank you, I’m glad you think it is a good initiative.

Sure, the requestor can always ask for a different amount. My goal for this onboarding package is to set a standard to deploy easily, but amendments can always be made with delegates’ support.

Overall, I’d like to keep the Onboarding Package as simple as possible to limit the points that require decisions or administration. The core decisions of the package, like the amount of incentives, the pools to incentivize, duration, incentivization tool, and frontend, can be decided by delegates. We will need a party to do the ops work to bridge incentives to the destination chain and trigger the incentives. After the incentives are set, nothing further should be required. I’m checking if the UF can take on this role; if not, I think the Accountability Committee would be the next logical group to do it.

For the pools to direct incentives toward, ETH-USDC 0.30%, WBTC-USDC 0.30%, and USDC-USDT 0.01% would be the three anchor pools; then, a fourth pool could be considered if there is a popular chain-specific asset. This should be defined in the governance proposal when requesting the package.

3 Likes