The defense moves to exclude the timestamped documentation. No expert witness. No live testimony explaining how the blockchain system works. Just a certificate from an automated process and a hash value recorded on-chain.

The motion has a real answer. But the answer depends entirely on which rule the offering party prepared for.

If they built their case around FRE 901(b)(9), they need a witness. If they built it around FRE 902(13), they need a certification. That's a meaningful difference when the expert is unavailable, expensive, or subject to a Daubert challenge.

---

The Rule That Gets Conflated

Most blockchain evidence discussions center on FRE 901(b)(9). That rule allows authentication by "evidence describing a process or system and explaining how it produces an accurate result." It's a process-reliability argument. Courts have applied it to computer-generated records, GPS data, and digital photographs.

It works. But it requires someone to lay the foundation. An expert, a system administrator, a qualified technician. Live testimony, subject to cross-examination. A witness who can be challenged, excluded, or simply too costly to bring in for a pre-trial hearing.

FRE 901(b)(9) is not a self-authentication rule. The offering party still carries the foundation burden. A lot of practitioners miss this distinction, and it matters when the evidentiary motion comes early.

---

What FRE 902(13) Actually Says

Congress added FRE 902(13) in 2017. It provides self-authentication for "a record generated by an electronic process or system that produces an accurate result." The mechanism: a written certification from a qualified person, submitted before trial with advance notice to opposing counsel.

No live witness required. The certification does the work.

The 2017 Advisory Committee Notes are explicit. The rule targets machine-generated records where reliability derives from the process itself, not from operator credibility or human judgment. The system runs. The record is produced. Either the process worked correctly or it didn't.

A blockchain timestamp fits that description precisely. The user submits a SHA-256 hash. The anchor transaction executes on-chain. A block confirmation records the timestamp. No human interpretation in the output. The certificate reflects what the blockchain recorded.

---

What the Certification Must Include

Under 902(13), the certification must come from a "qualified person" and must comply with the requirements of Rule 902(11) or (12). In practice: a written declaration under penalty of perjury, from someone with direct knowledge of the system, attesting that:

For a blockchain timestamp, that certification comes from the timestamp provider. It attests that the submitted hash was anchored on a specific date and time, that the on-chain transaction is publicly verifiable, and that the hash in the certificate matches the on-chain record.

Opposing counsel can still challenge the certification. They can subpoena the certifying witness, move to exclude on foundation grounds, or contest the qualifications of the declarant. But the burden shifts. The default becomes admission, not exclusion. That's structurally different from 901(b)(9), where the offering party carries the foundation burden throughout.

---

Why Dual-Chain Anchoring Matters Here

I built ProofLedger to anchor every proof to both Polygon and Bitcoin. That decision was about independent verification, not redundancy for its own sake.

Under a 902(13) certification, the core argument is that the system produces accurate results. Two independent public blockchains, operating different consensus mechanisms on separate infrastructure, both recording the same hash at the same time: that corroboration supports the accuracy argument without requiring the certifying witness to explain it.

Attacking the reliability of a single blockchain in cross-examination is already difficult. Attacking two independent ledgers with different validator sets and different operational histories is a different problem. The dual-chain record doesn't just satisfy the certification. It makes the certification harder to impeach.

---

What 902(13) Doesn't Cover

Self-authentication under 902(13) handles the admissibility foundation. It doesn't determine weight. The fact-finder decides what the evidence means once it's in.

It also doesn't address relevance or completeness. The timestamp proves when the hash was anchored. Connecting that hash to a specific file, at a specific version, still requires the offering party to make that showing separately. The hash-to-file link is a factual foundation question, not a certification question.

Chain of custody and authentication are not the same analysis. FRE 902(13) handles authentication. What happened to the file between creation and anchoring is a separate showing the offering party needs to address. The certification removes the need for a live witness to authenticate the blockchain record. It doesn't paper over gaps in custody that existed before the anchor was created.

---

Monday Morning: What This Means Practically

If you're building blockchain-timestamped documentation into an evidence workflow, prepare the 902(13) certification before you need it in court.

That means:

If you're on the other side reviewing blockchain evidence offered under 902(13), the attack points are: qualifications of the certifying person, accuracy and completeness of the process description, and whether the hash in the certificate actually matches what's on-chain. The certification shifts the burden. It doesn't end the analysis.

FRE 901(b)(9) still matters. For trial, belt-and-suspenders authentication using both a certification and a qualified live witness is defensible practice. But building a case solely around 901(b)(9) when 902(13) is available means depending on a witness who can be delayed, challenged, or excluded.

The 2017 amendments were written to reduce exactly that friction. Prepare accordingly.

---

More on ProofLedger's dual-chain timestamp process: proofledger.io?ref=legal