getTokenExpiryInfo(address), updateTokenExpiryInfo(address, Expiry), isToken(address token), getTokenType(address token), and updateTokenInfo(address, HederaToken).updateTokenInfo(address, HederaToken) call is especially powerful. If a token's admin key signs the transaction calling a contract, that contract can now make itself the token's treasury, assume authority to mint or burn units or NFTs, and so on.getContractInfo query that previously
returned CONTRACT_DELETED may now report INVALID_CONTRACT_ID.$0.026 for 90 days) to the expired contract's auto-renew account. If an auto-renew account has zero balance, the network will then try to charge the contract itself.ContractUpdate or it receives hbar. After this grace period, the contract will be purged from state.CryptoApproveAllowance transaction.NodeStakeUpdate export to track the current values of several key staking properties. Please review the linked protobuf comments for more details on these properties.getTokenExpiryInfo(address), updateTokenExpiryInfo(address, Expiry), updateTokenInfo(address, HederaToken), isToken(address token) and getTokenType(address token).UtilService with a prng transaction that generates a record with either a pseudorandom 48-byte seed, or an integer in a requested range.0x169, using the interface here as in this example. Applications might include NFT mint contracts, lotteries, and so on.RandomGenerate to prng, or the system contract specification. It does explain in detail how prng derives its entropy from the running hash of transaction records generated by the network.ContractCallLocal support to the ERC-20 and ERC-721 functions allowance, getApproved, and isApprovedForAll.0.0.800 account balance has crossed a threshold to be set by the council coin committee, rewards will be permanently activated.CryptoCreate and CryptoUpdate transactions with staking elections---even if not all wallets and exchanges are updated to make these elections just yet.EthereumTransaction by which an account that was auto-created with an ECDSA(secp256k1) key can submit Ethereum transactions to Hedera by signing with its ECDSA key. (Standard Ethereum restrictions on the sender's nonce apply.) Please see HIP-410 for details, including a summary of some very compelling use cases that the EthereumTransaction enables---for example, "I want to use MetaMask to create a transaction to transfer HBAR to another account".0.approve() or setApprovalForAll() have an equivalent HAPI cryptoApproveAllowance or cryptoDeleteAllowance expression---and this expression is externalized as a HAPI TransactionBody in the record stream. That is, the HIP-376 system contracts expose a subset of the native HAPI operations, only within the EVM.CryptoService HAPI queries still return information for only an account’s 1000 most recently associated tokens; mirror nodes remain the best source for full history.)TokenCreate through Hedera Token Service Precompiled Contract). This HIP supercharges contract integration, making it possible for a smart contract to create a new HTS token---fungible or non-fungible, with or without custom fees. (An interested Solidity developer might consult the examples in this contract.)approve() and transferFrom() mechanisms in ERC-20 and ERC-721 style tokens.0.0.X entity id; and analogously, every HTS non-fungible token appears as an ERC-721 token. This means a smart contract can look up its balance of a fungible HTS token; or change its behavior based on the owner of a particular HTS NFT. Please see the linked HIP for full details.getAccountNftInfos and getTokenNftInfos queries do not have a favorable cost/benefit ratio, and these queries are now permanently disabled.CREATE2 opcode). Smart contract developers are now free to use the CREATE2 EVM opcode. A typical use case is a distributed exchange that wants its pair contracts to have deterministic addresses based on the tokens in the pair.bytes ledger_id stipulated by HIP-33 as a UTF-8 encoding of a hex string. The returned bytes are now the big-endian representation of the ledger's numeric id. Second, prior to this release, the record of a dissociateToken from a deleted token did not list the discarded balance of the dissociated account if the token's treasury was missing. This is now fixed.ContractCreate or ContractCall raised to 4M.CryptoGetInfo with a ledger id that marks which Hedera network answered the query. Second, HIP-31 allows a client to include the expected decimals for a token in a CryptoTransfer. This means a hardware wallet can guarantee its token transactions will have the precision seen by the the user in the device display.CryptoTransfer without having already created an 0.0.X id on the network. The new user only needs to provide their public key, and when a sponsor account sends ℏ "to" their key via a new AccountID.alias field, the network automatically creates an account with their key. Additional transfers to and from an auto-created account may also use its alias instead of the account id.getAccountInfo query response to echo back the account alias instead of its 0.0.<num> id; this will be fixed in the next release. Please use the free getAccountBalance query to check the 0.0.<num> id that corresponds to an alias.) You will be able to use the alias in all other transactions and queries in a future release.ContractUpdateTransactionBody.fileID field, which is redundant given the existence of the ContractGetBytecode query.ContractCallLocalQuery.maxResultSize field, as this limit is now simply a side-effect of the given gas limit.maxAutoAssociations can receive air-drops (i.e., units or NFTs of a token type without explicit association). Second, we have also implemented HIP-24, which provides a safety measure for token types created with a pauseKey. If a TokenPause is submitted with this key’s signature, then all operations on the token will be suspended until a subsequent TokenUnpause.CryptoTransfer and ConsensusSubmitMessage operations are still supported at 10k TPS even with this scale.CryptoCreate or CryptoUpdate transaction, without knowing in advance which specific token types they will use.CryptoTransfer, the network will automatically create the needed association---no explicit TokenAssociate transaction needed. This supports several interesting use cases; please see the linked HIP-23 for more details.tokenFeeScheduleUpdate transaction has been re-enabled, and multiple royalty fees can now be charged for a non-fungible token type.0.0.101 and 0.0.102 will now populate their ServiceEndpoint fields. (However, the deprecated ipAddress, portno, and memo fields will no longer be populated after the next release.)TokenService getTokenNftInfos and getAccountNftInfos queries are now deprecated and will be removed in a future release. The best answers to such queries demand historical context that only Mirror Nodes have; so these and related queries will move to mirror REST APIs.getExecutionTime query in the NetworkService that supports granular performance testing in development environments.CryptoCreate or CryptoUpdate transaction, without knowing in advance which specific token types they will use.CryptoTransfer, the network automatically creates the needed association---no explicit TokenAssociate transaction needed. This supports several interesting use cases; please see the linked HIP-23 for more details.tokenFeeScheduleUpdate transaction has been re-enabled, and multiple royalty fees can now be charged for a non-fungible token type.0.0.101 and 0.0.102 will now populate their ServiceEndpoint fields. (However, the deprecated ipAddress, portno, and memo fields will not be no longer be populated after the next release.)TokenService getTokenNftInfos and getAccountNftInfos queries are now deprecated and will be removed in a future release. The best answers to such queries demand historical context that only Mirror Nodes have; so these and related queries will move to mirror REST APIs.getExecutionTime query in the NetworkService that supports granular performance testing in development environments.CryptoTransfer can perform atomic swaps with any arbitrary combination of fungible, non-fungible, and ℏ transfers. (Please do note that the "paged" getAccountNftInfos and getTokenNftInfos queries will remain disabled until release 0.18.0, as several large performance improvements are pending.)FUNGIBLE_COMMON). Custom fractional fees may now also be set as "net-of-transfer". In this case the recipient(s) in the transfer list receive the stated amounts, and the assessed fee is charged to the sender.TokenBurn and TokenMint transactions. Second, network administrators issuing a CryptoUpdate to change the treasury account's key must now sign with the new treasury key. Third, the supported TLS cipher suites have been updated to the following list:TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (TLS v1.2)TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (TLS v1.2)TLS_AES_256_GCM_SHA384 (TLS v1.3)tokenFeeScheduleUpdate transaction is not currently available. Second, only one royalty fee will be charged for a non-fungible token type. Both limitations will be removed in release 0.18.0.CryptoTransfer.CryptoTransfer fails atomically, changing no balances other than for the Hedera network fees.FractionalFee as described in this issue. In Release 0.17.0 the more natural FixedFee configuration will be available.CryptoTransfer can perform atomic swaps with any arbitrary combination of fungible, non-fungible, and ℏ transfers.GetAccountRecords query now returns, from state, all such records for which the queried account was the payer account.INVALID_EXPIRATION_TIME.ScheduleSign transaction in many common use cases. Users will be able to schedule CryptoTransfer and ConsensusSubmitMessage transactions in this release. Other transaction types will be introduced in future releases.0.0.101 and 0.0.102. The three deprecated fields are ipAddress, portno, and memo. When we rely on these fields, we cannot concisely represent node with multiple IP addresses. For example, take mainnet node 0 (account 0.0.3), which as of this writing has proxy IPs 13.82.40.153, 34.239.82.6, and 35.237.200.180. The mainnet 0.0.101 file must include a NodeAddress entry for each proxy, which means duplicating fields like nodeCertHash.0.0.101 and 0.0.102 time to prepare for exclusive use of the new format. After six months, we will eliminate the duplication and the ipAddress, portno, and memo fields will be left empty. (The fields will never be removed to ensure it remains possible to parse early versions of these system files.)string field whose UTF-8 encoding includes the zero-byte character; that is, Unicode code point 0, NUL. Databases (for example, PostgreSQL) commonly reserve this character as a delimiter in their internal formats, so allowing it to occur in entity fields can make life harder for Mirror Node operators.X is associated with token Y, then even if token Y is marked for deletion, a getAccountInfo query for X will continue to show the association with Y _until_it is explicitly removed via a tokenDissociateFromAccount transaction. Note that for convenience, queries that return token balances now also return the decimals value for the relevant token. This allows a user to interpret e.g. balance=10050 as 100.50 tokens given decimals=2.memo field present on contract and topic entities to the account, file, token, and scheduled transaction entities. (Note this memo is distinct from the short-lived memo that may be given to any TransactionBodyfor inclusion in the TransactionRecord.) All of these changes to HAPI are now more easily browsed via GitHub pages here; the new hashgraph/hedera-protobufs repository is now the authoritative source of the protobuf files defining HAPI._Balances.csv files. The type of this file is AllAccountBalances.900-1000 on startup if they do not exist.newTotalSupply field in the receipts of TokenMint and TokenBurn transactions. Without this field, a client must follow the entire record stream of a token's supply changes to be certain of its supply at the consensus timestamp in the receipt. (Note that HTS operations are now enabled on Previewnet and Testnet, but remain disabled on Mainnet at this time. Please consult the SDK documentation for HTS semantics.)fees.tokenTransferUsageMultiplier that scales the resource usage assigned to a CryptoTransfer that changes token balances. This scaling factor is expected to be set so that the cost of a CryptoTransfer that changes two token balances is roughly 10x the cost of a CryptoTransfer that changes only two hbar balances.CryptoUpdate transactions that target system accounts. (That is, accounts with numbers not greater than hedera.numReservedSystemEntities.) In earlier versions, only three payers were accepted: The target account itself, the system admin account, or the treasury account. Other payers resulted in a status of AUTHORIZATION_FAILED. This entire restriction is removed, with one exception---the treasury must pay for a CryptoUpdate targeting the treasury.SignatureList message type. Second, we added a top-level signedTransactionBytes field to the Transaction message to ensure deterministic transaction hashes across different client libraries; the top-level bodyBytes and sigMap fields are now deprecated and the already-deprecated body field is removed. Third, we deprecated all fields related to non-payer records, include account send and receive thresholds. This followed from the effective removal of non-payer records in v0.8.1.CryptoGetRecords and ContractGetRecords queries have also changed. The only queryable records are now those granted to the effective payer of a transaction that was handled while the network property ledger.keepRecordsInState=true. Such records have an expiry of 180 seconds. It is important to note that because a contract account can never be the effective payer for a transaction, any ContractGetRecords query will always return an empty record list, and we have deprecated the query.master for up-to-date semantics.getTxRecord API will continue to return ALL records with the transaction ID.0.7.3 which enables zero-stake nodes to be part of a network without affecting consensus. Hedera Services v0.7.0 migrated to new interfaces and methods provided in this version of the Swirlds SDK. HCS topic running hashes are now calculated including the payer account id. The release includes other minor fixes and improvements.ConsensusSubmitMessageTransactionBody, an optional field for the current chunk information. For every chunk, the payer account that is part of the initialTransactionID must match the Payer Account of this transaction. The entire initialTransactionID should match the transactionID of the first chunk, but this is not checked or enforced by Hedera except when the chunk number is 1.