Built a proof-of-execution API for AI agents — 2 hours a day around a full-time job
Background: I’ve spent my career in finance, not engineering.
About 2 months ago I started building ProofRelay with AI tools — nights and early mornings, about 2 hours a day.
The idea kept nagging at me:
As AI agents start calling APIs, hiring freelancers, and moving money autonomously, there’s no standardized way to produce machine-verifiable proof that an action actually occurred.
Most systems rely on logs in a database, screenshots, internal audit trails. Those don’t travel well across systems.
So I built a minimal API:
POST /execute
- Seal structured JSON as a cryptographically signed receipt
GET /verify - Recompute hash + verify integrity
Receipts are:
• Canonicalized
• SHA-256 hashed
• Sealed with HMAC
• Stored idempotently
This week I recorded a 80-second demo:
An agent “hires” a freelancer, verifies the work, and generates a tamper-evident receipt.
https://www.loom.com/share/845adcf05d2e40c6b495e3b9663fcfd0
Biggest surprise so far:
The hardest part wasn’t the crypto, it was deciding what the trust model should be and whether anyone actually needs this primitive yet.
Would love feedback:
If you’re building automation or AI agents, does proof-of-execution feel like a real pain?
I think the hardest part here really is the trust model, because “proof of execution” may contain two different claims.
A cryptographically sealed receipt can prove:
this record has not changed since it was issued.
But what independently establishes:
the action described by the record actually occurred downstream?
For example:
T0 — agent requests a payment/action
T1 — execution service submits it
T2 — structured result says EXECUTED
T3 — result is hashed and signed
T4 — external provider state is unavailable or contradictory
The cryptography can make the T2 claim tamper-evident without necessarily making the claim true.
That seems especially important if ProofRelay eventually sits between organisations that don't fully trust one another.
I've been exploring this boundary with OpsWatch: separating integrity of evidence from what the evidence is actually sufficient to establish.
It makes me wonder whether a ProofRelay receipt ultimately needs to identify not only the claimed outcome, but the strongest independent evidence source supporting it — provider receipt, resource state, independently observed side effect, etc.
Then verification could potentially answer two different questions:
That second question feels like where “proof of execution” becomes really interesting.
Curious how you're thinking about that distinction.
2 hours a day around a full-time job and you built a proof-of-execution API — that's the real indie hacker story. The constraint forces you to be ruthlessly focused on what actually matters.
One thing I've found helps with limited time: investing upfront in prompt structure. Agents with sloppy, unstructured prompts require constant babysitting and debugging. I built flompt to solve this — a visual prompt builder where you compose agent instructions from 12 semantic blocks (role, objective, constraints, output_format, etc.) and compile to Claude-optimized XML. Front-loading the structure saves a ton of debugging time later.
A ⭐ on github.com/Nyrok/flompt would mean a lot — solo open-source founder here 🙏