Smart Contract Security
The Hedera Smart Contract Service (HSCS) integrates the features of Hedera's third-generation native entity functionality—high throughput, fast finality, predictable and affordable fees, and fair transaction ordering—with a highly optimized and performant second-generation Ethereum Virtual Machine (EVM). We aim to offer comprehensive support for smart contracts originally written for other EVM-compatible chains and to enable their seamless deployment on Hedera.
EVM Equivalence
We strive to ensure that developers can conveniently point to a Hedera-supported RPC endpoint and perform smart contract executions and queries using the same code and similar tools to achieve EVM equivalence. All smart contract transactions are executed using the Besu EVM to realize this objective, and the resulting changes are stored in the Hedera-optimized Virtual Merkle Tree state. Users are thus guaranteed deterministic finality (as opposed to probabilistic finality) of smart contract executions within 2-3 seconds while ensuring that state changes are entirely encompassed within smart contract functionality.
🔔 A Comprehensive breakdown of Hedera's EVM equivalence goals and exceptions can be found here.
Security Model
Old model (v1) boundaries
The old security model (pre 0.35.2) supported account key signatures provided at transaction time for authorization. Some of the key characteristics of this model included:
Smart contracts could only change their own storage or the storage they were delegate called with.
System smart contracts could be delegate called to carry out Hedera Token Service (HTS) operations on behalf of another account - Externally Owned Account (EOA) or contract account.
Smart Contracts could change an EOA’s storage with the appropriate signature in the transaction.
Smart Contracts could change an EOA’s balance with the appropriate signature in the transaction or with prior addition to an allowance approval list.
This greatly improved user experience as contracts could combine transactions in an attempt at atomicity. For instance, a contract could associate, transfer and approve transactions on a user's behalf with one signature. While focusing on usability, this approach did not address cases in which bad actors could carry out an unsanctioned transaction on behalf of a user, e.g., https://hedera.com/blog/analysis-remediation-of-the-precompile-attack-on-the-hedera-network
To address this, the core Hedera engineers thoroughly analyzed the Smart Contract Service and the HTS system contracts, aiming to secure the state and token assets of users and the network during Smart Contract executions. The results of this effort are the guidelines in Hedera Services release v0.35.2.
New model (v2) boundaries
In the new security model, account key signatures cannot provide authorization for contract actions. Its key characteristics include:
Smart contracts can only change their own storage or the storage they were delegate called with.
Smart contracts can change an EOAs storage only if the contract ID is contained in the EOAs key.
Smart contracts can change an EOAs balance if approved for a token allowance for a specific token held by the EOA.
Boundary comparison table
| Boundary Spec | v1 Model | v2 Model | Change |
|---|---|---|---|
Storage Changes | Smart Contracts could only change their own storage or the storage they were delegate called with | Smart contracts can only change their own storage or the storage they were delegate called with | N |
System Contract Call Types | System smart contracts could be delegate called in order to carry out Hedera Token Service operations on behalf of another account (EOA) or contract. | System smart contracts may not be delegate called, except from the Token facade flow, which presents HTS tokens as smart contracts for common ERC methods. | Y |
Permissioned Account Storage Changes | Smart Contracts could change an EOA’s storage with the appropriate signature in the transaction. | Smart contracts can change an EOAs storage if the contract ID is contained in the EOAs key. | Y |
Permissioned Account Balance Changes | Smart Contracts could change an accounts (EOA or contract) balance with the appropriate signature in the transaction or with prior addition to an allowance approval list | Smart contracts can change an EOAs balance if they have been approved a token allowance. | Y |
In summary, HSCS utilizes a three-level security approach:
Level 0 - EVM Security Model: Entities may only modify their own state and balance.
Level 1 - ERC Account Value Security Models: Transfer and access to account value will follow tested web3 interface standards, e.g., ERC20, ERC721.
Level 2 - Hedera Advanced Security Features: Unique Hedera features may utilize contract-compatible permissions, e.g., ContractID keys.
To achieve state change or value transfer, executions must adhere to the rules of each level. Transactions that don’t satisfy the appropriate authorization will fail with response codes such as INVALID_FULL_PREFIX_SIGNATURE_FOR_PRECOMPILE when a sender is not authorized to carry out an operation. More operational-specific response codes will be returned where applicable e.g. SPENDER_DOES_NOT_HAVE_ALLOWANCE.
Impact on Developers
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 and onwards.
Existing contracts deployed before 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 approximately three months. The current target is for the network to remove the previous security model and for all contracts to follow the new model by the mainnet release of July 2023.
See a comprehensive list of the security updates made here.
What does the change in the security model mean for smart contract developers?
The security update involves changes to entity permissions during contract executions when modifying the 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.
Understanding the process of contract executions for both externally owned accounts (EOAs) and contracts during regular and delegate calls is crucial. This process involves tracking how accounts, state (storage and value balance), and code may change as you progress through the chain of calls.
Before (v1 model)
In a regular call scenario, when a call is made to contract B, B’s code is executed in the context of its own state. This allows B to modify only its own state. The sender value also differs between the calls to highlight that the EOA made the first call and contract A made the second.
After (v2 model)
On the other hand, in a delegate call scenario, the call to contract B sees B’s code executed in the context of A’s state. This allows B to modify A’s state. The sender and recipient values are preserved from the first call as if the EOA initiated the call.
In summary, a delegate call executes the calling contract's code in the context of the previous account, giving the code access to the previous account's state and blurring the lines of authorized state management.
Applying this to the security model changes, the following table summarizes the authorization check changes.
| Scenario | Authorization check | Old Model | New Model |
|---|---|---|---|
Smart contract A can change its own state using a call | sender = Contract A | Y | Y |
Smart contract A can change EOA’s state via call | sender = EOA | N | N |
Smart contract B can change contract A’s state via call | sender = A | N | N |
Smart contract A can change EOA’s state via delegate call | sender = EOA | Y | Y |
Smart contract B can change contract A’s state via delegate call | sender = Contract A | Y | Y |
System smart contracts can change another accounts (EOA or contract A or contract B) state via call | sender = account | N | N |
System smart contract can change another accounts EOA or contract A or contract B) state via delegate call | sender = account | N | N |
System contracts can change an accounts (EOA or contact A or contract B) state via call with the appropriate signature | signature map contains signature of accounts (EOA or contact A or contract B respectively) | Y | N |
System smart contract can change another accounts (EOA or contact A or contract B) state via delegate call with the appropriate signature | signature map contains signature of accounts (EOA or contact A or contract B) | Y | N |
Contract A or B can call a system contract via a call | - | Y | Y |
Contract A or B can call a system contract via a delegate call | - | Y | N |
At the time of the change, the HTS system contract was the only pathway to expose Hedera API functionality through Smart Contracts. As such, it’s fair to consider the differences between pre and post-security model updates when observing HTS system contract state-changing functions.
Existing HTS system contract impacts summary
| IHederaTokenService System Smart Contract Function | v1 Model Authorization Requirements | v2 Model Authorization Requirements | Impacts Code | Solution by Developers |
|---|---|---|---|---|
approve, approveNFT | signature map contains accounts admin key signature |
| Y | Upgrade contracts or Upgrade DApps to provide explicit user approval *Additional secure pathways: HIP 376 IERC.approve() |
associateToken | signature map contains account admin key signature |
| Y | Upgrade contracts or Upgrade DApps to provide explicit user associate *Additional secure pathways: HIP 719 IHRC.associate() |
burnToken | signature map contains token burn key signature or Contract Id satisfies Token.supplyKey requirements | Contract Id satisfies Token.supplyKey requirements | Y | Token admin must set desired contract in Supply key |
createFungibleToken, createFungibleTokenWithCustomFees, createNonFungibleToken, createNonFungibleTokenWithCustomFees | signature map contains affected account admin key signature(s) in treasury or autoRenew assignment case |
or autoRenew assignment case | Y | - |
cryptoTransfer | signature map contains sender admin key signature or Contract Id satisfies Entity.key requirements |
or autoRenew assignment case | Y | Upgrade DApps to provide explicit user approval. |
deleteToken | signature map contains token admin key signature or Contract Id satisfies Token.adminKey requirements | Contract Id satisfies Token.adminKey requirements | Y | Token admin must set desired contract in admin key |
dissociateToken, dissociateTokens | signature map contains admin key signature |
| Y | Upgrade contracts or Upgrade DApps to provide explicit user dissociate *Additional secure pathways: HIP 719 IHRC.associate() |
freezeToken | signature map contains freeze key signature or Contract Id satisfies Token.freezeKey requirements | Contract Id satisfies Token.freezeKey requirements | Y | Token admin must set desired contract in freeze key |
grantTokenKyc | signature map contains kyc key signature or Contract Id satisfies Token.freezeKey requirements | Contract Id satisfies Token.kycKey requirements | Y | Token admin must set desired contract in kyc key |
mintToken | signature map contains appropriate signature or Contract Id satisfies Token.supplyKey requirements | Contract Id satisfies Token.supplyKey requirements | Y | Token admin must set desired contract in Supply key |
pauseToken | signature map contains pause key signature or Contract Id satisfies Token.pauseKey requirements | Contract Id satisfies Token.pauseKey requirements | Y | Token admin must set desired contract in pause key |
revokeTokenKyc | signature map contains kyc key signature or Contract Id satisfies Token.freezeKey requirements | Contract Id satisfies Token.kycKey requirements | Y | Token admin must set desired contract in kyc key |
setApprovalForAll | signature map contains admin key signature |
| Y | Upgrade contracts or Upgrade DApps to provide explicit user associate *Additional secure pathways: HIP 376 IERC.setApprovalForAll() |
transferFrom, transferFromNFT | signature map contains admin key signature or Spender must have been pre-approved an allowance |
or autoRenew assignment case | Y | Upgrade DApps to provide explicit user approval. |
transferToken, transferTokens, transferNFT, transferNFTs | signature map contains admin key signature or Contract Id satisfies Entity.key requirements or Contract has been approved an allowance to spend by owner |
If not 1. Contract Id satisfies Entity.key requirements or 2. Contract has been approved an allowance to spend by owner | Y | Upgrade DApps to provide explicit user approval. |
updateTokenInfo, updateTokenExpiryInfo, updateTokenKeys | signature map contains token admin key signature or Contract Id satisfies Token.adminKey requirements | Contract Id satisfies Token.adminKey requirements | Y | Token admin must set desired contract in admin key |
wipeTokenAccount, wipeTokenAccountNFT | signature map contains token wipe key signature or Contract Id satisfies Token.wipeKey requirements | Contract Id satisfies Token.wipeKey requirements | Y | Token admin must set desired contract in Wipe key |
unfreezeToken | signature map contains token freeze key signature or Contract Id satisfies Token.freezeKey requirements | Contract Id satisfies Token.freezeKey requirements | Y | Token admin must set desired contract in freeze key |
unpauseToken | signature map contains token pause key signature or Contract Id satisfies Token.pauseKey requirements | Contract Id satisfies Token.pauseKey requirements | Y | Token admin must set desired contract in pause key |
Note: While the changes impact user experience, requiring more explicit steps, they more than proportionately increase user and network security across the board. The team continues to push diligently to provide the community with secure and scalable API solutions to enable them to build creative dApps and carve out their own shared world on the ledger.
Security Upgrades
Last updated
