Hash-then-anchor: proving data without putting it on-chain
Hash-then-anchor: proving data without putting it on-chain
Financial data has two needs that pull against each other. It has to stay private, because it contains borrower details, account numbers, and commercial terms. It also has to be provable, because investors need to know it hasn't been edited after the fact.
Hash-then-anchor meets both. You fingerprint the data privately, then record only the fingerprint on a public blockchain. The data never leaves its owner. The fingerprint becomes a permanent, timestamped record that anyone can check against.
How it actually works
Step 1: Hash. Take the dataset (a loan tape, a bank statement, a collateral report) and run it through a cryptographic hash function. For a large dataset, hash each record and combine them into a Merkle root. The result is a short string that uniquely represents the data.
Step 2: Anchor. Write that string into a transaction on a public blockchain. The blockchain records the string and the time it was written. Nothing else.
Step 3: Verify, any time later. Whoever holds the data can hash it again. If the new hash matches the anchored one, the data is unchanged since the anchor time. If it doesn't, the data has been altered.
What's on-chain is just 32 bytes of what looks like random characters. It reveals nothing about the underlying data. But it pins that data to a specific moment in a way that neither the data owner nor anyone else can later rewrite.
What it proves
- Integrity. The data hasn't changed since it was anchored.
- Existence at a time. The data existed in exactly this form no later than the block's timestamp.
- Consistency across parties. If an investor and an administrator each hold a copy, both can confirm they're looking at the same thing.
What it doesn't prove
Hash-then-anchor makes data tamper-evident. It doesn't make data true.
If a loan tape contains an error when it's hashed, the anchor permanently confirms that erroneous tape. This is why anchoring has to come after checking the data against its sources, not instead of it. See Verify first, tokenize second.
It also can't prove completeness on its own. If a record was left out before hashing, nothing in the anchor reveals that. Completeness comes from reconciling against an independent source, such as a bank feed or a registry, before hashing.
Why not just put the data on-chain?
Three reasons.
Privacy. Public blockchains are public. Borrower data, account numbers, and commercial terms can't be published, and in most jurisdictions doing so would breach data protection law.
Cost. Storing data on-chain is expensive. Storing one hash is cheap, and a single hash can represent millions of records.
Permanence. Data on a public chain can't be deleted. That's a feature for a fingerprint and a liability for personal data, which people have a legal right to have erased.
Why it matters
Hash-then-anchor shifts the question from "do I trust whoever holds the data?" to "does the data match its anchor?" The second question has a yes or no answer that anyone can check.
Rekord uses this pattern so that the data behind an instrument can be checked by investors without being exposed to them. The data stays with the parties who are entitled to hold it. The proof that it hasn't changed is public. See Does my data go on-chain? for what that means for borrowers and pledgors.