A unique, seamless, and streamlined airdrop experience for projects, developers, and end-users on Hedera

With Hedera mainnet upgrade v0.54 just around the corner, all major features of HIP-904: Frictionless Airdrops are now available for developers and builders on the testnet - and soon to be implemented on the mainnet!

Airdrops and the experiences created around them are crucial and prominent features of any web3 ecosystem. However, the industry-standard mechanisms by which airdrops are performed lack consideration for user sovereignty and protection. Because end-users cannot choose what tokens are sent to them, they are vulnerable to receiving tokens that may hold malicious intent or that they do not want to be associated with.

This drawback is one of the primary reasons Hedera implemented Token Associations and Receiver Signature capabilities - unique features of the network which provide robust and flexible safeguards against unwanted tokens as was highlighted by Dr. Leemon Baird earlier this year in the wake of one of BlackRock’s public Ethereum accounts being bombarded with memecoins and NFTs following its discovery.

Note: Token Associations apply only to HTS tokens. ERC-20 tokens by default do not have the concept of association, but could be implemented in a smart contract if desired.

Now - integrated with Hedera’s unique token association functionalities - the implementation of Frictionless Airdrops on Hedera can provide an enhanced end-user airdrop experience for projects, developers, and individuals alike. To begin, let’s examine in a broader sense the benefits of this new functionality for both senders and receivers of airdrops.

What Does This Bring to Hedera?

Frictionless Airdrops empowers token creators, developers, and projects by allowing them to distribute tokens more efficiently to a wider audience without the need for pre-existing token associations. This streamlined approach greatly enhances token distribution strategies, enabling seamless airdrop functionality without compromising user sovereignty.

On the receiver side: enhanced agency over their personal token holdings and incoming transactions means that end-users can enjoy highly controlled token management while participating in the airdrop experience. They can now automatically receive tokens from trusted sources, selectively claim airdrops, and reject tokens already in their wallet without incurring hidden fees - providing a balance between convenience and protection against unwanted tokens.

As is discussed in further detail below, Frictionless Airdrops provides developers with the necessary tools to create sophisticated token management systems and airdrop campaigns. Platforms can offer enhanced features to their users, such as pending airdrop management, automatic token association controls, and easy token rejection.

Additionally, the changes to automatic token associations and the introduction of unlimited automatic token associations for auto-created accounts, align the Hedera experience more closely with other web3 ecosystems.

Let’s explore these new features in detail.

Major Features

Unlimited Automatic Token Associations

Every account on Hedera may have zero or more token associations, indicating that the account is either capable or incapable of holding tokens - both fungible and non-fungible - of the associated type. The account property [max_auto_associations] keeps track of the maximum number of automatic associations allowed by the account.

Prior to this network upgrade, [max_auto_associations] was limited to non-negative numbers: [0] meaning no automatic associations are allowed and any positive integer N (meaning up to N automatic associations are allowed). For example, if an account has a value of 5 for the property [max_auto_associations], that means only 5 automatic token associations are permitted for the account.

The Unlimited Max Automatic Token Associations functionality permits a value of [-1] to be set for [max_auto_associations], meaning “unlimited” automatic token associations. Auto-created accounts will have [max_auto_associations] defaulted to [-1], accounts created by using CryptoCreate will be defaulted to [0], and accounts created prior to the release of the feature will remain unchanged.

In addition, this new functionality will calculate all appropriate fees and charge the sender of the tokens accordingly.

Code Snippet

const newAccount = await new AccountCreateTransaction()
    .setKey(newAccountPublicKey)
    .setInitialBalance(Hbar.fromTinybars(1000))
    .setMaxAutomaticTokenAssociations(-1)
    .execute(client);

Sender Pays Automatic Association Fees

Previously, users pre-paid for unused automatic association slots on their accounts, regardless of the setting for [max_auto_assocations]. This meant receivers bore the cost and had to set up associations before they could receive tokens.

Frictionless Airdrops flips this model; now, when a sender airdrops tokens to an account that isn't associated with that token type, the sender pays all fees related to token association as well as the first auto-renewal period of the association slot. This approach makes receiving tokens much easier and less costly for users, while putting the responsibility on those initiating token transfers to cover these initial costs.

Pending Token Transfers

When an airdrop is performed using the [TokenAirdrop] transaction and the receiver does not have any available or automatic association slots, the transfer will be kept in state as a pending transfer - as opposed to failing outright. This mechanism allows token senders to initiate transfers to accounts that haven't explicitly associated with the token or don't have available automatic association slots.

The introduction of a pending state for token transfers is critical to creating a balance between frictionless airdrop functionality and user sovereignty. When a sender initiates an airdrop to an account without available association slots, the transfer is stored in the network's state as a pending transfer. The tokens aren't deducted from the sender's balance nor credited to the receiver until the recipient actively claims them using a [TokenClaimAirdrop] transaction.

This approach protects users from unwanted token associations while still allowing them to receive airdrops if they choose. Importantly, senders can cancel pending transfers they've initiated using the [TokenCancelAirdrop] transaction, and they continue to pay for storing these pending transfers until they're either claimed or canceled, incentivizing responsible airdrop practices.

Let’s examine each of these new transactions in detail, as well as the new [TokenReject] transaction for users holding tokens that have already been associated - either manually or automatically.

New Transaction Types

TokenAirdrop

[TokenAirdrop] allows senders to distribute tokens to multiple recipients in a single transaction, even if the receiving accounts haven't previously associated with the token. This transaction type is designed to handle various scenarios, including transfers to already-associated accounts, accounts with available auto-association slots, and accounts without available slots or those requiring receiver signature.

As aforementioned, TokenAirdrop enables the creation of pending transfers when immediate distribution isn’t possible due to a lack of available auto-association slots. Instead of failing, the transaction creates a pending airdrop that can be claimed by the recipient user at a later time of their choosing.

The sender pays all associated fees, including transfer costs, association fees, and the first auto-renewal period's rent for any new associations. Additionally, an airdrop-specific fee is assessed to deter spam. This new transaction type strikes a balance between enabling seamless token distribution and respecting receiver account settings, making it a powerful tool for token creators and marketers while maintaining user control over received tokens.

TokenClaimAirdrop

[TokenClaimAirdrop] allows recipients to claim tokens that were sent to them via a TokenAirdrop transaction but remained in a pending state due to the recipient's account having no available automatic association slots. By requiring an explicit claim action, users have the final say in which tokens enter their accounts, preserving user control.

When a user initiates a TokenClaimAirdrop transaction, the user is agreeing to receive the airdropped tokens and associate their account with the token. The transaction must be signed by the receiver, adding an extra layer of security and consent. Importantly, the sender must still have sufficient balance to fulfill the airdrop at the time of the claim, or the claim will fail.

This transaction also serves as an explicit desire to associate with the token, combining the functions of token association and transfer in one action. By allowing users to selectively claim airdrops, TokenClaimAirdrop empowers recipients to manage their token portfolio actively, accepting only the tokens they want while easily ignoring unwanted airdrops.

TokenCancelAirdrop

[TokenCancelAirdrop] provides senders with functionality for managing unclaimed airdrops, giving senders the ability to cancel transfers that are in a pending state. It's particularly useful in scenarios where a sender might have changed their mind about an airdrop, made a mistake in the initial transfer, or wants to reclaim tokens from recipients who haven't claimed them within a desired timeframe.

When a sender initiates a TokenCancelAirdrop transaction, it removes the specified pending transfers from the network's state, making them no longer available for recipients to claim. This action incurs a nominal fee for the sender, encouraging responsible and mindful use of the airdrop feature.

This transaction can only be performed by the original sender of the airdrop and only affects unclaimed, pending transfers. Any airdrops that have already been claimed by recipients cannot be canceled. By providing this cancellation option post-distribution, TokenCancelAirdrop ensures that senders retain a certain degree of control over their airdrops - introducing both extra flexibility and enhanced sender control within the airdrop process on Hedera.

TokenReject

[TokenReject] enables account holders to transfer either their entire balance of a fungible token or specific non-fungible token serials back to the token's treasury account. It's designed to address the problem of "spam" tokens or unwanted airdrops, giving users a straightforward way to cleanse their accounts of tokens they don't wish to hold, regardless of how these tokens were acquired.

A critical feature of the TokenReject transaction is that it waives all custom fees and royalties that might normally be associated with transferring the token. This ensures that users can rid themselves of unwanted tokens without being subject to potentially malicious fee structures.

Note: the TokenReject transaction cannot be used if the token is frozen or if the account is paused on that token.

HashScan Integration

When Hedera is upgraded to v0.54 - bringing all major features of Frictionless Airdrops to the mainnet and its users - HashScan will be equipped with extended functionality for users to have increased observability and control with regards to airdrops.

Stay tuned for a more comprehensive deep-dive into the new functionalities Frictionless Airdrops will bring to HashScan which will provide a central hub from which users will be able to seamlessly set their account automatic association settings, view and/or claim pending airdrops, and reject tokens with ease.

What Does This Mean for Developers?

The Hedera API (HAPI) has been extended to include these new transaction types. The full implementation of HIP-904 also alters the behavior of existing operations like CryptoTransfer when dealing with automatic token associations. SDKs have been updated to support these newly introduced HAPI transaction types and modified behaviors, ensuring developers can easily integrate the new features into their applications.

SDKs:

• Airdrop a token

• Claim a token

• Cancel a token

• Reject a token

On the Mirror Node side, new API endpoints have been introduced to support querying pending airdrops, for both senders and receivers. These endpoints will allow users and applications to retrieve information about outstanding and pending airdrops, enhancing the overall visibility of token distribution processes.

For more detailed information on the technical implications of Frictionless Airdrops and the extended developer functionality it provides, please visit the following link.

Conclusion

Frictionless Airdrops revolutionizes the way tokens are distributed and managed on Hedera. By introducing enhanced control for both senders and receivers, this proposal addresses key pain points for token creators, and end-users alike - streamlining token distribution for improved community engagement while simultaneously empowering users to manage their digital assets more effectively.

With these new functionalities, we have laid the groundwork for a more vibrant, user-friendly, and dynamic token economy on Hedera. We are beyond excited to see the value this brings to the overall ecosystem and to the individual members of our incredible community.

Hello Future.

Additional Resources:

HIP-904 Documentation: https://hips.hedera.com/hip/hip-904

Javascript Token Airdrop Example: https://github.com/hashgraph/hedera-sdk-js/blob/main/examples/token-airdrop-example.js

Getting Started on Hedera: https://hedera.com/getting-started