HIP-542: Payer-sponsored auto-account creation with HTS assets
|Working Group||Neeha Sompalli (@Neeharika-Sompalli), Ali Katamjani ([email protected])|
|Needs Council Approval||Yes|
|Review period ends||Wed, 07 Sep 2022 07:00:00 +0000|
|Updated||2022-08-24, 2022-09-06, 2022-09-20, 2023-01-20, 2023-02-01|
Table of Contents
HIP-32 defined a new way to create a Hedera account by submitting a
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.
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.
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
- 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
The technical specification for this HIP requires three changes in the network:
- Instead of returning
CryptoTransferattempts 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
- When a new alias receives n different types of HTS assets, create the synthetic
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.
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.”
Please follow this issue for progress on the reference implementation.
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.
A future HIP should propose extending the
tokenTransfer system precompile to support auto-creation via non-hbar assets.
This document is licensed under the Apache License, Version 2.0 – see LICENSE or (https://www.apache.org/licenses/LICENSE-2.0)
Please cite this document as: