SilverScript is a high-level smart contract language that compiles readable rules into Kaspa Script, the instructions Kaspa checks when a coin is spent. It supports signature checks, spending conditions and covenants. Version 1.0.0 was released on 9 September 2026. [1][2]
What a covenant does
A normal coin’s lock can ask for a signature. A covenant can also examine the transaction spending it and restrict the locks placed on its replacement coins. In the Kaspa Programmability MasterClass, at 19:08, Manyfest explains this distinction: the rules can govern not only who opens a lock, but where its contents may go next. [3]
SilverScript handles much of the low-level work, including stack encoding, argument layout and covenant validation helpers. For a contract that keeps state, its current data forms part of the script; a permitted update spends the old coin and creates its successor. [4]
Start with a time-locked vault. It teaches contract parameters, time checks and signatures. Strictly speaking, this example is a spending lock rather than a covenant that restricts successor outputs: after unlocking, it does not require the coins to stay under particular rules. [4][3]
Write and compile your first lock
These instructions use the Linux compiler binary. On Linux, open a terminal with Ctrl+Alt+T. On Windows, follow them inside WSL, Windows Subsystem for Linux. The terminal is where you type commands; a text editor is where you save the files.
1. Create a project folder and download the compiler.
```bash
mkdir -p kaspa-lab
cd kaspa-lab
curl -LO https://github.com/kaspanet/silverscript/releases/download/v1.0.0/silverc-linux-x86_64.tar.gz
tar -xzf silverc-linux-x86_64.tar.gz
```
The compiler turns your source into Kaspa Script. Use the versioned release rather than assuming the development branch has the same interface. If the download or extraction fails, stop and check the error before continuing. [2]
2. Save the contract.
Open a text editor, such as Text Editor on Ubuntu or VS Code. Save the following as vault.sil inside kaspa-lab. The contract requires both the owner’s signature and a transaction time at or after the chosen unlock time. [1][4]
```silverscript
pragma silverscript ^0.1.0;
contract Vault(pubkey owner, temporal unlock_time) {
entry spend(sig owner_sig) {
require(tx.time >= unlock_time);
require(checkSig(owner_sig, owner));
}
}
```
Use the entry and temporal forms shown here for the pinned compiler, rather than copying older examples with entrypoint function and an integer time parameter. SilverScript source syntax and its compiler release number are separate things. [1][2]
3. Supply the constructor arguments.
Constructor arguments are the settings fixed when you compile this particular vault. Save vault.args.json in the same folder, using this structure. Replace the placeholder with your test key’s 32-byte x-only public key, written as 32 comma-separated decimal numbers between 0 and 255. Do not enter a private key. The time is Unix time in milliseconds. [1]
```json
[
{ "kind": "bytes", "value": [YOUR_32_PUBLIC_KEY_BYTES] },
{ "kind": "int", "value": 1798761600000 }
]
```
The placeholder is deliberately not valid JSON until replaced. The example unlock time is 1 January 2027 at 00:00 UTC.
4. Compile from the project’s terminal.
```bash
./silverc vault.sil --constructor-args vault.args.json -o vault.json
```
A successful compilation creates vault.json. If compilation fails, check the filename, JSON syntax, public-key length and parameter order. Compiling produces an artifact; it does not fund or deploy the vault. Deployment means creating a coin locked to the compiled script. [1][5]
Test before deployment
Test on testnet 10 before using real funds. Check rejection before the deadline, rejection with the wrong signature, and acceptance with the correct signature after the deadline. Compilation alone does not establish that a contract is safe. On 2 October 2026, IzioDev described SilverScript as mainnet-ready and stable while warning that contract authors can still make mistakes [6]; the repository’s own security policy still calls it experimental, and the documentation advises checking the repository and release notes before putting real value in a contract [4][7].
Who can spend, and when:
spend: the owner’s signature, at or after the unlock time.- No second person must agree.
- Outputs are not constrained, so an authorized spender may choose the destination. [4][3]
Watch the masterclass at 23:46 for Manyfest’s explanation of the debugger: running a lock locally to inspect its behavior before it reaches the network. [8]