Uniswap v4 and the DAO

On June 13, Uniswap Labs announced their vision for version 4 of the Uniswap protocol and published a repository with a draft of the protocol code. In contrast to the v2 and v3 protocol upgrades, which were delivered fully-baked, v4 is currently undergoing active development. Labs’ stated goal is to build “…in public, with open feedback and meaningful community contribution”.

The Uniswap governance community in particular is in an exciting position to provide such contributions and shape the next version of the Uniswap protocol. The coming months are an opportunity to define the DAO’s role in v4’s launch. This post:

  1. Describes where the DAO derives its agency and why it is in the community’s interest to engage in the v4 launch,
  2. Defines a loose process for generating discussion, aggregating feedback, and directing the output,
  3. Shares a rough timeline, and
  4. Lists a few questions to get your juices flowing.

The BSL and the DAO
Like Uniswap v3, v4 code is governed by a Business Source License (BSL) which prevents commercial or production use of the v4 codebase, unless an Additional Use Grant is granted. An earlier post describing the Uniswap v3 BSL can be found here; the main points also apply to v4.

The license specifies two ENS subdomains (v4-core-license-grants.uniswap.eth and v4-core-license-date.uniswap.eth) whose text records are used as references for distinct aspects of administering the license.

  • v4-core-license-grants.uniswap.eth will contain specific Additional Use Grants. Teams that receive Additional Use Grants can build on or deploy the v4 code for commercial application.
  • v4-core-license-date.uniswap.eth will contain the date at which the BSL expires and the code transitions to a GPL license. If no date is specified, the default transition occurs June 15, 2027.

The Uniswap DAO owns uniswap.eth. By a vote of UNI token holders, its timelock contract can determine:

  1. Recipients of an Additional Use Grant. Such recipients could include:
    a. Teams who the DAO would like to make changes to the protocol
    b. Teams who want to deploy the protocol on non-Ethereum chains
    c. Teams who want to leverage the code to build new protocols (ie Voltz)
  2. Whether the license should be converted to GPL earlier than June 15, 2027

Given these powers, along with the ability to turn on the protocol fee and direct its proceeds, it stands to reason that UNI token holders and delegates are incentivized to increase DEX volumes generally and Uniswap’s share in particular. They should therefore have reason to make v4 the best it can be and ensure its successful roll out.

Feedback Aggregation and Process
The UF is focused on facilitating public conversations where community members can discuss potential areas of concern and opportunities for enhancement for v4. These conversations may cover topics ranging from the codebase and protocol architecture to go-to-market strategy to user safety priorities and more. To jump start these discussions, I hope to connect one-on-one with delegates over the next two weeks. If you’re interested in chatting, feel free to book a time on my calendar here.

Community members are encouraged to start conversations around topics that are important to them in the forums. I provide a few guidelines below:

  • To help increase engagement, add context and detail to your post. In other words, a post that says, “We should do something about the protocol fee” is less likely to produce a useful outcome than one that says, “The current protocol fee implementation fails to consider X, Y, and Z. One potential solution would be to do A, B, and C” or “The current protocol fee implementation fails to consider X, Y, and Z. The potential implications are A, B, and C.”
  • Each post should have a stated goal. For the example in the above bullet point, that goal might be “Gauge concerns around current protocol fee implementation and discuss potential mitigations”.
  • To increase discoverability, use a unified topic format (see the ARB distribution topics). For v4 conversations let’s use [v4] - Topic and select the v4 Launch category.

Technical and architectural concerns, ideas, and potential solutions that are surfaced in these conversations should be funneled to the issues section of the v4 repo. Feedback not related to the code can be triaged on a case-by-case basis.

The UF is thinking about v4’s launch in terms of three milestones:

  1. Protocol code published. Occurred on June 13, 2023 when the protocol repo was opened for public view and contribution.
  2. Protocol code frozen. The audit process will begin contingent on the successful integration of EIP-1153 into the Cancun hard fork. We believe the earliest this will happen is September.
  3. Protocol code deployed. The v4 codebase will be subject to extensive auditing before it is deployed. We do not currently have an indication for how long the auditing process will take. Estimates range from one to four months.

The above timeline is purely indicative and it should be noted that the Cancun hard fork could be delayed, the audit process could be extended, and the protocol could be subjected to other security testing not discussed here.

Sample Questions
As a delegate or token holder, your opinion on the questions below matters. This also stands as a call for similar questions; post them in the comments of this post.

  • What are your priorities for the scope of protocol governance in v4?
  • What are your priorities for the implementation of protocol fees in v4?
  • What are your priorities for user (swapper, liquidity provider, unknown hook stakeholder) safety in v4?
  • What are your priorities for Additional Use Grants and non-Ethereum deployments of the protocol?
  • How can the DAO best assert its agency in the launch of v4?
  • What are the hallmarks of a successful v4 launch?

Updated to clarify that the audit process will not begin until the code is frozen.

It seems to me that there is a lot of complexity in the specific hook implementations. While it might be a stretch for the DAO to regulate hook usage, I was curious as if there was any planned documentation or guidelines for writing effective, secure hooks.

For example, documenting the different trust assumptions and potential foot guns that developers need to keep in mind seems like it could be very useful, especially when considering building toward a relatively novel construct.