Ori Newman published Silverscript v1 on 9 September. He said the first token mechanism he and IzioDev built in raw opcodes took thousands of lines of code, and that the same thing now sits in 60 easy-to-read lines of Silverscript (GitHub release).
Readable rules matter because extra conditions on money only work if someone besides the author can see who gets paid, when, and what happens if nobody claims the coins. Newman put out a language for writing those rules so people, and the models they use while drafting, can follow them before value sits underneath.
Readable source that still runs as Kaspa Script
Silverscript is a contract language for Kaspa. Authors write source that looks like ordinary program text. A compiler named silverc turns that source into Kaspa Script, which is still what a node executes when those coins are spent.
Newman said the language started as "CashScript with loops" and grew into a way to express complex contracts that keep state as they run. The v1 release ships silverc for Linux, macOS, and Windows.
A contract can name the paths by which it may be spent. It can demand a signature, wait for a period to pass, and inspect the transaction that is trying to move the funds. If the next outputs do not match the rule, the spend fails and the coins stay where they are. The author no longer has to assemble every low-level instruction by hand to say that.
Rules people can inspect before coins move
A simple send already has a spending restriction. The right key has to sign, and most people understand that bargain even if they never open a script. The moment money should move only on a schedule, only to a named person, or only if a token record is updated, the rule stops being obvious. Someone still has to write it, and someone else may have to live with it.
When that writing is thousands of opaque lines, review becomes a specialist task. Errors hide, including surprises about who can reclaim leftover coins. Readable source lets a second person see the recipient, the wait, and the escape hatch in the same pass.
The v1 tutorial shows how those ideas look as teaching examples rather than as products in a wallet.
One example is a recurring allowance. A funder locks coins under the script. After a waiting period measured by how far the network has progressed since that output was created, anyone can trigger a payout. The first output has to pay a named recipient the pledged amount. After a small miner fee, the remainder returns to the same contract so the next period can run. If too little would be left for another full pledge, the leftover goes to the recipient instead. The funder can take the remaining coins back at any time.
A second example is a conditional payment. The recipient can claim the coins with a signature. After a set time, the sender can reclaim them. The funds never sit in an escrow company's account. They sit on the network under a rule both sides can read.
Token use is the third illustration. A token that continues as it moves has to carry its record forward. State can sit on the output and continue when the coins are spent, so the next output keeps the same template with the updated record. Named functions and stored fields are how those checks stay small enough to read.
Enforcement without a middleman holding the funds
Toccata went live on Kaspa mainnet on 30 June 2026. It expanded the spending conditions native scripts can apply during ordinary validation (Toccata guide). Signature checks and other basic restrictions were already part of how coins moved. The upgrade widened what a script can demand, including conditions on where the funds go next.
Silverscript v1 does not activate new consensus rules. It is a way to write the conditions Toccata already made enforceable.
When coins are locked under a compiled script, nodes accept or refuse the spend as they validate the transaction. A custodian does not have to hold the funds, keep a website running, or sign off on each payout for that refusal to work. The enforcement is inherent in native script execution.
The screens and reviews that still have to be built
Newman said Silverscript will keep evolving, that Argent will add higher layers of abstraction, and that others will extend the ecosystem in their own ways. Those layers sit further out. The tool developers can use now is this v1 compiler.
Wallets still have to show an allowance or a timed payment in the same ordinary language they use for a simple send, including who gets paid, how long the wait is, and whether someone can reclaim. Issuers who ask other people to rely on a token rule need to publish the source and let reviewers match it to the compiled script that actually runs.
Until those screens exist, readable contracts help the people who open the file. A person who only sees a balance still cannot tell what the coins will do. Compilation is not an audit, so a clear file can still pay the wrong recipient. Developers need to compile against this v1, test the spends, and keep the source beside anything that holds value. Users need a wallet that names the recipient, the wait, and the reclaim path before they sign.
