About HIPs

    GitHub Logo HIP-542: Payer-sponsored auto-account creation with HTS assets

    Author Michael Tinker
    Working Group Neeha Sompalli, Ali Katamjani ([email protected])
    Discussions-To https://github.com/hashgraph/hedera-improvement-proposal/discussions/541
    Status Final ⓘ
    Needs Council Approval Yes ⓘ
    Review period ends ⓘ Wed, 07 Sep 2022 07:00:00 +0000
    Type Standards Track ⓘ
    Category Service ⓘ
    Created 2022-08-08
    Updated 2023-02-01
    Requires 32
    Release v0.31.0

    Table of Contents

    Abstract

    HIP-32 defined a new way to create a Hedera account by submitting a CryptoTransfer that sends hbar to a protobuf representation of a key called an alias.

    When an account is not already using the alias, and the sent hbar is enough to cover the account creation fee, then the network creates a new account with the key implied by the alias. It deducts the account creation fee from the sent hbar, and the new account’s balance is the remaining hbar.

    Thus auto-account creation does not work if sending only a unit of a fungible token or an NFT to a new alias, because HTS assets may not have fees deducted from them.

    We propose to support auto-creation via HTS assets by charging the account creation fee to the payer of the triggering CryptoTransfer. This means a new alias may be given anywhere in the transaction; both in the hbar transfer list, or in an HTS token transfer list. In the latter case, the assessed creation fee will include at least one auto-association slot, since the new account must be associated to its originating HTS assets.

    IMPORTANT: We do not propose to make nodes do extra work in precheck estimating implied auto-creation fees. These fees will be assessed as part of the CryptoTransfer service logic; and, as with all other service fees, will not be estimated in precheck.

    Motivation

    Allowing auto-creation with token assets makes the network match the expectations of Ethereum users, since Ethereum contracts allow ERC-20 and ERC-721 assets be transferred to an externally operated account (EOA) even before that account has been created by sending it value.

    Rationale

    We cannot provide free account creation, for the same DOS risks outlined in HIP-32. There is also no reasonable way to convert HTS token units or NFTs into hbar. Therefore, a solution to extend CryptoTransfer auto-creation to HTS assets is to deduct the account creation fee from the CryptoTransfer payer.

    User stories

    • As an NFT creator, I want to send an NFT to an onboarding collector, given only their public key.
    • As a dApp operator, I want to send my native token to an onboarding user in a single transaction; rather than first submitting a CryptoCreate, then a TokenAssociate, then a CryptoTransfer.

    Specification

    The technical specification for this HIP requires three changes in the network:

    • Instead of returning INVALID_ACCOUNT_ID when a CryptoTransfer attempts to credit a new alias with a non-hbar asset, run the same auto-creation logic that runs today when crediting a new alias with hbar.
    • Instead of deducting the account creation fee from the assets being transferred to a new alias, charge this creation fee to the CryptoTransfer payer account.
    • When a new alias receives n different types of HTS assets, create the synthetic CryptoCreate transaction with maxAutoAssociationSlots=n.

    Backwards Compatibility

    Any existing clients that use auto-creation need to be sure the payer account for the CryptoTransfer can afford an account creation fee, since this fee will no longer be deducted from the auto-created account’s initial balance.

    Security Implications

    This HIP does not change the charging and throttling protections used to secure auto-creation as added in HIP-32. So we do not perceive any new security implications.

    How to Teach This

    “Auto-create an account by sending HTS assets to its desired alias.”

    Reference Implementation

    Please follow this issue for progress on the reference implementation.

    Rejected Ideas

    We briefly considered requiring a simultaneous hbar payment upon auto-creation with HTS assets, but this would have eliminated most of the usability gains intended with the HIP.

    Open Issues

    A future HIP should propose extending the tokenTransfer system precompile to support auto-creation via non-hbar assets.

    References

    Copyright/license

    This document is licensed under the Apache License, Version 2.0 – see LICENSE or (https://www.apache.org/licenses/LICENSE-2.0)

    Citation

    Please cite this document as: