NotaryOS creates tamper-evident, Ed25519-signed receipts for AI agent actions. Each receipt is SHA-256 hash-chained to the previous one, so modifying any entry breaks the chain — pinpointing the exact tampered receipt.
The feature I'm most curious about HN's take on: counterfactual receipts. These prove an agent considered actions {A, B, C}, had the capability to execute all three, and actively rejected B and C at time T. Uses a commit-reveal protocol so the decision is locked before the outcome is known.
Example: agent receives a "delete all user data" instruction, evaluates it against policy constraints, and refuses. The receipt cryptographically proves the decision surface was bounded — verifiable evidence of restraint, not just absence of evidence of harm.
Try it:
pip install notaryos # v2.0
npm install notaryos # v2.0
curl -s https://api.agenttownsquare.com/v1/notary/status | python3 -m json.tool
Some context: I'm not a programmer by background — I'm an infrastructure/ops founder who was building a protocol for secure multi-agent communication and realized I'd accidentally built something else entirely. NotaryOS started as a test of that protocol engine in a real deployment. It worked. 350+ unique clones on GitHub with zero stars or comments, which I take to mean the tool is useful but nobody knows it exists. Posting here to change that.
This is a beta — payments aren't wired up yet, free tier is open. An honest open question: how do you prove the counterfactual set is complete? If an agent omits option D from its decision surface, the receipt proves it didn't choose D — not that D wasn't possible. I think this is a fundamental bound. Would value HN's thoughts.
harris-012•53m ago
I come from automotive B2B operations, not software engineering. I was building a distributed communication protocol for AI agents — zero-trust, X.509 certificates, sub-millisecond message passing — basically trying to solve "how do agents talk to each other securely." Along the way I realized the protocol primitives I'd built (hash chaining, Ed25519 signing, capability tokens) were exactly what you'd need for cryptographic accountability, not just communication.
NotaryOS is the first app built on that protocol engine. The engine handles the hard stuff — the crypto, the chain verification, the performance (178+ receipts/sec, 4.7ms P50 on a 4-vCPU droplet). NotaryOS is the developer-facing layer on top.
Design decisions worth calling out:
- Ed25519 over ECDSA: faster verification, smaller keys, no nonce-reuse footgun - Hash chain is per-agent, not global: no consensus overhead, offline-verifiable via SDKs - Payloads are never stored, only SHA-256 hashes: privacy-preserving by default - Counterfactual commit-reveal: agent commits a hash of its decision before the outcome is known, then reveals after the window closes. Anyone can verify the reveal matches
The counterfactual receipt design came from working with trading systems where you need to prove a bot didn't execute when conditions were met. I deployed this and have had it running in production. I've started seeing the term "counterfactual receipts" appear in other projects recently — as far as I'm aware, NotaryOS is the first deployed system implementing them.
Integrations for LangChain, CrewAI, AutoGen — three lines of code. Auto-receipting wrapper that instruments every public method on an agent class. Self-hosting via Docker Compose for air-gapped environments all coming soon!
Happy to go deep on the security, the receipt spec, or the protocol engine underneath.