One-time migration · not a live bridge

Seal the list once. Kaspa enforces every claim.

Freeze one agreed holder list, seal its fingerprint into a covenant, then let every included wallet receive its exact KCC-20 balance one time.

— / 5TN10 transactions confirmed
0admin keys after handoff
1trust event: the snapshot
1×claim per wallet, enforced in script

TN10 run used one synthetic holder · KCC-20 is a draft standard

Local engine

New here? What this page shows, in plain words

Think of it as a sealed coupon book. Someone writes down exactly who holds how much of an old token at one agreed moment, and that list is sealed into the new token's identity on the day it is born. After that, nobody can edit the list, not even the people who made it: no balance can be changed, no payout redirected, and every line in the book can be redeemed exactly once. The rules are enforced by Kaspa itself, the same way it stops a coin being spent twice.

Watch the five steps in the panel below to see how the sealed list becomes a claimable token.
Try one committed wallet further down: pick a sample wallet and press claim. It runs the real Kaspa rule engine on this computer, with play money.
Check the receipts at the bottom: the same five steps were also run for real on Kaspa's test network, and each transaction is publicly checkable.

Snapshot: The frozen list of who held how much of the old token at one chosen moment.
Checkpoint / DAA score: The exact moment on the Kaspa network where the list was frozen. Like a page number in the chain's history.
Merkle root: One short fingerprint that summarizes the whole list. Change any single entry and the fingerprint no longer matches.
Covenant: A Kaspa coin with rules attached. The network itself refuses any spend that breaks the rules, so no operator is needed.
Claim: A holder proving their line in the sealed list and receiving that exact amount of the new token, one time only.
Reserve: The full new-token supply, created once and held by the covenant until claims release it piece by piece.
Manifest: The full human-readable list that the fingerprint summarizes. Published so anyone can recompute and check it.
MuHash: A checksum independent bookkeepers can compute to confirm they all reconstructed the same starting list.
TN10: Kaspa's public test network. Real network, worthless test coins, which makes it the honest place to prove mechanics.
Simulation vs TN10: Buttons on this page run on this computer only. The receipts section links to the separate run on the public test network.

The one-time snapshot model

Trust the launch snapshot once. Trust Kaspa for every claim after.

Independent parties agree on one historical KRC-20 state, its Merkle root is fixed at covenant genesis, and the covenant then enforces the committed claims without a permanent bridge operator.

One-time commitment · no admin key

Choose one checkpoint

Stop the historical replay at one exact KRC-20 DAA score.

Loading checkpoint…

Verify every balance

Independent indexers must reproduce the same owners, amounts, and MuHash.

Supplied · not verified

Seal the root

The holder set becomes a Merkle root committed into the launch identity.

Waiting for local setup…

Prove and claim once

A holder supplies a Merkle branch; success retires that entitlement.

0 / 0 claimed locally

Receive native token state

The exact amount is released from the covenant-controlled KCC-20 reserve.

Reserve split · no recurring mint

Plain English

People and indexers must get the starting list right. Once that list is sealed, code rather than a committee prevents changing balances, redirecting payouts, or claiming the same entry twice.

Before launch · off-chain

Was the KRC snapshot correct?

Independent KRC indexers must replay the same checkpoint and reproduce the complete balance set, MuHash, manifest, and root.

Not verified by this lab

After launch · covenant

Can a balance be claimed twice?

No. The exact owner and amount must match the current root. A successful full claim replaces that leaf and advances the root.

Enforced by the local engine

Legacy side · unchanged

What happens to the old KRC-20?

It still exists and remains transferable. This is an optional claimable fork, not a burn, lock, or mechanism that invalidates KRC-20.

Economic value is social consensus

Protocol reality: KIP-17/KIP-20 covenant primitives are active. KCC-1, KCC-2, and KCC-20 remain Draft conventions, so this artifact is KCC20-shaped rather than final wallet-compatible KCC-20. KCC drafts KCC-20

Holder walkthrough

Run a claim on the real Kaspa engine

Pick a sample wallet. The local engine will prove its leaf, force the exact committed payout, retire the entitlement, and advance the root. Nothing leaves this computer.

Full claim only

Wallet from the supplied snapshot

In production a wallet would discover its own entry and fetch a fresh Merkle proof. Never enter a seed phrase here.

Loading a claimable entry from the local engine…

Snapshot total — base units committed

Remaining — base units claimable

Claims — leaves retired once

Holders — snapshot entries

Initial root / genesis commitment —

Current root / in-memory claim state —

Claim progress0 / 0

All supplied entries

Claimable entries from the snapshot

These balances were accepted as input, not independently checked against KRC history. Each successful local claim retires one leaf.

Engine evidence

Local execution receipts

Each receipt records a locally accepted fixture transition. The separate real TN10 run used a synthetic one-holder snapshot; its public transaction IDs appear below.

Evidence ladder

What is real now, and what still has to happen

A passing local script is one layer of evidence, not proof of an entire migration.

Question	Required evidence	Status here
Is the historical KRC holder set correct?	Independent indexers reproduce the checkpoint, MuHash, and full list.	Not verified
Are the root and manifest deterministic?	Canonicalization and hash reproduction.	Proven locally
Are exact one-time claims enforced?	Real TxScriptEngine execution plus replay and tamper tests.	Proven locally
Can Kascov audit the KCC side?	Acceptance-order indexing, covenant-ID and reveal verification, then exact-program state replay.	Observer ready · pin needed
Would these transactions enter TN10?	Wallet funding, RPC submission, mempool admission, confirmation, and a claimant-authorized downstream spend.	Not tested
Is the token final KCC-compatible?	Final KCC-1 ABI plus wallet, indexer, and marketplace interoperability.	Draft only
Did economic value leave KRC-20?	Community, marketplace, and exchange consensus.	Not decided by code

Detailed engine guarantees and limitations

Proven by this local run

Still outside this run

TN10 status

Reading TN10 receipts…

All five transaction shapes already pass the local Kaspa engine. The smallest honest network proof is this complete public chain of custody.

5 / 5 local engine Checking TN10…

Token genesisCreate the fixed-supply KCC-shaped token covenant.
Controller genesisCommit the snapshot root and controller state.
Reserve handoffMove the complete supply under covenant control.
Merkle claimProve one holder leaf and release its exact balance.
Recipient spendSpend or split the claimed native token UTXO.

Still not enough by itself: Those transactions prove the covenant mechanics on TN10. Kascov can observe their accepted lineage, but it still needs an exact kasmelt program pin for KCC state replay, and it is not a KRC balance indexer. Calling this a real KRC migration also requires at least two independent KRC indexers to reproduce the same checkpoint, MuHash, complete holder list, manifest, and Merkle root.