Yes. There are two open-source paths, and they work in different ways. OpenTimestamps is a protocol and client that timestamps hashes on Bitcoin through calendar servers. ProofLedger Community is a server you run yourself. It anchors hashes on Polygon with your own key and serves the same v1 API as proofledger.io. Both let you skip renting a service. The choice is about what you end up running: a client and a folder of proof files, or a server with an API, certificate pages and a public verify endpoint that other people can use.
What OpenTimestamps is and how it works
OpenTimestamps is an open-source protocol and toolset for timestamping on Bitcoin. You hash a file on your own machine and the client sends that hash to calendar servers. The calendar servers combine many hashes into a Merkle tree, a structure that rolls a large number of hashes up into one root hash, and that root goes into a Bitcoin transaction. You keep a .ots file. It holds the path from your hash up to the root that was committed on chain.
Under this model, a third party who wants to check your proof needs your file, your .ots file and the OpenTimestamps tooling to replay the path against Bitcoin. Nobody hosts a certificate page and there's no managed verification URL to send someone who isn't technical. There's also no vendor to call. You run the client and keep the .ots files, and keeping them safe is your job.
What ProofLedger Community is and how it works
ProofLedger Community is the proof core of ProofLedger, released as open source under the GNU Affero General Public License. It's a Node server with a SQLite database, and the source is at github.com/Fulcrum-Enterprises/proofledger-community.
It's a full service, not just a client. It exposes the same v1 API shapes as the hosted service at proofledger.io:
- single proofs and batch proofs, each with an optional
external_id(your own record id, so a retried request returns the same proof) - a proof bundle per proof, holding everything needed to verify it without the server
- lists of proofs, and a public verify endpoint that takes a SHA-256 hash
- certificates, and signed webhooks when an anchor lands
- the
Idempotency-Keyheader, and per-key rate limits
Each proof is anchored on Polygon in a public transaction, signed with your own Polygon key. If you'd rather keep the key off the API host, you can use a separate signer box. API keys are created with the server's command-line tool.
Tagged releases each publish a Docker image at ghcr.io/fulcrum-enterprises/proofledger-community, built for amd64 and arm64. The repository includes a docker compose file that pulls it.
The engine is the same as the hosted service. It hashes bytes with SHA-256, anchors the hash and returns a proof. There's no pipeline for specific file types, and the file never has to reach the server. Your client computes the hash and only the hash is sent.
What you're signing up to run
Self-hosting a proof server means looking after a few concrete things.
A wallet with a little POL in it. POL is the token that pays gas, the fee for each Polygon transaction. If the wallet runs dry, anchoring stops until you top it up.
A key to guard. The Polygon key signs every anchor transaction. If it leaks, someone else can spend your gas. Moving signing onto a separate signer box keeps the key off the machine that faces the API.
One SQLite file to back up. Your proof records, API keys and webhook registrations all live in that database. The anchors themselves are on Polygon and can't be lost. The server's record of which proof is which, and the certificate pages built from it, can be lost if you have no backup.
A server that stays reachable. Certificate pages and the public verify endpoint only work while your server is up. If someone you sent a certificate link to opens it while the server is down, the page doesn't load.
That last point is why bundles matter. A bundle you've handed out still verifies when your server is unreachable, as the next section shows.
Verifying a proof yourself
A proof is only useful if the person relying on it can check it without asking whoever issued it. Community and proofledger.io follow the same verification path, because Community writes the same transaction shape as the hosted service.
Get the bundle. Every proof has one. On your own server it's at the same path as on proofledger.io:
curl -H "Authorization: Bearer sk_..." \
https://your-host.example/api/v1/proof/<id>/bundleThe bundle holds the hash, the chain, the transaction id and the anchor time. Bundles also arrive inside every anchored webhook payload, so a system that listens for webhooks can store one per proof without any extra calls.
Check the file against the bundle, offline. The verify-proof package is on PyPI:
pip install verify-proofIt compares the file with the proof bundle on the checker's own machine. It makes no network call and doesn't contact your server or ProofLedger. Because Community bundles use the same format and transaction shape as hosted bundles, verify-proof handles both the same way.
Look up the transaction. Anyone can find the Polygon transaction id from the bundle on a block explorer. That confirms the hash was written to a public ledger at the anchor time, and no single operator controls that ledger.
Use the public verify endpoint for quick checks. It needs no key and takes a SHA-256 hash:
curl "https://your-host.example/api/v1/verify?hash=<64 hex characters>"A SHA-256 hash is 256 bits, written as 64 hexadecimal characters. On proofledger.io the same call goes to https://proofledger.io/api/v1/verify?hash=....
Check an AI agent's run. Agent run receipts in the verify-proof package chain each step of an agent's run as salted fingerprints and anchor the chain head as one ordinary proof. The receipt then verifies offline with verify-proof receipt verify. It works the same way whichever server anchored the proof.
Every path proves the same thing: this exact file existed no later than the anchor and hasn't changed since. It doesn't prove who made the file, when a photo was taken or who owns the rights.
What you hold under each model
With OpenTimestamps, you hold .ots files and rely on Bitcoin. Under this model, anyone checking your proof has to run the tooling, and nothing you can send them is a page they can simply open.
With ProofLedger Community, you hold a server, a key, a wallet and one database file. You also hold a bundle for each proof, which verifies without you. While the server is up, a non-technical recipient can follow a certificate link and a developer can call the verify endpoint. After it goes down, the bundles and the Polygon transactions are still there.
With the hosted service at proofledger.io, you hold the same bundles and the same Polygon transactions. ProofLedger runs the server.
When hosted makes sense
The hosted service is a separate product from Community, and it's not open source. Only Community is. It runs the same proof core and adds the parts that sit around a self-hosted server:
- A managed signer. No Polygon key for you to guard and no wallet to keep topped up with POL.
- Backups. You don't maintain the SQLite file.
- Partner branding. A software company that records proofs for its own users can have its product name on the certificate and verify page, worded exactly "Recorded through \<Partner\> · Anchored by ProofLedger". Each name is approved by hand after an impersonation check.
- Integrations:
- a GitHub App that anchors every release file, and a GitHub Action for release workflows - an n8n community node - Zapier and Make integrations, available by invite link - an MCP server and a Claude Code plugin for coding agents
- Support.
Moving between the two doesn't lock you in either direction. The API shapes match, so client code written against one runs against the other with a different base URL and key. The bundles share one format, so a proof from either one verifies the same way.
If you want to run the server yourself, start from the Community repository. If you'd rather have someone else hold the key and keep the verify pages up, plans for the hosted service are at proofledger.io/pricing.html. Builders adding proof of existence to their own product can find the quickstart at proofledger.io/platforms.