Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Frictionless Airdrops #904

Merged
merged 19 commits into from
Mar 25, 2024
Merged

Frictionless Airdrops #904

merged 19 commits into from
Mar 25, 2024

Conversation

Nana-EC
Copy link
Contributor

@Nana-EC Nana-EC commented Feb 26, 2024

Description:
This HIP enables 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.

Related issue(s):

Fixes #

Notes for reviewer:

Checklist

  • Documented (Code comments, README, etc.)
  • Tested (unit, integration, etc.)

Signed-off-by: Nana Essilfie-Conduah <[email protected]>
@Nana-EC Nana-EC self-assigned this Feb 26, 2024
Copy link

netlify bot commented Feb 26, 2024

Deploy Preview for hedera-hips ready!

Name Link
🔨 Latest commit 674494e
🔍 Latest deploy log https://app.netlify.com/sites/hedera-hips/deploys/6601b3163dba4d000801f351
😎 Deploy Preview https://deploy-preview-904--hedera-hips.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

Signed-off-by: Nana Essilfie-Conduah <[email protected]>
Copy link
Member

@david-bakin-sl david-bakin-sl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comments on the text/"narrative" part of the HIP - up to the section "HAPI (Hedera API)". Will continue later.

HIP/hip-904-frictionless-airdrop.md Outdated Show resolved Hide resolved
HIP/hip-904-frictionless-airdrop.md Outdated Show resolved Hide resolved
HIP/hip-904-frictionless-airdrop.md Outdated Show resolved Hide resolved
HIP/hip-904-frictionless-airdrop.md Outdated Show resolved Hide resolved

- The value `-1` is now permitted for `max_auto_associations`, and this value means “unlimited”.
- The account holder no longer prepays for unused slots regardless of the setting for `max_auto_associations`. Slots are only paid for when used, and are initially paid for by the sender during automatic associations. The account is responsible for covering rent for each association after the first auto-renewal period. `used_auto_associations` is incremented every time an auto-association is made.
- The default value for automatically-created accounts will now be `-1`. This means, if an account is created automatically (by performing a token transfer to an alias that does not yet exist, see [HIP-583](https://hips.hedera.com/hip/hip-583)), then the automatically created account is configured with unlimited automatic token associations.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know this section is describing changes of behavior but I think it is anyway still nice to remind readers what the default max_auto_associations is for non-automatically-created accounts.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your auto created account might be front run with a bunch of airdrops before the receiver can take control and turn the feature off, Is it absolutely necessary to be turned on in the first place? Should this not be opt-in which would be more like the current behavior?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@david-bakin-sl good point.
This is stated later on in the "Account Airdrops Default" section.
Does that make it clearer?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bugbytesinc this a compromise to manage multiple users and application flows across the web3 industry especially in DeFI and multi chain applications.

Your consideration is valid, note, users and application developers (as decision makers) will have the choice of what type of accounts they want and the characteristics of each they are willing to accept and utilize.

Additionally, this is parity with the rest of the web3 industry.
Notably, the payer pays for these fees and should discourage indiscriminate use. Beyond this TokenRejection may always be utilized.

Thoughts?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fundamentally, I don't see how this addresses the airdrop issue inside the EVM, outside the EVM is the HAPI, which by nature is a different thing. We can solve this with a flag on transactions for "include an association with this transfer" which is required to be signed by the receiver, which can be turned into a scheduled transaction wherein you have the same UI/X experience as you do adding all this extra HAPI constructs.

But specifically to my comment, I think the "defaults" during account creation ought not be changed, what production deployed contract relies on the current rules, are you opening up security vectors by doing this?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The default, in protobuf, won't change. If a wallet or SDK creates an account today, that account has 0 auto associations. If they use the exact same software tomorrow, it will also create an account with 0 auto associations.

Except for the case of sending a token to a new account (i.e. not using a create account transaction, but just a crypto transfer). In that auto-create case, we propose changing to -1 to accept auto-associations for the new account. This is actually not that surprising, since we allowed one auto-association already by auto-creating the account and auto-association. This workflow exists to help onboard traditional web3 users, who will all expect auto-association.

Can people send lots of tokens to such an account? Yes. Will they? Maybe. There is a cost barrier to widespread spamming (actual prices TBD by coincom). And an account holder can reject any token at any time and not have to pay rent for it or pay any custom fees etc. So a spammer is going to pay a lot of money to send something that somebody can get rid of easily.

The fundamental challenge is reducing friction for the masses -- people on MetaMask or any other eth-native wallet. This is important because we live in a cross-chain world and we want people to bring their apps to Hedera and fundamentally changing the user journey / workflow and alienating existing customers isn't a viable path. Existing customers expect to receive tokens without having "association" as a thing they are exposed to. Those customers will either get their accounts created for them (and the entity creating them can make sure auto-associations enabled), or they will get them auto-created by having a friend send some token to their "wallet" address, in which case it will be auto-created and must therefore have auto-association enabled by default.

That's the argument. Its a question of reducing friction for people coming into the ecosystem, with the cost of spamming being high enough that indiscriminate spam (like with email) won't happen.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess I don't see how this reduces friction. It adds more steps for all parties. Setting max-associations to a number still has a bit of friction (what we have now), but a lot less than this 3-4 step process. You still have contracts that will need to check the 1-of-4 states of an account before they can decide if they must auto-create - or - transfer - or - airdrop - or- give up? I'm not looking forward to programming that in a contract file.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @bugbytesinc, can you provide a more specific scenario?

There are many personas and applications that may benefit and be unblocked here and one goal is to ensure developers have a reasonable pathway to provide a seamless flow to the users.

With this HIP a contract that is responsible for sending tokens would not have to check a potential recipients account if it utilizes the proposed TokenAirdrop transaction.
If this is done

  • if the account is already associated the token will be transferred.
  • if the account has open slots, there will be an automatic association and the token will be transferred. Note, the slots may be there for any number of reasons - the account was auto-created and accepts unlimited tokens, the account was updated to ensure there are available slots.
  • if the account has no association and no slots the token transfer goes into a pending state and through wallets and explorers they will see the opportunity to claim and can take action.

The contract doesn't have to take further action for that transfer to eventually go through

HIP/hip-904-frictionless-airdrop.md Show resolved Hide resolved

If the receiver’s account is **not** associated with the token, and they have **no** free auto-association slots, then the airdrop transfer neither succeeds nor fails, but is held in state as a *pending transfer*.

### Pending Transfers
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any kind of rent fee for keeping a pending transfer alive indefinitely? It's taking up space in the store.

(In the airdrop diagram there is a fee table slot for "future rents until claimed" - but that seems to be rent on the token not the pending transfer as the same exact wording "future rents until claimed" appears on the right-hand-side for the token itself.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question.
I had a similar consideration and personally also think rent should factor in the pending state as a separate additional item.
Rent has yet to be designed fully but this will certainly be a consideration.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The pending transfer will definitely have rent on it. This is why it was called about above in a previous comment.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok. then maybe the airdrop diagram's fee table should have a row for the rent due for the pending transfer record itself.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm I agree in principle except rent hasn't been defined so i don't want to put in details wording that may be changed. Rent will have many components so i think just saying rent is assessed to the sender is enough for now

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A future HIP defining rent will explicitly call out all the contributors

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes I understand we haven't defined rents yet, but the flow diagrams already include table slots for "future rents". I'm just suggesting here that there be a table slot for "future pending transfer rents", to make it clear, in the same way, that this is the intent for the future and that the sender pays.

HIP/hip-904-frictionless-airdrop.md Outdated Show resolved Hide resolved
HIP/hip-904-frictionless-airdrop.md Outdated Show resolved Hide resolved
HIP/hip-904-frictionless-airdrop.md Outdated Show resolved Hide resolved

![Token Airdrop Transaction](../assets/hip-904/frictionless-airdrop-tokenAirdropTransaction.png)

> ⚠️ `TokenAirdropTransaction` will not support tokens with custom fallback fees that require the receiver to pay the fallback fee.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what about fee key then? custom fee could be changed between time of airdrop and acceptance.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question.
Fees to payer would be assessed at the time of the TokenAirdrop transaction. So whatever custom fees are then, doesn't matter what it gets changed to

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

glad this was explicitly called out. Also thought that fallback fee should be paid by the sender.


A sender may cancel pending transfers for a low nominal fee using the new `TokenCancelAirdrop` transaction. A receiver can also choose to just ignore pending transfers. It is expected that wallets may build special user workflows into their apps to allow customers to ignore pending transfers without having to actually issue a transaction to the network to cancel them. Since pending transfers are paid for by the sender, the receiver may choose not to simply filter them out in their wallet software.

All pending transfers sent by an account must be canceled before the account can be deleted.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I read "sent" as either the payer for the airdrop transaction, or the "treasury" account holding the air dropped tokens, should we clarify which here ?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Below, we state that if an account fails to renew rent, pending airdrops are automatically deleted, why have a different behaviour on account deletion ? Would it not be easier to just cancel all pending airdrops on deletion and not impose this requirement on account holders ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have to choose which behavior we're going to be consistent with. If you try to delete an account with associations, it fails. You have to remove each association first. If your account expires and you have tokens, it all gets archived. We took the same approach here. If you have pending transfers you have to delete them.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(I'll make this comment here rather than below, because it fits with Greg's comment:). If all pending airdrops from an account are deleted when the account fails to renew rent is that a potential latency issue if there are a lot of them accumulated? They were only added 10 at a time (due to the the transfer limit there) but you might have to delete thousands in the time of one transaction ...

(Although I do see a possibility: Deleting state when rent is unpaid is at our discretion and we could have a mechanism to spread out the work as we see fit. Though if we did that they'd still have to be ignored, though part of the state. But that has a fixed cost per pending tx at the time of a query or claim by a receiving account. That same lazy mechanism, with the ability to ignore pending transactions based on whether the account is valid, would work for delete as well.)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another comment: If, to delete an account you have to delete all pending airdrops, and that takes transaction fees, could this not lead to abandoned accounts? User just says "heck with it, see ya!", and the stuff is in our state until we implement rent and time it out. (Or are there other reasons for the user to delete his account (and clean things up) so he doesn't do this?)


1. As an hts-token-holder I want to be able to reject unwanted tokens (regardless of how they were obtained) by sending them back to the treasury account and not having to pay any custom fees.
2. As a non-hedera-centric wallet user, I want to obtain an auto-created account (by EVM address or public key) that is able to receive unsolicited tokens. I understand this account will have `maxAutomaticAssociations` set to -1 implying unlimited automatic associations.
3. As account owner for an account created by an EVM tool my experience with airdrops on Hedera is identical to that on Ethereum
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no "claiming of airdrops" on Ethereum, what does that US mean ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The assumption is that if you're using MetaMask / Brave / etc. then you have auto-associations set on your account. The only way your account could have been created was by someone sending value to your account, and since your account didn't exist before it is auto-created, and therefore has max associations set to -1, and thus your experience with airdrops will be the same as on other chains.

If a MetaMask / Brave / etc. user gets an account that was not auto-created or was not created with -1 as max associations, then they won't understand why they're not receiving airdrops. We'll need to make sure google/AI searches link to docs that lead them to hashscan where they can change to -1. We're of the belief that the number of such people will be a vanishingly small percentage, and with the MetaMask snap, we can actually handle this better / more directly. So while it isn't perfect, it should cover a very high percentage (well above 99% I would think).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Additionally, though Ethereum doesn't have it on the network many flows in web3 do support a similar concept.
For example an account holding token A may be awarded Token B but only if they go through a series of steps such as going to a DApp and issuing a mint of the token.
A parallel UX could be applied here.


- Should we expose pending transfers through the RPC utilizing custom endpoints?
- Should we enable TokenAirdrops via EVM transfers for web3 parity
- We could change the default IERC.transfer() when applied to an HTS token to be TokenAirdrop
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would make sense since this would be the expected behaviour on other EVM chains and would enable existing contracts to be deployed to Hedera without changes.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem is the contract now has the potential of dealing with a bunch of pending transfers that never completed, which will be strange, and will cost them when rent is enabled.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would It also cause more compute gas if there is a backlog of pending transfers against the contract? How would the contract maintain that an account hasn't accepted the token associate?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The current intent is no. The pending state is connected to a sender not the receiver, so for normal transactions a receiver is un-impacted. However, with future rent the sender will pay rent for the pending state.
Should the pending transfer state created by a contract as a sender need to be traversed in the future it is likely that the compute gas would be more.

Copy link
Collaborator

@gregscullard gregscullard left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left a few comments to be reviewed, also more general question below which I didn't see specifically called out in the PR, I feel it's inferred but not specified.

Who can air drop, the treasury only, or anyone ? Can Alice air drop a token she received from TokenIssuer to Bob ?

@rbair23
Copy link
Member

rbair23 commented Mar 6, 2024

Left a few comments to be reviewed, also more general question below which I didn't see specifically called out in the PR, I feel it's inferred but not specified.

Who can air drop, the treasury only, or anyone ? Can Alice air drop a token she received from TokenIssuer to Bob ?

Anyone can airdrop, not just the treasury.

Copy link
Member

@david-bakin-sl david-bakin-sl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not yet done, back later.

HIP/hip-904-frictionless-airdrop.md Outdated Show resolved Hide resolved
HIP/hip-904-frictionless-airdrop.md Outdated Show resolved Hide resolved
HIP/hip-904-frictionless-airdrop.md Outdated Show resolved Hide resolved
HIP/hip-904-frictionless-airdrop.md Outdated Show resolved Hide resolved
HIP/hip-904-frictionless-airdrop.md Outdated Show resolved Hide resolved
HIP/hip-904-frictionless-airdrop.md Outdated Show resolved Hide resolved
Comment on lines 308 to 310
Similar restrictions around transfer list and aggregation across sender and receiver from CryptoTransfer will be applied to TokenAirdop e.g. max 10 transfers per transaction

At the time of this HIP `TokenAirdropTransaction` will not be supported by the Scheduled Transaction Service. A future HIP may explore this support.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should these limits be specified (also) in a different section, i.e., above somewhere with the rest of the textual specification? The scheduled Tx limitation seems less of a "HAPI" section item, in particular.

Should the max 10 transfers per transaction limit be specified in the message's javadoc?

(Are protobuf specifications in HIPs meant to be applied directly to the protobuf source files, and if so does that include comments? I don't know. I do know there's an effort going on right now to make the protobuf sources' javadoc be more rigorously a specification and documentation source.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added the max 10 limit in the proto comments

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still thinking on the separate section

* The unique token identifier. If it's a FT then it's just the TokenID.
* If it's an NFT then NftID which captures both the TokenID and serial id
*/
oneof token_id {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, if you do an airdrop of fungible token T from account S to account R, and it goes to pending, then you do another one (in the same TokenAirdrop or a different one) and it too goes to pending, then when you cancel you cancel both of them, or IOW all pending airdrops from S to R of T. (Claim, which uses this same structure also.). Just checking.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If T is fungible then yeah all of the pending amount will be cancelled.
If T is non-fungible then it's limited to 10 at a time to be cancelled or claimed

HIP/hip-904-frictionless-airdrop.md Outdated Show resolved Hide resolved

A sender may cancel pending transfers for a low nominal fee using the new `TokenCancelAirdrop` transaction. A receiver can also choose to just ignore pending transfers. It is expected that wallets may build special user workflows into their apps to allow customers to ignore pending transfers without having to actually issue a transaction to the network to cancel them. Since pending transfers are paid for by the sender, the receiver may choose not to simply filter them out in their wallet software.

All pending transfers sent by an account must be canceled before the account can be deleted.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(I'll make this comment here rather than below, because it fits with Greg's comment:). If all pending airdrops from an account are deleted when the account fails to renew rent is that a potential latency issue if there are a lot of them accumulated? They were only added 10 at a time (due to the the transfer limit there) but you might have to delete thousands in the time of one transaction ...

(Although I do see a possibility: Deleting state when rent is unpaid is at our discretion and we could have a mechanism to spread out the work as we see fit. Though if we did that they'd still have to be ignored, though part of the state. But that has a fixed cost per pending tx at the time of a query or claim by a receiving account. That same lazy mechanism, with the ability to ignore pending transactions based on whether the account is valid, would work for delete as well.)


When a sender airdrops a token, if the receiver’s account is already associated with the token, then it is effectively treated as a normal crypto transfer, except that an airdrop transaction fee is assessed. This fee exists for all uses of `TokenAirdropTransaction` as a spam-deterrent fee.

If the receiver’s account is **not** associated with the token, but has available auto-association slots, then one of the slots is taken (i.e. `used_auto_associations` is incremented) and the transaction payer will pay for the association fee. They also pay a fee representing the price of a full auto-renewal period’s rent. This is done to make sure the receiver has time to dissociate from the token before renewal takes place. For example, if the airdrop were to happen the minute before account renewal, the token would not included in renewal because it has already been pre-paid by the sender for one full renewal period. Thus, the receiver always has at least one full renewal period to dissociate from any tokens they do not want to own.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For this case we say that "They also pay a fee representing the price of a full auto-renewal period’s rent." which should refer to the transaction payer, right?
The diagram above states something different though: Fee = Future rents until claimed and Payer = Sender.
Should we instead have the diagram say that Fee = Full auto-renewal period rent and Payer = Tx Payer?

@onlylarping
Copy link

onlylarping commented Mar 17, 2024

Co-founder of Karate Combat here.

Token associations have been a major pain point for us. They've affected our product roadmap and routinely kill business development paths. We spend a lot of time and money routing around them. So I'm happy to see the momentum behind a change.

However, I personally believe the community is missing a big opportunity to remove them in entirety and move closer to parity with most other networks.

If I understand correctly, this is not a trivial change for the network or frontend clients. Further, unless wallets build out supporting UI the HIP will have marginal impact. I'd guess that Karate Combat hosts a top 10 wallet on the network, and we would not prioritize implementing the UI necessary for pending transactions. I expect embedded wallets and multichain wallets to gain a lot of market share on Hedera, and it's hard for me to imagine either prioritizing a pending airdrop concept.

If the primary driver behind token association is avoiding spam, I feel strongly that the community should reconsider this opportunity to remove token association altogether. Pending airdrops effectively just move the spam to a new folder that encourages interaction. Spam assets have been effectively dealt with by major wallets on other chains through sorting, hiding, etc. And spam avoidance is 10x less important for Hedera than its apps viral coefficients and multichain wallet support.

If email, text messages or social media required a receiver to whitelist a sender ahead of time, I wonder if these networks would have ever proliferated.

jsync-swirlds and others added 2 commits March 18, 2024 09:17
* Removed the alternatives for Reject and PendingAirdrop for ease of merge, may re-add in a future PR.

Signed-off-by: Joseph Sinclair <[email protected]>
Adopt jsync-swirlds updates for text format and protobuf specifications comments
* Adjust pending airdrops to add missing information in record stream and minimize state storage.
* Adjust token reject protobuf for clarity and consistency

Signed-off-by: Joseph Sinclair <[email protected]>
@jrwingate
Copy link

Instead of making this an entire framework that requires a bunch of front end UI changes.. Why not, for the time being, make it a simple, AllowAirdrops flag on an account. A boolean that either lets people pay for an airdrop into my wallet, or doesnt. There is no onchain state management and the implementation scheme is ORDERS OF MAGNITUDE easier. As a wallet on the network, it would be much easier to give the key holder the ability to say, yes - this wallet could receive airdrops. Simple, easy, and only requires me to interact with my wallet a single time. MUCH MUCH MUCH easier for wallets to implement. I would commit to implementing this feature for BankSocial wallet...

@jrwingate
Copy link

jrwingate commented Mar 24, 2024

Co-founder of Karate Combat here.

Token associations have been a major pain point for us. They've affected our product roadmap and routinely kill business development paths. We spend a lot of time and money routing around them. So I'm happy to see the momentum behind a change.

However, I personally believe the community is missing a big opportunity to remove them in entirety and move closer to parity with most other networks.

If I understand correctly, this is not a trivial change for the network or frontend clients. Further, unless wallets build out supporting UI the HIP will have marginal impact. I'd guess that Karate Combat hosts a top 10 wallet on the network, and we would not prioritize implementing the UI necessary for pending transactions. I expect embedded wallets and multichain wallets to gain a lot of market share on Hedera, and it's hard for me to imagine either prioritizing a pending airdrop concept.

If the primary driver behind token association is avoiding spam, I feel strongly that the community should reconsider this opportunity to remove token association altogether. Pending airdrops effectively just move the spam to a new folder that encourages interaction. Spam assets have been effectively dealt with by major wallets on other chains through sorting, hiding, etc. And spam avoidance is 10x less important for Hedera than its apps viral coefficients and multichain wallet support.

If email, text messages or social media required a receiver to whitelist a sender ahead of time, I wonder if these networks would have ever proliferated.

The only problem with removing token associates all together, or making a spam folder, is the OFAC/AML/BSA sanctions we could all have issues with. For example, if a wallet is a known OFAC wallet... and it dusts my wallet with tons of HBAR in it, the new laws popping up all over the world would make it EXTREMELY hard for me to onramp and off ramp my crypto. This exact thing happened with TornadoCash on ETH. This is a MAJOR feature that future proofs Hedera key space over all other network key spaces, because I can choose which tokens to let into my wallet. I think having an AllowAirdrops boolean on the account level, that a wallet can show the user at the time of setup of a wallet, is the easiest and most effective way to do this in the short term without creating a pending bucket that would put tons of unnecessary state management on chain, and UI management on the wallets.

@jrwingate
Copy link

jrwingate commented Mar 24, 2024

If we could add token dissociate, even with a balance, I would like this HIP alot more.

@Nana-EC
Copy link
Contributor Author

Nana-EC commented Mar 24, 2024

Co-founder of Karate Combat here.
Token associations have been a major pain point for us. They've affected our product roadmap and routinely kill business development paths. We spend a lot of time and money routing around them. So I'm happy to see the momentum behind a change.
However, I personally believe the community is missing a big opportunity to remove them in entirety and move closer to parity with most other networks.
If I understand correctly, this is not a trivial change for the network or frontend clients. Further, unless wallets build out supporting UI the HIP will have marginal impact. I'd guess that Karate Combat hosts a top 10 wallet on the network, and we would not prioritize implementing the UI necessary for pending transactions. I expect embedded wallets and multichain wallets to gain a lot of market share on Hedera, and it's hard for me to imagine either prioritizing a pending airdrop concept.
If the primary driver behind token association is avoiding spam, I feel strongly that the community should reconsider this opportunity to remove token association altogether. Pending airdrops effectively just move the spam to a new folder that encourages interaction. Spam assets have been effectively dealt with by major wallets on other chains through sorting, hiding, etc. And spam avoidance is 10x less important for Hedera than its apps viral coefficients and multichain wallet support.
If email, text messages or social media required a receiver to whitelist a sender ahead of time, I wonder if these networks would have ever proliferated.

The only problem with removing token associates all together, or making a spam folder, is the OFAC/AML/BSA sanctions we could all have issues with. For example, if a wallet is a known OFAC wallet... and it dusts my wallet with tons of HBAR in it, the new laws popping up all over the world would make it EXTREMELY hard for me to onramp and off ramp my crypto. This exact thing happened with TornadoCash on ETH. This is a MAJOR feature that future proofs Hedera key space over all other network key spaces, because I can choose which tokens to let into my wallet. I think having an AllowAirdrops boolean on the account level, that a wallet can show the user at the time of setup of a wallet, is the easiest and most effective way to do this in the short term without creating a pending bucket that would put tons of unnecessary state management on chain, and UI management on the wallets.

Thanks for the comments @onlylarping and @jrwingate
@onlylarping, @jrwingate's scenario is a great example of why Token Association is an imperative feature of the network for many.
In some cases the lack of this feature as seen on other networks can result in real world legal and financial implications that many users aren't aware of or able to handle.
Account sovereignty is also a core component of web3 and users having the choice of how their account balance and details are modified is an important tenant on the Hedera network.

Trying to manage the above case, as well as the considerations you noted that Karate Combat and other builders must consider in working with token association is why this HIP tries to carefully balance the considerations of both types of users.
Both considerations (+/- token associate) provide value to users and applications for different desired use cases.

The HIP preserves the sovereignty and autonomy of accounts by not forcing associations if a user does not want them. However, accounts at any point in their life cycle can be configured to accept any tokens they want.

Should a user desire to create an account that accepts all tokens or none, the wallet of their choice can support either.
Additionally, wallets can chose to support configurations to toggle between state per a users preference.

Multichain wallets such as those from the EVM side will likely create accounts that don't have the concept of association and as such would support accounts that accept all tokens.
There's an open question at the end of this HIP in which the community could explore future network flows to support the default considerations in additional ways.

One goal here is to provide a medium ground that utilize a safe default choice at the network level but allows developers to support the choice of their users.

@jrwingate the "having an AllowAirdrops boolean" that you have is a subset of the existing support by the network that is further emphasized in this HIP.
A developer may support a user that wants to accept all tokens by setting max_auto_assocations to -1, to support a user that doesn't want to support any auto associations they set max_auto_associations to 0 which is the default.

I appreciate the feedback and it's always great to hear more details about the amazing applications and flows you're both supporting and planning for users.
Let me know if this doesn't address your pathways. I believe this HIP supports both your goals with consideration for many more.

@Nana-EC
Copy link
Contributor Author

Nana-EC commented Mar 24, 2024

If we could add token dissociate, even with a balance, I would like this HIP alot more.

HI @jrwingate
Can you elaborate on this as I believe the TokenReject suggestion in the HIP supports what might be the desired final goal i.e. getting rid of the unwanted tokens regardless of the presence of a balance.
Based on this HIP, regardless of how you acquired the tokens (whether intentional association or automatic association) a user at any point with non-zero balance can reject a token and have the value debited from their account.
Thanks for the suggestion

Nana-EC and others added 3 commits March 24, 2024 21:31
Proposed changes to protobuf structure for PendingAirdrop and Reject
Signed-off-by: Nana Essilfie-Conduah <[email protected]>
Signed-off-by: Nana Essilfie-Conduah <[email protected]>
mgarbs
mgarbs previously approved these changes Mar 25, 2024
@Nana-EC Nana-EC marked this pull request as ready for review March 25, 2024 16:28
@mgarbs mgarbs merged commit 71e3ebe into hashgraph:main Mar 25, 2024
5 of 6 checks passed
@Nana-EC
Copy link
Contributor Author

Nana-EC commented Mar 25, 2024

@bugbytesinc, @jrwingate, @bmgentile, @onlylarping, @teacoat et al thanks for your in PR community feedback.
It really helps us get closer to the various array of considerations the network has to make to support developers and end users.
Please feel free to add any further comments on the discussion section here - #905
Thanks

@onlylarping
Copy link

Multichain wallets such as those from the EVM side will likely create accounts that don't have the concept of association and as such would support accounts that accept all tokens.

I think that makes sense. Just one question on this. Does the sender or receiver pay for autoassociations after this HIP?

@Nana-EC
Copy link
Contributor Author

Nana-EC commented Mar 25, 2024

Multichain wallets such as those from the EVM side will likely create accounts that don't have the concept of association and as such would support accounts that accept all tokens.

I think that makes sense. Just one question on this. Does the sender or receiver pay for autoassociations after this HIP?

Thanks @onlylarping
After this HIP the sender pays for auto associations.

@Neurone
Copy link
Contributor

Neurone commented Mar 27, 2024

Hi guys, I like the HIP in general, but I still see the introduction of the TokenReject new transaction type as a problem and a risky precedent.

I suggest stripping the TokenReject from HIP-904 and dedicating it to a separate HIP for further discussion; the frictionless airdrop HIP reaches its goals without that specific feature.

Regardless of TokenReject's actual features, that new transaction type is a problem because it retroactively modifies the assumptions about what you can do/not do with a token.

My concerns are not related to the ability per sé to reject tokens but to retroactively apply that behavior.

Changing assumptions for a base service like HTS can lead to unexpected results for existing applications and undermine developer's trust their application will work on Hedera regardless of future changes.

As a developer, I should always have the guarantee that if I do something with some rules today, those rules will be valid forever unless I change something or opt-in for a new feature.

One current assumption is, for example, that in some cases, I cannot get rid of tokens (i.e., they are frozen). As a developer, I developed my application, all the business logic, the integrations, the UIs, and the user journeys around those assumptions.

We should generally apply new features as opt-ins from the time they go live, keeping the current behaviors as the default.

In extreme cases when it's impossible to do otherwise for technical or security reasons, we can apply the new features automatically for the new entities, but never retroactively.

@popowycz
Copy link

From an account management perspective, it seems there might be confusion regarding the differences in account behavior based on the proposal described in the Backwards Compatibility section, especially if an account holder has accounts that cross the boundary between grandfathered and those created after this is implemented. Also, it may be too far to infer that a user that has set an existing account to the maxAutomaticAssociations at the current limit would automatically be willing to have this automatically increased to an unbounded amount.

It seems many of the risks enumerated in HIP-23 would still seem to apply, especially if:

  • the new account creation method is opt-out vs opt-in
  • the account holder bears the cost of carrying the tokens (future rents) especially if max_auto_associations is ♾️
  • the account holder may be restricted from remove the tokens if they are frozen
  • the impact to state and network resource utilization over any extended period of time offsets any up-front fees (including increased size of accounts, managing the state of the tokens including holding onto a large amount of pending transfers)

Presumably the fee structures for these would hamper some of these adverse effects. Depending on the potential resource consumption, the ability to set network limits on concurrent pending transfers might be considered.

kimbor pushed a commit to kimbor/hedera-improvement-proposal that referenced this pull request Jun 24, 2024
Signed-off-by: Nana Essilfie-Conduah <[email protected]>
Signed-off-by: SimiHunjan <[email protected]>
Signed-off-by: Joseph Sinclair <[email protected]>
Co-authored-by: SimiHunjan <[email protected]>
Co-authored-by: Joseph Sinclair <[email protected]>
Co-authored-by: Michael Garber <[email protected]>
Signed-off-by: Kim Rader <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.