Implementation of Uniswap Token Swap within Superfluid Donation Flow

[benefacto]

Business Description

This issue aims to refine and expand the cryptocurrency donation process in our application, making it more flexible, user-friendly, and secure.

Here's an overview of what will be accomplished:

1. Streamlined Token Swapping: We're simplifying the process of swapping various cryptocurrencies (like WBTC, cUSD, CELO) into G$ tokens. This will make it easier for users to donate using their preferred cryptocurrency.

2. Efficient Path Calculation for Swaps: Our system will intelligently calculate the most efficient path for each currency swap, ensuring cost-effectiveness and speed in transactions.

3. Seamless Integration with Superfluid Donation Flow: We're enhancing our application to dynamically handle different swap paths. This allows for a more versatile and adaptable donation flow, accommodating various types of cryptocurrencies.

4. User-Friendly Frontend Experience: The frontend of the application will be updated to support these new features, making it intuitive for users to make donations with different cryptocurrencies.

5. Compliance and Collaboration: Our team will ensure that the implementation aligns with the project requirements and standards. Regular communication and collaboration within the team are key aspects of this process.

In summary, these enhancements will significantly improve the way users can donate using cryptocurrencies, making the process more versatile, user-friendly, and secure.

Technical Implementation

1. Approve Swap

• Identify the tokens you want to swap. This includes the input token (e.g., WBTC, cUSD, CELO) and the output token (G$).
• Ensure that the tokens are first approved to swap as referenced in Uniswap SDK documentation (example code)

2. Fetch and Calculate Swap Path:

• Follow the Uniswap SDK documentation (example code) to obtain the Pool object that can be used for calculating the swapPath.
• The swap path should be encoded properly as required by Uniswap V3. This typically involves concatenating token addresses and pool fee tiers. Uniswap V3 provides a convenience method for this:

  
  import {
  encodeRouteToPath,
  Pool,
  Route,
  } from '@uniswap/v3-sdk';

const route = new Route([pool], token1, token2); const swapPath = encodeRouteToPath(route);

### 3. **Integration with Superfluid Donation Flow:**
   - Modify the `supportFlowWithSwap` function in your code to dynamically accept the swap path. This involves changing the function to take the swap path as an input parameter rather than using a hardcoded value. https://github.com/GoodDollar/GoodCollective/blob/2b506d9d4f84cb4ae395308fbd2ea0d315409bb3/packages/app/src/hooks/useContractCalls.tsx#L67
   - Update the locations in your code where the swap path is referenced or required. Ensure that the swap path is correctly passed to these points in your code.

### 4. **Frontend Integration:**
   - In the frontend, ensure that the `supportFlowWithSwap` function is triggered correctly for non-G$ currencies, and `supportFlow` is used for G$ donations. 
   - Update the frontend code to pass the correct token addresses as parameters, based on the user's selected currency for donation. https://github.com/GoodDollar/GoodCollective/blob/2b506d9d4f84cb4ae395308fbd2ea0d315409bb3/packages/app/src/components/DonateComponent.tsx#L399 https://github.com/GoodDollar/GoodCollective/blob/2b506d9d4f84cb4ae395308fbd2ea0d315409bb3/packages/app/src/hooks/useContractCalls.tsx#L68

### 5. **Compliance with Project Requirements:**
   - Work closely with your team members, especially Lauren and Vlad, to ensure the implementation meets the project’s requirements.
   - Regularly update and communicate with the team about progress and any challenges encountered.

### 6. **Testing Scenarios:**
   - Conduct preliminary tests, such as attempting real swaps using the `supportAndSwap` flow and verifying the data sources like the subgraph and blockchain.
   - Once a feature is operational, create tickets for further testing and assign them to Vlad or other designated testers.

## Estimate

Estimating the time required which involves integrating with Uniswap for token swapping and ensuring seamless Superfluid donation flows, can be quite complex. The Uniswap boilerplate setup itself is intricate, and integrating it with an existing application adds to the complexity.

1. **Requirement Analysis and Planning (6-8 hours):** Understanding the detailed requirements for token swapping, efficient path calculation, and integration with the Superfluid donation flow.

2. **Uniswap Integration Setup (15-20 hours):**
   - Re-configuring the Uniswap SDK.
   - Identifying and approving tokens for swapping.
   - Implementing the logic to fetch and calculate the swap path using the Uniswap SDK.
   - Integrating the swap path calculation with the Superfluid donation flow.

3. **Frontend Integration (12-16 hours):**
   - Updating the frontend to support new features, including UI components for selecting different cryptocurrencies and displaying the calculated swap paths.
   - Ensuring that the frontend correctly triggers the `supportFlowWithSwap` and `supportFlow` functions based on the selected currency.

4. **SDK Integration and Testing (10-15 hours):**
   - Integrating the SDK logic with the Uniswap swap functionalities.
   - Conducting SDK tests to ensure that the token swapping and donation flows are functioning correctly.

5. **Compliance and Collaboration (5-7 hours):**
   - Collaborating with team members to ensure that the implementation aligns with project requirements and standards.
   - Regularly communicating progress and addressing any challenges encountered.

6. **Testing Scenarios and Debugging (10-12 hours):**
   - Conducting preliminary tests including real swaps using the `supportAndSwap` flow.
   - Verifying the integration with data sources like the subgraph and blockchain.
   - Debugging and resolving any issues that arise during testing.

7. **Review and Refinement (4-6 hours):**
   - Addressing any feedback and refining the feature as needed.

8. **Documentation and Deployment (3-5 hours):**
   - Documenting the feature implementation.
   - Preparing for and executing the deployment of the new features.

Adding these up, the total estimated time could be around **65-89 hours**. This estimate assumes that the developer is proficient with blockchain technologies, the Uniswap SDK, and the relevant frontend and backend technologies.

[sirpy]

1+2 The methods and sdk I wrote are working and tested.

3. the usage is incorrect, the sdk has explanation for each input field. mainly as discussed with @Joshua-Jack in the past, you need to use uniswap sdk to fetch the "swap path" as input for the support with swap flow
4. give me examples and references to code how you handle errors
5. that should be mainly tested and verified by @decentralauren and @vldkhh once you have a working product

Regarding Testing scenarios and report first I expect a finished product that has been minimally tested by the developer. For example if a supportAndSwap flow exists the developer that does it should at least try a real swap and not just assume the code is correct. The same goes for testing all data that should be read from subgraph, blockchain or elsewhere, that should first be verified as working by the developer. @Joshua-Jack is supposed to know what has been done or not been done, I don't understand why we need to produce a report at this point in time on what's not meeting the requirements.

Once a feature is working if it doesnt have a ticket then you should create one and then assign it to @vldkhh for testing.

[benefacto]

Hi @sirpy , thank you for your recent clarification regarding the methods and SDK, as well as the guidance on utilizing the Uniswap SDK for the swap path. This is incredibly helpful as I navigate the existing framework.

I understand and acknowledge the expectation of delivering a minimally tested product. I will ensure thorough testing of the features from my end, and I'm currently reviewing the error handling approach to ensure it aligns with best practices. I’ll provide detailed examples and code references for further review once this is in place.

I'd like to bring to your attention that I'm stepping into this project at a stage where the budget is nearly exhausted, which limits the extent of the work I can undertake. Coupled with the limited context and handover, and the reduced availability of Josh for clarification, this has posed significant challenges. However, I am committed to making the most of the resources at hand and pushing the project forward as efficiently as possible.

I greatly appreciate your and the GoodDollar team's support during this transition. Once I have a functional version ready, I'll create tickets for comprehensive testing and verification.

Thanks again for your understanding and assistance. Your input is crucial in helping me to adapt quickly and contribute effectively under these circumstances.

[sirpy]

@benefacto regarding uniswap

1. the path generating code you shared doesnt seem to include the pool fee.
2. remember that in the swap flow user has to first approve the input token.

[benefacto]

@benefacto regarding uniswap

1. the path generating code you shared doesnt seem to include the pool fee.
2. remember that in the swap flow user has to first approve the input token.

Thanks for the callouts! I fleshed out the examples a bit more so that this issue should not sufficiently describe the implementation path at this point. Do continue to let me know if you notice any gaps though.

[decentralauren]

Hi @benefacto !

• The business description sounds accurate - there is nothing in there that looks new or incongruent with the prototype and requirements shared prior.
• I do not have the technical expertise to comment on the Technical Implementation or Estimates, though know that @sirpy and team have implemented uniswap elsewhere before so hope there can be significant reuse of that work (and a reduction in the overall hours scoped). So I defer to @sirpy to provide feedback on these items (looks like you were discussing already).

[krisbitney]

The approach described for implementing token swaps isn't ideal because it doesn't factor in the need to find the most efficient route given a set of pools. That's actually not a trivial problem.

I recommend using an API-based solution instead, like https://1inch.io/api/

It's easier and will provide better swap prices for app users

[sirpy]

The approach described for implementing token swaps isn't ideal because it doesn't factor in the need to find the most efficient route given a set of pools. That's actually not a trivial problem.

I recommend using an API-based solution instead, like https://1inch.io/api/

It's easier and will provide better swap prices for app users

We use uniswapv3 on celo specifically, if 1inch api works then fine, other wise the uniswapv3 sdk should be good enough

[krisbitney]

The approach described for implementing token swaps isn't ideal because it doesn't factor in the need to find the most efficient route given a set of pools. That's actually not a trivial problem. I recommend using an API-based solution instead, like https://1inch.io/api/ It's easier and will provide better swap prices for app users

We use uniswapv3 on celo specifically, if 1inch api works then fine, other wise the uniswapv3 sdk should be good enough

You're right, 1inch doesn't support CELO.

To use uniswapv3 sdk in this manner, I will need to identify and whitelist a set of pools that will provide the swap routes we want to support. We can support swapping a limited set of tokens to G$, preferably only those that share a pool with it.

I don't know how far along this feature already is. I'm not suggesting we need to redo anything that is already completed.

[sirpy]

@krisbitney Can you point to the docs? I believe there's an official celo token list, used by ubeswap, we can use that list. Just tokens that share a pool isn't a solution as there's basically just 1 main pool cusd/G$

[krisbitney]

@krisbitney Can you point to the docs? I believe there's an official celo token list, used by ubeswap, we can use that list. Just tokens that share a pool isn't a solution as there's basically just 1 main pool cusd/G$

Nevermind, you're right. There is a solution to this. https://docs.uniswap.org/sdk/v3/guides/swaps/routing

I translated the uniswap v2 and v3 SDKs to AssemblyScript before and refactored a lot of the Uniswap v2 and v3 front ends to use a async wasm module versions of the SDKs. That was more than a year ago, and the smart order router wasn't yet an available solution, so things worked differently.

[L03TJ3]

@krisbitney status of this?

[krisbitney]

@krisbitney status of this?

Completed

[L03TJ3]

@decentralauren @patpedrosa was it decided that for now we only accept G$'s donation?

@krisbitney or there is a bug as for me only the G$ token shows up in the currency list

[krisbitney]

@decentralauren @patpedrosa was it decided that for now we only accept G$'s donation?

@krisbitney or there is a bug as for me only the G$ token shows up in the currency list

I'm not aware of a bug. It was working last I saw. But one-time donations are only in G$.

[krisbitney]

[patpedrosa]

One-time donations can be made in any currency. The only difference between the flows is that one-time donations are not done with Superfluid.

[L03TJ3]

@krisbitney @patpedrosa

So to be super clear: On time payments > any token Streaming > only gooddollar

Is that right?

If yes then @krisbitney the token list is applied to wrong type of paymemt

[krisbitney]

One-time donations can be made in any currency. The only difference between the flows is that one-time donations are not done with Superfluid.

@sirpy @L03TJ3 This is not supported in the GoodCollective SDK. Is it the case that it is supported in the smart contract but the SDK is incomplete?

[krisbitney]

@krisbitney @patpedrosa

So to be super clear: On time payments > any token Streaming > only gooddollar

Is that right?

If yes then @krisbitney the token list is applied to wrong type of paymemt

In the GoodCollective SDK, only the method supportFlowWithSwap supports swaps. The others do not.

[L03TJ3]

@sirpy @patpedrosa need clarification on how this should (have) been implemented

[sirpy]

supportflowwithswap supports swapping tokens to G$ and then streaming the G$s @L03TJ3

[L03TJ3]

Okay. And for single donations? @sirpy

[sirpy]

@decentralauren @patpedrosa @L03TJ3 Firstly I would discourage single donations. And make recurrent donations the default. If we must we can probably add swap and donate single

[decentralauren]

@sirpy ok. We'll put a new ticket in the backlog for this to address later.