[3rd April] Save & Retrieve recurring donation data for projects
divine-comedian opened this issue · comments
We'll need to save & fetch certain information to show user's & project owners data regarding a given donation stream. In order to query the information we need to check the stream between the donor & recipient address (or anchor address (allo protocol))
When a superfluid stream is created through the Giveth UI we should save the following information to our back-end:
- Sender
- Receiver
- Super Token
- ProjectId
- txHash (for batch call or createFlow tx) - e.g. https://mumbai.polygonscan.com/tx/0x7845ac65b07ece9a4d2da0c94d1fe3032e62a0ce840f77e4b4c97f863ddbd056
We identify the stream on the subgraph or other superfluid service by the sender, receiver & token and we can alias it to Giveth by the saved projectId in our DB.
When we need to fetch the data in the case of showing recurring donations for donors & project owners (public & private view) this will allow us to know exactly what to query.
Optimism
https://console.superfluid.finance/subgraph?_network=optimism-mainnet
OP Goerli
https://console.superfluid.finance/subgraph?_network=optimism-goerli
related to Giveth/giveth-dapps-v2#3093 , Giveth/giveth-dapps-v2#3092
@jainkrati - I'm second guessing myself on this one - Do we need back-end services on this one or can we handle it all from the front-end with the subgraph to get recurring donation (stream) data?
@divine-comedian Good question, if frontend can communicate with subgraph directly, in the backend side we just need to fetch donation data fro superfluid and insert new record in our DB?
@divine-comedian Good question, if frontend can communicate with subgraph directly, in the backend side we just need to fetch donation data fro superfluid and insert new record in our DB?
I guess the subgraph can fetch most of the relevant data for a given stream - For each stream made we should save it (defined by sender & receiver) so we can know all of the streams that are associated with Giveth and then we don't have to sort the subgraph data to know which ones are related to Giveth and which ones are not.
This would be relevant when we show data on the public & private view of user recurring donations and also projects receiving recurring donations from users.
When the user makes a recurring donation we save the 4 following pieces of info to our DB:
- Sender
- Receiver
- Super Token
- ProjectId
When we need to retrieve stream data we can use this to query the subgraph
@divine-comedian @MohammadPCh @alireza-sharifpour
Do we have some test TXs for creating anchor contract and create recurring donation?
@mohammadranjbarz This is a batchCall tx: https://goerli-optimism.etherscan.io/tx/0xb68fb77e70a34efbcc19448a6f5b638b5cf2ecabf5a97f13981dceadea44cd74
Thanks, @MohammadPCh but don't you have any non-batch transaction?
@mohammadranjbarz We batch most of our transactions, we have 4 types of transactions:
- only wrap (this is not a donation transaction)
- Batch: Wrap + Create Donation to Project + Create Donation to giveth
- Batch: Create Donation to Project + Create Donation to giveth
- Modify Donataion to a Project
@mohammadranjbarz - I just added another piece of info - saving the txHash of when the recurring donation is created - we'll need this to show on the project donation table.
Also we'll need to know when a recurring donation stream has ended and then update it in the DB - so you might need to add a boolean field to indicate if the stream is active or not
As for knowing if its active or not we might need to follow it in this issue:
#1148
I suggest we add two tables for this feature
Entities
- AnchorContractAddress
| name | type | required | description |
|---|---|---|---|
| networkId | integer | yes | |
| txHash | string | yes | |
| chainType | string | yes | SOLANA | EVM |
| address | string | yes | |
| project | Project | yes | |
| anchorContractAddress | AnchorContractAddress | yes | |
| creator | User | yes | |
| owner | User | yes |
- RecurringDonation
| name | type | required | description |
|---|---|---|---|
| networkId | integer | yes | |
| txHash | string | yes | |
| chainType | string | yes | SOLANA | EVM |
| project | Project | yes | |
| anchorContractAddress | AnchorContractAddress | yes | |
| donor | User | yes |
- RecurringDonationStream
For it doesn't need to create new table, we can add few fields to current donation table to show it's a recurring donation stream
Flow
We should follow Giveth/giveth-dapps-v2#3477 (comment) that @divine-comedian designed it.
These are the steps based on that diagram:
- Create anchor contract for project if not exists
- Create a recurring donation for a project with needed params
- Every day we get recurring donation info from network and create a stream donation related to that recurring donation, in this way we would know how much of a recurring donation is related to this round, and filling price, givback params, ...
- If recurring donation has been stopped we mark that as finished in our DB
@divine-comedian @jainkrati If you have comments on it please let us know
@mateodaza I has implemented some of them in #1194 so you can read it and continue on that PR ( I will focus on that as well) but I think first step for you can be have get stream info of a recurring donation from network (I think we use all protocol or something like that) I can continue other parts then integrate them, WDYT?
Date of Completion : 21st Feb to unblock FE
I checked the logic done by Mohammad that was merged, and validated the flow with Mitch, I think what is implemented is enough. To finish the flow. @mohammadranjbarz right?
Aside from maybe getting the final amount, which im almost done, but thats part of the #1148 issue.
@MohammadPCh this is ready to integrate
I'm not aware about this issue could you please help me on this @mohammadranjbarz @MohammadPCh
is it ready for testing? it's on inprogress and assigned to me
@maryjaf As I know, @mohammadranjbarz is working on it. there is a problem with some batchCall that he talked about on the call, he is trying to figure it out.
Mohammad to take a look at the telegram and follow up on batch call issues
The problem related to batch call donation also has been resolved