Use Case
Timestamping Build Artifacts and Release Hashes
Publishing a checksum next to a build proves that two files match. It does not prove when the digest first existed. Anchoring moves that record somewhere nobody owns, in one call, at the moment the artifact is produced.
The gap in a published checksum
The standard practice is sound as far as it goes: compute a SHA-256, publish it in the release body, an object store, or a manifest alongside the artifact. Anyone can recompute the digest and confirm the bytes are unchanged. That is an integrity guarantee, and it works.
What it does not establish is when. The timestamp on the release, the object, or the manifest is written by infrastructure the publishing party controls. If the question later becomes whether a given binary existed before a particular date, the answer rests on records held by the party with an interest in the answer. That is exactly the position you do not want to be in, and it is not a hypothetical: it is the routine shape of a supply-chain dispute, a licence audit, or a prior-art question.
Signing addresses a different half of the problem. A signed commit or a signed artifact binds it to a key holder, which answers who. Commit dates remain metadata the committer sets. Transparency logs such as Rekor add an independent record, operated by a project. A public ledger has no operator at all.
Anchoring from CI
Hash locally, send the digest. There is no endpoint that accepts a file, so the artifact never leaves the runner and there is nothing on our side to lose or be compelled to produce.
HASH=$(sha256sum dist/app.zip | awk '{print $1}')
curl -X POST https://proofledger.io/api/v1/proof \
-H "Authorization: Bearer $PROOFLEDGER_KEY" \
-H "Content-Type: application/json" \
-d "{\"sha256\":\"$HASH\",\"filename\":\"app.zip\"}"Polygon confirms in seconds. Setting bitcoin_requested also queues the digest for Bitcoin, which is Merkle-batched daily, so a single chain's failure is not a single point of failure.
For GitHub releases there is a composite Action that does the hashing, the call, and the release-body annotation in one step. See the Action on GitHub.
Verification that does not route through us
A verification path that depends on the vendor is worth very little in the situation where you actually need it. Two paths, neither requiring an account or a key:
curl "https://proofledger.io/api/v1/verify?hash=$HASH"
# or offline, without contacting ProofLedger at all
pip install verify-proof
verify-proof hash ./app.zipThe second reads the proof against the chain directly. If ProofLedger were gone tomorrow, every digest already anchored still verifies. That property is the point of using a public ledger rather than a hosted log.
Where this is worth doing
- Release artifacts. Anchor the digest at publish time, so the release date is attested somewhere outside your own infrastructure.
- Build provenance and audit records. Anchor the manifest or the log digest rather than the logs themselves.
- Model and dataset snapshots. Establish that a set of weights or a training corpus existed in a given state on a given date, which is increasingly the question being asked.
- Prior art and internal invention records. Anchor the document at the point of writing rather than reconstructing dates later.
- Compliance baselines. Fix the state of a configuration or a policy document at the point it took effect.
What it does not prove
An anchor establishes that a specific digest existed no later than the block it was written to. It says nothing about who created the file, whether it is original, whether its contents are accurate, or who owns it. Those are separate questions and a timestamp does not answer them. Anyone claiming otherwise is overselling.