Status: Public Beta v0.1 · About · Privacy-first · No blockchain
About TimeProofs
Why TimeProofs exists, who is behind it, and how the protocol is designed to stay open, privacy-first, and independent over the long term.
Mission & vision
Mission. Give everyone — developers, AI teams, researchers, creators, and legal teams — a simple way to prove when data existed and that it has not changed, without revealing the data itself.
Vision. TimeProofs is built as a reference implementation of a future open protocol called ProofSpec. The long-term goal is for ProofSpec to become a neutral standard for digital proof of existence, much like PDF or JPEG became standards for documents and images.
Hash locally · Timestamp via API · Verify publicly · No blockchain · No tokens.
Core values
1) Privacy-first by design
Only hashes leave your device. The protocol never needs your original files, prompts, datasets, or documents. This keeps personal data and trade secrets out of the proof layer.
2) Open and neutral
TimeProofs aims to stay neutral: no lock-in, no proprietary formats, no requirement to use a specific cloud provider. The ProofSpec protocol is designed to be implemented by others.
3) Verifiability over marketing
Every release and every important page is meant to be sealed with its own proof. The goal is that trust comes from verifiable artifacts, not from slogans.
4) Simplicity for developers
Integrations should be as simple as a curl call, a small SDK function, or a CI step. No complex onboarding, no accounts required to start, and minimal configuration.
What TimeProofs actually does
TimeProofs does three things well:
- Canonicalize and hash content on the client side. Text, files, outputs, or datasets are normalized and hashed locally (for example with SHA-256).
- Issue a signed timestamp at the edge. The hash is sent to the TimeProofs API, which signs a timestamped proof using controlled keys at the edge.
- Expose an open verify path. Anyone can verify the proof using the public endpoint or a self-hosted verifier, without needing access to the original data.
The reference implementation runs on edge infrastructure, but the protocol is designed to work on any stack that can sign and verify hashes.
Governance & roadmap
Reference implementation. The current TimeProofs deployment is a reference implementation of the ProofSpec protocol. It is used to validate the design, security model, and developer experience.
From product to standard. The roadmap moves in stages: first a stable public API, then formal ProofSpec documentation, then community input and, later, a foundation or standards body involvement (W3C, ISO-style discussions).
Open-source posture. The goal is for the client libraries, the specification, and the verification tools to be openly auditable, with a clear licence and contribution model.
Over time, governance should shift from a single maintainer to a broader group of stakeholders that care about open, privacy-preserving proofs.
Trust & transparency
Release proofs
Each version of the site and API is intended to be sealed with a release proof. The hash of the built artifacts is published, together with a verify link, so anyone can confirm that what is served matches what was released.
Security posture
The security page details the threat model, CSP, key policy, and disclosure process. The aim is not to claim perfect security, but to make the assumptions and controls explicit.
No hidden data flows
TimeProofs avoids capturing original content, personally identifiable information, or proprietary data. Logs are designed to be minimal and focused on operational integrity, not user profiling.
Who it is for
AI & ML teams. To prove when prompts, model versions, and outputs were produced, without leaking training data or business logic.
Legal & compliance teams. To attach time-stamped proofs to policies, evidence, filings, and audit trails.
Developers & DevOps. To seal build artifacts, configuration baselines, SBOMs, and deployment histories.
Creators & researchers. To publish work with attached proof bundles that certify existence at a given point in time.
If you sit in any of these categories and want to experiment with TimeProofs, start with: Create / Verify · API Docs · Use Cases
Contact & channels
Contact. You can reach the maintainer at contact@timeproofs.io for questions, early partnerships, or security reports.
Status & uptime. Operational status and incident history are published at status.timeproofs.io.
Community & updates. Public updates and discussions happen on:
- X (Twitter)
- GitHub repository
- LinkedIn page
- RSS feed for release notes and technical posts
As the protocol matures, more formal community channels and governance structures will be documented here.
This page is verified by TimeProofs
Release: … ·
Hash: … ·
Verify
Loaded from the central release manifest.