Starstream is a language that uses coroutines as its core primitive that is optimised to run in a zkVM (such as Nightstream). The end goal is a language and VM that can be used across any blockchain that chooses to include it.
Unique features of Starstream:
Learn more: - Basic overview: video and slides. - Technical overview: video and slides.
Starstream working group on Discord: https://discord.gg/9eZaheySZE.
Read more about how to use Starstream on the documentation website: https://lfdt-nightstream.github.io/Starstream/#getting-started
To begin working on Starstream from this repository:
./starstream to build and run the command-line interface and show its help message with more information.cargo test to run the tests.website/] for how to build it and its organization.vscode-starstream/] for build instructions. Use VSCode's "Launch extension" mode to debug.zed-starstream/ as a development extension../starstream wasm -c $your_source.star -o $your_module.wasm
# Can view disassembly using:
wasm-dis $your_module.wasm # from binaryen/emscripten
wasm2wat $your_module.wasm # from wabt
For multi-contract projects, use ./starstream build instead — see the
CLI docs for the full command set (check, docs,
build, lsp).
The Starstream DSL implementation and documentation website live in this repository.
Starstream is being built bit-by-bit, starting with full tooling for a simple language and adding each feature across the whole stack.
Concerns are separated into several crates. The 'compiler' turns source code into a validated AST, which is then interpreted directly or compiled further to a target such as WebAssembly.
Compiler:
starstream-types/ - Common AST types.starstream-compiler/ - Starstream language implementation.parser/ - Parser from Starstream source code to AST.formatter.rs - Opinionated auto-formatter.starstream-interpreter/ - AST-walking reference interpreter.starstream-to-wasm/ - Compiler from Starstream source to WebAssembly modules.Tooling:
tree-sitter-starstream/ - Tree-sitter definitions including grammar for syntax highlighting and analysis.starstream-language-server/ - LSP server implementation.starstream-language-server-web/ - Compiles the language server to WebAssembly (Web Worker only, uses wasm-bindgen).starstream-sandbox-web/ - Compiles starstream-to-wasm/ to Wasm for use in the web sandbox (freestanding).Executor and VM:
Starstream-specific executor and VM work lives under interleaving/. The
underlying folding/IVC scheme, CCS, memory, and VM trace building blocks are
implemented in Nightstream
and consumed here through pinned workspace dependencies such as neo-fold,
neo-ccs, neo-memory, and neo-vm-trace.
interleaving/starstream-interleaving-spec/ - Transaction and interleaving
semantics, public instance types (tied to a demo ledger implementation), and
witness types. Plus a Wasm spec for the requirements on the UTXO zkVM.interleaving/starstream-interleaving-proof/ - Starstream interleaving proof
circuit (CCS) and Nightstream folding-session integration with MCC middleware
for Twist and Shout (implemented in Nightstream).interleaving/starstream-component-runtime/ - Component execution runtime and
transaction session wiring (witness generation for proving, currently only for
the interleaving).interleaving/starstream-runtime/ - Minimal runtime for testing
Wasm to interleaving proof semantics. Will be replaced completely by
starstream-component-runtime eventually.Interfaces:
website/] - Documentation website and web sandbox.starstream-cli/ - Unified Starstream compiler and tooling CLI../starstream --help for usage instructions, or see the
CLI docs for the full command reference.vscode-starstream/] - Extension for Visual Studio Code.zed-starstream/ - Extension for Zed.# Run all tests
cargo test
We co-locate snapshot tests with the parsers they exercise. Each module (expression, statement, program, …) exposes a tiny helper macro that:
indoc! snippet for readability,parser() function, andDebug output of the AST using insta::assert_debug_snapshot!.Snapshots live under starstream-compiler/src/parser/**/snapshots/ right next to the code. The snapshot headers include the literal source (via the Insta description field), so reviews don’t need to cross-reference input files.
# run unit + snapshot tests
cargo test
# (optional) focused snapshot cycle
cargo insta test
cargo insta review
cargo insta accept
# clean up renamed/removed snapshots in one go
cargo insta test --unreferenced delete --accept
Because the helpers sit in the modules themselves, adding a new grammar rule is as simple as writing another #[test] in that module and feeding the helper macro a snippet.
$ claude mcp add Starstream \
-- python -m otcore.mcp_server <graph>