Merkle Trees, Commitments & Chaining
This section explains how individual data points are fingerprinted, hidden, organized into a tamper-evident structure, and linked across time to create an immutable historical record.
Starting with Commitments
Before we get to Merkle trees, we need to understand commitments as they're the building blocks.
What Is a Commitment?
A commitment is a way of locking in a value without revealing it. Think of it as putting a number in a sealed, tamper-evident envelope:
You can't see inside — the commitment reveals nothing about the value
You can't swap it out — once committed, the value is fixed
You can prove it later — when you reveal the value, anyone can verify it matches the commitment
In this system, a commitment is created by combining a value with a salt (a unique secret) and running them through a hash function:
commitment = hash(value + salt)The hash function is a one-way process. Given a value and salt, anyone can compute the commitment. But given only the commitment, it's impossible to figure out what value and salt produced it.
Why Salts Are Essential
Without a salt, commitments would be vulnerable to guessing. If someone knows the possible range of values (say, dollar amounts between $1 million and $100 million), they could hash each possibility until they find one that matches the commitment.
The salt eliminates this attack. Even if you know the value, you can't verify it without the salt. And salts in this system are derived from a private master secret. They never leave the secure enclave.
Analogy: Imagine a sealed envelope containing a number. Without a salt, it's like the envelope is slightly translucent. If there are only a few possible numbers, you might be able to tell which one is inside. With a salt, the envelope is completely opaque. The salt is like a unique, unpredictable padding that makes every envelope look identical from the outside.
Dual Commitments
The system creates two commitments for each value:
Public commitment
keccak256
Compatible with Ethereum smart contracts and widely used auditing tools
ZK commitment
Poseidon
Optimized for zero-knowledge proof systems
Both commitments lock in the same value. They just use different mathematical methods suited for different verification contexts. The public commitment is the one external auditors and smart contracts would check. The ZK commitment is the one used inside the zero-knowledge proof system.
Now: Merkle Trees
What Is a Merkle Tree?
A Merkle tree is a way of combining many fingerprints into one. It's named after Ralph Merkle, who invented it in 1979. The concept is used everywhere today — in Git (version control), in Bitcoin and Ethereum, in certificate transparency, and in file verification systems.
The idea is simple:
Start with all your commitments as leaves at the bottom
Pair them up and hash each pair together to create a parent
Keep pairing and hashing until you have a single hash at the top — the root
A, B, C, Dare the individual value commitmentsH(A+B)means "hash of A combined with B"The root is a single hash that represents all four values
Why Not Just Hash Everything Together?
You could just concatenate all values and hash them once. But a Merkle tree gives you additional capabilities:
Tamper evidence at the individual level. If someone changes just one value (say, B), the root changes completely. But more importantly, you can trace exactly which branch was affected.
Efficient selective verification. If you want to prove that a specific value (say, C) is part of the tree, you only need to provide a few sibling hashes along the path to the root — not the entire dataset. This is called a Merkle proof.
Consistent structure. No matter how many values are committed, the root is always the same size (32 bytes). The tree scales without the root growing.
A Real-World Analogy
Imagine a company with four divisions. Each division seals its financial report in an envelope (commitment). Then:
Divisions are paired: envelopes from Division A and B are sealed together in a larger envelope
The same for C and D
Finally, the two larger envelopes are sealed into one master envelope (the root)
If someone tampers with Division B's report, the seal on the A+B envelope breaks, which breaks the master seal. And you can check Division B's report without opening Division C or D's envelopes.
How the System Builds the Tree
Leaf Ordering
Commitments are placed in the tree in a specific, deterministic order based on their field identifiers. This ensures that the same data always produces the same tree, regardless of the order it was submitted.
Padding
The tree always has a fixed number of leaf positions (16 in the current system). If fewer values are committed, the remaining positions are filled with placeholder values (zeros). This ensures the tree structure is always the same, which is required for the zero-knowledge proofs.
The orange nodes are real commitments; the gray nodes are zero-padded slots.
Two Parallel Trees
Just as there are two types of commitments (public and ZK), there are two parallel Merkle trees:
Both trees have identical structure and leaf ordering. The only difference is the hash function used. The public root goes into the TEE attestation and is verifiable by anyone. The ZK root is used inside the zero-knowledge proof circuit.
What the Merkle Root Represents
The Merkle root is the cornerstone of the proof payload. It's a single, compact fingerprint that represents:
Every reserve value
Every liability value
Every salt used
The exact ordering and structure of the data
Change any single value, alter any salt, or reorder any element — the root changes completely.
This root is what the TEE hardware attests (see Trusted Execution Environments) and what the ZK proof verifies (see Zero-Knowledge Proofs). It's the anchor point that connects every layer of the system's security.
Timeseries Chaining
The Problem with Standalone Proofs
Imagine the system produces a proof every hour. Each proof confirms that at that moment, reserves and liabilities had certain values. That's useful — but what stops someone from going back and replacing last Tuesday's proof with a fabricated one?
If each proof stands alone, there's no way to tell. An attacker could:
Replace an old proof with one showing different numbers
Delete a proof from the history entirely
Reorder proofs to misrepresent the timeline
Insert fabricated proofs between legitimate ones
The individual proof would still verify correctly (it has valid attestation and ZK proofs). But the historical record would be a lie.
The Solution: Chain the Roots
Timeseries chaining solves this by making each proof depend on the one before it. When a new proof is generated, it includes the previous proof's Merkle root. The two roots are combined to create a chained root.
Proof #1 has no predecessor. It's the start of the chain, so its chained root is just its own root.
Proof #2 references Proof #1's root. Its chained root combines both.
Proof #3 references Proof #2's root. The chain continues.
Each link in the chain is like a knot in a rope — pull on any knot, and everything downstream shifts.
What Chaining Prevents
Replacing a historical proof: If an attacker replaces Proof #2 with fabricated data, the fabricated proof would have a different root. Proof #3 references Proof #2's original root — so the chain breaks. To get away with it, the attacker would need to re-forge every subsequent proof, each with valid hardware attestation and ZK proofs. That's effectively impossible.
Deleting a proof: If someone removes Proof #2, Proof #3 references a root that no longer exists. The gap is immediately obvious.
Reordering proofs: Each proof explicitly references its predecessor. Swapping them would mean a proof references a future proof — the ordering is self-evident.
Inserting fabricated proofs: Inserting between existing proofs would break the chain, because the subsequent proof already references the correct predecessor.
Why This Is Like a Blockchain
If this sounds familiar, it's because blockchains use the same principle. Each block contains the hash of the previous block, forming a chain that can't be modified without redoing all subsequent blocks.
Chain links
Blocks of transactions
Individual proof attestations
Secured by
Consensus (many nodes)
Hardware attestation + ZK proofs
Purpose
Decentralized ledger
Verifiable financial data
Frequency
Minutes (block time)
On-demand (per attestation)
Starting a New Chain
Sometimes it's necessary to start a fresh chain — for example, when deploying a new version of the system or beginning a new data feed. In these cases, the system can generate a proof with no predecessor, creating a new chain from scratch.
This is an explicit action. The proof payload clearly indicates that there is no previous root, so verifiers know this is a chain start, not a broken link.
Verifying the Chain
To verify the chain between any two consecutive proofs:
Take the earlier proof's root
Take the later proof's root
Confirm the later proof's "previous root" field matches the earlier proof's root
Recompute the chained root and confirm it matches
To verify the full history, walk the chain from the first proof to the latest, checking each link.
Verification
Verifiers can check the Merkle root by:
Taking all the commitments from the proof payload
Rebuilding the tree using the same algorithm
Confirming the recomputed root matches the root in the attestation
If the roots match, the commitments are the ones that were attested — nothing was added, removed, or changed after the hardware signed off.
Public Commitments Mode
The system supports an optional public commitments mode for when transparency is more important than privacy:
Private (default)
Only commitments — values hidden
Production use where privacy matters
Public
Raw values included alongside commitments
Full transparency scenarios
In public mode, anyone can see the individual values. The Merkle tree and commitments still provide tamper evidence, but privacy is not the goal — auditability is.
Key Properties
Tamper-evident
Changing any value changes the root
Privacy-preserving
Commitments hide values; only the root is public
Deterministic
Same data always produces the same root
Compact
One 32-byte root represents all data
Independently verifiable
Anyone can rebuild the tree and check the root
Selectively provable
Individual values can be revealed without exposing others
Historically linked
Each proof chains to the previous one, preventing tampering
Last updated