Ori Newman announced on 30 August 2026 that the SilverScript v1 release candidate is available after extensive review, testing, and standardization. He asked developers to test existing and new contracts against it and to report bugs or inconsistencies (X post).
The matching GitHub tag v1-rc1 was published the same day at 12:05:43 UTC. GitHub marks it as a prerelease, and it targets commit c7d17a15ac88610d013ec9ffffa9520aeb69929b (GitHub release). The notes call this the first candidate for SilverScript v1 after review, testing, and standardization, and say the candidate is intended to be functionally equivalent to the upcoming v1. The tag is a release candidate, not final v1.
Maintainers say that unless substantial issues are discovered, they intend to release v1 for mainnet use one week after the candidate. That is their stated plan, not a guaranteed date. The release credits elldeeone, IzioDev, Manyfestation, and Michael Sutton for contributions, review, and feedback.
SemVer and the source compatibility boundary
SilverScript is a high-level contract language that compiles to Kaspa Script and targets readable, maintainable stateful contracts. rc1 does not change that compilation target. It turns the pre-v1 language into a testable compatibility surface for source files and tooling.
Starting with v1, the project says releases will follow Semantic Versioning. A major version is for incompatible language or API changes. A minor version is for backward-compatible additions and improvements. A patch version is for backward-compatible bug fixes.
After final v1, maintainers intend to treat incompatible language or API movement as a major bump. Developers who compile against rc1 are checking whether their source matches the surface those rules will protect.
rc1 is a source and tooling stability boundary, not a consensus upgrade. SilverScript compiles to the existing Kaspa Script surface. Node software does not need an upgrade for this candidate.
Already compiled scripts on chain are also outside this release. Publishing silverc v1-rc1 does not rewrite deployed bytecode. Developers who keep SilverScript source should compile and test that source against rc1, especially if it used earlier syntax, unchecked assumptions, or APIs changed during pre-v1 review.
Portable artifacts add a second version number that should not be mixed with the compiler tag. Those JSON files are meant to carry contract source, compiler identity and version, a source hash, ABI constructor and entry declarations, and per-instance bytecode and address data. The declaration format is versioned independently from the compiler. Current README and spec text describe declaration schema version 1.0.0, which is not the same identifier as compiler tag v1-rc1 (README, declaration spec).
Five silverc builds and artifact verification
The release attaches five prebuilt silverc compiler archives for Linux x86_64, Linux arm64, macOS x86_64, macOS arm64, and Windows x86_64. GitHub exposes SHA-256 digests for each asset on the release page (v1-rc1).
The release workflow on the tag builds those five platform targets and uploads the compressed compiler binaries (release.yaml). At the tagged commit, GitHub checks were green for Check, Test Suite, Lints, Tree-sitter Test, and all five release build jobs (commit checks).
CI success on that commit is not an independent security audit. The release describes extensive review, testing, and standardization. It does not claim a completed third-party audit.
Documented silverc usage covers source compilation and portable artifacts: silverc contract.sil, silverc contract.sil --artifact contract.json, silverc --artifact contract.json --verify, and JSON output modes (README). The verification path can recompile embedded source and check hashes and metadata (DECL.md).
The tagged repository also includes the compiler, parser, formatter, language server, VS Code extension development support, Kaspa consensus test harnesses, contract artifact handling, and a tree-sitter grammar. Those components are in the candidate tree. They do not move rc1 from prerelease to final v1.
Language fixes that landed before the tag
Review still produced compatibility and correctness changes through August. Earlier in the month, merged work tightened entry argument sizes, return behavior, evaluation of discarded helper results, and array and slice typing and cast documentation (PR 210).
A later timelock correction separated Unix milliseconds, absolute DAA score, and relative DAA age using explicit typing, and renamed this.age to this.ageDaa (PR 214). Source that still depends on the old name or mixed lock units is the kind of pre-v1 contract rc1 is meant to expose.
The release-tag commit includes Michael Sutton PR #235, which changes AST treatment of as cast targets and adds span coverage (PR 235). Immediately before the tag, Ori Newman PR #236 standardized strings on JSON-style double-quoted escaping and allowed canonically encoded variable-width runtime state in portable artifacts (PR 236).
These are examples, not a complete changelog, and they do not imply known unresolved bugs in the candidate. They show why existing source should be recompiled against rc1 instead of assumed to match the tagged language.
The test gate that can delay final v1
Newman asked developers to test existing and new contracts and report bugs or inconsistencies (X post). The GitHub release repeats that request and adds unclear behavior and documentation problems (release).
The concrete check is source, not already deployed bytecode. Recompile maintained .sil files with an rc1 silverc build, emit artifacts, run --verify, and compare constructor and entry declarations with current ABI output. New contracts written for the v1 line should be compiled against this candidate as well.
Suspected vulnerabilities are a separate path. SECURITY.md on the tag asks reporters to use GitHub private vulnerability reporting and says not to disclose suspected security issues publicly before a fix (SECURITY.md).
Maintainers intend to release v1 for mainnet use one week after the candidate unless substantial issues are discovered. A reproduced defect in language behavior, compiler output, artifact verification, or documentation against v1-rc1 is the condition that would delay that release.
