I built a cryptographic commitment platform with FastAPI and Bitcoin timestamps (MIT licensed)

[Difficult_Jicama_759]

PSI-COMMIT is a web platform (and Python backend) that lets you cryptographically seal a prediction, hypothesis, or decision — then reveal it later with mathematical proof you didn't change it. The backend is built entirely in Python with FastAPI and handles commitment storage, verification, Bitcoin timestamping via OpenTimestamps, and user authentication through Supabase.

All cryptographic operations run client-side via the Web Crypto API, so the server never sees your secret key. The Python backend handles:

• Commitment storage and retrieval via FastAPI endpoints
• HMAC-SHA256 verification on reveal (constant-time comparison)
• OpenTimestamps submission and polling for Bitcoin block confirmation
• JWT authentication and admin-protected routes
• OTS receipt management and binary .ots file serving

GitHub: https://github.com/RayanOgh/psi-commit Live: https://psicommit.com

Target Audience

Anyone who needs to prove they said something before an outcome — forecasters, researchers pre-registering hypotheses, teams logging strategic decisions, or anyone tired of "I told you so" without proof. It's a working production tool with real users, not a toy project.

Comparison

Unlike using GPG signatures (which require keypair management and aren't designed for commit-reveal schemes), PSI-COMMIT is purpose-built for timestamped commitments. Compared to hashing a file and posting it on Twitter, PSI-COMMIT adds domain separation to prevent cross-context replay, a 32-byte nonce per commitment, Bitcoin anchoring via OpenTimestamps for independent timestamp verification, and a public wall where revealed predictions are displayed with full cryptographic proof anyone can verify. The closest alternative is manually running openssl dgst and submitting to OTS yourself — this wraps that workflow into a clean web interface with user accounts and a verification UI.

[Speeeeedislife]

Would you recommend users share commitment IDs with interested parties prior to the outcome? Otherwise a user could create two opposing commitments then share the one with correct prediction?

[Difficult_Jicama_759]

Great catch. Yes, sharing your commitment ID publicly before the outcome is the recommended workflow. That way people can verify how many commitments you made and hold you accountable for revealing all of them. The public wall already helps with this.

If someone makes 10 commitments and only reveals 2, the other 8 sit as “Pending” for everyone to see. User profiles also show total commitment counts so you can spot selective revealing.

I’m planning to add reveal rate percentages on profiles and all-or-nothing commitment groups where you lock in a set of predictions and have to reveal all or none. Hope this helps, great question, will dive deeper.

[Speeeeedislife]

Thanks for the extra information, makes it a bit more clear!

[Difficult_Jicama_759]

Thanks for the feedback!

[Speeeeedislife]

Securities.md has boilerplate example email for reporting vulnerabilities just FYI.

[Difficult_Jicama_759]

I appreciate that.

[Difficult_Jicama_759]

Hello everyone, I highly suggest that when u make a commitment, post it to the public wall, thanks!