Before you publish a repository or release tarball, timestamp the exact archive you will share. TimeBinder® makes a fingerprint in your browser. The files stay on your device. You get a checkable Proof of Time Certificate that shows that exact tree existed no later than a recorded time. It does not show who wrote the code, who owns it, or that a licence must be respected. Free to start. See prove source code existed before a date and source code timestamping.
Table of Contents
The routine: timestamp before you publish
- Export a release archive (zip or tar.gz of the tag you will publish). Do not include secrets.
- Optional. Confirm the hash with the free SHA-256 hash checker and compare later to the GitHub release asset.
- Timestamp the archive. Your first Pooled TimeBind is free, with no credit card required.
- Save the Proof of Time Certificate with the archive.
- Then push the public repo or attach the release.
- Later major versions get their own archive and TimeBind.
How to timestamp a file has the steps. Git dates alone are weak as independent proof: Git commit dates as proof.
Private work that becomes public
If the project started closed-source, timestamp milestone zips along the way, not only the open-source day. That trail shows what existed before the first public commit. For freelancer deliveries into the same codebase, see freelance code delivery before payment.
What a TimeBind shows, and what it doesn’t
A TimeBind shows that this exact file existed no later than the recorded time. It does not show authorship, ownership or copyright, and it does not choose a licence (MIT, GPL, and so on). Keep your licence file and contributor agreements. This is general information, not legal advice.
Before that public release, if an assistant helped write any of the files, the free vibe-coding review checklist is a pre-merge list: a named reviewer, a readable diff, and a record of what changed.
The same dated-file habit is useful before a cloud assistant sees a private repo. The free cloud coding assistant checklist looks at the plan, the terms and the files from before the session. It cannot decide a licence.
The same dated-file habit is useful before you merge a workflow that calls third-party actions. The free GitHub Actions workflow lockfile checklist looks at the current docs, the review, and the lockfile to keep. Locking does not show that an action is safe.
Frequently Asked Questions
-
Should I timestamp the .git folder?
Prefer a clean release archive of the source you publish. A whole .git zip is possible but large and noisy.
-
Does the first public commit date replace this?
No. Commit timestamps are set by the committer. An independent fingerprint of the release archive is stronger for “this tree existed by then.”
-
Monorepo: one zip or many packages?
Timestamp what you actually release. Multiple packages can share one TimeBind (up to 10 files).
-
What about signed git tags?
Useful. Still keep a dated archive of the tagged tree if disputes may involve the bits you shipped.
-
What does it cost?
Your first Pooled TimeBind is free, with no credit card required. After that, from US$5; ASAP is US$15. See plans and pricing
Timestamp your release archive free
Show that this exact file existed no later than a recorded time. Files stay on your device. Get a checkable Proof of Time Certificate. Free to start. Open TimeBinder
