DAG Ledgers vs Merkle Trees for Audit Logs — Why Different Problems Need Different Tools

A team that needs a tamper-evident audit log will, sooner or later, be told that a DAG ledger — IOTA, Hashgraph, Avalanche, Sui Mysticeti, Kaspa GhostDAG — is “faster than blockchain” and therefore the right substrate. The framing is a category error. DAG ledgers optimise network throughput by relaxing total ordering across many concurrent producers; audit logs need per-decision cryptographic verifiability against multiple independent trust domains. The four DAG families currently in production each fail the audit-log test for a different structural reason, and the right tool for the audit-log domain — Merkle trees plus RFC 9162 Signed Tree Heads plus a witness network — already exists, is standardised, and is deployed at planetary scale. This article makes that argument precisely, charitable to DAG advocates, family by family.

The Framing Trap — “Faster Than Blockchain” Is the Wrong Comparison

The dominant pitch for any DAG ledger compares its throughput and finality numbers against Bitcoin or Ethereum L1. Mysticeti’s published WAN commit latency is around 0.5 seconds; Hashgraph’s gossip-about-gossip routinely cites tens of thousands of transactions per second on a closed validator set; Kaspa’s GhostDAG produces blocks per second; IOTA Rebased has shed its old tip-selection topology entirely in favour of a Mysticeti-derived consensus stack. Every one of those numbers is real. None of them addresses what an audit-log consumer asks for. The audit-log consumer is not asking the network “did this happen?” — they are holding a record in their hand and asking “can I prove this record is in the log without trusting the log operator?” Throughput at the consensus layer is irrelevant to that question.

The framing trap is structural rather than malicious. Distributed-ledger marketing optimises for substrate-level metrics (TPS, finality, decentralisation) because those metrics differentiate ledgers from each other. The metrics that matter for an audit-log integration — per-record proof verifiability against an out-of-band anchor, recoverable fallback when the substrate is unavailable, independent-trust-domain diversity in the verification path — do not appear in the marketing material because they are not differentiators between DAG ledgers; they are differentiators between DAG ledgers as a class and Merkle-tree-plus-witness systems as a class. A team that lets the comparison stay framed as “DAG vs blockchain” never reaches the comparison that actually matters, which is “consensus substrate vs cryptographic-proof substrate.”

What makes this trap especially expensive is that the wrong choice is hard to back out of later. Migrating from a Merkle-tree audit log to a DAG-ledger audit log (or vice versa) is not a configuration change; it is a substrate replacement, with all the multi-year coordination cost that implies. The point of stopping the framing trap early is to avoid making a substrate decision in the language of a feature decision.

What Audit Logs Actually Need

A tamper-evident audit log has three load-bearing requirements, and each of them is operational rather than aesthetic. First, per-decision cryptographic verifiability: every record committed to the log must produce a proof — typically a Merkle inclusion path against a signed tree root — that any third party can validate offline using nothing more than the record itself, the proof, and the public key of the log (or, better, the cosignatures of a witness set). The verifier never has to ask the log “did this happen?” and trust the answer. They recompute the inclusion proof and compare. This is what makes audit logs evidence, in the legal-and-regulatory sense, rather than merely records.

Second, multi-jurisdictional anchoring with split-view detection. A serious audit log is consumed by parties in different jurisdictions, often years after the record was written, often by parties who specifically distrust the log operator. The way the system rules out a malicious operator showing different histories to different verifiers is by anchoring the log’s signed tree heads in multiple independent trust domains — eIDAS Qualified Trust Service Providers, Sigsum’s witness-checkpoint format, Sigstore Rekor, dedicated witness pools — and by gossiping cosignatures so that a fork is detectable as soon as one verifier somewhere sees disagreeing roots. The witness layer is what turns a one-party promise into something cross-jurisdictionally checkable. (For the full survey of how the witness ecosystem works in 2026 — Sigsum, OmniWitness, ArmoredWitness, Tessera/TesseraCT, the gossip patterns, and the threshold choices — see Witness Networks for Transparency Logs.)

Third, deterministic synchronous finality at issuance time. When the auditor inspects a record produced last March, the auditor expects to see a binary state: the record either has its required anchors at the time it was issued, or it is flagged as degraded. There is no “probabilistically final” state for a regulatory submission. Either the inclusion proof checks against an STH that was witnessed and anchored at the time of issuance, or the record is incomplete. Probabilistic finality, where the audit substrate eventually agrees on what happened with overwhelming likelihood, does not satisfy this — it leaves a window during which a record’s status is “almost certainly accepted but not yet definitively so,” which is a window that auditors and regulators do not accept.

These three requirements — per-decision verifiability, cross-domain anchoring, deterministic finality — are not preferences. They are the success criteria. A substrate that delivers any two without the third is not 67% of an audit log; it is something else entirely.

What DAG Ledgers Actually Deliver

DAG ledgers, as a class, optimise a different objective: the throughput of an open consensus network with many concurrent block producers. The DAG topology is the mechanism. Instead of a single linear chain where each block must reference exactly one parent and producers serialise their writes, a DAG allows blocks (or transactions) to reference multiple parents and be produced in parallel. Total ordering is recovered later by a deterministic rule applied across the DAG — Hashgraph’s virtual voting, Avalanche’s repeated subsampling, Kaspa’s GhostDAG colouring algorithm, Mysticeti’s commit rule over an uncertified DAG. The win is real: by relaxing the global-ordering bottleneck, DAG ledgers achieve throughput numbers that linear chains cannot match without painful trade-offs at the consensus layer.

What this delivers is a high-throughput consensus output: a stream of confirmed transactions that the network agrees has happened, plus (depending on the family) some notion of finality — probabilistic, near-immediate, or deterministic-with-asynchronous-recovery. For applications where the consensus output is the artefact — a payment is final when the network agrees it is final, a smart-contract state transition is committed when the validator set commits it — that delivery is exactly what is needed. The verifier’s question (“is this transaction confirmed?”) is the same question the consensus protocol answers (“did the validator set agree it is confirmed?”), and the answer flows naturally out of normal operation.

The audit-log consumer’s question is structurally different. The audit-log consumer is not asking whether the network agrees a record exists. They are asking whether they themselves can produce, from the record alone, a cryptographic proof that ties the record to a signed tree root that was anchored in a trust domain they already trust. Network agreement is not a substitute for that proof, and the absence of an inclusion-proof path means the consumer must fall back to “trust the network” — which is precisely the anti-pattern the proof system was supposed to eliminate. The DAG ledger has answered a question; it has not answered this question.

IOTA Tangle and IOTA Rebased — Tip Selection vs Inclusion Proof

The original IOTA Tangle (pre-Coordicide) was the most architecturally distinctive of the DAG ledgers, and the most instructive about the audit-log mismatch. In the original tangle, each new transaction confirmed two prior tips, and a transaction’s cumulative weight — the total weight of transactions that had transitively confirmed it — grew over time as more transactions accumulated downstream. The protocol’s claim was that, eventually, a transaction’s cumulative weight made it effectively immutable. That is a property of the network’s collective state, computed by walking the local node’s view of the tangle.

The audit-log mismatch is precise: cumulative weight is observation-dependent. A verifier holding a transaction in their hand cannot, from the transaction alone, produce a self-contained proof that the transaction has cumulative weight W as of some reference point. They have to obtain a tangle copy, walk it, and compute the weight themselves — and a different node’s tangle copy, observed at a different time, will compute a different weight. There is no Merkle inclusion path because there is no canonical Merkle root; there are tips, weights, and a probabilistic argument that the weight is sufficient. For payment systems this is workable; for audit logs where the verifier may have no chain access at verification time and must check the proof against a tree head that was anchored years ago, it is not.

IOTA’s own response to this acknowledged the gap. The Coordicide initiative — IOTA 2.0 — attempted to remove the central coordinator and produce a decentralised tangle with stronger finality properties; it never reached production. IOTA Rebased, the project’s current iteration, has abandoned the original tangle topology entirely and now runs Sui Mysticeti underneath as its consensus substrate (per the IOTA Rebased technical view, 2024–2025, and the MDPI Sensors review at Sensors 25(11)/3408). The “every transaction confirms two prior” topology that defined the tangle is gone. What remains is a Mysticeti-based BFT consensus stack with IOTA-flavoured economics, which inherits all of Mysticeti’s audit-log mismatches discussed below. The lesson here is not that IOTA failed; it is that the original tangle’s defining mechanism was not load-bearing for the use case that actually scaled, and the project corrected by adopting a different substrate.

Hashgraph — Virtual Voting Produces No Signed Artifacts

Hashgraph’s consensus algorithm is a genuinely elegant piece of work. Validators continuously gossip both recent transactions and the gossip history itself (gossip-about-gossip), so each node accumulates a hashgraph — a DAG of who-told-whom-what-when — that is provably the same structure across all honest nodes. Once a node has the hashgraph, it can compute the consensus order by virtual voting: the node simulates how every other node would have voted on the order, given the gossip topology, without any actual votes being exchanged. The message-complexity win is large; under the right conditions Hashgraph achieves consensus in O(log n) rounds without per-round vote messages.

The audit-log mismatch lies in what virtual voting does and does not produce. It produces a consensus order that every honest node will independently compute as identical. It does not produce signed artefacts corresponding to that order. There is no “Hashgraph cosignature on the order at round R” that a third party could check; the order is a derivation, not a signed statement. A verifier who wants to check “transaction X was committed at order position N” has to either (a) trust a node’s report of the consensus order, or (b) reconstruct the hashgraph themselves and re-run virtual voting, which requires the full gossip history.

Audit-log consumers want the opposite: signed artefacts they can check offline, ideally cosigned by witnesses in independent trust domains. Hashgraph’s win — that consensus does not require explicit votes — evaporates when the consumer wants the votes as evidence. You can bolt a separate signing layer on top (have validators sign STHs derived from the consensus order) but at that point the value of virtual voting has been replaced by what the signing layer does, and the underlying Hashgraph engine is doing work the audit consumer does not need. The four-year history since Hashgraph’s core algorithm was released under Apache 2.0 in 2022 is consistent with this read: outside Hedera’s own deployment, no production audit-log system has adopted Hashgraph as its substrate, despite the patent encumbrance being long gone.

Avalanche Snow* — Probabilistic Finality and the Audit Mismatch

The Avalanche Snow* family — Snowflake, Snowball, Avalanche, Snowman — uses repeated subsampled voting to drive nodes towards consensus probabilistically. A node queries a random subsample of peers, accepts a colour (transaction outcome) if the subsample is sufficiently lopsided, and after β consecutive successful rounds (the default β is around 20) considers the outcome final. The mathematics is well-formalised: given honest-majority assumptions and reasonable network conditions, the probability of a wrong final decision is bounded by a quantity exponentially small in β. For payment networks where eventual rejection of a fraudulent transaction at low probability is acceptable, this is a fine model. The throughput numbers are good and the latency is acceptable.

The audit-log mismatch is that probabilistic finality and audit finality are different domains. An auditor presented with a record from last March wants to know whether the record was finalised at the time of issuance, deterministically and synchronously, with the inclusion proof anchored in a tree head that was witnessed and gossiped at that time. The Snow* protocol’s answer is “the network considered it final after β successful rounds, with probability 1 − ε.” That answer is mathematically true but operationally unusable for the audit consumer: ε is non-zero, the rounds happen after issuance time rather than at issuance time, and the finality is a property of the network’s consensus state rather than a property of the record itself. Worse, the audit consumer who wants to verify the record offline at year-five has no clean way to check that β rounds successfully completed for that specific record — they have to trust the network’s later report that they did.

This is not a defect of Avalanche; it is a domain mismatch. Avalanche’s design objective was high-throughput probabilistic consensus on an open validator set. The audit-log domain wants deterministic synchronous finality on closed cryptographic anchors. A team proposing Avalanche as an audit substrate is implicitly proposing that probabilistic-with-low-ε is good enough for audit; the regulatory regimes that consume audit logs do not generally agree.

BlockDAG (Kaspa GhostDAG, Sui Mysticeti) — Throughput at the Wrong Layer

The BlockDAG family — Kaspa’s GhostDAG, Sui’s Mysticeti, several recent variants — relaxes the linear-chain bottleneck by allowing blocks to be produced in parallel, referencing multiple parents in a DAG, with a deterministic colouring or commit rule to recover total order across the DAG. Mysticeti’s contribution (per arXiv 2310.14821, Babel et al.) is particularly notable: an uncertified DAG, where blocks are committed without per-block certificates, with a commit rule that achieves WAN finality around 0.5 seconds. Kaspa’s GhostDAG colours blocks as “blue” (in the consensus chain) or “red” (excluded by the rule), with parameter K controlling the maximum DAG width. Both deliver high throughput because parallel block production parallelises the consensus-layer work that linear chains serialise.

The audit-log mismatch operates one layer up. The throughput a BlockDAG delivers is consensus-layer throughput: how many blocks (or transactions, depending on the granularity) the network can commit per second. Audit logs do not need consensus-layer throughput to be high. They need per-record inclusion-proof generation to be cryptographically self-contained, anchored against a tree head, and witnessed across independent trust domains. Whether the underlying consensus substrate produces 100 commits per second or 100,000 is irrelevant to the inclusion-proof question — the inclusion proof is generated from a Merkle tree built on top of whatever the substrate commits, and the Merkle tree’s properties are independent of the substrate’s throughput.

Mysticeti specifically illustrates this layering point. The Mysticeti commit rule is impressive substrate-tier engineering: it removes per-block certificates, achieves sub-second WAN commit, and is the consensus engine under both Sui and the post-rebase IOTA. None of that gives you per-record verifiability. You still need a Merkle tree over the records, an STH-style signed root, witness cosignatures over the root, and gossip of those cosignatures — and that machinery is the same machinery you would build on top of a linear chain, a single-operator transparency log, or no consensus substrate at all. Mysticeti is solving a problem (consensus latency under WAN conditions); the audit-log problem (per-decision cryptographic verifiability) is an independent layer above it.

This is why the steel-man for Mysticeti is not “use it as your audit substrate.” The steel-man is “if your application separately needs WAN-scale low-latency consensus plus an audit log on top, use Mysticeti for the consensus layer and Merkle trees plus RFC 9162 STHs plus a witness network for the audit layer.” Two tools, two problems, two layers — not one tool for both.

What Merkle Trees + RFC 9162 STHs Provide That DAG Ledgers Don’t

The Merkle-tree-plus-RFC-9162 architecture is what the audit-log domain has converged on, and the convergence is not an accident. Each property answers a specific audit-log requirement that the DAG-ledger architectures structurally cannot. Four properties matter most.

Per-record cryptographic proof. A Merkle inclusion path is a logarithmically sized sequence of sibling hashes that, combined with the record and the tree root, lets any verifier recompute the path and confirm membership. The verifier needs nothing else — no node, no chain access, no consensus state. They need the record, the proof, the root, and the root’s signature. This is the property a regulator can check on a piece of paper years after the fact, given only the cryptographic primitives.

Anchoring across multiple independent trust domains. A Signed Tree Head is just a (tree_size, root_hash, timestamp, signature) tuple, and the right number of independent witnesses to cosign it is a deployment choice, not a substrate choice. Real-world deployments anchor STHs across eIDAS Qualified Trust Service Providers, Sigsum’s witness-checkpoint format, Sigstore Rekor’s transparency log, and dedicated witness pools (OmniWitness, ArmoredWitness). The auditor who distrusts any single trust domain can require cosignatures from a quorum of others. A DAG ledger can be witnessed too in principle, but the witnessing has to be added on top — it is not native — and the question then becomes why one is paying for the DAG layer at all.

Consistency proofs (RFC 9162 §2.1.2). Given two STHs at different tree sizes, a verifier can request a consistency proof and check that the older history is cryptographically a strict prefix of the newer history. The log operator cannot rewrite history without producing an STH that is detectably inconsistent with a previously-witnessed STH. This is not a property of consensus; it is a property of the Merkle tree structure itself, derivable from the hash function alone. DAG ledgers have no equivalent: the substrate may agree on a current state, but it does not produce a cryptographic prefix-consistency proof between an old root and a new root.

A mature, deployed witness ecosystem. As of 2026-05, the witness layer that defends transparency logs from split-view attacks is production-grade across multiple independent implementations — Sigsum, OmniWitness, ArmoredWitness, Tessera/TesseraCT — and the gossip patterns (direct query, aggregation-based, quorum cosignature) are well understood. See Witness Networks for Transparency Logs for the full ecosystem survey. The ecosystem has been built by parties who specifically wanted the audit-log property and who chose Merkle trees as the substrate because the audit-log property follows naturally from them.

A DAG-ledger audit substrate would have to reproduce all four of these properties from scratch, on top of a substrate whose native abstractions are different. The reproduction is not impossible — anything cryptographic is composable in principle — but the case for spending the engineering budget on that reproduction has to clear a high bar, and the bar is not cleared by “DAG is faster.” Faster at what? Not faster at producing the four properties above, because those are not throughput-bound at the substrate layer.

The 5-Question Gate as the Decision Rule

Before any team adopts a DAG ledger (or any chain-like component) as audit substrate, the proposal should be put through the 5-Question Test for Adding Distributed Ledger Technology. The test was codified to reject substrate-replacement decisions disguised as feature additions, and it generalises cleanly to the DAG-vs-Merkle question discussed in this article. Each of the four DAG families above fails the test for the same reason at the same gate.

Q1 of the test asks whether the proposed component is a batching/optimisation tier between existing issuance-time signing and existing settlement-time anchoring. A team operating a working audit log already signs records at issuance and anchors signed tree heads at settlement; the proposed DAG ledger does not sit between those two events. It replaces the audit log entirely, taking over the substrate role, with the consensus output now playing the part that the signed tree head used to play. That is substrate replacement, which the test rejects at Q1 and never reaches Q2–Q5. The TPS and finality numbers are irrelevant to the test outcome because they are substrate-level metrics; the test discards the substrate framing and forces the architectural question of where the new component sits between existing crypto operations.

The test’s worked Example C — adding Sui Mysticeti as audit substrate — fails at Q1 explicitly. The same outcome holds for IOTA Rebased (also Mysticeti underneath), Hashgraph, Avalanche, and Kaspa GhostDAG when proposed as audit substrate: each is being proposed as foundation, not tier. Patent clearance, open-source licensing, and impressive throughput numbers do not change this — they are necessary preconditions for the test even being worth running, but they are not the test’s content. Running the test takes about five minutes per proposal and produces an explicit recorded answer that goes into the architecture decision record. That recorded answer is what an audit team can defend later when a regulator asks why the substrate choice was made.

When to Use Which — A Clear Decision Rule

The decision rule, after all the above, can be stated cleanly. Use a DAG ledger when:

• The application domain is a high-throughput consensus problem — payments, decentralised application platforms, validator-set-coordinated state transitions — where the consensus output is the artefact the consumer cares about.
• Eventual or probabilistic finality is acceptable at the application layer (payment systems with chargebacks, DeFi protocols with reorg-tolerance windows).
• The consumer’s question matches the network’s question: “did the validator set agree that this happened?” If yes, the substrate’s answer is the consumer’s answer.
• You are willing to add a separate audit layer on top if you also need cross-domain audit — using Merkle trees and witness networks above the consensus substrate, treating the DAG ledger as the consensus engine and not as the audit substrate.

Use Merkle trees plus RFC 9162 STHs plus a witness network when:

• Each record must be independently verifiable years later by a third party with no access to the original system or substrate.
• The audit is multi-jurisdictional and the verifier may not trust any single operator, including the log operator.
• Deterministic synchronous finality at issuance time is required — the regulatory or contractual regime treats “almost certainly final” as not final.
• The consumer wants signed evidence they can hold in their hand and check offline, not consensus reports they have to ask the network for.
• Split-view detection across independent trust domains is part of the threat model.

For any non-trivial system, both lists may apply at once — different layers, different substrates. The error that this article exists to forestall is the assumption that the same substrate must serve both roles because it has the right throughput numbers. Throughput at the consensus layer and per-decision verifiability at the audit layer are independent properties; the right architecture decouples them and uses the right tool for each.

Conclusion

DAG ledgers are good engineering. The problem is not the engineering; it is the framing that pits “DAG vs blockchain” as the relevant comparison. The relevant comparison for the audit-log domain is “consensus substrate vs cryptographic-proof substrate,” and the audit-log requirements — per-decision verifiability, cross-domain anchoring, deterministic finality, mature witness ecosystem — point unambiguously at the second category. Each of the four DAG families analysed above fails the audit-log test for a structurally different reason, and the failure is not about speed; it is about category. Tip selection produces probabilistic weights, not Merkle proofs. Virtual voting produces consensus orders, not signed artefacts. Snow* produces probabilistic finality, not deterministic synchronous finality. BlockDAG produces high consensus-layer throughput, not per-record inclusion proofs. None of those failures is a defect; each substrate is a strong solution to the problem it was actually designed for.

The architectural discipline this article advocates is to ask the audit-log question first, in audit-log language, and pick the substrate that natively delivers what the audit-log consumer needs. For tamper-evident audit logs that must withstand cross-jurisdictional scrutiny across years, that substrate is Merkle trees plus RFC 9162 STHs plus a witness network. The 5-question gate exists to enforce that discipline before a multi-year substrate decision is made in the wrong language; the witness ecosystem exists to make the cryptographic-proof substrate operationally real; and this article exists to keep the framing honest when someone proposes that “faster than blockchain” is the answer to a question the audit-log consumer was not asking.