What is the change?

After the security incident of March 2023, core Hedera engineers conducted a thorough analysis of the Smart Contract Service and the Hedera Token Service system contracts. No new vulnerabilities were found, but the team looked for any behavioral differences between Hedera Token Service system contract APIs and those of Ethereum Virtual Machine (EVM) or ERC token APIs that could be used maliciously. To eliminate any possibility of such differences being used as attack vectors in the future, the consensus node software will align the behaviors of the Hedera Smart Contract Service and HTS system contracts with those of EVM and typical token APIs such as ERC 20 and ERC 721.

As a developer on Hedera, what should I do?

Developers are strongly encouraged to test their applications with new contracts and UX using the new security model to avoid unintended consequences.

• The new security model has been applied to contracts created from the mainnet 0.35.2 release onwards.
• Existing contracts deployed prior to this upgrade will continue to use the previous security model for a limited time to allow for application/UX modifications.
• The previous security model will only be maintained for an approximate period of 3 months. The current target is for the network to remove the previous security model and for all contracts to follow the new security model by the mainnet release of July 2023.
• See more information in the official Hedera documentation.

What does the change in security model mean for smart contract developers?

The security update involves changes to entity permissions during contract executions when modifying state. In short, system contract calls (smart contract calls to the Hedera Token Service) are no longer executed with all upper caller privileges even if the authorized user provides a signature.

After

Before

Impact on Functionality

Below are some of the key functions impacted with the model update:

• Externally owned accounts (EOAs) and contracts must now provide explicit approval/allowance to a contract for the approved entity to be able to transfer value from that account balance.
• For functionality specific to HTS tokens (e.g. Pause, Freeze, or Grant KYC), a contract is authorized to perform the associated token management function only if the ContractId is listed as a key on the token (e.g. Pause Key, Freeze Key, or KYC Key respectively). This applies for all key structures (key list, key thresholds, etc.). Keep in mind that a contract will not be able to perform HTS management functions if the contract is not listed as a key for the token.
• Users can no longer associate their account to HTS tokens using a smart contract. Token associations can be performed using the Hedera SDKs (also see HIP-719 for an incoming alternative via ERC interface).
• While users can continue to create HTS tokens through smart contracts, only the smart contract used to create the token can be specified as the treasury account and/or auto-renew account (when enabled) for the token. A contract cannot specify another account for those fields. Note that a contract is still able to specify any public key as the manager of HTS functionality (e.g. Pause, Freeze, Grant KYC, etc.)
• Additional information and guidance will continue to be provided in the following weeks. Note that testing your specific contracts is the best way to identify the actions you may need to take to align with the new security model of the Hedera Smart Contract Service.