The Merkle Funnel
How millions of business events become one number a court can check.
Anchoring every transaction to a public ledger is unaffordable. Anchoring nothing leaves you asserting your own history. The Merkle Funnel is the narrowing path between the two: transactions become blocks, blocks become slabs, slabs become batches, and one root per batch goes to the outside world — where each step is arithmetic anyone can repeat.
The claim a verifiable-records platform ultimately makes is simple: this is what happened, and we could not have changed it afterwards. Everything else is machinery in service of that sentence. The difficulty is economic. Writing each transaction to an external ledger costs a fee and a round-trip per transaction, which is unworkable at commercial volume. So most systems anchor occasionally, or not at all, and the guarantee quietly degrades into “trust our database”.
The Merkle Funnel refuses that trade by making the anchor cover everything without containing everything. Each stage folds many items into one cryptographic root, and each fold is independently recomputable. One published root stands behind millions of events, and any single event can be proved to sit under it.
The funnel, stage by stage
Four narrowings, each in a different failure domain from the last.
1. Blocks — the member-classes mesh
Business transactions are executed and agreed by the member-classes BFT mesh. Every block’s hash is recorded as it is finalized. Nothing has left the operator’s own infrastructure yet, and nothing is claimed beyond “these nodes agreed”.
2. Slabs — the first fold
At fixed intervals a slab producer fires at the block boundary and computes a Merkle root over that whole range of block hashes. The result is one row: slab id, network, start height, end height, block count, and the root. A slab is the unit that says this contiguous run of history hashes to this value.
The choice of a range rather than a single block is what makes the economics work — and because the range is contiguous and its endpoints are recorded, a gap is arithmetically obvious rather than a matter of trust.
3. Batches — the aggregator
The aggregator node polls the org nodes’ slab records, gathers slabs into a batch, and computes a final Merkle root over them. This is the second fold: many slabs, each already standing for many blocks, reduced to a single value.
The aggregator is its own BFT chain with its own database, deliberately not co-tenanted with the workload it reads from. It is not simply a queue — it is an independent party that has to agree with itself about what it collected.
4. Anchors — top hats and the public ledger
The top-hat node polls the aggregator for pending anchors and submits them to Hedera Consensus Service, recording the returned topic and transaction id against the batch. That published root is the point at which the platform stops being the only witness: the timestamp and ordering are now attested by infrastructure the operator does not run and cannot retrospectively edit.
What it is made of
| Component | Role |
|---|---|
| Slab producer | Inside each member-classes node. Fires at slab boundaries and records the Merkle root of that block range. |
| agg-node | Its own BFT chain. Polls org nodes’ slab records, batches them, computes the final Merkle root, and queues the batch for anchoring. |
| tophats | Its own BFT chain. Drains the pending-anchor queue, submits to Hedera Consensus Service, and records the resulting topic and transaction id. |
| merkle-audit | The independent verifier. Reads anchored batches and recomputes each root from the underlying block hashes rather than trusting the stored value. |
One shared funnel, not one per network. Every outlet relays through the same agg + top-hat pipeline, rather than each running its own independently-scaled mesh. That is deliberate: a single funnel means a single anchoring history to reason about, one place where the public record is produced, and no possibility of two networks disagreeing about which anchor covers what.
The Go source lives with the platform’s own aggregator and top-hat modules; the funnel repository owns only the deployment wrapper. There is no forked copy of the anchoring code — the thing being audited and the thing being deployed are built from the same source.
Its auditor nodes
The funnel is mirrored by an independent auditor tier — an auditor aggregator and an auditor top-hat, deployed in their own model, sharing none of the workload’s infrastructure.
The audit question here is unusually crisp, because every stage is arithmetic. A stored Merkle root that cannot be recomputed from the block hashes underneath it is a forged root — there is no interpretation to argue about and no operational excuse available. That is precisely what the verifier does: it fetches the anchored batches, re-derives each root from first principles, and compares.
This is the property that makes the funnel worth building. Most of a platform’s integrity claims rest on behaviour that is expensive to check. The anchoring path rests on a computation that a third party can repeat on a laptop, against a root published somewhere the operator cannot reach.
Where it sits
Tx-Rails executes business processes through a layered BFT hierarchy — member-classes nodes execute, an overseers layer enforces the process definitions, and each layer is mirrored by its own auditor mesh. The Merkle Funnel is what that hierarchy exports.
It sits at the boundary between the operator’s world and everyone else’s. Inside the boundary, integrity rests on Byzantine agreement between nodes the operator runs. Outside it, integrity rests on a published root and arithmetic. The funnel is the transition, and it is deliberately one-way: data does not flow back down it. Nothing downstream can rewrite what has been anchored, because the anchor is no longer in the operator’s custody.
Two consequences follow, and both are the point:
- Cost scales with time, not volume. Anchoring is per batch, not per transaction, so the external cost of proving a million events is the cost of proving one.
- Disclosure scales with need, not with proof. The published root reveals nothing about the transactions beneath it. A specific event can be proved to sit under a specific anchor without exposing anything else that shares it — which is what makes the mechanism usable for commercially sensitive and regulated data alike.
Why fold at all
The objection is that a hash chain would be simpler. It would — and it would prove less. A chain establishes that records follow one another; it does not let you hand somebody a short proof that one particular record belongs to a history somebody else has already timestamped.
Folding buys three things at once. The external cost stops tracking transaction volume. The proof of any single event stays small regardless of how much history surrounds it. And the verification stays cheap enough that an adversarial party — a regulator, a counterparty’s auditor, an opposing expert — can actually perform it rather than accept it.
The Merkle Funnel is not where the platform does its work. It is where the platform stops being the only witness to it.
See also the companion documents on the National Registry, for the authority records these layers are judged against, and on Sovereign Name Resolution for the transport substrate beneath them.
Contact: john@itotchaincloud.com.au
Tx-Rails — Built by IT/OT Chain & Cloud Australia (ITOTCCA). Sydney · London.