Open justjoolz opened 2 years ago
Your suggestion makes sense. Such a feature would be very beneficial to an operator who wants to give out special tokens.
This suggestion also means that a Claim screen for users also needs to be implemented. A simple screen can be created quickly. However, if a richer UI is needed, it will require more man-hours than originally planned, so we will need to prioritize.
@avcdsld agree that the suggestion is beyond the scope of the original bounty, but at the same time I thought it made sense to mention here as there is a definite overlap in terms of UX....
The Airdrop Dapp could be stand alone and optionally integrated into the batch transfer.
I've sketched out what the contract could look like here:
https://github.com/justjoolz/FTAirdrop/blob/master/cadence/FTAirdrop.cdc
@justjoolz It's great! Very well done sketch. Thanks. One thing to check, I think we need to do address validation here, right? https://github.com/justjoolz/FTAirdrop/blob/895ecb57943dc1738c90b0a4c92b66477f84e394/cadence/FTAirdrop.cdc#L88
And we also need to manage status to check if the user claimed or not.
That line is actually completely un-required, as is address validation as the Address is passed 'automatically' as part of the receiver capability and as such can't be spoofed.
I fixed the status of user claim bug and improved the error messages also caught another major bug in one of the assertions too :)
Also there is probably no need to allow user to specify amount to claim, can't think of a situation now where anyone wouldn't want to claim the full amount.....
Also there is probably no need to allow user to specify amount to claim, can't think of a situation now where anyone wouldn't want to claim the full amount.....
I agree with you. Also the current code does not allow users to know from the contract how much they can claim.
I am a little concerned about the current code.
This for
statement requires more Computation as the number of Drops increases and it is not scalable.
I would suggest that Drops should be stored in the creator's storage. We need a container resource for this.
https://github.com/justjoolz/FTAirdrop/blob/93cc70a2e9b59bf03df0c834d979cae8277f9f86/cadence/FTAirdrop.cdc#L56-L63
What do you think?
I see your point, there would have to be a large number of drops running concurrently for this to be an issue, but you are right it opens up the possibility of a griefing attack where a user creates huge number of drops to max out the script computation hard limit.... wouldn't affect the operation of the contract though
The alternative where a user creates a Drop resource and holds it in their own storage (in a DropCollection) would make checking all drops available to a user a little more complicated.
Also it would open up another attack vector whereby a user could for example unlink their public capability to a drop in progress, wait until it's finished and then claim all the tokens back..... storing the Drop resource in the contract avoids the Drop creator having such control/power.
The structure of creators having Drop resources in their storage is similar to FLOAT. Creators who want to airdrop can simply share the URL containing their address with those they wish to distribute.
Also it would open up another attack vector whereby a user could for example unlink their public capability to a drop in progress, wait until it's finished and then claim all the tokens back.....
Hmmm, I do not see the benefit of creators doing this. Creators are the ones who want to airdrop, so why would they want to prevent themselves from doing so?
Hmmm, I do not see the benefit of creators doing this. Creators are the ones who want to airdrop, so why would they want to prevent themselves from doing so?
Just pointing out that it introduces the possibility for bad actors to setup a drop then not honour it.
I see. Thanks! I would like to incorporate this optional feature in the near future.
This contract does something very similar:
https://github.com/Flowtyio/lost-and-found/blob/main/contracts/LostAndFound.cdc
https://earni.fi/ / https://github.com/Earnifi Is the best one I've found. Also it does have a premium feature where it shows some airdrops as a "?" and money value. These are legit airdrops. Ive been able to find most via twitter and reddit + current airdrop value.
@avcdsld happy to lend a hand if you want to collaborate :)
@unbrokentoken thanks for sharing, looks like that site is more of an aggregator than a drops service
@justjoolz Thank you, I will have a design demo completed and discussed with the Dapper Collectives within the next week or two. After that, if this feature is required as a request, we would love to have your help.
Did you meet with Dapper Collectives already?
As far as I'm aware, the primary use case for disperse.app on Ethereum is Airdropping ERC20 tokens straight into to a users account without the user having to do anything to receive the tokens.
On Flow this is strictly not possible. This is to prevent unwanted 'spam' tokens being sent to a users account without their consent.
If a user familiar with Ethereum tried to distribute their freshly minted tokens to a list of addresses, no accounts would be able to receive the tokens unless they had already setup the appropriate receiver in their account prior to the batch distribution.
Rather than just telling the user they cannot transfer their tokens to those accounts, I propose the addition of a simple Airdrop contract.
The batch transfer app would check the addresses, for the addresses without an appropriate receiver the user is presented with option to transfer those tokens and the address list to the AirDrop contract.
The AirDrop can be setup with a duration, during which the creator cannot withdraw the tokens deposited, and after which the users can no longer claim their tokens.
This would provide the functionality expected from disperse.app in a way that is in line with Flow/ Cadence's values.