Reevaluating AquaFi in light of UniswapV3 - #XIOfeedback

As you may already be aware, Uniswap recently announced some major changes to Uniswap in the form of version 3. There are some implications for the development of AquaFi protocol we like your feedback on.


A) Choosing to go ahead with Uniswap V3 support would result in Aqua being delayed until around mid to late June.

B) Choosing to continue with Uniswap V2 and/or Sushiswap support exclusively would result in Aqua being released around mid to end of April.

Questions for the community are therefore:

  1. Do you think we should delay the release of Aqua to support Uniswap V3?
  2. Are there any additional features to Aqua you would like to see that may be possible now due to Uniswap V3 that was not possible in Uniswap V2?

Read about it in detail…

You can read more about Uniswap V3 here.

I wanted to take a moment and break down exactly what this means for Aqua since the protocol was designed to take liquidity tokens with Uniswap LPs being one of the biggest target audiences.

I tasked the development team to perform the initial research into Uniswap V3 as soon as it released and I will now be summarising a lot of that information here.

The key decision that needs to be made here is whether we should delay Aqua to include support for Uniswap V3. The current estimated delivery date for Aqua is mid to end of April - this is if we do not incorporate changes for Uniswap V3.

Uniswap V3 Summary

  • Liquidity positions in V3 are represented by non-fungible tokens (NFTs) rather than ERC20 liquidity tokens.
  • Liquidity providers can provide concentrated liquidity - this means liquidity can be provided to a specific price range as opposed to the entire pool
  • There are three “pools” for each pair in V3, one for each fee setting - V3 supports liquidity fees of 0.3%, 0.5% and 1%
  • Pool contracts now contain the methods needed to add a new “position”, add liquidity to an existing position, remove liquidity, claim the accrued fees and the functionality to swap tokens.
  • When adding liquidity, users will be able to define the upper and lower bounds of their liquidity (concentrated liquidity)
  • A lot of logic such as initiating the pool and setting the initial price is managed by a periphery contract provided by Uniswap

Impact Summary

  • The main concern is with the method needed for fee calculation which will need reworking since we are using NFTs now rather than ERC20 LP tokens could have been easily computed upon due to their fungible nature.
  • The Aqua Primary Contract was designed to accept ERC20 tokens but this will now need modifying to accept ERC271 (NFT) LP tokens.
  • The Aqua architecture needs to be re-designed with these changes in mind whilst ensuring support for existing ERC20 tokens still exists.
  • The way in which fees are collected by the Aqua protocol needs to be re-designed since it’s not possible to take a small percentage of the LP tokens when focusing on NFTs within Uniswap V3.

Community Feedback

We are therefore looking for feedback from the community to determine what our next steps should be. We are currently going ahead with Uniswap V3 detailed research and have tentatively agreed to go down the V3 route however this could change based on feedback and guidance from the community within this thread.

  1. Do you think we should delay the release of Aqua to support Uniswap V3?
  2. Are there any additional features to Aqua you would like to see that may be possible now due to Uniswap V3 that was not possible in Uniswap V2?

Please, provide quick feedback to the first question directly in this poll!

  • A) Delay the release of Aqua to support Uniswap V3
  • B) Continue with Uniswap V2 and/or Sushiswap support exclusively

0 voters

Please vote in the Official poll


One question, if we launched the V2 version, would we ultimately upgrade to accommodating v3? And if so, would this require a token swap?


On this subject I think I’d rather we do what you and the team think is best, as I don’t know enough to choose. I’m erring towards delay for V3, otherwise what’s the point of launching a project that will be virtually redundant almost immediately?

the short term me wants V2 but the long term me knows V3 is the way to go. We would just be kicking the can down the road if we stay on V2.

The timing is unfortunate, but maybe the concept will gain from the update. Who knows, maybe the transition wont be that big of a setback. We can also surf on the waves of the V3 launch, I think it will be good timing.

1 Like

1. Do you think we should delay the release of Aqua to support Uniswap V3?
YES. Oh god YES.
Aquafi is just at the right time to start filling the niches for V3. X-token (XTK) is already getting a very high evaluation and a lot of attention after Hayden Adams retweeted them:

@alerk323, I’d like to know the same.


  • what is preventing the support of both liquidity models? Where the ERC-20 model is supported initially, and ERC-721 support is added when V3 is ready?

  • if we ONLY support ERC-721, then that means other protocols are excluded, right? That seems kinda maximalist to UniSwap. Are we betting that other protocols copy UniSwap and pivot to a ERC-721 model too?

1 Like

Thanks for putting this post out. Great transparency.

Do you think we should delay the release of Aqua to support Uniswap V3?

  • Yes. Voted. However, (in the same vain as XID-eacb5) if the development of Aqua on V2 is almost done, could it not be released, battle-tested, and then upgraded? What are the downsides to launching and then continuing the development on V3?

Are there any additional features to Aqua you would like to see that may be possible now due to Uniswap V3 that was not possible in Uniswap V2?

  • Is there a development middle-ground so to speak, whereby we could release with V3 qualities but only supporting certain popular NFT concentrated positions? For instance just supporting the top 5 current volume UNI LPs (plus XIO LPs) with 10% concentration at x slippage. So setting the parameters for a few popular NFT positions while a full rollout is worked on?

  • As this is an NFT platform. As a marketting campaign having a Aqua version of unisocks? Just a side thought.


In relation to this i believe we should take full advantage of what v3 has to offer so that when uniswap release it persons can come directly to aqua to utilize there nft and if it possible we could use a option to make use of the concentrated liquidity that persons provide.

I think we are all here for the long run, so the decision should be made based on what’s best in the long run.

This would mean that delaying a few months (which isn’t that long if you look back in a few years) sounds like the best option. It would be interesting to see whether there is a middle ground where we release erc20 and upgrade to erc271 (a lot of people also mentioned this as a suggestion). I don’t know if this will take a lot of work, that is something that the AquiFi team knows best.

So bottom line, the V3 way seems the best way to go, but maybe we can have our pie and eat it too(?)

Going with V2 is way too short-term, as much as I’d like to see Aquafi released. Voted on V3. Doing so might also give us some first-mover momentum.

1 Like
  1. Do you think we should delay the release of Aqua to support Uniswap V3?

Definaltey delay it and be on good path … its an upgrade.

  1. Are there any additional features to Aqua you would like to see that may be possible now due to Uniswap V3 that was not possible in Uniswap V2?

Since there are higher returns its already a win win and since the fee curve is adjusted it should be better for Aqua itself

This is a path I have been thinking about but have been advised that it would still require some delay since the main contracts need to be able to support NFTs. If we went down this route, there are two options:

  1. Build in no support for Uniswap V3, this means we would require a total migration since the contracts do not support NFTs (not a route I want to go down)
  2. Build in some support for V3 which would delay the current launch but would allow us to introduce V3 at a later date

Something to keep in mind is that if we add the minimum amount required to avoid a migration down the road for when we introduce V3, it would mean releasing some form of Aqua sooner BUT we would still need to go through the extensive unit testing, Dapp testing, test net and potentially another audit for when we introduce the update which supports V3. This means we could end up seeing V3 delayed even further - eg from mid June/late June to mid July/August

Personally, I believe if we are going to delay the project, we should include full support for V3 since it means we can perform all the above in one go for V2 and V3.

Yeah, I agree with this sentiment so I have tasked the developers to start working on the new architecture for V3. This could change depending on community feedback but so far it looks like the community agrees with this decision.

Nothing is stopping us from doing this but as mentioned above, adding support for NFTs (ERC271) would require pretty big changes to the architecture already so to me it feels like the right decision is to delay and include full support.

Yes that is exactly what it would mean but this is not a decision on the table. If we go ahead with support for ERC271, we would also support ERC20 LP tokens.

Unfortuantely no, there is no middle ground in the way you described. In order to have any support for ERC271 tokens in any form, we require big architecture changes - at which point we would be able to support all the concentrated positions.

Sorry I don’t understand this question - would you be able to elaborate?


OK, thank you for the detailed reply to explain the developmental difficulties of various options.

I understood the two options in the poll to be A) only ERC-721, or B) only ERC-20, but your explanation is that option (A) is delay of launch to support ERC-721, whilst retaining ERC-20 support. Perhaps you could write that explicitly in the poll / Snapshot page when we get to that point?

It’s great news, and I’m fully behind supporting both ERC-721 and ERC-20 if it means a short delay, yet still aligned with UniSwap-V3 ramp-up.


Goddamit, you explained it explicity in the summary. Sorry for missing that. My bad.

I think the central idea of Aqua is majorly dependent on the liquidity providers and will only work well where the majority of the liquidity providers sit.

As such, even though it may be delayed a bit to incorporate the Uniswap V3, I would strongly suggest to go with the Aqua full release will full and complete support of Uniswap V3.

However, as Aqua will be supporting other DEX’s as well which are still on ERC20 based liquidity, I would suggest to test release the tokens (maybe 10% of the alloted aqua tokens) and let the people taste it with Sushi swap and current Uniswap V2.

1 Like

I support the delay if we are confident that V3 support can be implemented by June/July. But I would caution against those assuming that Uniswap V3 support is critical for success.

IMO, Sushiswap is very likely to inherit a lot of liquidity at least in the short term, due to the current lack of interoperability between UniV3 and existing protocols. I also think Sushi has probably reached critical mass and has staying power, even though it is ultimately ‘just’ a fork of Uni.

If we can be among the first to launch with Uni V3 support, that would be fantastic exposure and is much better than having to do some kind of token swap down the line.
But if this is an enormous endeavor for the developers, with significant risks of major delay or failure, then I would prefer for us to just get a working product out there.

1 Like

I saw your edit but I think the vote could have been clearer too :slight_smile:

Unfortunately, I don’t think we can edit the poll on the initial post above without losing all the votes.

I am also not sure that we will need to go to a snapshot vote for this topic - it seems like the overwhelming response is to go ahead with Uniswap V3 at the moment. If we start getting a split then I would be supporting a token-based vote. I’d be interested to hear your thoughts on this - if we go to a snapshot vote now and wait for this thread to complete its course before moving a decision, we could potentially fall up to two weeks behind.

I understand what you are trying to achieve here but as mentioned in my post above, it would mean performing the audits twice, all the testing twice and generally just more work to have two polished versions for use.

Welcome to the forum - great to see a new face here!

I don’t believe this is an enormous endeavour for the developers. There are some significant changes introduced but I believe we are on top of these and have a pretty good handle on what changes need to be made within Aqua.

Thanks for the response. Given all that I agree with delaying and going all-in on V3, especially because this means V2 would also be supported (and thus non-uniswap protocols could still be used). It’s a bummer in the short term but it sounds like the right decision overall and will likely give us first mover advantage by launching soon after uniswap V3 goes live. Great work on all of this umar.

1 Like

IMHO, we should develope aqua for V3, so I agree for delay it. There’s no reason to spend time and resource in an already old product. better wait and get a full fresh innovative future proof AQUA.

1 Like

V3 is definitely the way to go, and even though I want it to release soon, I know how much better aqua will be if it supports V3. But what would hold us back from releasing in V2, and upgrading later? My technical understanding is limited as I am sure there is a good reason, could someone please eli5 to me?