KASPASEAL
Your agents, on the record.
KaspaSeal gives AI agents tamper-proof audit trails: every action is declared before it
runs and sealed after — 69 bytes anchored to the Kaspa BlockDAG, verifiable by anyone in
seconds. No platform to trust. Just math and a public chain.
Logs are just files. Files get edited.
AI agents now act with real consequences — they issue refunds, move records, send
messages, sign things. When something goes wrong (or someone claims it did), the only
evidence is usually a log file owned by whoever ran the agent. Logs can be rewritten,
backdated, or deleted, and "trust our database" is a weak answer to an auditor, a
counterparty, or a courtroom challenge.
KaspaSeal's answer is mechanical, not promissory: at the moment an agent acts, a 69-byte
fingerprint of that action is written to a public blockchain that nobody — including us —
can quietly edit afterwards. The action's contents stay private; the fact of it, its
timing, its author, and its place in the sequence become part of an append-only public
record.
The protocol of distrust
-
Declare. Before a tool runs, the agent anchors an INTENT: a SHA-256 of
the full call envelope, signed by its identity. The payload stays private — only the
hash and the signature touch the chain.
-
Seal. After execution, a RESULT anchors with a parent_txid pointing at
its intent. Disputes and counterparty attestations chain the same way — an append-only
trail nobody can quietly edit.
-
Verify. Anyone with the txid checks the record on the public BlockDAG —
no account, no API key, no trust in KaspaSeal itself. Open-source verify page; bring
your own node if you like.
Honest scope: a proof shows what the agent declared and when — pair it with
tool-side receipts when you need execution guarantees.
Fair questions
I’m new to all of this. What problem does KaspaSeal actually solve?
AI agents now take actions with real consequences — they move money, send emails, change
records. The only evidence is usually a log file, and log files can be edited, backdated,
or deleted by whoever runs the system. KaspaSeal writes a tiny fingerprint of every agent
action onto a public blockchain as it happens; rewriting it afterwards would mean
out-mining a public proof-of-work network. When someone asks you to prove what your agent
did, you point at math instead of asking them to trust you.
What exactly goes on the chain? Is my data public?
69 bytes per proof: a protocol marker, the action type, a SHA-256 fingerprint of the
payload, and a pointer to the parent proof. The payload itself never touches the chain and
cannot be reconstructed from the fingerprint. Anyone holding the original payload can
recompute the fingerprint and confirm it matches the on-chain record. This hosted demo
receives your payload to anchor it server-side; run the open-source SDK yourself and only
the 32-byte fingerprint ever leaves your process.
What is Kaspa, and why build on it?
Kaspa is a proof-of-work network built on a BlockDAG; its GhostDAG protocol lets many
blocks coexist in parallel. Since the May 2025 Crescendo hard-fork, mainnet produces about
10 blocks per second, so a transaction typically reaches practical finality within seconds
for fees measured in thousandths of a cent. Raw speed is not the moat — per-action,
identity-bound chaining is. KaspaSeal is Kaspa-only by design: if Kaspa fails, KaspaSeal
fails.
What does a proof actually prove — legally and practically?
It proves that this exact content existed at this time and was signed by this identity,
and that the trail’s order was declared as it happened. It does not by itself prove the
action executed in the real world — an agent could declare an intent and fail to act. That
is why the pattern is INTENT before, RESULT after, chained, and why serious deployments
pair proofs with tool-side receipts. Courts already accept electronic business records; an
independently anchored record is far harder to challenge as altered or backdated.
What happens if KaspaSeal the company disappears?
Your proofs outlive us. They sit on a public chain we do not control, the verifier is
open-source (Apache-2.0) and self-hostable against your own Kaspa node, and signature
checking is plain secp256k1 + SHA-256. Trusting KaspaSeal is never a requirement for
verifying a KaspaSeal proof.
Is anyone actually required to keep records like this?
Increasingly, yes. The EU AI Act requires high-risk AI systems to log events automatically
(Article 12), phasing in from August 2026. The SEC’s amended Rule 17a-4 expects WORM
storage or a complete time-stamped audit trail, and the EU’s DORA mandates tamper-proof,
long-retained audit logs. NIST’s AI Risk Management Framework points the same way. None
name blockchains — they name properties a public-chain anchor has natively.
Why not OpenTimestamps, a timestamp authority, or a transparency log?
All real tools for different jobs. OpenTimestamps anchors batched hashes to Bitcoin but
commits roughly hourly and proves only existence — no identity binding, no per-action
chaining. RFC 3161 timestamp authorities are centralized. C2PA signs media provenance but
its metadata can be stripped. Transparency logs are append-only but operator-run.
KaspaSeal’s shape: per-action, identity-signed, parent-chained records, each anchored
individually to a public proof-of-work DAG within seconds.
Is this demo the real thing? What does production cost?
The demo runs on Kaspa’s TN10 test network: the transactions, signatures, and verification
are fully real; the tokens spent on fees are worthless by design. Test networks are
periodically retired, so demo proofs share the testnet’s lifespan — the demo shows the
mechanism while long-term durability is a mainnet property. v1 ships on TN10 with mainnet
on the roadmap. On-chain cost per proof is a fraction of a cent.
Learn more
Demo runs on the Kaspa TN10 test network — the proofs are real, the tokens are worthless.
Verification is open-source (Apache-2.0) and works without KaspaSeal's servers. © 2026
KaspaSeal™ — an independent project, not affiliated with or endorsed by the Kaspa project.