The Verification Principle
Any proof system is only as strong as its verification mechanism. If verifying proof requires trusting the proof provider, you haven’t really proven anything — you’ve just added a middleman.
TimeProof’s verification engine is designed around a simple principle: the person checking the proof should never need to trust TimeProof.
This means:
- No account required to verify
- No payment required to verify
- No API key or authentication token needed
- All verification data is either public (blockchain) or included in the certificate
- The cryptographic operations can be performed with standard, open-source tools
Three Verification Paths
Path 1: Web Verification (Simplest)
Who it’s for: Anyone who wants quick confirmation
How it works:
- Visit TimeProof’s verification page
- Drag your file onto the page (or paste its SHA-256 hash)
- The system computes the hash locally in your browser
- It looks up the hash in TimeProof’s database
- It reconstructs the Merkle proof and verifies against the on-chain root
- Green check = verified. Red X = not found or mismatch.
Trust level: You trust TimeProof’s web interface is performing the verification correctly. The file never leaves your browser (hashing is client-side), but you’re relying on TimeProof’s servers for the Merkle proof lookup and blockchain verification.
Best for: Quick checks, non-adversarial situations, personal records.
Path 2: Certificate + Polygonscan (Independent)
Who it’s for: Anyone who wants to verify without relying on TimeProof
How it works:
- Compute the SHA-256 hash of your file using any tool (openssl, sha256sum, Python, etc.)
- Compare it to the hash in your timestamp certificate — they must match
- Take the transaction hash from your certificate and look it up on Polygonscan
- Decode the transaction data to find the Merkle root
- Use the Merkle proof from your certificate to walk from your file hash up to the root
- If your computed root matches the on-chain root, the timestamp is verified
Trust level: You trust the Polygon blockchain (thousands of validators) and the SHA-256 hash function (NIST standard). You do not trust TimeProof at all.
Best for: Legal proceedings, adversarial situations, compliance audits.
Path 3: Programmatic Verification (Fully Automated)
Who it’s for: Developers, organizations processing many verifications
How it works:
import { createHash } from 'crypto';
import { ethers } from 'ethers';
// 1. Hash the file
const fileHash = createHash('sha256')
.update(fileBuffer)
.digest('hex');
// 2. Verify Merkle proof
let computed = fileHash;
for (const step of certificate.merkleProof) {
computed = step.position === 'left'
? sha256(step.hash + computed)
: sha256(computed + step.hash);
}
// 3. Check against blockchain
const provider = new ethers.JsonRpcProvider(polygonRPC);
const contract = new ethers.Contract(
contractAddress, abi, provider
);
const onChainRoot = await contract.getAnchor(
certificate.anchorId
);
// 4. Verdict
const verified = computed === onChainRoot;
Trust level: Same as Path 2 — you trust only the blockchain and standard cryptography. Additionally, you can inspect every line of verification code.
Best for: CI/CD pipelines, batch verification, integration into existing systems.
Verification Components
SHA-256 Hash Match
The most basic check: does the file produce the same hash as the certificate claims?
If the file has been modified by even a single bit, the hash will be completely different (avalanche effect). A matching hash means the file is byte-for-byte identical to what was timestamped.
This check catches:
- Accidental file corruption
- Intentional file tampering
- Version confusion (verifying a different version than what was timestamped)
Merkle Proof Reconstruction
The Merkle proof is a series of sibling hashes that allow you to reconstruct the path from your file’s hash to the Merkle root. Each step combines your current hash with a sibling hash (either on the left or right) to produce the parent hash, climbing the tree until you reach the root.
The proof is valid if and only if the computed root matches the on-chain root. It’s mathematically infeasible to forge a valid Merkle proof for a hash that wasn’t in the original tree.
On-Chain Root Verification
The Merkle root stored in the TimeProofAnchor smart contract on Polygon is the ultimate source of truth. The block timestamp tells you exactly when the anchor was written. The immutability of the blockchain ensures this record can’t be altered.
Verification checks:
- The transaction exists and is confirmed
- The Merkle root in the transaction matches the computed root
- The block timestamp confirms when the proof was anchored
Edge Cases and Failure Modes
File modified after timestamping
Result: Hash mismatch (Step 1 fails) Meaning: The file you’re verifying is not the same file that was timestamped. This could be accidental (wrong version) or intentional (tampering).
Certificate data corrupted
Result: Merkle proof fails to reconstruct to root (Step 2 fails) Meaning: The proof data in the certificate is damaged or incorrect. Re-download the certificate from TimeProof or use the original certificate backup.
Blockchain reorganization
Result: Transaction temporarily not found Meaning: Polygon reorganizations are extremely rare and affect only the most recent blocks. Wait a few minutes and re-verify. For timestamps older than a few minutes, this is not a concern.
TimeProof service unavailable
Result: Path 1 unavailable, Paths 2 and 3 unaffected Meaning: TimeProof’s website is down but your proof remains valid. Use your certificate and Polygonscan for independent verification.
The Trust Spectrum
| Method | Trust TimeProof? | Trust Polygon? | Technical Skill |
|---|---|---|---|
| Path 1: Web | Yes (interface) | Indirectly | None |
| Path 2: Manual | No | Yes | Moderate |
| Path 3: Code | No | Yes | Developer |
Every user can start with Path 1 for convenience and escalate to Path 2 or 3 when independent verification matters. The system is designed so that trust is always optional — you can always verify yourself.