Token association as an optional setting

[gerbert-vandenberghe]

To make Hedera more user friendly and not make the token association block certain business flows, certainly in the digital entertainment industry, we like to make the need for token association a setting on the wallet that can be switched on by more advanced users.

Please find more info on the draft HIP here: https://github.com/ArkaneNetwork/hedera-improvement-proposal/blob/master/HIP/hip-0000-makeTokenAssociationOptIn.md

[mattsmithies]

Yes, we need this and have had extensive conversations with @gerbert-vandenberghe and the Venly team on this matter.

[mattsmithies]

I would add that an approach of adjusting a given user's account capability could be preferable to allow for permission for a third party to act upon a user to help with custodial wallets, or semi-closed systems like marketplaces, pools, and exchanges.

Thinking in terms of how Flow's cadence language design is resource orientated. Conceptually I give permission for an entity to perform an action, I would like a key to having the "resource" or "permission" to perform X.

In this case, I propose something along these lines during an additional account configuration.

setPermissionedTokenAssociationKey()

Now, additional keys could be added or definitions for different permissions based on different hedera services. We could use a similar language like "borrow", as is found through cadence.

This way a token cannot be airdropped to any account and the token "layer" would retain its purity, happy for a rebuttal! @Cooper-Kunz

This account "permission" in particular could provide more interoperability of user/dev experience between different chains.

[Cooper-Kunz]

While I agree that user experience can be improved by removing, and/or making token associations optional (I don't think anyone would argue otherwise) it seems like this proposal fails to address any of the numerous reasons that Hedera chose to implement associations.

Personally, I would attempt to define these as:

1. DDoS risk on the network (a botnet can flood the network with incredibly cheap airdrops)
2. Memory bloat risk on the network (fear that a large number of useless tokens will be created & distributed)
3. Spam risk on accounts (attackers could fill public accounts with tokens rendering apps/their accounts wasted)
4. Reputational risk (see Vitalik not wanting to hold billions of $SHIB(*))
5. Tax burden risk (unclear regulatory environment on airdrop management)

I think that these issues may need to be reasonably addressed in the security implications section (that is currently empty) before having a productive conversation around the changes required. Perhaps you can consider something like drastically increased "rent" on tokens that are held by less than X active addresses, etc. but obviously increases the difficulty of implementation.

[gerbert-vandenberghe]

Thanks for the feedback. Some thoughts on these security issues:

DDoS risk on the network (a botnet can flood the network with incredibly cheap airdrops)

There are plenty of other ways to do such a DDOS, e.g. you can set up a couple of accounts and keep minting these tokens towards these accounts that have the token associated.

Memory bloat risk on the network (fear that a large number of useless tokens will be created & distributed)

This is indeed an issue, but there is an upkeep cost for contracts so unused token contracts will be cleaned. Possibly there is some room for tweaking the upkeep parameters.

Spam risk on accounts (attackers could fill public accounts with tokens rendering apps/their accounts wasted)

The question is whether the effort is worth the result for people doing this. There are also costs involved. People can opt in for the token association to avoid the spam risk.

Reputational risk (see Vitalik not wanting to hold billions of $SHIB(*))

People should not make their accounts public, certainly no public, high profile people who can be easily targeted. They can still opt in on the token association to avoid this risk.

Tax burden risk (unclear regulatory environment on airdrop management)

This is only in some countries, people can opt in for token association.

There needs to be found a balance between security and usability. We can design the optimal secure network, though when it becomes impossible to build user friendly applications on top of it, it defies the purpose. The token association makes quite some business flows impossible and we would like to address that issue.

An alternative is the possibility to opt out of the token association need at the time of account creation. It will decease the risk of above security implications. Downside is that we cannot allow people to import their account into Venly as when they have not opted out, it might break business flows. Hence we will have to limit our functionalities in Hedera.

Another option is that we can associate the tokens on behalf of our users. It requires to give the creator of the account who has no access to the private key the option to associate a token with the account. Though the system becomes much more complex and our B2B customers might choose a simpler solution. E.g. when a user wants to buy an NFT in a webshop the flow is as follows:

Without token association:

1. User bus the NFT
2. Webshop transfers NFT to user's account

With token association

1. The user buys the NFT.
2. The webshop has to call us to associate the token the user's account.
3. The webshop waits for confirmation.
4. We add the token association.
5. We notify the webshop.
6. The webshop transfers the token.

[bugbytesinc]

Perhaps in user interface experience "The user buys the NFT" is the same as "User executes the association transaction". How would they know the difference?

[gerbert-vandenberghe]

The user buys the NFT on a webshop, that is no wallet software and they have no access to this wallet.

[tkozzer]

I'm not sure exactly how this would work technically, but what if every account came with a method called setTokenAssociationRequired(<boolean>)? If an account holder decides that they are willing to take the risks involved with allowing all and any tokens to be airdropped to their account, that should be their right. And for all those, who would like to take a more measured approach could go the explicit token association route.

Another idea would be to allow an account holder to whitelist an account/account list or an organization (account list managed by the org). Instead of having to associate each token, have it where the consuming account could freely accept any tokens minted by the accepted accounts. Maybe a good way of thinking of this is an open door policy with an account. Each party is giving a key to other and saying that you are welcome to send me any tokens that you mint which could be something like an airdrop or a simple business transaction.

[donaldthibeau]

I think my inclination would be for association to be required by default and a user could optionally choose to not require association. Those who want to participate in these marketplaces could choose to not have it on by default. Otherwise users may get spammed with tokens, introducing a more complex requirement for them to get the tokens out of their account.

[Babaw]

Baptiste from Xact Wallet team here. I support this idea. An option into accounts to authorize automatic token association could be really cool. With token association required by default.

[bugbytesinc]

A compromise may be to have the receiver sign the first transfer receiving a given token, which then could be considered an implicit association.

[topshef]

Token associate an account to another account might be interesting to explore. Certainly at the wallet level a user might want to pre-approve tokens from a trusted party. This could be the operator account that mints a series of tokens.

There might be other permutations to explore, and debate which are better on chain vs wallet implementation.

Greg mentioned possible bundled tx as a hip, might have some relevance here too
https://discord.com/channels/373889138199494658/768621337865486347/856870873456443402

[rocketmay]

An issue that I have with the current implementation of the auto association is that it requires the user to pay the association fee.

When a user is sent an unsolicited token they pay the fee to associate it. This is unintuitive, you would expect the sender to pay for any fees required to send the token to the user.

I propose that if a user has auto token associate set on their account and the sender sends a token that the account isn't associated with, the association fee is automatically added to the sender's transaction to be paid by the sender.

This would provide some protection for users and put the responsibility onto the entity that is performing the action. The entity can mitigate issues around this by properly polling the users account for relevant information, which is more reasonable than making the user responsible.

[Ashe-Oro]

Can the sending user make the association for the receiving user? I imagine the associate tx needs to be signed by the receiver (incl the tx fee), unless you're saying for the sender to also send the amount of HBAR to the user to cover the fee?

[hashaxis]

We're not sure if this comment needs its own HIP, but we just wanted to chime in here as it's also relevant here.
(This does not apply directly to auto-associations but to max associations in general.)

1,000 max associations is far too low for even our most basic use cases for a treasury account. Even a consumer grade user could easily reach 1,000 tokenIds associated when mostly dealing in "1-of-1" NFTs (such as collectibles or other unique items used to verify memberships or ownerships.)

We understand the concern about flooding the network with cheap airdrops; and propose a scaling fee model where the fee increase on some scale as you enter new tiers of associated accounts.

Scaling Fee Example:
0 - 1000 (standard fees)
1001 - 10,000 (standard fees) * (1.10)
10,001 - 50,000 (standard fees) * (1.50)
50,001 - 100,000 (standard fees) * (2)

A scaling fee model will allow enterprise cases who are willing to pay higher fees to do so, and discourage bad actors who will find it infinitely more expensive the more they try to flood the network.

Then Enterprise customers can make a business decision to calculate if their product fees cover the cost of associating more accounts. (Currently the only option we have is to start juggling potentially thousands of new accounts unnecessarily which from a security and development standpoint is a waste.)