A public proof of a build connection.

ShipStamp addresses a practical indie-builder problem: a polished application and a current repository do not show when a specific build was connected to a live deployment and publicly recorded.

The solution

A builder verifies a public GitHub commit, publishes a versioned manifest at the live deployment, and records the matching manifest hash through a wallet transaction on Monad.

Why onchain

The record should remain independently inspectable without trusting ShipStamp's server, database, or continued operation. The wallet signature and chain timestamp are the useful part.

What ShipStamp proves

The public commit existed at verification time. The live deployment served a manifest naming that repository, commit, deployment origin, project, and submitting wallet. The wallet recorded its matching hash at the Monad block timestamp.

What it does not prove

That every deployed file came from the commit; GitHub ownership; identity between the GitHub author and wallet; code safety, originality, or trustworthiness; continuous deployment history; or legal ownership.

System boundary

No application database.

Next.js validates public commits server-side through GitHub's REST API. A server-only verifier safely fetches the fixed manifest path from a public HTTPS origin. An injected EVM wallet submits the canonical manifest hash to ShipStampRegistry on Monad Testnet. Receipt and project pages read the contract directly and can recheck the currently served manifest.

USER → NEXT.JS → GITHUB REST

DEPLOYMENT → WELL-KNOWN MANIFEST → SERVER VERIFIER

WALLET → SHIPSTAMP REGISTRY → MONAD

PUBLIC READS → CONTRACT STATE + EVENTS