ProofLedger Evidence Process Statement
This document describes how ProofLedger creates, anchors, and verifies digital proof records so that reviewers can evaluate the procedural reliability of ProofLedger certificates.
1. Overview
ProofLedger acts as a neutral evidence recorder. It provides proof of existence by computing a one-way cryptographic hash of a file, recording that hash and related metadata in an internal audit log, and anchoring the hash to public blockchains. ProofLedger never stores customer files, only hashes and minimal metadata.
2. Hashing process
ProofLedger uses the SHA-256 hashing algorithm to represent the contents of a file as a fixed-length hexadecimal value (the "file hash").
- SHA-256 is a widely accepted one-way cryptographic hash in courts and technical standards.
- Any change to a file's contents, even a single bit, produces a completely different hash.
- Only the hash and minimal metadata are stored; the file itself is never stored by ProofLedger.
3. Time and record creation
When a user submits a file for proof, ProofLedger creates an internal record that includes:
- Internal proof ID.
- Public certificate ID.
- SHA-256 hash of the file.
- Account identifier (such as email address).
- Timestamps for record creation, first proof event, and certificate issuance.
All system timestamps are stored and displayed in Coordinated Universal Time (UTC). Server clocks are synchronized using standard network time protocols (NTP). Operational logs are retained to support later review of proof creation events. Once created, proof records are append-only and cannot be altered, overwritten, or retroactively modified.
4. Blockchain anchoring
4.1 Polygon anchoring
For Polygon anchoring, ProofLedger periodically groups one or more file hashes into a transaction on the Polygon blockchain. The resulting transaction ID (tx hash) is stored in the ProofLedger record and displayed on the certificate with a direct link to a public Polygon explorer.
- The presence of a Polygon transaction ID that can be independently verified on-chain shows that the corresponding hash was included in that transaction as of the block timestamp.
4.2 Bitcoin anchoring
For Bitcoin anchoring, ProofLedger groups one or more file hashes into a Merkle tree and commits the Merkle root to the Bitcoin blockchain in a transaction. The Bitcoin transaction ID and Merkle root are stored in the ProofLedger record and displayed on the certificate.
- If a Bitcoin transaction ID is present and verifiable on-chain, it shows that the Merkle root existed at or before that block's timestamp.
- If a Bitcoin Merkle root is present, the file hash can be recomputed into the Merkle tree to confirm inclusion in the anchored batch.
5. Data retention and privacy
- ProofLedger stores file hashes and minimal metadata (such as filenames, sizes, and account identifiers) needed to operate the service and support later verification.
- ProofLedger does not store, retain, access, or transmit file contents and cannot reconstruct files from stored hashes.
- Proof records and audit logs are retained for the life of the service unless required to be deleted by law.
Certificate representation
ProofLedger certificates are non-authoritative summaries of recorded proof data. The online verification page is the authoritative record. They are provided for portability and review. The authoritative record is the underlying proof record and its independently verifiable blockchain references.
6. Record status & administrative annotations
Each ProofLedger record carries a status that reflects its procedural state within the ProofLedger system. Statuses describe process outcomes only. They do not determine truth, ownership, authorship, admissibility, or legal effect.
- PENDING — The record has been created and timestamped, but has not yet completed ProofLedger’s internal procedural review or anchoring cycle. The hash and timestamps already exist and are immutable.
- APPROVED — The record has completed ProofLedger’s standard evidence procedure. Hashes, timestamps, and any associated blockchain anchors are final and will not change.
- DENIED — The submission failed procedural requirements (for example, policy or technical constraints). The original submission event, hash, and timestamps remain recorded and verifiable.
- CONTESTED — A third party or administrator has recorded a dispute or annotation regarding interpretation or relevance. The original record remains final and unchanged.
Administrative actions, including status changes and dispute annotations, are recorded as additive audit events. ProofLedger does not overwrite, delete, or retroactively modify original hashes, timestamps, or blockchain anchors.
7. Verification process
ProofLedger verification is designed to be performed independently of ProofLedger. A certificate is intended to be used together with:
- the original file (or agreed copy) whose hash appears on the certificate;
- fresh SHA-256 hash calculations performed by the parties or a qualified expert; and
- independent verification of the Polygon and/or Bitcoin transaction IDs using public blockchain explorers.
The QR code printed on each certificate links to an online verification page for that specific certificate. The online view repeats the essential certificate data and links to the relevant blockchain transactions.
ProofLedger cannot retroactively invalidate, revoke, or alter a proof record once created. Administrative actions, status changes, and dispute annotations are recorded as additive audit events. They do not overwrite, delete, or modify the original hash, timestamps, or blockchain anchors.
A disputed or contested record remains a valid historical record. Dispute status reflects the presence of an external challenge or review process, not a determination of truth, falsity, ownership, or legal outcome.
8. Jurisdiction and operator
ProofLedger is operated by ProofLedger LLC, a company organized under the laws of the State of Florida, United States. Operational control of the hashing, logging, and anchoring processes rests with ProofLedger LLC.
9. Versioning and changes
This Evidence Process Statement is versioned. Significant changes to ProofLedger's hashing, logging, timekeeping, or anchoring processes will result in an updated version number and effective date. Certificates may reference the version that was in effect at the time of issuance.
This document describes ProofLedger’s standard technical processes. It does not assert legal conclusions about admissibility, ownership, authorship, or intent. Evaluation of any ProofLedger record or certificate remains the responsibility of courts, arbitrators, or other decision-makers.