Spacedrop: an airdrop that recipients pay for

Spacedrop implements an airdrop via cryptographic IOUs that users relay to a smart contract to collect their tokens, paying for their own transaction costs.

I just published Spacedrop on a gitlab repository. Spacedrop implements an airdrop scheme where recipients pay for transaction gas costs, instead of the issuer.

Performing an airdrop the usual way can get costly, since it requires paying for gas costs to send the tokens to a bunch of recipients. With Ethereum mainnet transaction costs being in the order of $0.01 to $0.1, implementing a massive airdrop can get rather expensive. With Spacedrop, the bulk of the cost is offloaded to the recipients of the airdrop.

To set up Spacedrop, the issuer only needs to allow the Spacedrop contract to distribute tokens on their behalf, for example using token.approve(spacedrop, total_tokens_to_distribute) in the case of an ERC20 token. Spacedrop is compatible with any ERC20 and ERC777 token.

Then, the airdrop issuer must send off-chain (e.g., via email, or on a public website) a signed message that is unique for each recipient. Then, recipients can then send these messages to the Spacedrop smart contract to retrieve their tokens via claimTokens().

These messages are cryptographic IOUs that include:

• The token to be transferred.
• A sender, recipient, and token amount.
• A nonce (more on why this is necessary later).
• The signature of the sender.

With these parameters, the smart contract can verify that in fact the sender did authorize this transaction, and execute a transaction on their behalf.

Spacedrop checks that a user does not try to collect his tokens twice (that is, calling claimTokensERC20() or claimTokensERC777() with the same parameters more than once). A naive implementation would however prevent the issuer from sending the same token amount to the same recipient more than once. Since a multi-phase airdrop could entail sending the same amount of tokens to the same address multiple times, we allow the sender to provide a different nonce each time, effectively working around this limitation.

The issuer of an aidrop can pause the airdrop. In the case of an ERC20, this can be achieved by calling token.approve(spacedrop, 0) or transferring their token balance to another address. Note that recipient’s calls to claimTokens() will start failing, thus wasting their gas. The airdrop can be resumed by increasing the token allowance again, and transactions that failed will this time succeed. Of course, an issuer can create a spacedrop that cannot be cancelled by sending the tokens to a contract that cannot later prevent token transfers unilaterally.

Regarding costs. For the issuer, gas costs are reduced to setting up the spacedrop via calling approve() as explained above; Spacedrop is dramatically cheaper than a standard airdrop for the issuer. For recipients, the cost is comparable to a standard token transfer.

The aggregate cost for a Spacedrop, including gas paid by issuer and recipients, is slighly higher than in a standard airdrop, since in the latter several token transfers can be lumped together in a single transaction. That said, the total cost should be in the same order of magnitude.

Note that in Spacedrop recipients must actively collect the tokens they are granted. This may or may not be desirable. On one hand, the issuer can recover unclaimed tokens. Spacedrop does not help perform airdop spam, for better or worse. Finally, recipients must of course own some ether in order to pay for transaction costs. Again, this may not be desirable.

Interestingly, the Spacedrop contract has no owner and does not require redeploying to implement different airdrops. None of that is required, since all the necessary data is encoded in the IOUs that recipients relay to the smart contract. One deployment of the smart contract should be forever good.

Currently, the Spacedrop repository only includes the smart contract and basic tests. To dos are: a nice front-end to collect tokens, backend code to automate sending the info to recipients.

A word of caution: this code has not been extensively tested. Use at your own risk!

Relevant references:

• A post on the use of ec signatures in Solidity.
• A post on payment channels, and another one. Payment channels have similarities with the implementation of Spacedrop. Loosely speaking, Spacedrop and payment channels leverage off-chain IOUs that can be redeemed through a smart contract.
• AirdropChannels implement the same concept of a recipient-paid airdrop, although the solution is considerably more complex (212 lines of code vs 40 in Spacedrop as of this writing).
• (Edit.) Merkle Airdrops also implement this concept of a recipient-paid airdrop. In this case, the Merkle root of valid claims is committed to a Smart Contract, which has some nice properties at the cost of some extra complexity (see comments to this blog post and this reddit thread).