Sigstore and blockchain anchoring answer different questions about a release file. A Sigstore signature ties an artifact to an identity and records that signature in a log run by the Sigstore project. A blockchain anchor records the file's SHA-256 hash, a 64-character fingerprint of its bytes, on a public ledger with no operator. That shows this exact file existed no later than the anchor. So the decision comes down to what you need a person downloading your release to be able to check, and who has to stay online for that check to work.

What Sigstore and cosign are and how they work

Sigstore is made up of several parts. Cosign is the tool that signs an artifact. Fulcio issues the short-lived certificate used for the signature. Rekor is a transparency log, meaning a public record that entries are added to, and the signature is recorded there.

Because the certificates are short-lived, the signature rests on an identity rather than on a long-held private key. An identity provider vouches for who is signing, and the certificate carries that identity.

Trust model. A verifier relies on the identity provider and on the transparency log. The Sigstore project operates Rekor, so the log entry is that project's record.

Verification path. A verifier checks the artifact against the signature, the signature against the certificate and its identity, and the signature's record against the log.

What it speaks to. A Sigstore signature addresses which identity signed this artifact. The record of it sits in a log that has an operator.

What ProofLedger does differently

ProofLedger doesn't sign your artifact with an identity. It hashes the bytes with SHA-256, anchors the hash, and returns a proof.

The record sits on a public ledger. Every proof is anchored on Polygon in its own public transaction, usually within a minute. The date comes from the network, and the transaction can be looked up on a block explorer without involving ProofLedger.

Only the hash leaves your machine. The file stays with you. This holds for every file type and every size, because there's one engine and it doesn't care what's inside the file.

You hold a file that verifies without the vendor. Each proof has a bundle containing the hash, chain, transaction id and anchor time. It comes in the open verify-proof file format and is available from GET /api/v1/proof/:id/bundle.

It fits into the release itself. There are two ways to wire it into GitHub:

  • GitHub Action. It's in the GitHub Marketplace as ProofLedger Release Timestamp, and workflows use uses: Fulcrum-Enterprises/proofanchor-github-action@v2. On a GitHub Release it hashes the artifact on the runner, submits the hash and waits for the Polygon anchor, up to two minutes by default. It then attaches the proof bundle to the release and links the transaction in the release notes.
  • GitHub App. It installs from github.com/apps/proofledger, and you connect it to a ProofLedger account once. Every release published on that repository is then anchored on its own, with one proof per release file from the SHA-256 GitHub reports, so no file is downloaded. A "Proof of existence" table goes into the release notes with a certificate link per file. Once the hash is on Polygon, <file>.proof.json is attached to the release with the transaction link. The App holds Contents read and write on the chosen repositories and nothing else. Its proofs count against the connected account's monthly allowance, as API proofs do. Details are on the pricing page.

What an anchor doesn't show. It doesn't say who made the file or who published it, and it doesn't say the file is safe to run. It says this exact file existed no later than the anchor.

Here's how the two compare side by side:

| Question | Sigstore (cosign, Fulcio, Rekor) | ProofLedger | |---|---|---| | What gets recorded | The signature, in the Rekor log | The file's SHA-256 hash, in a Polygon transaction | | What it speaks to | Which identity signed the artifact | This exact file existed no later than the anchor | | Who a verifier relies on | An identity provider and a log operated by the Sigstore project | A public ledger with no operator | | What the verifier holds | The artifact and its signature material | The artifact and a proof bundle in the verify-proof format |

Verifying a proof yourself

There are two routes. One uses ProofLedger's records and one doesn't.

Without ProofLedger

Start with the release file and its proof bundle. If the release went through the GitHub App, the bundle is the attached <file>.proof.json. The Action also attaches a bundle to the release.

Install the package:

pip install verify-proof

The verify-proof package compares the file with the bundle on your own machine and makes no network call. If a single byte of the file has changed, the hash won't match.

Next, take the transaction id from the bundle and look it up on a Polygon block explorer. The explorer shows that the transaction exists and when it landed on the chain. ProofLedger plays no part in this check. Its servers could be offline and neither step would change.

Node users have a verify-proof client too. Command details are in the API docs.

Through ProofLedger's public lookup

Hash the file yourself:

sha256sum myapp.tar.gz

Then ask the public endpoint about that hash:

curl "https://proofledger.io/api/v1/verify?hash=<sha256>"

This call needs no key and is limited to 120 requests per hour per IP. Every proof also has a public verify page that a non-technical reader can open.

Both of these look the proof up in ProofLedger's records, so they depend on ProofLedger being reachable. They're the convenient route, and the bundle and block explorer are the route that doesn't need ProofLedger at all.

Which fits your situation

You want to show when a release file existed. With a transparency log, the record belongs to whoever operates the log, and that operator is part of what a verifier relies on. With an anchor on Polygon, the record is a public transaction with no operator behind it. ProofLedger is built for this question, and the bundle attached to the release travels with it.

You don't want verification to depend on anyone staying online. Under the Sigstore model, the log and identity provider are the dependency you take on for the steps that consult them. With ProofLedger, the file and bundle comparison runs locally with no network call. Checking the transaction needs the Polygon network and a block explorer, and neither is run by ProofLedger.

You want this in your release flow without writing code around it. The GitHub App anchors every published release once it's connected, and the Action does the same work as a workflow step. A release with no files gets one proof of the release record.

You're building proofs into your own pipeline. The v1 REST API takes a hash at POST /api/v1/proof, with an optional external_id so a retried request returns the same proof. POST /api/v1/proofs/batch takes up to 100 hashes in one call. A signed webhook tells you when the Polygon anchor lands. The reference is in the API docs, and the spec is at /openapi.json.

You want to run the service yourself. ProofLedger Community is the open-source proof core as a self-hostable Node and SQLite server. It has the same v1 API shapes and anchors on Polygon with your own key or a separate signer box. It writes the same transaction shape as proofledger.io, so verify-proof checks its bundles the same way. You keep the key safe and the server reachable for its verify pages. The hosted service is a separate product and isn't open source.

You need to show who made a file. A ProofLedger proof doesn't identify anyone. It's evidence about a file and a moment, and a claim about authorship needs other evidence to back it.