Token airdrops without explicit associations

[mgarbs]

From the draft:
_

User Stories

Terminology

The following terminology is used in the rest of this Specification

• Airdrop-Sender: the owner of a token that they wish to send to somebody without the explicit association/permission from the intended recipient
• Airdrop-Recipient: the intended recipient of the above airdrop
• Node-Operator: the operator of a node in the Hedera network

User stories

• As an Airdrop-Sender, I want to send arbitrary tokens (Fungible and/or Non-fungible) to Airdrop-Recipients so that I can create interesting business use cases
  1. I understand that the recipients of the airdrop may not wish to accept these tokens and I am willing to pay for the network resources used while they make their decision.
  2. If the intended Airdrop-Recipients do not accept my transfer, I want to be able to restore those tokens to my account so that I can do whatever I wish with those tokens.
• As an Airdrop-Recipient, I want to receive arbitrary tokens (Fungible and/or Non-fungible) from the Airdrop-Senders so that I can accumulate those in my account.
  1. I want to achieve the above while having explicit control over what tokens actually show up in my account.
  2. I want to achieve the above without being subject to the reputational/legal/spam risk of being associated with unwanted tokens
  3. I want to achieve the above without having to be forced to pay for the storage/renewal of these unwanted tokens unless I explicitly accept those.
• As a node operator in the network, I want to make sure that the network security is not compromised and that somebody pays for the network resources that are used. The design of this HIP is partially inspired by how we handle spam emails in today's world, but with an added safeguard of ensuring that there is an economic disincentive for an Airdrop-Sender from sending indiscriminate spam. Through this HIP, we will create a new concept of unsolicited-token-outbox/inbox that maintain a record of intended transfers of airdrops._

Here is the HIP that is being reviewed: HIP-655

[bugbytesinc]

This can be accomplished more elegantly by one small backwards compatible change in the existing protocol. Association requires consent, so therefore, the if the receiving account signs the transaction of the airdrop it can implicitly create the association as a part of receiving the airdrop. When you combine this with scheduled transactions, you can make this an asynchronous human workflow. Wallet user interfaces can interpret the situation via mirror node queries to provide elegant easy to understand interfaces. We do not need the changes in the HAPI described in this HIP to attain the goals stated.

[HGraphPunks]

That's a really interesting idea!

I think the philosophical difference being: Should the infrastructure ease development and usage, or should the platforms be creative to gain functionality needed for better UX.

I typically fall in the, platforms should be creative category to not overdevelop an underlying technology.

However on this particular issue I think an inbox is the best solution as it's an added functionality that almost all platforms /services/ end users need:

An ability to get airdrops before knowing any technical details about the sender

The method you describe would require any token sending platform:

• Build a scheduled association transaction for every receiver and submit to the network
• Wait for the responses to come in, knowing some won't see it before transaction expiry
• Assume some won't ever see it if they use wallets that don't show association scheduled transactions to users
• Have to determine when the airdrop can go out in the future as associations come in

So it's possible, but the UX of both the developer and the user is quite clunky and fragmented.

Having a centric network level protocol that simplifies the methods of airdrops while protecting the users from malicious activity is essential for good UX and an easy standard for platforms to adopt than a workflow concept that can be interpreted.

I do think there can be additions to this hip to help users manage the inbox like:

• auto accept all NFTs from treasury wallet X
• Auto deny all tokens sent to inbox (could be a flag too so senders don't have to pay gas to users who are auto denying)

End goal I think is:

• Users have security of not getting spam sent into their account
• Users don't have to know any technical information to receive an airdrop in their inbox to accept
• Users can easily deny spam / unwanted tokens sent to them
• Developers can do an airdrop once and not worry about keeping track of association and multiple communications and rounds trying to get wanted airdrops to users.

[GrizzleGuy]

Practically it feels like a small (but non trivial) difference between having spam in my account and spam in my inbox. In either case I need to filter the spam, and given low costs to spam I’d think the inbox/waiting-area would fill with garbage quickly.

Maybe it’s an opportunity for an add-on app or service, but things I want as a user are

• not have to manually filter spam
• • Maybe set requirements for the account sending the unsolicited drop such as
• **Ive whitelisted the sending account
• **Ive accepted a token from the sending account previously
• **The sending account has some non trivial HBAR balance (more likely to be a real account and not a low budget spammer)
• **Ive sent HBAR or a token to that account previously
• **The sending account is not on a watchlist/community blacklist

[mgarbs]

These are all interesting ideas @bugbytesinc , @HGraphPunks , @GrizzleGuy . We have a hip that's been drafted around this a PR in Review. Would you mind commenting on the PR too?

https://github.com/hashgraph/hedera-improvement-proposal/pull/655/files

[rocketmay]

One thing that I'm not sure has been covered in this HIP:

Is the receiver required to hold HBAR in order to receive the airdrop?

Currently it seems that this is the case, since the user must send a transaction to the network to receive the token. Creating the token inbox without addressing this friction point will still lead to grief from projects, particularly web2 projects who are onboarding users that aren't crypto native and thus won't have any HBAR.

Is there any method to have the sender set a flag to pay for the receiver's association and acceptance transactions in full? This would resolve a huge pain point that is holding many companies back from moving onto Hedera.

User Story: I am a project onboarding users onto my platform through token incentives. I want my users to be able to receive my NFT's/tokens on a fresh, empty account without requiring them to first load their account with HBAR.

[HGraphPunks]

I strongly agree with this input and think it needs to be added to the HIP.

[bugbytesinc]

Another way this can be done without this HIP: the sender signs a scheduled transaction that requires the receivers signature, the receiver's wallet can handle the issue of association in the background after the user approves receiving the token on the wallet's UI. Or if the user wants to take no action to receive tokens, this is already covered by autoassociation. This HIP is not necessary.

[HGraphPunks]

Interesting idea! I don't think I understand how this scenario would work currently though.

If I understand what you're saying:

1. Developer doing airdrop has to create and send associate transactions to all wallets holding NFT
2. Wallets would have to display associate transaction and receive transaction bytes through some runner
3. Users would have to accept the association transaction within 30 min before those transaction bytes expire
4. Developer would have to monitor association transactions on the network to send the NFT after accepted

This is sort of doable today and how airdrops are done in most cases.

The caveats being - there's no method currently I know of that you can send transaction bytes directly to an account to display in an account to accept.

To me, the end result is a clunky experience for Developers airdropping, wallet providers, and end users. There's timelines and notifications that must be created outside the network for the workflow to be successful, and the developer airdropping has to monitor mainnet constantly to see when / who has approved.

For closer parity of how airdrops work on other networks and keeping the security of association;
I still see this HIP as viable and much needed to ease the user experience of receiving NFTs, FTs, and developer experience of airdropping with no implications to security, and adding the ability for users to asynchronously agree to accepting airdrops over long timeframes.

[rocketmay]

There are paradigms which are used on Hedera today that platforms have come up with to work around the difficulties of token association and sending/receiving NFTs. However I believe that a HIP like this is critical to address the friction that projects (not just users, projects) are having with building on the Hedera network. Scheduled transactions are powerful but difficult to apply at scale in the way these projects want to use the network. We're not just talking DeFi creators, but also Web2 companies and brands that are trying to use Hedera and hitting the UX roadblocks along the way.