HIP-756: Contract Scheduled Token Create

Author	Nana Essilfie-Conduah, Luke Lee
Working Group	Richard Bair, Jasper Potts, Atul Mahamuni, Stanimir Stoyanov (stanimir.stoyanov@limechain.tech)
Requested By	Hashgraph
Discussions-To	https://github.com/hashgraph/hedera-improvement-proposal/pull/756
Status	Accepted ⓘ
Needs Council Approval	Yes ⓘ
Review period ends ⓘ	Fri, 28 Jul 2023 07:00:00 +0000
Type	Standards Track ⓘ
Category	Service ⓘ
Created	2023-06-14
Updated	2025-01-24

Abstract

This proposal addresses the feature gap of a smart contracts ability to designate another account to the autoRenew and treasury roles on a token during creation.

Since smart contracts executions do not utilize the Hedera signature map they are unable to carry along the authorizations that the Hedera ledger uses to confirm an accounts participation and acknowledgment in a transaction.

To address this Smart Contracts can utilize the Hedera Schedule Service by submitting a scheduled transaction to which accounts can sign / authorize as an acceptance of the role assignment.

Motivation

In many DeFi scenarios a contract may create a token and desire to set another account (EOA or contract) to play a role on the token entity such as the treasurer or the autoRenew account. In each case the account would be responsible for carrying out actions that are critical to the token life cycle and may at time incur a cost (value debit) to the account or transaction submission fees.

However, under the Hedera Smart Contract Service (HSCS) Security Model v2 it is not possible to authorize a contract in advance to modify an accounts property or cause a debit to their balance without their authorization. This essentially means treasurer and autoRenew accounts can only take on the value of the contract creating the token.

This is a step back in the Hedera UX that is made easier by the use of in transaction signatures.

Rationale

By providing a secure mechanism to assign accounts roles on tokens, smart contracts can continue to be used for more decentralized operation whiles still maintaining the integrity of account sovereignty by allowing account to approve or reject role assignments.

User stories

1. As a smart contract developer, I would like to initiate a smart contract transaction that creates a token and assigns other accounts to autorenew and/or treasurer operator roles.
2. As a smart contract developer, I would like to update the accounts that are currently assigned as autoRenew and treasurer.
3. As a smart contract developer, I would like to retrieve information such as the token details for the scheduled token create transaction.

An example of an E2E flow would see an EOA Ama call contract account B which then calls a variation of the IHTS createToken() methods to create a token C which assigns EOA Dede as a treasurer account and EOA Eric as the autoRenew account. Upon execution of the transaction by the system contract logic on a consensus node will submit a synthetic ScheduleCreate transaction with the desired TokenCreate as the inner transaction. The transaction execution will return the address of the ScheduleId to the calling contract B. For token C to be created both Dede and Eric will have to submit a ScheduleSignTransaction (via HSS system contract or SDK) using the returned ScheduleAddress/ScheduleID. The action of submitting a signed ScheduleSign transaction will serve as an approval of the scheduled TokenCreate in which they will assume a role. When the last signature is obtained by a network node the scheduled TokenCreate will be submitted as a child transaction and the resulting token address will be returned in the execution or a future query.

Specification

The ledger HSCS will utilize the existing Scheduled transaction service supported on the ledger within the System contract logic.

To achieve this the Hedera Schedule Service (HSS) system contract logic must be updated to create scheduled transactions and utilize scheduled transaction features.

Hedera Schedule Service (HSS) system contract

The IHederaScheduleService interface must be updated to explicitly

• capture scheduled token creations and updates
• retrieve information about the scheduled token creation

Hash	Selector
0xda2d5f8f	getScheduledCreateFungibleTokenInfo(address scheduleAddress) returns (int64 responseCode, FungibleTokenInfo memory tokenInfo)
0xd68c902c	getScheduledCreateNonFungibleTokenInfo(address scheduleAddress) returns (int64 responseCode, NonFungibleTokenInfo memory tokenInfo)
0xca829811	scheduleNative(address systemContractAddress, bytes callData, address payerAddress) returns (int64 responseCode, address scheduleAddress)

scheduleNative(address,bytes,address) will be used to schedule the token creation or update transaction. The callData will be the ABI encoded TokenCreate or TokenUpdate transaction. The payerAddress will be the account that will pay for the transaction fees. For the purpose of the HIP the only whitelisted systemContractAddress will be the HederaTokenService system contract (0x167) and for the callData the only acceptable ABI encoded transaction will be the TokenCreate and TokenUpdate transactions - createFungibleToken, createFungibleTokenWithCustomFees, createNonFungibleToken, createNonFungibleTokenWithCustomFees and updateTokenInfo.

Backwards Compatibility

Backwards compatibility is ensured as no existing features are modified. Similar to HTS system contract this HIP simply exposes HAPI entity functionality.

Security Implications

Existing security consideration such as throttles for both Scheduled transactions and TokenCreate will remain applicable. Additional considerations may include

Storage considerations

Schedule transaction timespan will continue to be honored and scheduled transactions will be removed from memory upon execution or expiration.

Fee considerations

Gas collections should encompass the following aspects of the network

• Storage cost via fees
• EVM execution work via gas
• Consensus Node execution work via fees

How to Teach This

Reference Implementation

Rejected Ideas

A few options were considered prior to this, notable considerations were

1. An update to the TokenCreate HAPI transaction to optionally leave out signatures for treasury and autoRenew, with the requirement that a future TokenUpdate transaction would be required by the treasurer and autoRenew accounts to either accept or reject their assignments. The normal functioning of a token would be halted until roles had been accepted. Additionally, the concept of a TokenAccountOperator enum would have been introduced in the protobuf to capture various operator roles. On the system contracts additonal functions (defaultTokenOperators(), authorizeTokenOperator(address operator, uint operatorType) and revokeTokenOperator(address operator, uint operatorType)) to expose query, apporval and rejection logic. These function were inspired by EIP 777.
2. Overload the existing create and update token functions by adding a bool to indicate if the transaction is a scheduled transaction. This would require that the returned address be either the token address or the schedule address and thus make the api unnecessarily confusing.
3. Create separate functions that reflect the existing TokenCreate and TokenUpdate functions but with the ability to schedule the transaction - scheduleCreateFungibleToken(…), scheduleCreateFungibleTokenWithCustomFees(…), scheduleCreateNonFungibleToken(…), scheduleCreateNonFungibleTokenWithCustomFees(…) and scheduleUpdateTokenInfo(…). This would have required a new set of functions to be added to the IHederaScheduleService interface for every future schedulable functionality.
4. A function to retrieve the token address given a schedule address prior to the token creation. This would have required a new function to be added to the IHederaScheduleService interface.

Open Issues

1. Long term scheduled transactions via smart contract. This issue will be addressed in a future HIP.

References

• HIP-755

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: