Frictionless Airdrops

[Nana-EC]

HIP 904 aims to enable frictionless airdrops of both fungible and non-fungible tokens by removing the requirement to pre-associate tokens with the receiver's account, and by allowing the sender to create associations on the receiver's account automatically at transfer time by paying for any token-associations created as a result of the airdrop. The sovereignty of account holders who do not wish to receive unsolicited tokens is preserved by supporting the concept of pending token transfers to such an account. Potential token receivers may claim their token airdrop whiles available if desired and airdrop senders may cancel their sent airdrop should they change their mind.

With this HIP, accounts will no longer prepay for unused token association slots. Association fees will be charged for those slots only when a token is actually associated with an account.

This HIP also introduces the concept of token rejection. Here an undesired token class value is returned to the treasury with all custom fees waived.

From the user perspective, this HIP introduces the following concepts:

• Supporting an explicit unlimited number of automatic token associations when maxAutomaticAssociations = -1
• Defaulting the maximum automatic associations to -1 (unlimited) for auto-created accounts
• Associating the token-types automatically when a token instance is sent to an account and a slot is available. Calculating and charging the sender for all appropriate fees.
• Implement new airdrop HAPIs, TokenAirdrop, TokenCancelAirdrop used by airdrop sender’s to send airdrops and reclaim pending airdrops, and TokenClaimAirdrop used by an account to claim a pending airdrop.
• Implement new TokenReject transaction that allows a token-holder to reject a token and send it back to the token's treasury without any extraordinary fees such as custom fees and disassociate from the token.
• Maintenance of the number of token-association-credits in an account so that an account is not charged for the token-association during the first full auto-renewal period.
• The network will award a rent credit for a token holder for at least one full auto renewal period upon automatic association.

See #904 for initial comment and https://hips.hedera.com/hip/hip-904 for latest HIP status.

[bugbytesinc]

Oh my gosh, this has way too many degrees of freedom. Why can't you just add a flag to the transfer transaction indicating that association will happen if this TX succeeds and then just require the signature of the receiver for the transfer transaction to be valid?

Then, that transfer TX can be scheduled and does that not meet the requirements without all this complexity?

[Nana-EC]

Thanks @bugbytesinc for the suggestion.
Your recommendation refers to an implicit association.
I initially explored this during HIP 777, although I called it "Implied Association".
It works for some cases and not for others.
One consideration is it requires coordination of signatures up front and as a result doesn't allow for asynchronous behaviour and therefore doesn't scale as easily. Accounts without these capabilities would therefore not be able to utilize it.
TokenClaim is essentially this as you're getting the signature of the receiver and they are approving the association on their account.

However, there are other scenarios where the idea could still be explored outside of this HIP.

In my previous consideration there were 3 cases where this could be applicable

• (the case you highlight) A normal HAPI CryptoTransfer in which an account is debited value and is credited a new token. Assuming the sender of the token signs then the act of the recipient signing implies they want to be credited the token. This is an atomic swap transaction situation.
• A scheduled CryptoTransfer in which the potential recipient will be credited a token. In this case if the potential recipient signs that transaction they are implying they want to receive the token. This was an idea from David on my team.
• A user provides an approval for a token to another account. This implies the user wants to have a balance of a token that another account can manage.

[AdrianKBL]

I love this HIP! One of the biggest challenges in onboarding people from Web2 to Web3 is the issue of token associations, and I believe that with these new functionalities, we can make it much easier and simpler. I’ve read the HIP, and I still have a few questions…

1. Account A sends an airdrop to Account B (Account B does not have auto-associations or the token associated). How long will the pending_aidrop remain with Account B? Does Account A have any way to cancel the airdrop after a certain period?.

2. In this point, I don’t quite understand what is meant… If the receiver never claims the airdrop, then the sender continues to pay for it forever, or until their account expires, is deleted, or the sender cancels the pending transfer. What would the sender have to pay forever? That is, if I send an airdrop from Account A to Account B and Account B does not have auto-associations or the token associated, what does Account A have to pay if Account B never claims that airdrop?.

3. You mention that the TokenAirdrop method can be used, and if the receiving account has the token associated or has available auto-associations, a TransferTransaction will be executed. What would happen if I make 10 transfers of fungible tokens and half of them do not have the token associated or available auto-associations, and the other half do? Would 2 transactions be executed (one TokenAirdrop with 5 accounts and another with TransferTransaction with the remaining 5)?

Overall, I think this is an excellent idea and will solve many problems.