ComparisonHedera Consensus Service (HCS)

Choosing a tamper-evident audit log: HCS, trusted timestamps or a ledger database

Every tamper-evident audit log answers one question: could someone have altered or back-dated this record without anyone noticing? The options differ in whom you must trust and who can check. This comparison sets hash-chained tables, RFC 3161 trusted timestamps, managed ledger databases and anchoring on Hedera Consensus Service side by side, with a decision table and the cases where HCS is the wrong tool.

Reviewed 10 October 2026 8 min read

On this page

Proving a record was not altered or back-dated, and to whom
Four ways to make records tamper-evident
Trust model, verifiers and ordering, side by side
Why fair ordering between organisations changes the answer
Keeping personal data off a public log
Which option answers which audit question
A hypothetical logistics consortium weighs its options
What can still go wrong once an option is chosen
Questions and answers
Sources

Proving a record was not altered or back-dated, and to whom

Audit trails fail in two ways. Someone edits an entry after the fact, or someone inserts an entry dated earlier than the day it was written. A tamper-evident design does not stop either from happening; it makes both detectable by whoever checks. The useful design question is therefore not which technology is most secure, but who needs to check, what they already trust, and whether they will have your cooperation when they do.

An internal auditor who can query your database needs different evidence from a counterparty in a commercial dispute, or a regulator reviewing events years later. The further the verifier sits from your organisation, the less a log you operate alone can prove to them, and the more you need an independent party, or network, to have witnessed the record.

Four ways to make records tamper-evident

Hash-chained table: Each new row stores a cryptographic hash of the previous row, so altering any historical row breaks every hash after it. It is cheap and runs inside your existing database, but whoever controls the database can recompute the whole chain, so on its own it shows consistency, not independence.
RFC 3161 trusted timestamp: A timestamping authority signs a token that binds a hash of your data to a time, following the IETF Time-Stamp Protocol¹. Anyone holding the token, the data and the authority's certificate can verify it. In the EU, a qualified electronic time stamp from a qualified trust service provider carries a legal presumption that its time is accurate and the bound data intact².
Managed ledger database: A database service that keeps an append-only journal with cryptographic digests you can export and check. It saves you building the chain, but the operator still runs the only copy, and the service can be withdrawn: Amazon QLDB reached end of support on 31 July 2025, and its customers had to migrate³.
HCS topic anchoring: You submit a digest of the record to a Hedera Consensus Service topic. The network assigns a consensus timestamp and a sequence number and folds the message into the topic's running hash⁴. Anyone can read the topic through a mirror node and check the digest without asking you for access.

Trust model, verifiers and ordering, side by side

Criterion	Hash-chained table	RFC 3161 timestamp	Ledger database	HCS anchoring
Whom you must trust	The database operator, entirely	The timestamping authority and its certificate chain	The service operator and its journal	Hedera's consensus nodes collectively; a mirror node only for reading, which a stored receipt can cross-check
Who can verify independently	Only people you give database access	Anyone holding the token, the data and the authority's certificate	Anyone you give an exported digest and proof	Anyone who can read the topic through a mirror node
Ordering across organisations	None; each organisation orders only its own rows	Times only; tokens from different authorities are not ordered against each other	Order within one operator's journal	One sequence per topic, identical for every submitter and reader
Cost model	Storage and compute you already pay for	Per-token or subscription charges from the authority	Service charges for storage, input and output	A per-message network fee set in US dollars and published by Hedera
If the provider exits	No provider; the exposure is internal tampering	Issued tokens stay checkable while the certificate chain can still be validated	Migrate the journal before shutdown, as QLDB customers had to	Recorded messages stay checkable from any mirror node or from your own copies

Read across a row rather than down a column: the right answer depends on which row matters most to the verifier you have in mind.

Why fair ordering between organisations changes the answer

A timestamp says a record existed no later than a given moment. That is enough when one organisation keeps one log, but not when several parties submit events that interact: a shipper's delivery confirmation, a buyer's rejection notice and a carrier's damage report, each from a system with its own clock. In a dispute, the argument is often about which came first.

Tokens from two timestamping authorities are not ordered against each other in any authoritative way, and each party's hash chain orders only its own entries. A consensus service places every message submitted to a topic in a single sequence that all parties see identically, with timestamps that come from the network rather than from the submitter's clock. That shared order, more than the timestamp, is what HCS adds for multi-party evidence.

Keeping personal data off a public log

Which option answers which audit question

If
One organisation needs to detect internal tampering, and its verifiers will have access to its systems.
Then
A hash-chained table, with the chain head anchored at intervals to a timestamp token or an HCS topic.
Anchoring the head turns an internal chain into evidence an outsider can check, for little extra cost.
If
Evidence may need to persuade an EU court or regulator about when a document existed.
Then
A qualified electronic time stamp from a qualified trust service provider, optionally alongside an HCS anchor.
The eIDAS presumption attaches to qualified time stamps; a public network does not inherit it.
If
Several organisations submit events that must be ordered against each other, and none should run the log alone.
Then
HCS topic anchoring, with every party verifying through a mirror node of its choice.
A single shared order with no privileged operator is the property the other options lack.
If
The records concern people, may need erasing, and no digest design has been agreed.
Then
Do not write to any public log yet; agree a salted-digest design with the data protection officer first.
Retrofitting erasure onto anchored data is far harder than designing for it.

A hypothetical logistics consortium weighs its options

Hypothetical example

Proof of delivery across five companies

For example, a consortium of a shipper, two carriers, a warehouse operator and a buyer might want proof-of-delivery events that any member can rely on in a dispute. The first proposal is for every member to timestamp its own events with a timestamping authority of its choice.

That would prove when each event existed, but not how a carrier's handover relates to the warehouse's receipt when the two are seconds apart and stamped by different authorities. The consortium instead agrees one HCS topic per trade lane: members submit a salted digest of each signed event, and each runs a small verifier against a mirror node. The buyer, which expects some disputes to reach an EU court, also obtains qualified time stamps for the few events that trigger payment.

What can still go wrong once an option is chosen

Anchoring a digest of the wrong thing

Early signalThe digest is taken over a rendered PDF while disputes concern the underlying data.

MitigationDefine a canonical serialisation for each record type and publish it with the verification procedure.

Losing the data an anchor refers to

Early signalSource records are archived under a rule shorter than the period in which a claim could be brought.

MitigationAlign retention for records, salts, receipts and tokens with the longest dispute or audit window.

Verification that depends on one provider

Early signalOnly one mirror node or timestamp service has ever been queried.

MitigationStore receipts and tokens yourself and rehearse verification against a second source at least once a year.

Questions and answers

Will an HCS receipt be accepted as evidence?

No technology guarantees admissibility; courts weigh evidence under their own rules. In the EU, the amended eIDAS Regulation says an electronic ledger cannot be denied legal effect or admissibility solely because it is electronic, and reserves a stronger presumption for qualified electronic ledgers run by qualified trust service providers⁷. A public HCS topic is not a qualified ledger on its own. Keep the source record, its serialisation rules, the receipt and a written verification procedure, and take legal advice in each jurisdiction that matters.

Can RFC 3161 timestamps and HCS anchoring be combined?

Yes, and for high-stakes records it is often sensible. Request a timestamp token over the same digest you submit to the topic, or timestamp a periodic Merkle root of the topic's messages. The token gives a time attested by a named authority; the topic gives the shared order between parties. Each remains verifiable on its own, so losing access to one does not invalidate the other.

What will verification look like in ten years?

A verifier will need the original record, the exact rules used to serialise and hash it, the message or token as recorded, and a way to read the history, whether a mirror node, an archive or your own copy. Hash functions age, so record which algorithm was used and plan to re-anchor long-lived evidence with a stronger function if the original weakens.

Is a ledger database still a reasonable choice after the QLDB shutdown?

It can be, for history that only one organisation needs to query. The lesson from the retirement is to treat the vendor as replaceable: keep exports of the journal and its digests in an open format, document how to verify them without the service, and anchor digests externally if outsiders must ever rely on them. Then a shutdown becomes a migration project rather than a loss of evidence.

Sources

RFC 3161: Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) — IETF · checked 10 October 2026
Regulation (EU) No 910/2014 on electronic identification and trust services (eIDAS), Article 41 — EUR-Lex · checked 10 October 2026
Services in Full Shutdown (Amazon QLDB end of support: July 31, 2025) — AWS General Reference · checked 10 October 2026
Consensus Service — Hedera documentation · checked 10 October 2026
Regulation (EU) 2016/679 (General Data Protection Regulation), Article 17 — EUR-Lex · checked 10 October 2026
Guidelines 02/2025 on processing of personal data through blockchain technologies — European Data Protection Board · checked 10 October 2026
Regulation (EU) 2024/1183 amending Regulation (EU) No 910/2014, Articles 45k and 45l — EUR-Lex · checked 10 October 2026

Tell us what your audit trail covers and who must be able to check it

Describe the records, the verifiers and where a dispute would be heard. We will reply with the option that fits, including whether HCS is needed at all.

Compare audit-trail options