Hedera Consensus Service (HCS)
Turn an event into a checkable receipt.
Hedera Consensus Service (HCS) gives any application a public log with network-assigned timestamps and one agreed order of messages. ColdAI uses it to turn business events into receipts that outside parties can check: we define what the evidence must prove, integrate submission and receipt handling, and give every participant a way to verify messages independently, while sensitive records stay in systems you control.
The opportunity
Start with a decision
worth improving.
Two organizations need to confirm which version of a business event was recorded and when. They can share a verifiable receipt without putting an entire confidential document on a public network.
From possibility to a working system
Follow the flow.
Three connected decisions. One considered architecture.
Conceptual flow, not a live system or measured result.
Define the evidence
Choose the event schema, identifiers and source material. Decide whether to submit a digest or other minimal representation and document exactly what the resulting receipt will establish.
Submit and observe
Integrate message submission and receipt handling with the application. Account for retries and duplicate events so the business process does not confuse delivery attempts with distinct facts.
Verify independently
Provide a way to compare source material with its recorded representation. Preserve the off-chain evidence and explain the difference between proof of recording and proof of underlying truth.
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.
Event and evidence schema
Clarify the system boundary, the responsible owners and the decisions the architecture needs to support.
HCS submission and verification integration
Turn the agreed design into reviewable work, evaluated against representative inputs and explicit success criteria.
Retention and replay procedures
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 HCS is
Hedera Consensus Service (HCS) is a public, decentralised log. You submit a message to a topic; HCS gives you back a verifiable timestamp and a fair total ordering across all submitters, with sub-second finality and aBFT security. Because HCS does not store the message payload itself on consensus nodes, it scales to very high throughput at protocol cost — making it ideal for evidence, telemetry, and cross-chain messaging.
ColdAI's HCS service
Audit trail design
Schema design, payload hashing, and topic governance to produce cryptographically verifiable evidence pipelines that hold up to regulatory and forensic review.
Supply-chain and provenance
Event capture from ERP, IoT, and partner systems anchored to HCS for verifiable provenance and chain-of-custody.
AI agent receipts
Anchor model inputs, outputs, and decisions to HCS so AI-agent activity can be independently verified and replayed.
Cross-chain messaging
Use HCS as a neutral ordering layer between systems and ledgers — useful for bridges, oracles, and multi-party workflows.
Common HCS use cases we deliver
- Regulatory audit logs for financial workflows
- Supply-chain provenance and ESG claims
- Voting, attestations, and governance records
- AI model and agent telemetry with verifiable timestamps
- Bridge and oracle ordering layers
Anchor your evidence on HCS
Talk to ColdAI about using Hedera Consensus Service as the verifiable backbone for your audit, supply-chain, or AI-agent telemetry pipeline.
Contact our Hedera teamIn depth
Go deeper on HCS design
Two in-depth guides: whether HCS is the right tool for your audit trail at all, and how to design topics, envelopes and verifiers once it is.
- 01ComparisonHCS vs timestamping authorities and ledger databasesFour ways to make an audit trail tamper-evident, compared: hash-chained tables, RFC 3161 time stamps, ledger databases and Hedera Consensus Service anchoring.
- 02ArchitectureDesigning HCS topics, message schemas and verificationAn architecture reference for Hedera Consensus Service: topic layout, admin and submit keys, message envelopes, size limits, mirror-node replay and verifiers.
How HCS works, in six terms
HCS is easiest to reason about through the handful of objects a design actually touches1.
- Topic
- A named channel that messages are submitted to. Each topic keeps its own sequence of messages and can restrict who may write to it.
- Consensus timestamp
- The time the network assigns to a message when consensus is reached, derived from the nodes that received it rather than from the submitter's clock.
- Sequence number
- A message's position on its topic. It rises by one with each accepted message, so a jump in what a reader has seen means something is missing from its view.
- Running hash
- A value that chains each message to everything accepted on the topic before it. It changes with every message and comes back in the submission receipt.
- Receipt
- The network's confirmation that a submission reached consensus, carrying the topic's new sequence number and running hash.
- Mirror node
- A server that ingests the network's records and serves topic history through APIs. Mirror nodes take no part in consensus, and anyone can run one2.
What a consensus receipt proves, and where the proof stops
A receipt proves properties of a message: that these exact bytes were accepted on this topic, at this consensus time, in this position relative to every other message on the topic. Because order and time come from the network rather than from any participant, no single organisation, including the one that submitted the message, can later rearrange or back-date it.
It proves nothing about the world outside the message. If a warehouse system records a delivery that never happened, HCS faithfully timestamps a false claim. If a digest is computed over the wrong version of a document, the receipt is accurate and useless. Sound HCS design therefore spends as much effort on where each event comes from, who signs it and how it is serialised as on the network integration.
The same boundary is why ColdAI keeps confidential data off the topic. A digest is enough to show that a record existed unchanged at a point in time; the record itself stays in the participant's own systems, under its own retention and access rules.
How ColdAI delivers an HCS evidence workflow
Each stage ends in an output that participants can review before the next begins.
Define the evidence
Agree which business event is being attested, which fields identify it, which source system is authoritative and what a verifier must be able to conclude. Choose between a digest, a salted hash or a batch root, and write down what the receipt will and will not establish.
Integrate submission and receipts
Connect the source application to HCS through a submission service that signs envelopes, records transaction IDs and stores receipts beside the original records. Retries count as attempts at one event, so a network timeout never creates a second fact.
Give every party a verifier
Provide a routine that recomputes digests from source records and compares them with messages read from a mirror node, reporting any mismatch with the evidence untouched.
Plan retention and replay
Set how long records, salts and receipts are kept, which mirror nodes production reads from, and how a new participant can replay a topic's history from its first message.
Is HCS the right Hedera service for this job?
- If
Participants need to agree what happened and in what order, and nothing on the ledger has to change in response.
ThenHCS on its own: submit digests to a topic and verify through mirror nodes.
It is the simplest Hedera service that provides shared ordering and timestamps.
- If
An event should automatically trigger a payment, a release of funds or a change of ownership.
ThenA smart contract, with HCS alongside only if a separate evidence log is needed.
HCS orders messages but executes no logic.
- If
The thing being tracked is a unit of value or an entitlement that changes hands.
ThenA token on the Hedera Token Service, with HCS for the surrounding event history if useful.
Balances and transfers are what HTS enforces; a log of messages cannot.
- If
Only one organisation will ever read the log and no outsider needs to verify it.
ThenQuestion whether a shared ledger is needed at all; a database with occasional external anchoring may be enough.
A shared network earns its keep when parties do not want to rely on one operator.
- If
Even the timing and frequency of messages must stay confidential between known participants.
ThenConsider a permissioned deployment such as HashSphere, or separate topics per relationship.
A public topic reveals when and how often messages arrive, even when their content is hashed.
What to have ready before an HCS project starts
Frequently asked questions
What does it cost to submit messages to HCS?
Each submission pays a network fee that Hedera sets in US dollars, charges in HBAR and publishes in its fee schedule, which is revised from time to time, so check the current schedule rather than a figure quoted in an article. Since HIP-991, a topic can also charge its own fixed fee per message3. Budget separately for integration, verification tooling and mirror-node access, which network fees do not cover.
Can anyone read the messages on an HCS topic?
On Hedera mainnet, yes: messages can be read by anyone through mirror nodes, even when a submit key restricts who may write. That is why ColdAI submits digests or salted hashes rather than documents or personal data. The topic shows that a record existed unchanged at a point in time, and the record itself stays behind your own access controls.
How is HCS different from writing events to a smart contract?
A contract stores state and runs logic, so every event becomes a contract call subject to the contract's rules and gas. HCS only orders and timestamps messages; it holds no business state and runs no code. Use HCS when you need a shared, ordered record of events, and a contract when an event must cause something to happen on the ledger.
Can HCS record what an AI agent did?
Yes. An agent platform can submit a digest of each consequential action, covering the request, the tool call and the result, so its activity can later be checked against an independent order and time. The receipt shows what was recorded and when, not whether the agent's decision was sound. The wider agent design is covered on our Hedera AI Studio page.
Do we need to run a Hedera node to use HCS?
No. Applications submit messages to the existing network through the Hedera SDKs and pay per transaction. What you may want to operate is a mirror node, which serves topic history for reading and verification. Many teams use a commercial mirror-node provider instead, or run their own alongside one for resilience.
Sources
- Consensus Service — Hedera documentation
- Mirror nodes — Hedera documentation
- HIP-991: Permissionless revenue-generating Topic Ids for Topic Operators — 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.
- A defined event to attest
- Data retention and privacy requirements
- Participants who need verification