A Permissionless Fixed-Supply Token Launcher for Kaspa

Kaspa Toccata brought covenants to mainnet — programmable constraints on how a UTXO can be spent. That opens the door to user-created tokens. But "open the door" and "walk through safely" are different problems. The upstream KCC20 reference implementation in SilverScript still sums signed token amounts without positive-overflow guards; a local VM probe on a recent snapshot accepted a negative allocation that inflated a balance from 1000 to 1400. A permissionless launcher needs to solve that class of bug at the contract level, not hope every integrator writes correct client code.

This article explains the planned architecture of Kaspa Forge Tokens — specifically the KF20-FIXED-v1 profile: a fixed-supply, one-time-genesis fungible token launcher built on Kaspa covenants. Tokens is not live. The P0 spec is frozen, and P1 contract/generator work exists in an isolated repository, but the independent consensus proof package, production deployment, and public infrastructure are not yet built. Everything described here is the design and its reasoning — not an invitation to use a deployed service.

What problem a token launcher solves

Creating a fungible token on a UTXO chain means answering four questions:

1. Where does the supply come from? Someone must commit the initial allocations into on-chain outputs, once. 2. How do transfers work? Each spend of a token-carrying UTXO must verify that the spender actually owns the tokens and that total supply is conserved. 3. What stops inflation? If an arithmetic bug or a loose script allows a transfer output to claim more tokens than its inputs held, the supply silently inflates. 4. Who holds the keys? If a central minter or platform key can mint arbitrary amounts, you've recreated a custodial token with a blockchain veneer.

On Kaspa, covenants (enabled by Toccata on mainnet) let a script validate the structure of its own successor outputs. That means a token UTXO can enforce conservation — *the outputs of my spending transaction must carry exactly my token amount* — at the consensus level, without trusting any off-chain actor.

The problem is that the enabling infrastructure is draft-stage. KCC-0001, KCC-0002, and KCC-0020 are in the main branch of the KCC repository but remain *Draft* status. KCC-0021 (metadata) is an open PR. The official KCC20 example in SilverScript was found to accept negative amounts without raising an error. A launcher that copies that pattern would inherit the same arithmetic hole. KF20-FIXED-v1 was designed from scratch to close it.

How the mechanism works

The state layout

Every KF20-FIXED-v1 token UTXO encodes a 77-byte positive-only state. The exact byte layout is frozen in the P0 spec — widths, field order, and encoding rules are compiler-native, meaning the SilverScript compiler generates the validation code directly from type definitions rather than relying on hand-written ABI checks.

The state holds the raw token amount, the 32-byte owner key (an x-only P2PK Schnorr pubkey), and internal classification bytes. All amounts are checked-positive: the contract rejects any successor whose token outputs would sum to a negative or zero value. This is the direct fix for the upstream KCC20 signed-amount bug — not a client-side check, but an on-chain arithmetic invariant enforced by the covenant script itself.

Direct genesis — no factory

A common pattern for on-chain token systems is a factory contract: a single authoritative program that spawns new token families. KF20-FIXED-v1 does not use one. Instead, the frozen generator produces a unique family directly:

1. User provides metadata, supply, decimals, allocations.
2. Generator builds the exact genesis transaction.
3. First funding outpoint + all bare token outputs → Covenant ID.
4. The Covenant ID is deterministic: anyone can recompute it from
   the same inputs and verify it matches what was broadcast.
5. KIP-20 (on-chain) checks that the new Covenant ID formula and
   authorized output set are valid for the declared template.

The Covenant ID *is* the token's identifier. There is no central registry, no admin key, and no minting authority embedded in the genesis outputs. After genesis, the only way to spend a token cell is to produce a valid successor that passes the covenant's conservation and authorization checks.

The reason direct genesis works without executing the token script during creation is subtle: KIP-20 verifies the *origin* of a new covenant — the formula that produces its ID and the set of authorized outputs — but does not run the program of an output being *created*. The positive-supply and metadata-consistency proofs happen in Kaspa Forge's own admission verifier against the exact chain bytes, not in the consensus engine. Anyone can deploy a malformed lookalike off-platform; it will produce a different Covenant ID and will not pass Kaspa Forge's history_verified classification.

Transfer conservation

Once a token cell exists, every spending transaction must satisfy the covenant:

• Authorization: the spender provides a valid Schnorr signature for the owner key in the state.
• Conservation: the sum of raw token amounts in all token outputs equals the sum in all token inputs. No partial burn, no hidden inflation.
• Shape enforcement: outputs must use the same profile, template hash, and owner mode. Cross-family inputs and unknown owner types are rejected.
• Fee envelope: the transaction must include a KAS change output (if needed) and a network fee within the capped budget. The KAS reserve per token cell is computed at genesis time and checked at every spend.

There is no burn operation in v1. Supply conservation means every token that enters a transaction must leave it. This is a deliberate simplification — a burn mechanism can be added in a future profile without changing the frozen v1 bytes.

The signer boundary

The token-wallet-wasm module is not a general-purpose wallet signer. Its interface exposes a small set of typed operations:

template_manifest()
preview_fixed_genesis(intent, utxos, fee_quote)
verify_and_sign_fixed_genesis(intent, observed_package, wallet_key)
preview_transfer(intent, token_cells, kas_utxos, fee_quote)
verify_and_sign_transfer(intent, observed_package, wallet_key)

The critical property: the signer reconstructs the transaction from scratch using node-observed inputs, then compares its reconstruction to the user's intent. It does not blindly sign whatever the UI hands it. It checks network, profile version, token ID, every amount, every owner, KAS values, output shape, mass, and fee — all before the key touches a signature.

The key exists only inside the unlocked Desk session. Temporary buffers are zeroed after signing. The server never sees the seed, never builds a transaction, and never holds signing authority.

How Kaspa Forge plans to use it

The planned flow inside Desk:

1. User opens the Tokens tab and unlocks their profile. 2. Selects "Fixed supply," fills in metadata, decimals, raw supply, and allocations to specific P2PK addresses. 3. The UI validates fields, deduplicates ticker/name, and computes a canonical metadata digest. 4. token-wallet-wasm fetches current wallet UTXOs and a node fee quote, builds the genesis transaction, and computes the future Covenant ID. 5. A confirmation screen shows: token ID, raw/human supply, each recipient, KAS reserve per cell, network fee. In KF20-FIXED-v1, the service fee is zero — there is no fee output. 6. User confirms with their password; the WASM signer rebuilds, verifies, and signs the exact transaction. 7. The typed server endpoint runs its own admission checks and submits the signed transaction to the connected Kaspa node. 8. The UI tracks state from submitted → accepted → indexed. Only after indexed does the token receive a verified-history badge and appear in the public catalog.

The separate indexer — not shared with Safe, Escrow, or Arena infrastructure — reconstructs all token state from the accepted virtual chain. Key entities:

Balances and holder lists are derived views, recomputed from canonical live cells. A separate undo journal handles chain reorgs atomically.

The public read API is planned as:

GET  /api/safe/tokens/templates
GET  /api/safe/tokens/{covenant_id}
GET  /api/safe/tokens/{covenant_id}/holders
POST /api/safe/tokens/submit

Read endpoints require no capability for public chain facts. The submit endpoint accepts only a fully signed KF20 transaction and reruns admission. Metadata upload gets a separate rate limit and never affects spendability.

Trade-offs and honest boundaries

What v1 sacrifices

• No minting. Supply is fixed at genesis. If you need an ongoing issuance mechanism, you need a future profile (KF20-CAPPED-v1), not a flag on v1. The capped variant separates the asset cells from a controller cell that holds max_supply, minted_supply, and mint authority — but it is a roadmap item that begins only after fixed-supply mainnet stabilization.

• Single owner mode. v1 tokens are owned by exactly one 32-byte P2PK Schnorr key. No multisig, no timelock, no DAO governance at the token level. Those are separate profiles or extensions, not hidden flags.

• No burn. You cannot destroy tokens to reduce supply. Conservation is enforced on every spend. This makes accounting trivial but means tokens are permanent once created.

• Zero service fee. Kaspa Forge takes nothing from token creation or transfer. The only cost is the Kaspa network fee, which the signer computes and caps.

The upstream arithmetic problem

The upstream KCC20 example in SilverScript (kaspanet/silverscript) sums token amounts in a signed integer without positive or checked-add guards. A historical probe on snapshot d57e5dff showed the VM accepting a negative allocation that inflated a simulated balance. As of the master@140bf184 watch (25 commits ahead of the Tokens pin), this bug persists — updating the compiler does not fix protocol-level arithmetic.

KF20-FIXED-v1 addresses this by:

1. Enforcing positive-only encoding in the 77-byte state. 2. Requiring checked sums on all successor token outputs. 3. Rejecting any transaction where an amount field or aggregate sum could be negative or zero.

These are on-chain consensus checks, not client-side validations.

Current development status

No amount of architectural elegance substitutes for those gates. The contract bytes exist and compile reproducibly, but "compiles" is not "deployed" and "deployed" is not "audited."

The KCC20 roadmap

A future KF20-KCC20-v1 profile would use the KCC-0020 native state format (a six-field KCC20State in canonical order, four-byte BLAKE3 dispatch, transfer/transfer_delegator entrypoints). It gets its own Covenant ID family, artifact namespace, classifier version, and independent audit. Work begins only after KF20-FIXED-v1 is stable on mainnet — and only if the KCC-0020 draft is finalized and the arithmetic issues in the upstream example are resolved. Argent (the actor/spawn compiler) is an optional research dependency for that profile, not a production requirement.

Security model

The core security property: Kaspa Forge never holds your tokens and never holds your keys. A token UTXO is a standard P2SH output on the Kaspa DAG. If the Kaspa Forge service disappears, the tokens are still spendable — as long as you have your key and can build a valid covenant transaction against any Kaspa v2+ node. The open-source contracts and tools (github.com/Kaspaforge/kaspaforge) let you do exactly that from a terminal, using vaultctl or any compatible signer.

What Kaspa Forge *does* provide is the safety layer: the UI that prevents you from broadcasting malformed transactions, the admission checks that catch arithmetic and shape errors before they hit the mempool, and the indexer that gives you a verified view of token state. None of these are consensus — they are engineering that makes the permissionless contract usable without becoming a protocol expert.

---

*This article reflects the architecture as of August 2026. Kaspa Forge Tokens is planned — not live. For the latest on covenant-based products that are live on Kaspa mainnet, see Kaspa Safe, Escrow, and Arena Blackjack.*