DMT Receipts
Related Servers
Alternatives to DMT Receipts
No user-submitted related servers found.
Related Servers
- AlicenseAqualityBmaintenanceStamp, upgrade, and verify Bitcoin timestamps via AI agents using the OpenTimestamps protocol. No API keys required.9140 npm3MIT
- AlicenseAqualityBmaintenanceAppend-only evidence receipts for AI records: seal, verify, cite, chain-check, anchor status. A seal proves a record existed at a time, not that its contents are true. Five tools over stdio with npx -y apex-psi-mcp — no account, no key, verification free forever.5316 npm1MIT

Orphographofficial
AlicenseNot gradedqualityAmaintenanceEnables AI agents and MCP hosts to anchor file hashes to Bitcoin via OpenTimestamps and verify proofs, ensuring files existed before a given time with privacy-preserving local hashing.MIT- AlicenseAqualityCmaintenanceEnables AI agents to certify their creations with verifiable, timestamped proof anchored to Bitcoin, and to verify certificates.3MIT
- AlicenseNot gradedqualityDmaintenanceEnables AI agents to timestamp files in Bitcoin by submitting only their SHA-256 hashes, paying per hash in USDC via x402, and retrieving or verifying OpenTimestamps .ots proofs without an account or API key.MIT

Proof-100 MCP Serverofficial
AlicenseNot gradedqualityCmaintenanceEnables AI agents to timestamp SHA-256 fingerprints or short text on the BitcoinZ blockchain via shielded transactions, returning transaction IDs and viewing keys, and to check proof balance and deposit address.MIT
TDQS
Scored across 2 tools
The two tools are cleanly complementary: stamp_memory creates a receipt, verify_receipt checks one. There is no overlap and the descriptions make the create/verify split explicit.
Both names follow a strict verb_noun snake_case pattern (stamp_memory, verify_receipt). The convention is predictable and directly reflects each tool's action and target.
Two tools is thin in absolute terms, but the server's scope is deliberately narrow — stamp a memory and verify a receipt — and each tool clearly earns its place. Nothing superfluous is present.
The basic stamp/verify lifecycle is covered, but verify_receipt only checks header/digest consistency and explicitly does not validate calendar operations or Bitcoin inclusion, leaving agents to invoke external ots upgrade/verify for the real proof. No status lookup or receipt introspection is offered, though the stateless design limits what could be added.