Glossary
The words, defined
One short paragraph each. Terms underlined with dots elsewhere on the site link back here.
- Actor
- Argent's unit of an application: one covenant with its own state and entries. An app is several actors whose interactions Argent wires together through ICC.
- become
- Argent keyword: an entry finishes by declaring the actor's next state — the transition the chain will enforce.
- blockDAG
- A block structure where blocks can have many parents, so parallel blocks are kept instead of discarded. Kaspa's blockDAG is what lets it run many blocks per second under proof of work.
- CDAG
- The computation-DAG research model behind vProgs — programs living natively in the DAG rather than being encoded in script locks. Roadmap territory.
- Covenant
- A lock on coins that dictates how they are allowed to move next. Not a promise or a bookkeeper's note: consensus rejects any spend that breaks the rule.
- Covenant ID (KIP-20)
- A stable identity for a covenant lineage, so one contract can own things, be referenced by other contracts, and be found again across many transactions.
- Covenants++
- The covenant capability set Kaspa gained with Toccata: transaction introspection, lineage proofs (KIP-17), covenant identity (KIP-20) and inline ZK verification (KIP-16).
- Entry
- A callable function on a contract or actor — the only doors into it. Anything an entry doesn't allow can't happen.
- GHOSTDAG
- The protocol that puts every block of the blockDAG into one agreed order without throwing parallel blocks away — the reason Kaspa keeps Bitcoin-style security at high block rates.
- ICC
- Inter-covenant communication: Argent's mechanism for separate actors (covenants) to interact atomically inside one transaction.
- Inline ZK (KIP-16)
- Zero-knowledge proof verification inside Kaspa script (the OpZkPrecompile opcode) — the chain can check that something happened without seeing the details. Live on mainnet since 2026-06-30.
- kascov.io
- The covenant explorer and zero-install playground: try covenant code in the browser, and inspect live covenants, KCC-20 holdings and trades on mainnet and testnet-10.
- Kasplex
- The indexer protocol that introduced KRC-20 tokens to Kaspa in 2024.
- KCC-20
- Covenant-native tokens: supply and transfer rules checked by Kaspa consensus itself, with no off-chain bookkeeper to trust. Live and traded on mainnet; the written standard is still consolidating.
- KRC-20
- The first Kaspa token standard: balances recorded as inscriptions and tracked by off-chain indexers. It works and is widely supported — but the chain itself doesn't check the token rules.
- Lineage proof (KIP-17)
- A proof that a coin descends from a covenant's line of transactions — what lets a rule follow coins across many spends instead of applying only once.
- N:M pattern
- Several covenant inputs and several covenant outputs of the same contract handled in a single transaction — Silverscript's model for batched state.
- P2SH
- Pay-to-script-hash: an output commits to the hash of a script, and the script itself is revealed when the coins are spent.
- Script pricing
- Toccata's per-operation cost model for scripts, replacing the old flat size limits — heavier operations cost more of a transaction's budget.
- Singleton
- A covenant pattern where exactly one live instance of a piece of state exists at any time — the shape most "one contract, one state" apps take.
- Template commitment
- A covenant committing to the allowed script(s) of its next output — the core trick that makes "these coins may only move like this" enforceable.
- testnet-10
- The current public Kaspa test network where covenant development happens before anything touches real money.
- Toccata
- The 2026 Kaspa upgrade that brought transaction v1, Covenants++, script pricing and inline ZK — the moment Kaspa learned to enforce rules on money.
- Transaction v1
- The upgraded transaction format introduced by Toccata that carries the data covenants need.
- Transition
- One allowed state change of a covenant: old state, plus your request, plus the transaction's facts, to a permitted new state. Everything else is rejected.
- UTXO
- Unspent transaction output — the individual "coin objects" Kaspa tracks. Covenants attach rules to specific UTXOs, which is why the rules travel with the money.
- vProg
- Roadmap concept: a program living natively in Kaspa's DAG rather than being encoded as a covenant script. Nothing to build with yet.
- Witness
- The data supplied when spending — signatures, arguments, revealed scripts — that satisfies (or fails) the lock on the coins.