The map

Six names come up when people talk about programmability on Kaspa. They are not six competing options, and the most common expensive mistake is treating them as if they were.

Three of them are one stack. Kaspa Script, Silverscript and Argent sit on top of each other. You do not choose between them any more than you choose between machine code, C, and an application framework.

.ag source       actors, typed state, entries, become, ICC
    │
    ▼
Argent compiler
    │
    ├──▶ plain .sil contracts ──▶ Silverscript compiler
    │                                        │
    └──▶ portable artifact                   ▼
              │  artifact.json              Kaspa Script
              ▼  manifest.json              OP_CAT, OP_SUBSTR,
       argent-runtime                     introspection, KIP-20
              │
              ▼
  one atomic multi-actor Kaspa transaction

The other three are genuinely separate choices. Toccata, vProgs and Layer 2 solve different problems and live elsewhere in the design space.

The stack, layer by layer

Layer	What you write	Reach for it when
Kaspa Script	Opcodes, by hand	You are debugging, or doing something no compiler exposes
Silverscript	One contract, .sil	One covenant with a self-contained spending condition — a vault, an escrow, a multisig
Argent	A whole app, .ag	Multiple contracts holding typed state that must transition together, atomically

You do not skip layers in learning, even though you do in writing. Each layer’s debugging happens one layer down: an Argent bug is read in the generated .sil, and a Silverscript bug is read in the emitted script. Working top-down is how people get stuck.

The adjacent options

• Toccata makes Kaspa UTXOs expressive enough to carry real application state. It is on mainnet, which is more than the rest of this page can say.
• vProgs run computation off-chain and prove it with a zero-knowledge proof that nodes verify on-chain. That is a different trust and cost model, and it is where shared state lives — Silverscript’s local UTXO state is the complement, not the competitor.
• Layer 2 — an EVM chain settling to Kaspa. Choose it when you want existing Solidity tooling and are willing to accept an L2’s trust assumptions.

Choosing, honestly

Start from what your state looks like.

• State belongs to one owner and changes on a clear condition → Silverscript.
• Several pieces of state must change together, atomically, possibly across apps → Argent.
• State is shared between many participants and the computation is heavy → vProgs.
• You want Solidity and existing tooling more than you want L1 → an L2.

And weigh maturity as heavily as fit. Every page in this section carries a status banner at the top. Read it before you build on the thing it describes.