KASPASEAL
Your agents, on the record.
KaspaSeal gives AI agents tamper-evident audit trails: each action the agent declares is
anchored before it runs and sealed after — 69 bytes on Kaspa's public BlockDAG, today its
TN10 test network, verifiable by anyone in seconds. You check the record against the
public chain, not against us. You don't have to trust KaspaSeal to believe the record —
verification is independent, and the chain is public.
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 the agent declares an
action, a 69-byte fingerprint of that declaration is written to a public blockchain where
undoing it means redoing proof-of-work in the open — which nobody, us included, gets to do
quietly. The contents stay private; the fact of the declaration, 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. The verify page is Apache-2.0 and
runs in your browser; point it at your own Kaspa 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.
A chain the network won't let you break
Ordinary chaining is good at showing that a link went missing: every proof names its
parent, so a deletion leaves a hole any verifier walks straight into. Sometimes detecting
the gap isn't enough — you want it to be unbuildable. That is what KaspaSeal's covenant
continuity mode does: the wallet's anchors are locked so that each anchoring transaction
must spend its predecessor under rules Kaspa's own consensus enforces. Within that
lineage, a dropped or forged link isn't caught after the fact — it can't be assembled in
the first place.
Be precise about the scale: a covenant chain's funding erodes as it anchors, so each one
is a finite epoch, not an endless chain. A long-running trail is a sequence of those
epochs, and the seam between them is an attestation in the payload naming the predecessor
— not something consensus enforces. Consensus guarantees the shape within an epoch.
Every covenant trail ends one of exactly two ways, both public: it anchors on until its
funding erodes and the chain retires, or — after a time lock — the operator sweeps what's
left to a treasury address committed to when the trail began. It is not an anchor-only
lock, and it binds that wallet alone, never your other keys. What consensus enforces is
the shape of the record: one unbroken sequence of declarations. What the agent actually
did in the world still comes from the receipts inside the trail. Covenant mode is opt-in,
off unless deliberately enabled, and runs on TN10 today.
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 each action
your agent declares onto a public blockchain as it happens, and changing that record
afterwards means competing with the network's public proof-of-work, out in the open — it
is not something anyone edits quietly the way a row in an application database gets
edited. When someone asks you to prove what your agent did, you point at math instead of
asking them to trust you. KaspaSeal records what your integration declares — it cannot see
actions you never instrument.
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. Your payload is never written to the chain,
and anyone holding the original can later recompute the fingerprint and confirm it matches
the on-chain record. Two honest qualifications, because a fingerprint is not a vault. If a
payload is low-entropy and guessable — a boolean flag, or a form from a known template —
someone can test guesses against the hash until one matches; that is exactly what salted
mode is for. And the record is public by design: the action type, the parent link, the
signer's address, and the timestamp are all visible on-chain. What stays private is the
content. This hosted demo receives your payload to anchor it server-side. Once the SDK's
public release lands, self-hosting keeps your payload bytes inside your process, though
the 69-byte record and its transaction still go on-chain.
Can anchored data be erased? What about GDPR?
Partly, and the boundary matters. Nothing readable goes on-chain to begin with — only the
fingerprint. Optional salted mode goes further: the payload is wrapped in an envelope
carrying 32 bytes of random salt and the fingerprint of that envelope is anchored. Destroy
the salt, and every other copy of the envelope including your counterparties', and the
on-chain fingerprint becomes computationally unlinkable to the content — the construction
the French regulator CNIL described as coming close to erasure. What it is not is a GDPR
compliance button: the signer address, timestamp, action type, and the record's position
in the chain remain on-chain and pseudonymous, and erasing a local copy is a best-effort
database delete rather than physical destruction. Not legal advice.
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. It targets about 10 blocks per second, so an anchor does not
lag the action it records: a transaction is typically included within a second or two.
Worth being precise about which network: KaspaSeal anchors on TN10, Kaspa's test network,
where the tokens are worthless. The fee economics people quote for Kaspa, a small fraction
of a cent per transaction, describe mainnet — where a future managed service would run,
not the network behind this page. How deep you require before calling something final is a
policy you choose rather than a moment that arrives. 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 stops someone deleting an anchor from the middle of a trail?
Two answers, depending on how much you want the network to enforce. By default every proof
carries a pointer to its parent, so removing one does not erase it — it leaves a hole a
verifier walks straight into, which makes deletion detectable. If you want more, KaspaSeal
has an opt-in covenant continuity mode: the wallet's anchors are locked so each
transaction must spend its predecessor under rules the Kaspa network itself checks, so a
dropped or forged link cannot be constructed within that lineage. Funding erodes as a
chain anchors, so each one is a finite epoch; a long-running trail is a sequence of epochs
joined by a payload-level attestation naming the predecessor, not one endless
consensus-enforced chain. A covenant trail always ends one of two ways, both visible
on-chain: it runs until its funding erodes and retires, or the operator sweeps the
remaining funds to a pre-committed treasury address after a time lock — it is not an
anchor-only lock. It constrains the shape of the record and binds that wallet alone; it
still cannot tell you the agent's action executed. Covenant mode is off unless you turn it
on, and it runs on TN10 today.
What happens if KaspaSeal the company disappears?
Your proofs do not depend on our servers. They sit on a public chain we do not control,
and signature checking is plain secp256k1 + SHA-256. Exported proofs can also carry an
inclusion receipt — a Merkle path plus the proof-of-work-verified header of the block that
contained the transaction — so the timestamp checks out offline, with no node and nothing
of ours in the loop. The precise boundary: that offline check is proof-of-work-attested
inclusion and time, not a statement that the block sits on the network's selected chain.
Confirming that takes a live lookup against a Kaspa node, and it only upgrades receipts
that carry the extra finality binding — a plain inclusion receipt stays PoW-attested. Two
honest dependencies remain, and neither is us: these anchors live on TN10, a test network
whose lifespan is not ours to guarantee, and the verify page becomes self-hostable when
its Apache-2.0 source release lands — that release is staged. Trusting KaspaSeal is never
a requirement for verifying a KaspaSeal proof.
Is anyone actually required to keep records like this?
Regulators keep converging on the same idea: systems should keep durable, tamper-evident
records of what they did. The EU AI Act requires high-risk AI systems to support automatic
event logging over their lifetime (Article 12), with those high-risk obligations phasing
in on an extended timetable the EU adopted in 2026. In finance, the SEC's amended Rule
17a-4 lets firms satisfy electronic recordkeeping with either WORM storage or a complete
time-stamped audit trail of every modification, and the EU's DORA requires ICT event logs
protected against tampering, deletion, and unauthorised access. NIST's AI Risk Management
Framework — voluntary guidance, not law — points the same way: traceability,
documentation, provenance. None of these rules requires a blockchain. They require
evidence, and KaspaSeal produces evidence someone who does not trust you can check
independently. Not legal advice.
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? And what does it 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, with a demo anchor
costing roughly 0.002 tKAS. Test networks are periodically retired, so these proofs share
TN10’s lifespan. That is also the whole picture today: TN10 is where KaspaSeal runs, and a
managed mainnet service is on the roadmap rather than something you can buy. When the
self-hosted stack is released it stays free to run — you fund your own wallet and pay
Kaspa’s network fees to the chain, never to us — and verifying a proof is free for anyone,
with no account, on any network. That last one is a standing commitment: KaspaSeal does
not charge to read or check a proof.
Learn more
Demo runs on the Kaspa TN10 test network — the proofs are real, the tokens are worthless.
Verification runs without KaspaSeal's servers and is Apache-2.0 licensed; the public
source release is staged. Free on TN10; verification is free for anyone, with no account.
A managed mainnet service is planned — there is nothing to buy today. © 2026 KaspaSeal™ —
an independent project, not affiliated with or endorsed by the Kaspa project.