HIP-756: Contract Scheduled Token Create
|Author||Nana Essilfie-Conduah, Luke Lee|
|Working Group||Richard Bair (@rbair23), Jasper Potts (@jasperpotts), Atul Mahamuni (@atulmahamuni)|
|Needs Council Approval||Yes ⓘ|
|Review period ends ⓘ||Fri, 28 Jul 2023 07:00:00 +0000|
|Type||Standards Track ⓘ|
Table of Contents
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.
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.
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.
- 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.
- As a smart contract developer, I would like to update the accounts that are currently assigned as autoRenew and treasurer.
- As a smart contract developer, I would like to retrieve information such as the address and other token details for the token created via a 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
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
C to be created both
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.
The ledger HSCS will utilize the existing Scheduled transaction service supported on the ledger within the System contract logic.
To achieve this the Hedera Token Service (HTS) system contract logic must be updated to create scheduled transactions and utilize scheduled transaction features.
IHederaTokenService interface must be updated to explicitly
- capture scheduled token creations
- retrieve information about the scheduled transaction
- obtain the token address that will be created by the successful execution of the scheduled transaction.
- capture the details of a scheduled token creation for clarity
Backwards compatibility is ensured as no existing features are modified. Similar to HTS system contract this HIP simply exposes HAPI entity functionality.
Existing security consideration such as throttles for both Scheduled transactions and TokenCreate will remain applicable. Additional considerations may include
Schedule transaction timespan will continue to be honored and scheduled transactions will be removed from memory upon execution or expiration.
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
A few options were considered prior to this, notable considerations were
- An update to the
TokenCreateHAPI transaction to optionally leave out signatures for treasury and autoRenew, with the requirement that a future
TokenUpdatetransaction 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
TokenAccountOperatorenum would have been introduced in the protobuf to capture various operator roles. On the system contracts additonal functions (
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.
- How can a consensus node retrieve the valid TokenAddress given a ScheduleAddress. On the Mirror Node this will be possible by following ScheduleAddress → ScheduleId → Schedule transaction execution timestamp → Token Create child transaction → recordFile Token Id. However, this information isn’t available to the consensus node. Should a ScheduleId → TokenId map be created and persisted?
- It is possible to overload the existing create and update token functions by adding a
boolto 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.
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: