Build Kaspa apps

Route

Pick the route

Most products need only payments and wallet UX; Toccata matters once a spend rule must be readable first.

Fungible tokens build on KCC-0020, a draft standard with a known supply-split defect: see KIPs and KCCs.

A covenant can only inspect its own spending transaction; no KIP gives it a shared-state read.

Demo

Attack a covenant vault

state VaultState {
    byte[32] owner_pk_hash;
    byte[32] recovery_pk_hash;
    byte[32] payout_spk_hash;
    byte[32] recovery_spk_hash;
    int balance;
    int last_spend_daa;
}

actor Vault owns VaultState {

    entry withdraw(int amount, sig owner_sig, pubkey owner_pk)
        emits next: Vault
    {
        require(blake2b(owner_pk) == owner_pk_hash);
        require(checkSig(owner_sig, owner_pk));

        // what can leave: fixed cap, fixed destination
        require(amount <= 500 && amount <= balance);
        require(tx.outputSpkHash(0) == payout_spk_hash);
        require(tx.outputAmount(0) == amount);

        // how soon again: time since this covenant's own last spend
        require(tx.inputDaaScore(self) - last_spend_daa >= 36000);

        // what comes next: same KIP-20 covenant id, updated state
        VaultState new_state = {
            owner_pk_hash: owner_pk_hash,
            recovery_pk_hash: recovery_pk_hash,
            payout_spk_hash: payout_spk_hash,
            recovery_spk_hash: recovery_spk_hash,
            balance: balance - amount,
            last_spend_daa: tx.inputDaaScore(self),
        };
        become next <- Vault(new_state);
    }

    entry recover(sig recovery_sig, pubkey recovery_pk) {
        require(blake2b(recovery_pk) == recovery_pk_hash);
        require(checkSig(recovery_sig, recovery_pk));

        // no cap, no delay: recovery ignores both
        // but the destination is still fixed, and the vault ends
        require(tx.outputSpkHash(0) == recovery_spk_hash);
        require(tx.outputAmount(0) == balance);
        // no `become`: this covenant's lineage ends here
    }
}

Evidence

How much of this is actually running

An indexer counts 84,196 covenants on mainnet, 687 active, holding about 1,561,431 KAS; Testnet-10 carries far more, about 88,493 active.

Baseline written into this page September 1, 2026.

Sources, all read Status: Active: KIP-16, KIP-17, KIP-20, KIP-21.

Application layer

Argent and Silverscript

Toccata made covenants enforceable. Argent, Sutton's compiler, turns a readable application into the Silverscript the network already checks. Silverscript 1.0 shipped on 9 September 2026; Argent remains pre-release and needs further audit and hardening for general production use.

Try it

One line at a time, from Argent down to Kaspa Script

Nothing reaches the network as Argent: every line ends up as script a node already checks. The Ticket example hands off a ticket in three lines.

The gap it fills

A covenant is opcodes. An application is several agreeing.

A covenant is a rule attached to a coin, raw opcodes: readable alone, hard to audit once several agree. Argent, Sutton's unofficial compiler, takes an actor description and writes the script.

Inter-Covenant CommunicationSeparately compiled apps joined into one all-or-nothing transaction. lets one app's actor authorize another's, so two land together or not: second of three rungs on the What is Kaspa page, the first not live.

state TicketState {
    byte[32] owner;
    int units;
}

actor Ticket owns TicketState {
    entry transfer(byte[32] next_owner, sig owner_sig, pubkey owner_pk) emits next: Ticket {
        require(blake2b(owner_pk) == owner);
        require(checkSig(owner_sig, owner_pk));
        require(next.value == self.value);

        TicketState new_state = {
            owner: next_owner,
            units: units,
        };

        become next <- Ticket(new_state);
    }
}

app Tickets {
    actor Ticket;
}

Repository signals

Three active repos, zero releases

Baseline read from GitHub on September 1, 2026.

What's proven, what isn't

Partitioned state works. Shared state is a design direction.

Quoting the README's caution without its working-pieces list misdescribes it. Working compiler examples do not establish production readiness.

Demo

What a proof can and can't verify

KIP-16's proof check confirms validity, not where the inputs came from.

What to build

Products, sorted by what they need

A synced node and Silverscript compilation come first; no getUtxosByCovenantId RPC exists yet.

Fact-check a claim: claim fact-check. Toccata prep: status operator checklist.

Verify yourself

Run the checks yourself

Climb the ladder: an explorer read, a second API, then a node reading chain state.

# Docker route; Rust+Cargo for source. A node verifies chain state, not wallet keys.
docker pull kaspanet/rusty-kaspad:latest
mkdir -p ~/kaspa-data
docker run -d --name kaspa-node --restart unless-stopped \
  -v ~/kaspa-data:/app/data \
  -p 16110:16110 -p 16111:16111 -p 17110:17110 -p 18110:18110 \
  kaspanet/rusty-kaspad:latest

docker ps
docker logs --tail=80 kaspa-node

# Source build with UTXO indexing (needed for wallet/UTXO queries). Wait for full sync.
git clone https://github.com/kaspanet/rusty-kaspa
cd rusty-kaspa
cargo run --release --bin kaspad -- --utxoindex

# Terminal wallet and RPC, from a checkout. Read address, amount, fee, network before signing.
cd cli
cargo run --release

# wRPC is off by default; bind carefully on public machines.
cargo run --release --bin kaspad -- --utxoindex --rpclisten-json=default

# Check netsuffix/release/flags against active docs first.
cargo run --release --bin kaspad -- --testnet

cargo run --release --bin kaspad -- --testnet --netsuffix=10 --utxoindex

# Fund only printed kaspatest: addresses from a TN12 faucet; every Kaspa testnet
# shares that prefix, so TN10 faucet tKAS won't work here. --submit broadcasts for real.
git clone https://github.com/parker2017code/tn12-covenant-vault-demo
cd tn12-covenant-vault-demo
npm ci
npm run check:all
npm run check:tn12

# Batch-check txids for acceptance, block hash, confirmation count.
curl --request POST \
  --url https://api.kas.fyi/v1/transactions/acceptance \
  --header 'Content-Type: application/json' \
  --header 'x-api-key: <api-key>' \
  --data '{"transactionIds":["<txid>"]}'

# Bounded range; KDP caps each request at 100 scores.
curl --request GET \
  --url https://api.kas.fyi/v1/blocks/daa-score/{daa_score_start}/{daa_score_end} \
  --header 'x-api-key: <api-key>'

# Large histories need cursor pagination; cache results.
curl --request GET \
  --url 'https://api.kas.fyi/v1/addresses/<address>/transactions?limit=100' \
  --header 'x-api-key: <api-key>'

# Amounts are sompi strings. Key goes in x-api-key. 429 means back off.
1 KAS = 100000000 SOMPI
amount: "31112708372"

Checks that catch the expensive mistakes

Stay testnet-only until mainnet evidence says otherwise.

References

What to read before writing code