Why Silverscript

Writing covenants directly in opcodes is possible and unpleasant. Silverscript is a CashScript-inspired language that compiles to native Kaspa Script — no virtual machine, no intermediate representation, no runtime to trust. What runs on-chain is ordinary Kaspa Script that you can read.

It adds what raw script lacks: types, named functions, arrays, loops, and control flow, plus the low-level builtins that make covenant work practical.

The shift from Solidity

The hard part is not syntax. It is that a Silverscript contract does not do anything.

A Solidity contract is an object with storage and methods that mutate it. A Silverscript contract is a spending condition: a predicate over a proposed transaction, which either permits the spend or does not. It has no storage it can write, no way to initiate anything, and no existence between transactions beyond the coins locked to it.

pragma silverscript ^0.1.0;

contract MultiSig(pubkey pk1, pubkey pk2, pubkey pk3) {
  entrypoint function spend(sig s1, sig s2) {
    require(checkMultiSig([s1, s2], [pk1, pk2, pk3]));
  }
}

Constructor parameters are baked into the contract and fixed at the address. Function parameters are supplied by whoever spends. require is the whole vocabulary of control: every path either passes every requirement or the spend is invalid.

What it is good at, and where it stops

Good at: vaults, time locks, escrows, multisig, and covenants that constrain what the next transaction may look like — anything expressible as a condition on one UTXO being spent.

Where it stops: several contracts that must transition together as one atomic operation. Silverscript covers a single contract well; coordinating a set of them is what Argent exists for.