The 5-Question Test for Adding Distributed Ledger Technology

When someone proposes adding a blockchain, DLT, DAG ledger, or transparency log to an existing system, ask five questions before agreeing. All five must answer correctly to proceed; any single wrong answer means reject for now. The test is not anti-blockchain — it is a gate that distinguishes a batching/optimisation tier between existing crypto components (almost always a good idea, when it fits) from a substrate replacement that asks you to trade per-decision cryptographic verifiability for network consensus (almost always a bad idea, regardless of how fast the new substrate is). The test was codified internally at 8M Networks in 2026-05-05 to reject “consensus-substrate philosophy” before it ate per-decision verifiability; the same five questions generalise to any system that already has issuance-time signing and settlement-time anchoring.

The Trap: Why “We Should Add A Blockchain” Decisions Are Usually Wrong

The phrase “we should add a blockchain here” is rarely a technical proposal. It is usually a frame: someone has read about a new ledger that does N transactions per second, finalises in M milliseconds, has no patents, and is open source — and now they want to insert it somewhere into the architecture. The question they actually need to answer is much narrower: between which two existing components does this new tier go, and what does it batch or optimise that we currently do another way?

If the proposal cannot answer that, it is not adding a tier — it is asking you to replace something. Replacement of an audit substrate, settlement layer, or trust anchor is a fundamentally different decision: it costs years, requires coordinated migration of every downstream consumer, and trades architecture you understand for architecture whose failure modes you do not. The 5-question test exists to surface this distinction in five minutes of conversation rather than three months of design work that ends with a quiet abandonment.

The trap is structural, not malicious. Distributed-ledger marketing optimises for substrate-level metrics (TPS, finality, decentralisation) because those are the metrics that differentiate ledgers from each other. The metrics that matter for integrating into your system (per-decision proof verifiability, recoverable fallback, independent-trust-domain diversity) are not in the marketing material. The test forces those metrics into the conversation before commitment.

The Five Questions

The five questions are sequential. Each must be answered before the next is meaningful. The first three are about what role the proposed component will play; the last two are about what you are giving up to get it.

Q1: Is the proposed component a batching/optimisation tier between your existing issuance-time signing and your existing settlement-time anchoring?

If your system already signs decisions at issuance time and anchors them at settlement time, there is a legitimate niche between those two events for a tier that batches, deduplicates, or accelerates. Layer-2 rollups on Ethereum fill that niche. RFC 9162 Certificate Transparency logs fill that niche for PKI: certificates are signed by the CA at issuance and verified by the relying party at use, and the CT log batches, witnesses, and exposes the issuance event for third-party auditing without replacing either signature.

If the proposed component does not fit between two existing crypto operations, it is not a tier. It is substrate: a new foundation that future signing or anchoring must be rebuilt on. Substrate adoption is a separate, much harder decision (it requires re-deriving every property of the system on top of the new foundation) and almost never the right next step for a system that already works. If NO — reject for now. This single question rejects most of the proposals that reach this stage.

Q2: Does the proposed component preserve per-decision cryptographic verifiability — every output carries a proof a third party can check independently?

A system has per-decision verifiability when each decision (a transaction, a credential issuance, an audit event) produces a proof that a third party can validate by checking signatures, hashes, and inclusion paths against well-known anchors. The auditor never has to trust the system itself; they recompute and compare. PKI has this property: a cert chain is checkable offline against root-CA public keys.

Many DLT proposals replace this with consensus-time verifiability: a third party can ask the network “did this decision happen?” and accept the answer if a quorum of nodes agrees. Those are not the same property. Consensus-time verifiability degrades when the network is partitioned, when nodes collude, or when the third party is offline; per-decision verifiability does not. If NO — reject. You are trading verifiability for consensus, which is the trap. The architectural reason chains were invented in the first place — Bitcoin’s white paper opens by framing the double-spend problem as a question about who arbitrates conflicts between unrelated parties — does not apply to systems that already have a settlement anchor.

Q3: Does the proposed component require trusting the chain’s network consensus instead of checking proofs against your existing anchors?

This is the contrapositive of Q2 stated as a runtime check. If your downstream verifier currently validates a decision by walking a Merkle path to a known anchor, and the proposed component replaces that with “ask N nodes and trust majority,” the component has consumed your proof system and replaced it with social trust in a network you did not previously depend on. Sigsum’s log+witness design and CT’s witness-gossip protocol both exist precisely so that downstream verifiers do not have to trust the log operator — the witness signs the log root, the verifier checks the witness signature, and the chain of trust terminates in keys the verifier already had.

A component that requires trusting the chain itself (rather than proofs derivable from its data) is asking you to extend your trust boundary to include the entire validator set of that chain. If YES — reject. This is the “trust the network” anti-pattern. The cost is permanent: every future security audit must now reason about the integrity of every validator the chain has ever had.

Q4: Does the component have a recoverable fallback to direct (non-batched) operation when it fails?

Optimisation tiers should fail to slower but still working, not down. Layer-2 rollups have escape hatches to L1; CT logs have direct cert verification as the floor; OCR oracles fall back to on-chain aggregation. If the proposed component is unavailable for an hour — chain halt, network partition, validator outage — can the system continue to issue and settle decisions through the original direct path? If not, the proposal has just created a new dependency whose availability is now your floor, regardless of the availability of every other component. If NO — reject. A tier without a fallback is a single point of failure dressed as redundancy.

This question also catches a subtler failure mode: components whose fallback exists in theory but is untested. A fallback that is exercised only during incidents is not a fallback; it is a mythology. The test demands a fallback that is part of normal operation — even if rarely — so that operators have proven the recovery path before they need it.

Q5: After adding this component, is your independent-trust-domain diversity SLA still satisfied?

Independent-trust-domain diversity is the property that no single failure (operator, jurisdiction, software stack, signing key) can compromise the system. It is consumed implicitly by adding any component, because every new component brings its own operator, code, and key material. Adding a Layer-2 batches your transactions through a sequencer; adding a transparency log adds a log operator and witnesses; adding a DAG ledger adds a validator set.

The question is whether the component gives back enough diversity to justify what it consumes. A CT log adds more witness-domain diversity than it consumes (multiple log operators, independent witnesses) so it nets positive. A monolithic permissioned chain consumes diversity (single validator set) without giving it back, so it nets negative. If NO — reject. The component is consuming diversity budget without giving back enough. Make this calculation explicit before adoption — diversity is a budget, not a property, and budgets get spent silently when no one tracks them.

Worked Example A: Adding RFC 9162 Transparency Log to an Existing PKI (passes all 5)

A team already operates a PKI: a CA signs certificates at issuance, relying parties verify chains at use, and the architecture has run for years. The proposal is to add a Certificate Transparency log per RFC 9162 so that every issued cert is publicly logged and third parties can audit the CA. Apply the test:

• Q1 (batching tier between issuance and verification?): Yes. CT logs sit between the CA’s issuance signature and the relying party’s verification, batching certs into Merkle trees and producing Signed Certificate Timestamps that prove inclusion.
• Q2 (per-decision verifiability preserved?): Yes. Every cert still carries the CA’s signature; the SCT adds a separate, independently checkable inclusion proof against the log’s signed tree head.
• Q3 (trusting chain consensus instead of proofs?): No. The relying party checks the SCT signature against the log’s well-known public key; consensus is not consulted. Witness gossip (and Sigsum’s witness-co-signature pattern) makes the trust boundary even narrower.
• Q4 (recoverable fallback?): Yes. If the CT log is down, the cert still verifies via the original PKI chain; SCT presence is enforced softly by browsers.
• Q5 (diversity preserved?): Yes — improved. Multiple independent log operators (Google, Cloudflare, DigiCert, Sectigo) and witness operators add diversity domains the PKI lacked.

CT passes cleanly. It is the canonical worked example because every property of the test is satisfied by existing deployments and the trust model has been argued in published papers and IETF standards.

Worked Example B: Replacing Your Audit Log with Hyperledger Fabric (fails Q1 — substrate)

A team operates a service that emits audit events to an append-only log; downstream auditors verify the log’s signed tree head against a known anchor. The proposal is to replace the log with a permissioned Hyperledger Fabric network so that audit events are committed by validator consensus.

• Q1 (batching tier between existing crypto operations?): No. The proposal replaces the existing log; it does not sit between two existing operations. The signed tree head goes away and is replaced by a Fabric block hash signed by the orderer set. Reject at Q1 — substrate.

The remaining questions are not even reached. The proposal is asking for substrate replacement framed as a tier addition. The test catches this in one question. The team’s actual options are (a) keep the existing append-only log and add witnessing for diversity, or (b) commit to a multi-year substrate migration with full re-derivation of audit guarantees on Fabric — and the test makes (a) versus (b) the explicit choice rather than letting (b) slip in disguised as a feature add.

Worked Example C: Adding Sui Mysticeti as Your Audit Substrate (fails Q1 — substrate, even though it’s faster than Bitcoin)

A team is told that Sui’s Mysticeti consensus achieves sub-second finality at high throughput, has no patent encumbrance, and is open source. The proposal is to use Sui as the audit substrate for a new product line. The marketing pitch focuses on TPS and finality.

• Q1 (batching tier between existing crypto operations?): No. Sui is being proposed as substrate — the foundation of audit, not a tier between existing audit signatures and an existing anchor. Reject at Q1.

The TPS and finality numbers are irrelevant to the test outcome. Speed is a substrate-level metric; the question is whether substrate replacement is the right decision, and the answer is almost always no for a team that is not yet running its own substrate. The test discards the TPS/finality framing and forces the architectural question: what crypto operations exist already, and where does the new component fit between them? Sui has no answer that satisfies Q1 in the audit-substrate framing. (It might satisfy Q1 in a different framing — say, as an L2 batching tier above an existing L1 anchor — but that is a different proposal and would have to be presented and tested as such.)

The Patent-Status Caveat: Necessary But Not Sufficient

A common counter-argument is that a new ledger has cleared its patent encumbrance and therefore should be evaluated on technical merit alone. This conflates a necessary precondition with a sufficient one. Hashgraph released its core consensus algorithm under Apache 2.0 in 2022 after years of patent gating. Four years later, in 2026, no production deployment exists outside Hedera. The patent removal was necessary (without it, no one would adopt) but not sufficient (with it, the substrate-replacement decision is still hard, and most teams making that decision still pick “no” or “later”).

The same pattern applies to Avalanche’s Snowman/Snow* family, IOTA Tangle (Coordicide), BlockDAG variants like Kaspa GhostDAG, and Sui Mysticeti. All four DAG-ledger families fail Q1 of this test when proposed as audit substrate (per the 8M Networks DAG-ledger evaluation matrix, 2026-05-05). Patent clearance changes the cost basis but not the architectural calculus. The 5-question test runs after patents have been cleared; a clean patent status simply means the test is worth running at all.

When To Revisit: The Post-Substrate-But-Pre-Anchor Niche

If a future proposal can articulate a post-substrate-but-pre-anchor niche the component fills — for example, “this is an L2 batching tier above our existing L1 anchor, with escape hatch back to L1 on failure” — then Q1 may pass. At that point the test gives a clean way to rationalise adoption: walk through Q2–Q5, get explicit answers, document them in the architecture decision record, and proceed.

This is not a hypothetical. Ethereum L2 rollups (Optimism, Arbitrum) pass the test cleanly when proposed as batching tiers above L1: Q1 (yes — between transaction signing and L1 settlement), Q2 (yes — fraud/validity proofs preserve per-decision verifiability), Q3 (no — proofs are checked against L1, not L2 consensus), Q4 (yes — escape hatch to L1), Q5 (yes — multiple rollup operators add operator diversity). The test does not reject all chain-like components; it rejects substrate proposals masquerading as tier additions.

The 8M Networks v0.8.1 ADR-L2-aggregator-interface accepted this exact test as the validation gate for any future ADR proposing a chain-like, DAG-like, or DLT-like component. Future ADRs of that shape must record their five answers explicitly, with worked examples comparable to A/B/C above. Recording the answers is the deliverable; the answers themselves are the architecture decision.

The Test in Practice

Use the test as a five-minute conversational gate before any architecture-review meeting that includes the words “blockchain,” “DLT,” “ledger,” “DAG,” or “consensus” in its agenda. Do not let the meeting begin until Q1 has an answer. If the answer is “no, it’s substrate,” redirect the meeting to either substrate decision (a different and longer conversation) or what existing tier addition would solve the underlying problem instead (usually the actually useful conversation). If the answer is “yes,” proceed to Q2–Q5 and document the answers in whatever ADR or design doc captures the decision.

The test does not produce decisions; it produces clarity about which decision is being made. That clarity is what most “should we add a blockchain” conversations lack, and supplying it is the entire value of having a test in the first place.