Gridcoin Stamp — GitHub Action

When a GitHub release is published, the action collects the artifacts attached to it, hashes each one locally on the runner, submits the hashes to stamp.gridcoin.club, and writes a “Blockchain Timestamps” table into the release body with a verification link per file. The file contents never leave your CI environment — only the 64-character hash does.

A GitHub release is a mutable object. Tags can be force-pushed, auto-generated source archives can drift byte-wise between downloads, release notes can be rewritten, and the whole release can be deleted by anyone with write access. None of that changes the fact that at some specific moment you intended a specific set of bytes to represent a specific version — but after the fact, proving that intent in a way other people can independently check is surprisingly hard.

Timestamping each release asset against a public blockchain pins a cryptographic fingerprint to an immutable ledger. Anyone — downstream packagers, compliance auditors, a distant forensic investigator — can later hash the file they have in hand and confirm that those exact bytes existed under your release's name at the time of publication. It's the same idea that notaries have been selling for centuries, minus the notary.

The interesting question is not whether to timestamp, but how to do it so that the proof survives every edge case that release tooling quietly walks into. That's what this action exists to answer.

Add a single workflow file to your repository. It fires whenever you publish a release through the GitHub UI or via any release automation that reaches the release: published event — semantic-release, goreleaser, manual clicks, all work.

name: Stamp Release
on:
  release:
    types: [published]

jobs:
  stamp:
    runs-on: ubuntu-latest
    permissions:
      contents: write
    steps:
      - uses: gridcat/gridcoin-stamp-action@v1
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}

The contents: write permission is required because the action uploads assets back to the release and edits the release body. Everything else — source-archive re-upload, manifest generation, idempotent reruns — is on by default.

By default the action submits the hashes and returns immediately — the blockchain typically confirms within 2–5 minutes, and the verification URLs will start resolving some time after the workflow completes. If you'd rather have the workflow block until every stamp is confirmed on-chain, flip wait-for-confirmation on:

- uses: gridcat/gridcoin-stamp-action@v1
  with:
    github-token: ${{ secrets.GITHUB_TOKEN }}
    wait-for-confirmation: true
    poll-timeout: 600

The easy path: pull the …-stamped.zip or …-stamped.tar.gz asset from the release page and drop it onto stamp.gridcoin.club. The hash is computed in the browser, looked up against the blockchain, and rendered as a proof page — the file itself never leaves the verifier's machine.

The terminal path: compare the SHA-256 of any downloaded asset against the corresponding row in the release body, or regenerate the proof manifest from git state and confirm its hash matches the row for <tag>.stamp.txt. Both routes are covered step-by-step in the repository README.

The full list of inputs, outputs, rerun semantics, tag-mutation recovery, and CircleCI + semantic-release integration notes lives in the GitHub repository. Issues, pull requests, and feedback are all welcome — this is a young project and the ecosystem it serves is small, so every piece of input materially shapes where it goes next.

If you build anything on top of it, or if the stamp table on one of your releases caught someone's attention, I'd love to hear about it.