update HIP after architecture review (#778)

Signed-off-by: lukelee-sl <luke.lee@swirldslabs.com>
Signed-off-by: Michael Garber <michael.garber@swirldslabs.com>
Co-authored-by: Michael Garber <michael.garber@swirldslabs.com>

HIP/hip-756.md

@@ -1,16 +1,16 @@
 ---
 hip: 756
 title: Contract Scheduled Token Create
-author: Nana Essilfie-Conduah (@nana-ec)
-working-group: Richard Bair (@rbair23), Jasper Potts (@jasperpotts)
+author: Nana Essilfie-Conduah (@nana-ec), Luke Lee (@lukelee-sl)
+working-group: Richard Bair (@rbair23), Jasper Potts (@jasperpotts), Atul Mahamuni (@atulmahamuni)
 type: Standards Track
 category: Service
 needs-council-approval: Yes
 status: Council Review
 last-call-date-time: 2023-07-28T07:00:00Z
 created: 2023-06-14
 discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/pull/756
-updated: 2023-08-01
+updated: 2023-08-08
 ---
 
 ## Abstract
@@ -35,9 +35,9 @@ By providing a secure mechanism to assign accounts roles on tokens, smart contra
 
 ## User stories
 
-1. As an EOA 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 an EOA I would like to initiate a smart contract transaction that signs off and accepts a token operator roles assigned to the contract.
-3. As an EOA I would like to initiate a smart contract transaction that retrieves the token address of a scheduled token create tranaction
+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 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 `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`. 
@@ -55,18 +55,20 @@ To achieve this the Hedera Token Service (HTS) system contract logic must be upd
 The `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
 
-|   Hash        |   Selector                                                                                                                |
-|---------------|---------------------------------------------------------------------------------------------------------------------------|
-| `0xe780c5d3`  | `getScheduledFungibleTokenCreateTransaction(address scheduleAddress) returns (FungibleTokenInfo memory tokenInfo)`        |
-| `0x14749042`  | `getScheduledNonFungibleTokenCreateTransaction(address scheduleAddress) returns (NonFungibleTokenInfo memory tokenInfo)`  |
-| `0xf616ec93`  | `getScheduledTokenAddress(address scheduleAddress) returns (int64 responseCode, address tokenAddress)`                    |
-| `0x4742876e`  | `scheduleCreateFungibleToken(…) returns (address scheduleAddress)`                                                        |
-| `0xa001e7d2`  | `scheduleCreateFungibleTokenWithCustomFees(…) returns (address scheduleAddress)`                                          |
-| `0xbbaa57c2`  | `scheduleCreateNonFungibleToken(…) returns (address scheduleAddress)`                                                     |
-| `0x228fa74a`  | `scheduleCreateNonFungibleTokenWithCustomFees(…) returns (address scheduleAddress)`                                       |
+|   Hash        | Selector                                                                                                                 |
+|---------------|--------------------------------------------------------------------------------------------------------------------------|
+| `0xe780c5d3`  | `getScheduledFungibleTokenCreateTransaction(address scheduleAddress) returns (FungibleTokenInfo memory tokenInfo)`       |
+| `0x14749042`  | `getScheduledNonFungibleTokenCreateTransaction(address scheduleAddress) returns (NonFungibleTokenInfo memory tokenInfo)` |
+| `0xf616ec93`  | `getScheduledTokenAddress(address scheduleAddress) returns (int64 responseCode, address tokenAddress)`                   |
+| `0x4742876e`  | `scheduleCreateFungibleToken(…) returns (address scheduleAddress)`                                                       |
+| `0xa001e7d2`  | `scheduleCreateFungibleTokenWithCustomFees(…) returns (address scheduleAddress)`                                         |
+| `0xbbaa57c2`  | `scheduleCreateNonFungibleToken(…) returns (address scheduleAddress)`                                                    |
+| `0x228fa74a`  | `scheduleCreateNonFungibleTokenWithCustomFees(…) returns (address scheduleAddress)`                                      |
+| `0xc42a9a17`  | `scheduleUpdateTokenInfo(…) returns (int64 responseCode, address scheduleAddress)`                                       |
 
 ## Backwards Compatibility
 
@@ -106,6 +108,7 @@ A few options were considered prior to this, notable considerations were
 ## Open Issues
 
 1. 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?
+2. It is possible to 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. 
 
 ## References