ProcessHedera Smart Contract Service (HSCS)
A smart contract security review process for Hedera, from threat model to monitoring
A security review is not a single audit bolted onto the end of a project. It is a sequence that starts with a written specification and threat model and ends with monitoring a live contract. This page sets out seven steps tailored to Hedera, the platform-specific risks reviewers look for, and what internal testing, independent audit and formal verification each can and cannot tell you.
On this page
Matching review effort to what the contract controls
A contract that issues attendance badges and one that holds tokenised bonds can share a code style and a test framework, but they should not share a review budget. Effort should scale with what the contract controls: the value it can move, the rights it can grant or revoke, and how hard its mistakes are to undo. A contract that can simply be redeployed with an apology needs less scrutiny than one whose errors lock funds or misassign ownership.
On Hedera, that judgement includes the native services a contract reaches. A contract that calls the Hedera Token Service can mint, transfer or freeze tokens through a system contract, and those powers weigh as much as anything written directly in Solidity. ColdAI's position is that a test suite is not a security guarantee, and that independent review deserves consideration before contracts control valuable assets or consequential rights1.
The seven review steps at a glance
- Specify and threat-model
States, invariants, privileged roles and trusted inputs written down.
- Hedera-specific checks
Response codes, association, tinybar maths and key structures reviewed.
- Test in depth
Property, fuzz, invariant and adversarial tests beyond the happy path.
- Constrain admin powers
Upgrade, pause and key authority limited and disclosed.
- Independent audit
A frozen commit reviewed by people who did not write it.
- Deployment ceremony
Reproducible build, production keys, verified source.
- Monitor and respond
Alerts, a rehearsed pause and a communication plan.
Working through each review step
Write the specification and threat model
Describe each state the contract can occupy, the transitions between states, the invariants that must always hold (for example, that total supply equals the sum of balances), the privileged roles and the off-chain inputs the contract trusts. Then list who would gain from breaking each invariant, and how.
Apply the Hedera-specific risk checklist
Walk the code against the platform risks listed below and mark each item as handled, not applicable or open, with a note on how it was checked.
Test beyond the intended flow
Add property-based and fuzz tests that throw generated inputs and call sequences at the contract, invariant tests that check the specification after every call, and adversarial scenarios written by someone other than the author.
Constrain and disclose admin powers
Decide whether the contract is upgradeable, who can upgrade or pause it, whether changes pass through a timelock, and whether control sits behind a threshold key so no single person can act alone. Publish those powers in plain language.
Commission an independent audit
Scope the audit to a frozen commit and hand over the specification, threat model, checklist and test results. Triage each finding as fixed, accepted with a stated reason, or disputed with evidence, and have fixes re-reviewed.
Run a deployment ceremony
Deploy from a reproducible build with keys in production custody, check every constructor and initialisation parameter against the specification, verify the source on Sourcify so HashScan displays it2, and record each transaction.
Monitor and respond
Watch mirror-node contract logs and balances for the events and thresholds the threat model flagged, rehearse the pause procedure, and keep a message ready for users and counterparties if something goes wrong.
Hedera-specific risks reviewers look for
What each assurance layer proves, and what it leaves open
| Assurance layer | What it gives you | What it does not prove |
|---|---|---|
| Unit and integration tests | The behaviours someone thought to test work as intended | That untested inputs or call sequences are safe |
| Property, fuzz and invariant tests | Stated rules hold across many generated inputs and sequences | That the stated rules are complete or correct |
| Independent audit | Experienced reviewers have examined a fixed commit against known vulnerability classes and your specification | That code changed afterwards, or risks outside the scope, are safe |
| Formal verification | Proof that the code satisfies specific formally stated properties | That those properties capture everything users care about, or that the platform behaves as the tool models it |
| Monitoring and incident response | Early detection and a rehearsed reaction when something goes wrong | Prevention; it limits damage rather than avoiding it |
Some teams map review depth to a published scheme such as the EEA EthTrust Security Levels specification7. Whichever you use, record which layers each release has passed.
A hypothetical review of an invoice-financing contract
Questions and answers
What should we hand a smart contract auditor?
A frozen commit, a build that reproduces the deployed bytecode, the written specification and threat model, the admin-powers statement, the completed Hedera risk checklist, test and coverage results, and a list of known issues you have accepted. Name a technical contact who can answer questions quickly. Auditors spend less time reconstructing intent, and more time looking for defects, when the intent is written down.
Do we need formal verification for our contracts?
Not for most contracts. It is worth considering when a contract is small, holds significant value and has properties that can be stated precisely, such as conservation of balances or a strict state machine. It proves only the properties you write, under the tool's model of the platform, so it complements tests and an audit rather than replacing either.
Who signs off a contract before mainnet?
The accountable product owner, not the auditor. Sign-off should confirm that every audit finding has been triaged, admin powers are disclosed, keys are in production custody, and monitoring and the pause procedure have been rehearsed. In regulated settings the risk or compliance function usually co-signs, and the record of that decision belongs with the deployment record.
When should a live contract be reviewed again?
Whenever its code, its admin configuration or the value it controls changes materially: an upgrade through a proxy, a new token integration, a change of key holders or a large increase in the assets it holds. Between changes, review alerts and rehearse the incident procedure periodically so the response plan stays current.
Sources
- Hedera Smart Contract Service: delivery approach and boundary — ColdAI
- How to verify a smart contract on HashScan — Hedera documentation · checked 10 October 2026
- System smart contracts — Hedera documentation · checked 10 October 2026
- Decimal handling (8 vs 18 decimals) — Hedera documentation · checked 10 October 2026
- Accounts, signature verification and keys (ECDSA vs ED25519) — Hedera documentation · checked 10 October 2026
- OWASP Smart Contract Top 10 — OWASP Foundation · checked 10 October 2026
- EEA EthTrust Security Levels Specification — Enterprise Ethereum Alliance · checked 10 October 2026