atomic assoc contracts

[littletarzan]

Description:

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	9d7d37b
🔍 Latest deploy log	https://app.netlify.com/sites/hedera-hips/deploys/645e80c5000b7a0008f3bf8a
😎 Deploy Preview	https://deploy-preview-711--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 settings.

[Nana-EC]

Interesting idea.
Left comments as questions.

[Nana-EC]

Does the proposal refer to all smart contract regardless of creation path?
For example those created via HAPI ContractCreate have the option of setting max_automatic_token_associations and updating it in a ContractUpdate.

This might be a good section to address why that path is not sufficient for the proposal

[littletarzan]

This proposal refers to all smart contracts regardless of creation path. Smart contracts are often intermediaries for many different tokens, so it becomes a challenge to maintain association maps and retain decentralization. Presently, dexes are associating/dissociating tokens using precompiles every time they are used as intermediaries. If Hedera was able to refine association checks such that the ending contract balance must be greater than zero, it would eliminate the need to pay 5 cents more per transaction.

We will address why the max_automatic_token_association is not sufficient.

[littletarzan]

@Nana-EC this is now addressed on line 24

[Nana-EC]

Can you expand on this?

[littletarzan]

I meant generally speaking there might be a risk for a contract to accept an unassociated token and carry a balance. As long as there's a firm check at the end of the transaction that unassociated token balance = 0, I don't think there is a security risk.

[Nana-EC]

Okay. Should be explicit in the HIP so it's clear to all

[Nana-EC]

Would this feature be opt-in or opt-out?
In either case if applicable what procedure would a contract creator take?

[littletarzan]

I would like to see this applied to every smart contract. If a contract's token balance changes from zero to nonzero during a contract call transaction, then check for association at the end of the transaction. I would also support opt-in or opt-out if there are use cases that call for it. If an opt-in flag is enabled, and the contract can create another contract using CREATE or CREATE2, then the created contracts should inherit the property from the parent contract.

[bguiz]

I'd recommend adding references to:

• EIP-20
• HTS
• anything specific to HTS associateToken an dissociateToken
• anything specific to response codes (e.g. where TOKEN_NOT_ASSOCIATED_TO_ACCOUNT and SUCCESS are defined)

[bguiz]

In the code examples below, I'd recommend:

• explicitly define the input parameters (token and recipient)
  • e.g. can recipient only be an EOA, or could it be any address, including SCs?
  • e.g. can token only be an HTS token, or could it be any token, including ones authored in Solidity?
  • @param treasury should be @param recipient in the function-level comments
• in lieu of the comment // assumes msg.sender approved an allowance to address(this), include the code for the approval, as it is more explicit
• In function1, the return value of the 2nd invocation of HederaTokenService.transferToken is saved in respCode, whereas in function2 this does not happen
  • I assume that you wanted to do so in both, and assert that in function1 it was SUCCESS, and in function2 it should be TOKEN_NOT_ASSOCIATED_TO_ACCOUNT or your newly proposed TOKEN_NOT_ASSOCIATED_TO_CONTRACT
  • If so, add that assertion or a comment; plus consider adding function3 which results in the newly proposed response code.

[mgarbs]

My perspective here is that if the contract ever held custody of an asset, it should pay the association cost out of sheer fairness to all entities in the network. Doing something else is giving special treatment to contracts when they are just another entity and should be treated as such.

[mgarbs]

@littletarzan want to make sure you saw this comment ^^

[littletarzan]

@mgarbs Is it true the association fee is to help pay for expanded network state size? If so, then atomic custody of tokens by smart contracts without association would not add to the net size of the network state. It seems unreasonable to have to pay the association fee to custody a token for an atomic or infinitesimal amount of time.