The authentication challenge clears. The foundation under FRE 901(b)(9) is laid. The blockchain timestamp is authenticated.
Then opposing counsel stands up. "Objection. Hearsay."
And they're right. A blockchain record is an out-of-court statement offered for the truth of what it asserts: that a specific file existed at a specific time. Without a hearsay exception, it's inadmissible regardless of how well it authenticates.
FRE 803(6) is where that exception lives. And I'd argue it gets less attention than it deserves.
---
What FRE 803(6) Actually Requires
The business records exception allows admission of records made in the regular course of any business activity, provided they meet four conditions:
1. The record was made at or near the time of the recorded event 2. By someone with knowledge, or from information transmitted by someone with knowledge 3. As a regular practice of the business 4. Kept in the course of a regularly conducted business activity
"Business" under FRE 803(6) is broader than the word implies. Courts have read it to include any organization or association. The question isn't whether money changes hands. It's whether the record was created in a systematic, reliable way.
A blockchain network creates records automatically, in real time, at the moment of anchoring. No human decides whether to log the transaction. The protocol does it every time. That's about as "regular practice" as it gets.
---
The Trustworthiness Condition
FRE 803(6) has a backdoor: a record can be excluded if "the source of information or the method or circumstances of preparation indicate a lack of trustworthiness." This is where opposition pushes.
The argument will be that blockchain records are self-generated, unverified by any human, and therefore untrustworthy. It's not a frivolous argument. But it doesn't hold up.
Trustworthiness under 803(6) doesn't require human verification. It requires that the method of creation be reliable. Courts applying this standard look at whether the record was created contemporaneously, by a system designed to do exactly that, without incentive to misrepresent the data.
A blockchain anchor satisfies all three. The timestamp is created at the moment of anchoring, not reconstructed after the fact. The system was built for this purpose. The blockchain has no stake in what hash gets anchored to it. It doesn't care who wins the lawsuit.
---
901(b)(9) and 803(6) Are Not the Same Argument
This distinction matters for litigation strategy. Conflating them costs cases.
FRE 901(b)(9) is an authentication rule. It establishes that the record is what it claims to be, specifically a product of a process that generates accurate results. That foundation is required before the record can even be considered by the trier of fact.
FRE 803(6) is a hearsay exception. It kicks in after authentication. You need both.
An attorney who clears 901(b)(9) and assumes the timestamp record is in evidence has gotten one step right. If opposing counsel then raises a hearsay objection with no 803(6) foundation in place, the record still goes out.
The practical overlap is worth noting: the certification work that supports FRE 902(13) self-authentication tends to support the 803(6) argument too. A written certification documenting the automated anchoring process, its regularity, and the absence of human intervention in the anchoring step serves both foundations. One document, two evidentiary purposes. That's worth building into the standard case preparation workflow before the motion deadline.
---
What Dual-Chain Anchoring Adds
I built ProofLedger to anchor every hash to both Polygon and Bitcoin. That decision was about verification redundancy. But it ends up supporting the 803(6) argument in a specific way.
Two chains mean two independent records, each capable of satisfying the business records foundation on its own. If opposing counsel attacks the Polygon record's trustworthiness (network behavior, validator questions, whatever the theory), the Bitcoin record stands independently. Same hash. Different chain. Two corroborating business records from unrelated systems.
Process reliability through redundancy. It strengthens the 803(6) argument the same way it strengthens the 901(b)(9) argument: the more independent systems produce identical results, the harder it is to argue the process is untrustworthy.
---
Three Documents to Prepare Before the Motion
The paralegal preparing blockchain timestamps for a case file needs to distinguish between three distinct things:
The FRE 902(13) certification. This handles authentication. A written certification from the anchoring service establishing that the record is what it claims to be. Gets past the authentication gate. Does not address hearsay.
The 803(6) custodian declaration. This handles hearsay. It needs to establish who operates the anchoring service, how the process works, that it runs identically for every record, and that the declarant has personal knowledge of those facts. Different document, different legal function, different evidentiary gate.
The proof record itself. Transaction hash, block explorer link, certificate URL. This is the evidence. The first two documents are the foundation that lets it in.
Preparing the 902(13) cert without the 803(6) declaration means you're ready for one objection, not two. Opposing counsel will raise both. Better to have the custodian declaration ready before the filing deadline than to scramble for it during a hearing.
One more thing to anticipate: the argument that self-generated records are inherently untrustworthy. Courts applying 803(6) to automated records (ATM logs, electronic medical records, access control system entries) have accepted mechanical reliability and contemporaneous creation as sufficient. Blockchain anchors belong in that category. The trustworthiness argument is winnable. But it needs to be prepared before the motion is filed, not answered on the fly.
The authentication fight gets most of the attention. Rightly so. But if hearsay is in play, the 803(6) foundation is what actually gets the timestamp into evidence.