Hedera Smart Contract Service (HSCS)
Make the rules executable—and reviewable.
Hedera Smart Contract Service (HSCS) runs Solidity on Hedera's EVM and lets contracts reach the network's token, account, scheduling and randomness services through system contracts. ColdAI delivers contracts specification-first: we describe the state machine and its invariants before writing code, test normal, invalid and privileged behaviour, and plan deployment, monitoring and upgrades with the people who will operate the contract.
The opportunity
Start with a decision
worth improving.
A transaction should proceed only when its defined conditions are met. The implementation must cover normal operation, invalid inputs and privileged actions before it handles consequential assets.
From possibility to a working system
Follow the flow.
Three connected decisions. One considered architecture.
Conceptual flow, not a live system or measured result.
Specify the state machine
Describe allowed states, transitions and invariants before writing contract code. Identify administrative powers and the external information the contract must trust.
Test the execution
Implement and test the contract alongside application integration. Exercise permission checks, unexpected inputs and adversarial sequences using the tooling appropriate to the selected environment.
Plan the lifecycle
Define deployment, monitoring and incident procedures. Decide how upgrades or emergency controls work and communicate those powers to the parties relying on the contract.
The work, made concrete
What we can build
with your team.
We agree scope, dependencies and acceptance criteria before delivery. Your project can start with an assessment, a pilot or an integration into an existing system.
Contract specification and threat model
Clarify the system boundary, the responsible owners and the decisions the architecture needs to support.
Implementation and test suite
Turn the agreed design into reviewable work, evaluated against representative inputs and explicit success criteria.
Deployment and operations documentation
Make the next step operable: document responsibilities, known limitations and the path from pilot to ongoing use.
Explore the practice
Further capabilities
and implementation detail.
What HSCS is
Hedera Smart Contract Service (HSCS) is an EVM-equivalent execution layer on Hedera. You can deploy any Solidity 0.8.x contract using familiar tooling — Hardhat, Foundry, Remix, Ethers.js — and Hedera adds two things you do not get on most EVM chains: predictable USD-denominated gas pricing, and native system-contract bridges to HTS and HCS so contracts can mint, transfer, and audit at protocol cost rather than re-implementing those primitives in Solidity.
ColdAI's HSCS service
HTS integration via system contracts
Use HTS tokens directly inside Solidity via the HTS precompile — combine EVM programmability with native token economics.
Audit & hardening
Independent review, fuzz testing, and threat modelling for production HSCS contracts.
DevOps & monitoring
Deployment pipelines, mainnet observability, and incident response procedures for live contract estates.
Where HSCS shines
- DeFi primitives that need EVM portability
- RWA logic on top of Asset Tokenization Studio
- Custom governance and on-chain registries
- Identity-bound logic (paired with DID)
- AI-agent payment routing and policy contracts
Build EVM contracts on Hedera
Engage ColdAI to design, ship, and audit production Solidity contracts on Hedera Smart Contract Service.
Contact our Hedera teamIn depth
Go deeper on Hedera contracts
Two in-depth guides: what changes when an EVM team ports contracts to Hedera, and how a security review should run before contracts hold real value.
- 01GuidePorting Solidity contracts from Ethereum to HederaWhat changes when Solidity contracts move from Ethereum to Hedera: addresses and keys, HBAR decimals, token association, gas, ordering and a cut-over checklist.
- 02ProcessHedera smart contract security review, step by stepA seven-step smart contract security review for Hedera: threat model, platform-specific risks, test depth, admin powers, audit, deployment and monitoring.
Where a Hedera contract sits in the stack
- Application and wallets
Front ends, back-end services and user wallets built with Ethers.js, viem or the Hedera SDKs.
- JSON-RPC relay or SDK
The relay accepts Ethereum-style requests; the SDKs submit native Hedera transactions.
- HSCS EVM execution
Runs contract bytecode and charges gas for the work performed.
- System contracts
Reserved addresses exposing the token, account, schedule, exchange-rate and PRNG services to Solidity1.
- Consensus and network state
Orders transactions with aBFT consensus and updates state; mirror nodes then serve the history.
What EVM equivalence gives you, and what Hedera adds
Because Hedera runs the EVM, Solidity contracts and the usual tools carry over: Hardhat, Foundry, Remix and Ethers.js all work through the JSON-RPC relay. Teams bring existing code, libraries and review habits with them, and can hire from the wide pool of Solidity developers rather than training people on a new language.
What Hedera adds is reach into native services from inside a contract. Instead of reimplementing a token in Solidity, a contract can create, mint and transfer Hedera Token Service tokens through a system contract, and every HTS token also answers ERC-20 or ERC-721 calls at its own address2. Fees follow a schedule set in US dollars, and finality comes from asynchronous Byzantine fault-tolerant consensus rather than from waiting for blocks to accumulate.
Consensus Service messages are not called from Solidity in the same way; where a contract workflow also needs an independent evidence log, the application submits to an HCS topic alongside the contract call. The platform differences that catch teams arriving from other EVM chains, from HBAR decimals to token association, are covered in our guide to porting Solidity from Ethereum.
Specification-first delivery, from state machine to lifecycle plan
Specify the state machine
Write down the states the contract may be in, the transitions allowed between them, who may trigger each one and the invariants every transition must preserve. Name each external fact the contract relies on, such as a price or a delivery confirmation, and its source.
Model the threats
For each privileged role and trusted input, describe what an attacker or a careless operator could do with it and how the design contains the damage.
Decide where each rule lives, then implement
Place every rule deliberately: in Solidity, in a native Hedera service reached through a system contract, or in the application. Write the contract and its integration together so the boundary is tested from both sides.
Test normal, invalid and privileged paths
Exercise permission checks, malformed inputs and hostile call sequences as well as the intended flow, first on a local Hedera node and then on testnet.
Plan deployment and operations
Document deployment, key custody, monitoring and incident handling, decide how upgrades or emergency controls work, and tell the parties who rely on the contract what those powers are.
A hypothetical escrow contract, specified before any code
What belongs in contract code, and what belongs elsewhere
- If
A rule must hold even when the operator of the application would prefer otherwise.
ThenPut it in contract code, where participants can read and verify it.
Enforcement that does not depend on trusting the operator is the main reason to use a contract.
- If
The only controls needed are token-level: supply, freezing, KYC flags or custom fees.
ThenUse native Hedera Token Service features and keys before writing custom Solidity.
Native controls avoid new code that would itself need review.
- If
The rule changes often, depends on private data or needs human judgement.
ThenKeep it in the application, and record decisions on HCS if others must be able to check them later.
Contract changes are deliberately slow and public; most business policy is neither.
- If
The contract needs an outside fact such as a price, an identity check or a delivery confirmation.
ThenDefine who supplies it, how it is signed and what happens when it is late or wrong before writing the function that uses it.
A contract is only as reliable as the inputs it is told to trust.
Delivery risks we plan for on contract projects
Rules not agreed before coding starts
Early signalDevelopers settle ambiguities in the specification while writing functions.
MitigationHold a specification review with business, legal and engineering owners and treat open questions as blockers.
Admin powers decided at the last minute
Early signalUpgrade or pause functions appear shortly before launch.
MitigationSettle the authority model during specification and disclose it; the security review process shows where it is tested.
No owner once the contract is live
Early signalKeys sit with a departed contractor or a single engineer.
MitigationAssign key custody, monitoring and incident roles to named people before deployment.
Rebuilding what the network already provides
Early signalCustom Solidity duplicates token controls or scheduling that Hedera offers natively.
MitigationCheck native services and system contracts first, and write down why any custom logic is still needed.
Frequently asked questions
Which tools does ColdAI use for Hedera smart contracts?
Standard EVM tooling: Solidity with Hardhat or Foundry for building and testing, Remix for quick experiments, and Ethers.js or the Hedera SDKs in applications, connected through the JSON-RPC relay. We add Hedera-specific tests for token association, system-contract response codes and HBAR decimal handling, and run contracts on a local node and testnet before mainnet.
Can a Hedera smart contract use HTS tokens directly?
Yes. The token service system contract lets Solidity create, mint, transfer and associate native tokens, and each HTS token also answers standard ERC-20 or ERC-721 calls at its own address. Check the response code that token-service calls return, and remember that an account must be associated with a token before it can receive it, unless automatic association applies.
Can Hedera smart contracts be upgraded after deployment?
They can, using the same proxy patterns as other EVM chains, and a contract can also be created with a Hedera admin key. Whether to allow upgrades is a governance decision: it permits fixes but gives someone the power to change the rules. Decide who holds that power, whether changes pass through a timelock or a threshold key, and disclose it to users.
Does ColdAI review and harden contracts as well as write them?
Yes. ColdAI's HSCS work includes independent review, fuzz testing and threat modelling for production contracts. For contracts that will control significant value, we also recommend an audit by a separate firm, so that the people who designed the contract are not the only ones checking it.
What kinds of contracts does ColdAI build on HSCS?
Contracts for decentralised finance primitives that need EVM portability, real-world asset logic alongside the Asset Tokenization Studio, governance and on-chain registries, identity-bound logic, and payment-routing and policy contracts for AI agents. In each case the contract is one part of a wider design that also covers keys, integrations and day-to-day operation.
Sources
- System smart contracts — Hedera documentation
- HIP-218: Smart Contract interactions with Hedera Token Accounts — Hiero Improvement Proposals
Connect the architecture
The next connection.
Explore the complementary capabilities that can turn an individual technology into a complete workflow.
Your next move
Bring us the
real problem.
A workflow that takes too long. A system that cannot connect. An idea that needs a technical path. Start there, and we can define what to investigate, build and measure.
- Precise transaction rules
- An agreed custody and authority model
- Resources for security review