Question 1

I’m new to all of this. What problem does KaspaSeal actually solve?

Accepted Answer

AI agents now take actions with real consequences — they move money, send emails, change records. The only evidence of what they did is usually a log file… and log files can be edited, backdated, or quietly 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 a customer, auditor, or counterparty asks “prove what your agent did,” you point at math instead of asking them to trust you. The honest limit: KaspaSeal records what your integration declares, so it can only speak to the actions you instrument — absence of a record is not proof that nothing happened.

Question 2

What exactly goes on the chain? Is my data public?

Accepted Answer

69 bytes per proof: a protocol marker, the action type, a SHA-256 fingerprint of the payload, and a parent transaction reference (normally the previous proof in the trail). Your payload —the order details, the email contents— is never written to the chain, and anyone holding the original can later recompute the fingerprint and confirm it matches the on-chain record bit for bit. Two honest qualifications, because a fingerprint is not a vault. If a payload is low-entropy and guessable — {"approved": true}, or a form from a known template — someone can test guesses against the hash until one matches; that is exactly what salted mode above is for. And the record is public by design: the action type, the parent link, the spent outputs (an address, for ordinary single-key anchors), and the block time are all visible on-chain; the signer’s key and signature travel in the off-chain proof bundle. What stays private is the content. (One nuance: 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.)

Question 3

Can anchored data be erased? What about GDPR?

Accepted Answer

Partly — and the honest boundary matters here. Nothing readable goes on-chain to begin with; only the fingerprint does. Optional salted mode goes further: KaspaSeal wraps your payload in an envelope carrying 32 bytes of random salt and anchors the fingerprint of that. Destroy the salt — and any other copy of the envelope, including your counterparties’ — and the on-chain fingerprint becomes computationally unlinkable to the content: even someone who later obtains the original data cannot confirm or deny it matches the anchor. That is the construction French regulator CNIL described as coming close to erasure. What it is not: a GDPR compliance button. The spent outputs (an address, for ordinary single-key anchors), the block time, the action type, and the record’s position in the chain stay on-chain and pseudonymous — the signer’s key lives in the off-chain proof bundle — and erasing your local copy is a best-effort database delete, not physical destruction of the medium. Useful tool, not legal advice.

Question 4

What is Kaspa, and why build on it?

Accepted Answer

Kaspa is a proof-of-work network built on a BlockDAG — its GhostDAG protocol lets many blocks coexist in parallel instead of one chain tip at a time. It targets about 10 blocks per second, so an anchor doesn’t lag the action it records: a transaction is typically included within a second or two. Worth being precise about which network, though — 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, which is where a future managed service would run, not the network behind this page. (And how deep you require before calling something final is a policy you choose, not a moment that arrives — our own verify page defaults to a conservative confirmation depth.) By comparison, Bitcoin-based timestamping batches hashes into roughly hourly commitments. To be fair: some modern networks and L2s are also fast and cheap — raw speed isn’t the moat, per-action identity-bound chaining is. And the honest coupling: KaspaSeal is Kaspa-only by design; if Kaspa fails, KaspaSeal fails. We accept that trade for speed, cost, and a verification story with no servers of ours in it.

Question 5

What does a proof actually prove — legally and practically?

Accepted Answer

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’s why the pattern is INTENT before, RESULT after, chained — and why serious deployments pair proofs with tool-side receipts. On admissibility: courts already accept ordinary electronic business records (in the US via FRE 803(6), with self-authentication routes in FRE 902(13)–(14)), so the honest claim isn’t “logs are worthless in court” — it’s weight. An independently anchored record is far harder to challenge as altered or backdated, and some jurisdictions now go further: Vermont’s 12 V.S.A. § 1913 presumes blockchain-recorded facts authentic, and Arizona recognized blockchain-secured records in statute back in 2017. We’d rather tell you the honest boundary than sell you a magic notary.

Question 6

What stops someone deleting an anchor from the middle of a trail?

Accepted Answer

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 doesn’t erase it — it leaves a hole a verifier walks straight into. Deletion becomes detectable, which is usually the property that matters in a dispute. 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 can’t be constructed within that lineage. Three things to be clear about. 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. And it constrains the shape of the record, never the world: it still cannot tell you the agent’s action actually executed. Covenant mode is off unless you turn it on, and it runs on TN10 today.

Question 7

What happens if KaspaSeal the company disappears?

Accepted Answer

Your proofs don’t depend on our servers. They sit on a public chain we don’t control, and signature checking is plain secp256k1 + SHA-256 — verifiable as long as that math stands. 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, because it matters: 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 isn’t ours to guarantee, and the verify page becomes self-hostable when its Apache-2.0 source release lands — that release is staged. The design goal throughout is that trusting KaspaSeal is never a requirement for verifying a KaspaSeal proof.

Question 8

Is anyone actually required to keep records like this?

Accepted Answer

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 doesn’t trust you can check independently. (Not legal advice — whether any of it applies to you is your counsel’s call.)

Question 9

Why not OpenTimestamps, a timestamp authority, or a transparency log?

Accepted Answer

All real tools — different jobs. OpenTimestamps anchors batched hashes to Bitcoin (free!) but commits roughly hourly and proves only existence: no identity binding, no per-action chaining. RFC 3161 timestamp authorities answer in seconds but are centralized — compromise the authority and every stamp it ever issued is in doubt. C2PA signs media provenance, but its metadata can be stripped and it isn’t built for action streams. Transparency logs (Certificate Transparency, Sigstore’s Rekor) are append-only but operator-run; monitors catch misbehavior after the fact. Ledger databases are tamper-evident inside one trust domain. KaspaSeal’s specific shape: per-action, identity-signed, parent-chained records, each anchored individually to a public proof-of-work DAG within seconds. If hourly batched existence proofs are all you need, OpenTimestamps is genuinely great — we’re for when each action and its order must stand on its own.

Question 10

Is this demo the real thing? And what does it cost?

Accepted Answer

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 (a demo anchor costs roughly 0.002 tKAS). One honest caveat follows from that: test networks are periodically retired — Kaspa has replaced older testnets before — 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.