Pending Token Transfers

[Nana-EC]

Description:
Users on the Hedera network have the ability to control the token classes that can be added to their balance. A user must first associate with a token class before they may receive token value from others. This differs from other networks where users may receive token value with no restrictions - in short, airdrops are currently not supported on the Hedera network. For some, this serves as a fundamental account protection feature, for others, this serves as an extra user step required before receiving desired token.

HIP 655 provides a suggestion for a token outbox concept that tracks a sending users intent to airdrop tokens to a receiving account (EOA or contract) that has not yet associated with the token class.

This outbox gives a mapping that may be used to enable the simulation of the airdrop transfer concept that web3 users are familiar with. A network can communicate a senders commitment to transfer a token to a potential recipient, the intended recipient maintains account sovereignty as the network enforces the association requirement before a receiver takes ownership of the tokens. Tokens in an outbox are conceptually pending token transfers or offers to the desired recipient until they accept or reject the intent. Upon acceptance the intended token value will be added to the recipients balance. Additionally, support for association and transfer of tokens in an atomic operation will allow the seamless ability to take ownership and transfer from your pending balance.

Related issue(s):

Fixes #

Notes for reviewer:

Checklist

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

[netlify]

✅ Deploy Preview for hedera-hips ready!

Name	Link
🔨 Latest commit	23ffc60
🔍 Latest deploy log	https://app.netlify.com/sites/hedera-hips/deploys/660584ecb3ec4d000860caa7
😎 Deploy Preview	https://deploy-preview-777--hedera-hips.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

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

[bmgentile]

I believe this is going to negatively impact decentralized exchanges on the Hedera network; here's how:

1. Liquidity Pool Dynamics:
• Delayed Finality: If someone swaps for a certain token type on a DEX but doesn’t immediately associate the token, the actual transfer of tokens from the liquidity pool is delayed. This would mean the liquidity pool’s total assets and the ratio of tokens within it would not reflect real-time transactions, creating a lag in the reflection of actual liquidity.
• Potential for Sudden Drains: If multiple users decide to associate their tokens simultaneously after a delay, it could lead to sudden and substantial drains from the liquidity pool. This could destabilize the pool, especially if it’s not very large.

2. Price Impact and Slippage:
Swapping tokens on DEXs often comes with price impacts, especially for large trades or low-liquidity tokens. If the actual liquidity pool does not reflect pending associations, it could mislead users about the potential price impact of their swaps. When the tokens are eventually associated and deducted, the sudden change in liquidity might result in unexpected slippage for subsequent traders.

3. Arbitrage Opportunities:
This delayed token association mechanism might be exploited by arbitrageurs. They could monitor the pending associations and act on price discrepancies between the DEX and other exchanges before the liquidity pool adjusts.

4. User Experience and Complexity:
• For the end-users, this could introduce another layer of complexity. They’d need to be aware of the association mechanism and its implications on their trades. Some might forget to associate, leading to confusion or concerns about missing funds.
• Users might also use the association delay tactically, waiting for favorable market conditions before associating and finalizing their trades. This could lead to speculative behavior.

5. Operational Overheads for DEX:
The DEX would need mechanisms to monitor and handle pending associations. This could increase the operational complexity and resource usage.

[bmgentile]

If the goal is to solve for airdrops specifically, there could be a transaction type on Hedera called “Airdrop Transfer” and that specific transaction type allows someone to send tokens with this "pending" feature. This way it would silo the airdrop ability and be an AMAZING feature for our users (and one that's frequently requested) / support growing the adoption of Hedera.

It would hurt many applications if it’s not a very specific transaction type to enable "pending", and all transfers of tokens had it enabled.

[Nana-EC]

If the goal is to solve for airdrops specifically, there could be a transaction type on Hedera called “Airdrop Transfer” and that specific transaction type allows someone to send tokens with this "pending" feature. This way it would silo the airdrop ability and be an AMAZING feature for our users (and one that's frequently requested) / support growing the adoption of Hedera.

It would hurt many applications if it’s not a very specific transaction type to enable "pending", and all transfers of tokens had it enabled.

@bmgentile HIP 655's goal is to fix airdrops. This HIPs goal is to ease the friction of onboarding and that first experience of transferring tokens to an account that's not associated. Airdrops update a recipients balance without them taking action. This allows them to take action to approve or reject, so this is more airgrab-ish

[Nana-EC]

If the goal is to solve for airdrops specifically, there could be a transaction type on Hedera called “Airdrop Transfer” and that specific transaction type allows someone to send tokens with this "pending" feature. This way it would silo the airdrop ability and be an AMAZING feature for our users (and one that's frequently requested) / support growing the adoption of Hedera.

It would hurt many applications if it’s not a very specific transaction type to enable "pending", and all transfers of tokens had it enabled.

@bmgentile All transfer that are applicable to this state would utilize the outbox. Should a user have to take action to receive the token after the transfer why would this hurt applications?
Can you highlight some scenarios to help weigh where there are still gaps in the solution.

[Nana-EC]

If the goal is to solve for airdrops specifically, there could be a transaction type on Hedera called “Airdrop Transfer” and that specific transaction type allows someone to send tokens with this "pending" feature. This way it would silo the airdrop ability and be an AMAZING feature for our users (and one that's frequently requested) / support growing the adoption of Hedera.

It would hurt many applications if it’s not a very specific transaction type to enable "pending", and all transfers of tokens had it enabled.

@bmgentile A new transaction type just to circumvent token associate wouldn't work as it'd break the sovereignty of an account choice on the network to be associated or not with a token. Users should be able to chose the behaviour their account takes (use auto association etc) for HTS as it differs from ERC tokens in these advanced management features.

[Nana-EC]

I believe this is going to negatively impact decentralized exchanges on the Hedera network; here's how:

1. Liquidity Pool Dynamics: • Delayed Finality: If someone swaps for a certain token type on a DEX but doesn’t immediately associate the token, the actual transfer of tokens from the liquidity pool is delayed. This would mean the liquidity pool’s total assets and the ratio of tokens within it would not reflect real-time transactions, creating a lag in the reflection of actual liquidity. • Potential for Sudden Drains: If multiple users decide to associate their tokens simultaneously after a delay, it could lead to sudden and substantial drains from the liquidity pool. This could destabilize the pool, especially if it’s not very large.

2. Price Impact and Slippage: Swapping tokens on DEXs often comes with price impacts, especially for large trades or low-liquidity tokens. If the actual liquidity pool does not reflect pending associations, it could mislead users about the potential price impact of their swaps. When the tokens are eventually associated and deducted, the sudden change in liquidity might result in unexpected slippage for subsequent traders.

3. Arbitrage Opportunities: This delayed token association mechanism might be exploited by arbitrageurs. They could monitor the pending associations and act on price discrepancies between the DEX and other exchanges before the liquidity pool adjusts.

4. User Experience and Complexity: • For the end-users, this could introduce another layer of complexity. They’d need to be aware of the association mechanism and its implications on their trades. Some might forget to associate, leading to confusion or concerns about missing funds. • Users might also use the association delay tactically, waiting for favorable market conditions before associating and finalizing their trades. This could lead to speculative behavior.

5. Operational Overheads for DEX: The DEX would need mechanisms to monitor and handle pending associations. This could increase the operational complexity and resource usage.

@bmgentile these are solid illustrations, thanks.
The DeFi complexity of liquidity management on top of this feature does indeed make it challenging.
I'm not sure how the system can both debit a sender and credit a potential recipient without the potential recipients first associating when it comes to HTS tokens.
Hedera DApps can manage this challenge by checking for association and enabling users, however, EVM native DApps aren't yet willing to add this additional Hedera account feature set to their flow as it's not an EVM native feature.

Indeed complexity is increased.
I will continue to think on this. 🤔

[dougvk]

@bmgentile @Nana-EC I'm not so sure this is a problem for DEXs. One of the classic user flows for depositing liquidity into a pool or staking into a pool is having to approve this or that token before you can even interact with the pool itself. Approvals to me sound the same as associations. In fact, they're more strict -- sometimes they are infinite approvals -- but Ethereum hacks have shown that that's a bad practice. So usually you have to go through approvals every time you want to deposit or withdraw. Jumping through these sorts of hoops is normal in Ethereum DEX UX flows.