For most audit trails, a relational database with append-only tables and a hash chain is the correct answer, and reaching for a blockchain is over-engineering. The distinction that actually decides it is who has to be convinced: if the party reading the audit trail trusts the party running the database, tamper-evidence is sufficient and Postgres does it well. If the reader is a regulator, a counterparty, or a court that has no reason to trust the operator, then the operator’s own database cannot settle the question, and you need a record whose integrity does not depend on the operator’s honesty. Cryptuon’s DataMgmt Node is built for that second case: an EVM-compatible chain holds the commitments, a Kademlia DHT distributes the payload, and end-to-end encryption keeps the contents readable only by the parties entitled to them.
TL;DR
- Ask who the verifier is. Internal forensics trusts the operator, so a hash-chained table is enough. External verification does not, and that is the only case where a ledger earns its complexity.
- Tamper-evident is not tamper-resistant. A hash chain in Postgres detects edits only if the verifier holds an independent copy of a prior digest. Whoever can write rows can usually recompute the chain.
- Anchoring is the cheap 80%. Periodically publishing a Merkle root of your existing audit table gives external verifiability without moving your data anywhere.
- DataMgmt Node is for shared custody, not logging. Its case is several organisations needing one record none of them solely controls, with payloads encrypted end to end and distributed over a DHT.
- Immutability and erasure can coexist. Put hashes on-chain and ciphertext off-chain. Destroying the key makes the payload unrecoverable while the integrity proof survives.
- Where the database wins outright: query flexibility, cost, latency, operational familiarity, and the ability to fix a mistake. Those are not small things.
- See how we scope verification and provenance work, or describe your project to talk through a compliance architecture.
What an audit trail has to prove
“Audit trail” is used loosely enough to hide the fact that it bundles five separate properties, each with a different cost and a different failure mode.
Integrity. The record has not been altered since it was written.
Ordering. Events happened in the recorded sequence. This is harder than it sounds across systems with independent clocks, and it is frequently the property that actually matters — who approved the payment before it went out.
Non-repudiation. The party who recorded an event cannot later deny having done so. This requires signatures over the event, not merely a user_id column populated by the application.
Availability. The record can be produced when someone asks, which may be seven years later, after the vendor has been acquired and the system decommissioned.
Retention and erasure. Some records must be kept for a statutory period. Others must be destroyed on request. Those requirements are in direct tension and both are legally binding.
Most systems described as having an audit trail satisfy integrity weakly, ordering approximately, and non-repudiation not at all. That is often fine. It stops being fine when the record’s purpose is to convince someone outside the organisation.
What a database gives you, and where it stops
A well-built audit table in Postgres is genuinely good. Triggers capture changes without the application’s cooperation, roles prevent updates and deletes, and a hash chain links each row to its predecessor so a silent edit breaks the chain.
CREATE TABLE audit_log (
seq BIGSERIAL PRIMARY KEY,
occurred_at TIMESTAMPTZ NOT NULL DEFAULT clock_timestamp(),
actor TEXT NOT NULL,
action TEXT NOT NULL,
entity TEXT NOT NULL,
payload JSONB NOT NULL,
prev_digest BYTEA NOT NULL,
digest BYTEA NOT NULL
);
CREATE OR REPLACE FUNCTION audit_chain() RETURNS TRIGGER AS $$
DECLARE
prev BYTEA;
BEGIN
SELECT digest INTO prev FROM audit_log ORDER BY seq DESC LIMIT 1;
prev := COALESCE(prev, '\x00'::BYTEA);
NEW.prev_digest := prev;
NEW.digest := digest(
prev
|| convert_to(NEW.occurred_at::TEXT, 'UTF8')
|| convert_to(NEW.actor, 'UTF8')
|| convert_to(NEW.action, 'UTF8')
|| convert_to(NEW.entity, 'UTF8')
|| convert_to(NEW.payload::TEXT, 'UTF8'),
'sha256'
);
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
CREATE TRIGGER audit_chain_trg
BEFORE INSERT ON audit_log
FOR EACH ROW EXECUTE FUNCTION audit_chain();
REVOKE UPDATE, DELETE ON audit_log FROM PUBLIC;This is a good design and it should be the default. Verification is a single pass recomputing each digest from its predecessor, any single-row edit invalidates every subsequent digest, and the whole thing costs one trigger.
The gap it cannot close
Now consider the adversary this is supposed to defend against: someone with write access to the database. Perhaps a compromised administrator account, perhaps an insider, perhaps an operator under pressure to make a bad afternoon disappear.
That adversary edits the row and recomputes the chain. prev_digest and digest are ordinary columns in the same table. A superuser who can ALTER TABLE can drop the trigger, rewrite history, restore the trigger, and hand you a chain that verifies perfectly from genesis.
The chain only helps if the verifier holds a digest from before the tampering, obtained from somewhere the adversary could not reach. That is the entire mechanism. Without an external witness to some earlier state, a self-contained hash chain proves only that the data is internally consistent — which is exactly what a careful forger produces.
Everything that follows is about where that external witness lives.
Tamper-evidence versus tamper-resistance
The vocabulary is worth fixing because vendors blur it.
Tamper-evident means alteration is detectable, given a reference point the adversary did not control. A hash chain plus an off-site digest published daily to a third party is tamper-evident.
Tamper-resistant means alteration is infeasible because the record is replicated across parties with no common controller. This is what a public ledger provides, and it is a stronger and much more expensive property.
Most compliance requirements ask for tamper-evidence and most architectures over-deliver or under-deliver by mistake. WORM storage with an object lock is tamper-evident and cheap. A private blockchain run entirely by one company is tamper-evident at best, because the same entity controls every validator — it has the cost structure of a ledger and the trust model of a database.
What anchoring changes
The cheapest way to add an external witness to an existing system is anchoring: periodically compute a Merkle root over the audit rows written since the last anchor and publish that single hash to a chain nobody controls.
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;
/// @notice Publishes Merkle roots of off-chain audit batches.
/// Storage cost is one word per batch regardless of how many events it covers.
contract AuditAnchor {
struct Anchor {
bytes32 root;
uint64 fromSeq;
uint64 toSeq;
uint64 anchoredAt;
}
mapping(bytes32 => Anchor[]) private _anchors; // keyed by stream id
mapping(address => bool) public writers;
address public immutable admin;
event Anchored(bytes32 indexed stream, bytes32 root, uint64 fromSeq, uint64 toSeq);
error NotAuthorised();
error NonMonotonic();
constructor() { admin = msg.sender; writers[msg.sender] = true; }
function setWriter(address who, bool allowed) external {
if (msg.sender != admin) revert NotAuthorised();
writers[who] = allowed;
}
function anchor(bytes32 stream, bytes32 root, uint64 fromSeq, uint64 toSeq) external {
if (!writers[msg.sender]) revert NotAuthorised();
Anchor[] storage a = _anchors[stream];
if (a.length > 0 && fromSeq != a[a.length - 1].toSeq + 1) revert NonMonotonic();
a.push(Anchor(root, fromSeq, toSeq, uint64(block.timestamp)));
emit Anchored(stream, root, fromSeq, toSeq);
}
function anchorCount(bytes32 stream) external view returns (uint256) {
return _anchors[stream].length;
}
function anchorAt(bytes32 stream, uint256 i) external view returns (Anchor memory) {
return _anchors[stream][i];
}
}Three properties follow from this that the database alone cannot provide.
The timestamp is not yours. block.timestamp is set by consensus among parties with no interest in your audit trail. You cannot backdate an anchor, and neither can anyone who compromises your systems.
The sequence is enforced. NonMonotonic rejects an anchor that does not continue from the last one, so an entire batch cannot be silently dropped from the record. A gap is visible on-chain.
The proof is small. A Merkle inclusion proof for one event against a published root is a few dozen bytes and reveals nothing about the other events in the batch. An auditor examining one transaction never sees the rest.
Crucially, none of your data moved. The audit table stays in Postgres with its indexes, its retention policy, and its familiar operations. What you have added is roughly one transaction per batch and a verifier that no longer has to take your word for it.
For a large fraction of “we need an immutable audit trail” requirements, that is the whole answer, and it is a weekend of work rather than a platform migration.
When you need more than anchoring: shared custody
Anchoring assumes one organisation owns the data and merely needs to prove it did not tamper with it. The harder case is several organisations that each need the record, none of whom should have unilateral control, and where the payload itself is confidential.
Supply chain consortia have this shape. So do clinical trial networks, syndicated lending, reinsurance, and regulated data-sharing between institutions. The audit trail is not a log of one system’s activity — it is the shared truth between parties whose interests diverge precisely when the record matters most.
This is what DataMgmt Node is for. It combines three components, each addressing a different property from the list at the top:
- An EVM-compatible chain holds commitments, access grants, and the audit trail itself. This is the integrity, ordering, and non-repudiation layer.
- A Kademlia DHT distributes payloads across participating nodes. This is the availability layer, and it removes the single storage operator who could otherwise withhold the data.
- End-to-end encryption means payloads are ciphertext everywhere except in the hands of a key holder. This is what lets confidential data live on infrastructure that the other parties also run.
The combination is the point. A chain alone cannot hold payloads at sane cost. A DHT alone has no ordering or access control. Encryption alone does not tell you whether a record was altered. Each piece is unremarkable; the arrangement is what makes shared custody workable.
DataMgmt Node resources: datamgmtnode.cryptuon.com · Documentation · Source on GitHub
Writing and sharing a record
The client-side shape is deliberately close to an object store, because that is the mental model teams already have.
from datamgmt import Node, Policy
node = Node(
rpc_url="https://rpc.internal.example",
dht_bootstrap=["/ip4/10.2.0.11/tcp/4001", "/ip4/10.2.0.12/tcp/4001"],
keystore="~/.datamgmt/keys",
)
# Encrypt locally, publish ciphertext to the DHT, commit the hash on-chain.
record = node.put(
payload=lab_result_pdf, # bytes; never leaves the process in cleartext
stream="trial-4417/results",
metadata={"site": "EDI-03", "visit": "W12"}, # cleartext, kept deliberately thin
policy=Policy(
readers=["did:ethr:0xA71c...", "did:ethr:0x3f09..."],
retain_until="2033-01-01",
erasable=True, # key destruction permitted before retention ends
),
)
print(record.content_hash) # what the chain stores
print(record.tx_hash) # the commitment transaction
print(record.dht_key) # where the ciphertext lives
# A reader resolves, fetches, verifies, and decrypts in one call.
payload = node.get(record.content_hash) # raises if the hash does not match
# The trail is a chain query, not a table scan of someone's private database.
for entry in node.audit(stream="trial-4417/results"):
print(entry.block, entry.actor, entry.action, entry.content_hash)Two details are load-bearing. Metadata is cleartext and therefore kept as thin as legally possible — a site code and a visit number rather than a patient identifier, because anything in metadata is visible to every participant forever. And node.get verifies the content hash against the on-chain commitment before returning; a DHT peer that serves altered bytes fails the check rather than quietly succeeding.
Immutability and the right to erasure
The obvious objection to putting anything regulated on a ledger is that data protection regimes grant a right to erasure, and a ledger by construction does not forget.
The resolution is to be precise about what is immutable. On-chain, the system stores a content hash, an access policy, and a trail of actions. Off-chain, it stores ciphertext. A SHA-256 digest of a document is not personal data in any useful sense — it cannot be reversed, and without the document it identifies nobody.
Erasure is then performed by destroying the decryption key, a technique usually called crypto-shredding. The ciphertext may persist in the DHT, but it becomes permanently unreadable, and the on-chain integrity proof survives to show that a record existed, when it was written, and when it was rendered unrecoverable. The audit trail of the erasure is itself part of the audit trail, which is what a regulator asking whether you honoured the request actually wants to see.
This is not a loophole and it should not be sold as one. It depends on the key having been genuinely unique to that record, on key destruction being thorough across every backup, and on the relevant supervisory authority accepting crypto-shredding as erasure — a position that is widely but not universally held. What the architecture provides is a technically coherent answer; whether it satisfies a given regulator is a legal question with a jurisdictional answer, and the schema choice above — thin cleartext metadata — is what makes that conversation survivable.
How the options compare
| Approach | Verifiable by | Erasure story | Query flexibility | Where it genuinely wins | Maturity |
|---|---|---|---|---|---|
| Postgres + hash chain | Anyone who already trusts the operator | Trivial: delete the row, accept the broken chain | Full SQL, joins, indexes, ad-hoc reporting | Cost, latency, familiarity, and the ability to correct a genuine mistake | Mature; the right default |
| Object storage WORM (S3 Object Lock) | Anyone trusting the cloud provider’s lock | Blocked until retention expires — which is the point, and the problem | Poor; it is a file store | Regulatory retention mandates, trivial ops, very low cost | Mature, widely accepted by auditors |
| Anchored hash chain | Anyone, via a public chain | Same as Postgres; the anchor proves a record existed, not its content | Full SQL over your own data | 80% of the benefit for a fraction of the cost; nothing migrates | Straightforward; well-trodden pattern |
| Managed ledger DB (e.g. QLDB-style) | Anyone trusting that cloud provider | Vendor-defined, usually limited | SQL-like over an append-only journal | Cryptographic verification with managed operations and no chain to run | Mature but single-vendor by design |
| DataMgmt Node | Any participant, with no common controller | Crypto-shredding: destroy the key, keep the proof | Chain queries plus DHT retrieval; not a reporting database | Multi-party custody where no single party is trusted, with confidential payloads | Active development |
The row worth defending is the first. A database wins on the things teams actually do every day: querying across entities, joining to business tables, and correcting a mistake made in good faith. Ledgers make the last one genuinely hard — a wrong entry must be superseded rather than fixed, and every downstream reader must understand the supersession. That is a feature when the adversary is an insider and a daily irritation when the adversary is a typo.
DataMgmt Node is deliberately not in that competition. It is not a replacement for your logging table and it should not be one. Its case is narrow: several parties, divergent interests, confidential payloads, and a record none of them can rewrite alone.
Business outcome: where the cost actually is
The compliance cost of an audit trail is rarely the storage. It is the labour of proving things to people.
Audit preparation. An external audit typically begins with the auditor asking how they can be confident the extract they were handed is complete and unaltered. With an internal-only trail, the answer is a description of controls, which is another way of saying “we will now audit the controls as well”. With published anchors, the answer is a Merkle proof per sampled transaction, which the auditor verifies independently in minutes. The saving is in the auditor’s hours and, more significantly, in the scope of what they have to test.
Dispute resolution. When two parties disagree about what was agreed and when, and each holds their own logs, resolution is a negotiation between two unverifiable accounts. When both are reading the same chain, there is nothing to negotiate. In multi-party settings this is where the architecture pays for itself, because disputes are expensive in a way that storage never is.
Breach forensics. After an incident, the first question is what the attacker touched and the second is whether the logs can be believed. If the log lives in the system that was compromised, the honest answer to the second question is no. An anchor written before the intrusion bounds the damage: everything up to that root is provably intact, and the investigation starts from a known-good point instead of from zero.
Cryptuon has covered the adjacent provenance problem for tokenised assets in Tokenizing Real-World Assets Under Compliance, where the same hash-on-chain, payload-off-chain split appears with a different set of regulatory constraints.
Limitations
Current limitations
- A DHT is not a durable archive by default. Availability comes from peers choosing to keep serving the data. Long statutory retention needs pinning commitments or a conventional archival copy alongside.
- It is not a reporting database. There is no join, no aggregate, no ad-hoc query across records. Teams that need analytics build a conventional read model and accept that it is a derived, trusted-locally view.
- Key management becomes the critical dependency. End-to-end encryption moves the failure mode from “someone read the data” to “nobody can read the data”. Key custody, rotation, and recovery are now core operational concerns.
- Writes cost more than an INSERT, in both latency and fees. Commitment transactions confirm on chain time, not database time. Anything on a user-facing hot path should be written locally and committed asynchronously.
- Crypto-shredding as erasure is a legal position, not a settled fact. It is widely accepted and not universally so, and the answer varies by jurisdiction and supervisory authority.
Roadmap items
- Stronger availability guarantees for long-retention streams, including explicit pinning agreements between participants.
- Richer on-chain access policy, including time-bounded and role-derived grants rather than enumerated reader lists.
- First-class support for derived read models, so analytics can be rebuilt from the trail with provenance intact.
- Tooling to generate auditor-ready inclusion proofs for a sampled set of records without exposing the rest of the batch.
Frequently Asked Questions
Do I need a blockchain for an audit trail?
Usually not. If the people reading the trail already trust the organisation running it, an append-only table with a hash chain and restricted permissions is the right design. A ledger is justified when the verifier has no reason to trust the operator, or when several parties with divergent interests need one record none of them can rewrite alone.
Can a hash chain in Postgres be tampered with?
Yes, by anyone who can alter the table and recompute the chain, which usually includes a database superuser. A self-contained hash chain proves internal consistency, not authenticity. It becomes meaningful only when a digest from an earlier state has been published somewhere the adversary could not reach — which is exactly what anchoring provides.
What is anchoring, and is it enough?
Anchoring means computing a Merkle root over a batch of audit records and publishing that single hash to a chain you do not control. It gives you an independent timestamp, an enforced sequence, and small per-record inclusion proofs, while your data stays exactly where it is. For most single-organisation compliance requirements it is sufficient, and it is far cheaper than migrating anything.
How does this work with the right to be forgotten?
Personal data never goes on-chain. The chain holds a content hash, an access policy, and the action trail; payloads live off-chain as ciphertext. Erasure is performed by destroying the decryption key, which makes the payload permanently unreadable while leaving the integrity proof intact. Whether that satisfies a specific regulator is a legal question that varies by jurisdiction.
Why a DHT instead of S3 or IPFS?
A Kademlia DHT across participating nodes removes the single storage operator who could withhold or delete data unilaterally, which matters when the participants do not fully trust one another. S3 is cheaper and simpler when one party legitimately owns the storage. The DHT is chosen for the multi-party case specifically, and it trades operational simplicity for the absence of a single custodian.
Is a private blockchain a reasonable middle ground?
Rarely, and it is worth being blunt about why. A chain whose validators are all run by one organisation has the trust model of that organisation’s database and the cost structure of a distributed ledger. It is worth considering only when validators are genuinely operated by different parties with different incentives — at which point it is no longer private in the way the term usually implies.
The bottom line
The question “blockchain or database for audit trails?” has a boring answer most of the time: database, with an append-only table, a hash chain, and revoked update permissions. That design is cheap, fast, queryable, and well understood, and the overwhelming majority of audit requirements are satisfied by it.
The question becomes interesting at exactly one boundary — when the verifier does not trust the operator. Crossing that boundary does not require abandoning the database. Anchoring a Merkle root to a public chain adds external verifiability for roughly one transaction per batch while every byte of data stays where it is, and for single-organisation compliance that is usually the whole job.
Beyond it lies the genuinely multi-party case: several organisations, confidential payloads, and a shared record none of them can unilaterally rewrite. DataMgmt Node exists for that case, and the arrangement — chain for commitments, DHT for availability, end-to-end encryption for confidentiality — is what makes it workable rather than theoretical. If that is the shape of your problem, see how we scope verification and provenance work, read the underlying work on research, or describe your project.