Uniswap V2’s Path to Sustainability and the DXdao - Forking Uniswap V2

Uniswap V1 has become an important piece of DeFi infrastructure. Indeed, for the DXdao’s own token DXD, only days after the launch of the bonded curve fundraise, the Uniswap V1 DXD pool address has the largest amount of DXD besides the DXdao . Uniswap V2 promises many improvements over V1, including ERC20 / ERC20 Pairs, improved functionality as a price oracle, and flash swaps (see https://uniswap.org/blog/uniswap-v2/). I and the devs I work with have the utmost respect for the Uniswap team and what they have accomplished. The V1 contracts are immutable, extract no fees to a third party, are arguably as decentralized as the Ethereum platform itself, and exemplifies what DeFi should be. Uniswap V2 is also immutable, but does introduce a .05% protocol fee.

Why the protocol fee?

In https://uniswap.org/blog/uniswap-v2/#path-to-sustainability Hayden Adams writes:

“To open a path to self-sustainability, the code for Uniswap V2 includes a small protocol charge mechanism. At launch, the protocol charge will default to 0, and the liquidity provider fee will be 0.30%. If the protocol charge is switched on, it will become 0.05% and the liquidity provider fee will be 0.25%.

This feature, including the exact percentage amounts, is hardcoded into the core contracts which remain decentralized and non-upgradable. It can be turned on, and directed by, a decentralized governance process deployed after the Uniswap V2 launch. There is no expectation that it will be turned on in the near future but it opens the possibility for future exploration.”

And then goes on to say:

“However, the best version of Uniswap will be one that autonomously incentivizes contributions to its own growth and development as well as to the broader ecosystem in which it exists—one that supports the contributions of the incredible community that has formed and continues to grow.

Uniswap is an ideal candidate for exploring decentralized on-chain cash flows. Without any additional growth, it will generate more than $5M in liquidity provider fees this year. If the protocol charge was on, ~$830,000 of this would instead go to a decentralized funding mechanism used to support contributions to Uniswap and its ecosystem.

This type of support boosts network effects from which Uniswap and its users benefit greatly. Incentivized contributions lead to increased protocol functionality and usage. Usage generates fees which attracts liquidity. Increased liquidity further entrenches Uniswap, attracting additional users, contributors, and integrations.”

There is a promise of future decentralized governance of the protocol fee funds. While Uniswap is a very popular project with many people involved in some form or another, it is unclear at this point how this decentralized governance process would work. Also, Uniswap is a VC backed company. They may be reputable VCs but they presumably have an expectation of making outsized returns for their venture fund investors. It is unclear what their expectation of profit out of this protocol fee may be.

The Role for the DXdao

The DXdao has an existing, though nascent, governance system and community. The DXdao could offer a decentralized governance mechanism for the protocol fee today. By forking Uniswap V2 and launching DXswap, we can make the decentralized finance ecosystem more robust.

  1. Diverse Approaches. Decentralized governance and building community are hard things, and we are just beginning to experiment and blaze the trail forward. By offering an alternative to Uniswap, we are increasing the diversity and resilience of the ecosystem and its experiments and increasing the chances that the future will be decentralized.

  2. Accountability. By competing with Uniswap V2, DXswap and the DXdao will hold Uniswap accountable in their plans to decentralize governance of their protocol fee.

  3. Positioning. By exercising the ability to fork and adapt protocols, the DXdao community prepares itself to fork other protocols. And demonstrates to the DeFi community that projects will need to both remain competitive and become more decentralized in the face of potential competition.

Other Opportunities and Advantages

Governing Liquidity Fees. Another opportunity the DXdao has is to allow governance of the liquidity fee. This can even be done per trading pair. That way, for instance, the DXD pool could be set to a lower trading fee if desired. Or a pool fee could be set higher. The interface between the DXdao and setting the liquidity fees can be changed so that in the future new governance approaches can be introduced. For example, the decisions on setting the trading fee could be set by the liquidity providers. Token projects and their communities could also participate in this process, possibly proposing and incentivizing changes to their token pool’s liquidity fee.

Decentralized Browser Application. The front end launched by the DXdao will be hosted on IPFS and ENS, making the full stack decentralized and creating better resilience for the system.

Transparent and Autonomous Token Listing. With the DXdao’s upcoming token TCR integration, the DXswap front end will be able to reference this TCR for its list of supported tokens. The process for adding tokens to this list will be open and transparent.


The works has already begun!


The most important changes introduced “dymanic fees” are explained in this issue and implemented in this pull request


Would a better approach be to approach the Uniswap team about using the dxDAO for that mechanism, instead of competing with them?

Uniswap has a strong team that continues to maintain the protocol (and tools) and a pretty large brand moat. It seems like it may be better to attempt to work together on this?


@econoar thats a good point. It is important to remark that the code changes in the fork are minimal, the code is extremely similar but with different governance mechanisms. The underlying protocol is the same, which means that you would be able to use Uniswap and DXswap at the same time, smart contracts can be created unifying this two “TokenPairManagers” and choose the better pair fro your trade, it can be in uniswap or dxswap.

DXswap wont be a fork in terms of codebase, but in terms of governance of the system.And I think that the ethereum defi ecosystem needs both solutions.


Dxswap will be installed with the same configuration of uniswap v2 with the difference that the fee receiver will be the Dxdao and the Dxdao can decide for the protocol fee and swap fee(per pair).

It could vote for no protocol fees forever which means Dxswap will be a public good like Uniswap v1. This path will never happen with Uniswap v2.

So thinking Dxswap == Uniswap v2 is not right.


Well Uniswap has the best interests of their shareholders in mind so they will indefinitely take a chunk off of the users. Where would discussing with them possibly lead?

I’m also thinking that adding governance on top of Uniswap does not seem like enough to make it a brand new product.


First thing that comes to my mind is what forking Uniswap does to the mood of the community. They have a huge name/brand, does this create hostility that ultimately backfires? The flip side is that doing this is a move in the right direction towards decentralization and maybe this is the best way to get there. As for the fees, when I saw the example of 800K being routed towards the protocol, that felt too high. Finding an annual or lifetime cap would be easier to swallow.


I’ll rewrite this later. In a more professional way. Got more ideas.

1 Like

Forking Uniswap increases decentralization and creates more accountability. Uniswapv2, based on conversations I’ve had with people outside of dxDao, is not showing that it’s able to be responsible with the brand image it has. Reducing fees while improving governance is a legitimate use of dxDao’s resources. It’s good for us and good for the wider community. Of course some people who are profiting from excessive fees might be unhappy, but most people will recognize that forks are good and necessary.


I’ve started to come around to this side of the debate as well! I’ve not been through a fork of another product so that was my gut reaction, but I agree that is promotes decentralization.


Why don’t we just manage liquidity pools on uniswap, instead of trying to copy/paste uniswap and add a governance layer?

I think instead of trying to rebrand forks as our own products, we could instead generate revenue for the dao by participating in the already existing defi infrastructure. We could have a dxDAO 0x staking pool, dxDAO Token Sets, dxDAO owned unv-2 tokens, dxDAO maintained collateral on compound and aave, so on and so forth.

In order to Forster adoption, wouldn’t it make more sense to work in existing protocols, instead of forking them and rebranding as our own like Tron tries to do to Ethereum?

Any serious dev who believes in decentralization would like to see the number of nodes/validators/pools increase. The fact a decentralized organization they could join would be decentralizing their protocol further would get better attention than a dao trying to jack their protocols with a few tweaks, calling their work ours.

1 Like

We also should consider what is going to be attract traders and liquidity providers to use dxSwap rather than UniswapV2. Realistically most traders won’t care if the 0.05% of fees in question are going to liquidity providers or to other places, so I think it’s mainly a matter of making sure the liquidity providers are incentivized to pool on dxSwap instead. But, how much revenue will actually come from dxSwap if there is no fee going to dxDAO? Is there any room for revenue in this model? Something to consider.

Edit: We could have the liquidity provider fee controlled by dxDAO. If the fee is high enough, liquidity providers might switch over, and the increased liquidity might decrease the slippage enough to cancel out the increased fees, from the point of view of traders. With an incentive for both liquidity providers and traders, we could then have a controllable protocol fee managed by the dao. We could tune these two parameters empirically as needed.