Software

Your code has history. Now it has proof, too.

Repositories change owners, partners leave, freelancers deliver and disappear, and sometimes a competitor ships something surprisingly similar. Git history helps, but it can be rewritten and depends on whoever runs the server. Recording snapshots of your code creates independent proof that a version existed on that date.

See how it works

The challenge

Where proof usually breaks down

Git history can be rewritten

Commit dates can be changed and the repository depends on whoever administers it. It isn't neutral proof.

Disputes between partners

When a partnership ends, "who built what, and when" becomes the heart of the argument.

Deliveries without clear milestones

In outsourced projects, proving what was delivered at each stage avoids disputes over scope and payment.

How Docmint helps

Technical proof that's simple to create and easy to check

An independent milestone

The snapshot's hash goes on a public blockchain. Neither you, your Git server nor Docmint can change the date.

Confidential code stays confidential

Code is never uploaded. Only the file's fingerprint is recorded.

One record per release

Record each version's package. Together, the records form a verifiable product timeline.

Verifiable by any expert

SHA-256 is an industry standard: any specialist can check the record with common tools.

What to record

Files worth recording

Source code snapshots (ZIP, TAR)
Releases and published binaries
Algorithms, models and notebooks
Technical and architecture docs
Specs, PRDs and prototypes
Databases and training datasets
Freelancer and vendor deliveries
Technical proposals for clients

Any format works: Docmint records the file's fingerprint, not its content.

In practice: recording every release

Your team ships an important product version.

1
Generate the release package (e.g. git archive) and the documentation PDF.
2
Record the files as a batch in Docmint, with the version number in the title.
3
Keep the receipts alongside the release tags.
4
In a future dispute, you show that exact code existed on that date.

Best practices

Record a reproducibly generated archive (e.g. git archive of a tag).
Note the commit hash in the record's description (no secrets).
Record milestones: MVP, major releases, third-party deliveries.
Never include keys, passwords or personal data in titles and descriptions.
For patent filings, talk to a specialist: the record does not replace a patent office.

What the law says

Under the Berne Convention and the TRIPS agreement, software is protected as a literary work from creation, without registration. Docmint does not replace optional software registrations or patents, but provides fast technical proof of authorship and date.

Frequently asked questions

Isn't a Git commit already proof?

It helps, but commit dates can be altered and the repository depends on who controls it. A blockchain record is an external, neutral milestone.

Do I need to record the whole repository?

Record an archive of the version (its hash is what matters). Keep that file exactly as recorded.

Does it replace software registration?

No. Official registration is optional and has its own effects. Docmint is complementary technical proof — fast and affordable.

Start with your next file.

Create your account in seconds and get 3 free records to try in your daily work.