The local activation candidate is compiler 0.2.0-alpha.1, language 0.2, ABI 1. FOR/NEXT is enabled through public library and CLI paths with scoped counters, header snapshots, carried state, nested returns and ordered emissions. Windows validation and the expanded native Linux gate are recorded in the activation checkpoint. No new release has been published. The historical release evidence below applies to its original revision.
M5 is complete. The approved experimental prerelease was published on 2026-10-25 at b9411b67e9923549f9355eeb0c1eb5910da64368. Windows/Linux compiler, simulator/full-node and source-inclusive package CI passed on that exact revision. At that released checkpoint the compiler was 0.1.0-m3.8b, ABI 1; Rust totals are 277 Windows / 278 Linux. See the release scope, runtime baselines and validation record.
M3 is complete (274 Windows / 275 Linux Rust tests). M4-1 environment, M4-2 payment and M4-3 height/signature checks passed on both platforms. M4-4 passes eight replay/mutation scenarios on Windows and Linux, including confirmed double-spend rejection, raw solution/reveal/amount failures and recipient variants. Rejected spends preserve coin state across another farmed block; valid controls confirm exact outputs. All 15 planned scenarios passed on both platforms; Linux results were confirmed by the user. M4-5 reporting tests and complete aggregate verification passed on native Windows and Linux, as confirmed by the user. Hosted Windows/Linux compiler and simulator CI passed on 75002bb; M4 is complete. See the simulator instructions. At that released checkpoint the compiler was 0.1.0-m3.8b; dependency locks and Rust counts are unchanged.
The typed BASIC core supports scalar and collection values, local assignment, structured branches, pure nonrecursive functions, byte/string operations, and explicit condition emission. Contract boundaries accept INTEGER, BOOLEAN, BYTES, STRING, AMOUNT, PUZZLEHASH, PUBLICKEY, and nested PAIR/LIST fixed parameters and solution fields (up to 32 of each). INTEGER JSON values are canonical decimal strings, BOOLEAN values are JSON booleans, and BYTES values are exact {"hex":"..."} objects. STRING values are JSON strings of Unicode scalars: unpaired surrogate escapes and malformed UTF-8 are rejected. Raw STRING atoms are validated by generated CLVM even when unused. Empty strings, NUL, BOM and noncharacters are preserved without Unicode normalization. Byte leading zeros are preserved; hex is normalized to lowercase. LIST values are JSON arrays of recursively typed elements; generated checks require proper list tails and validate every element. Host conversion allows at most 65,536 tree nodes per complete fixed/solution list, including collection spines and nil tails. This host budget is separate from VM execution limits. PAIR values are exact {"first":valueA,"rest":valueB} objects with recursively typed children. Duplicate keys, including inside pair and hex objects, are rejected. Schema depth is limited to 32, schema size to 1024 nodes per field, and host JSON nesting to 96 containers. Generated CLVM validates raw boundary values, including unused fields.
AMOUNT is a distinct type in 0..2^64-1; PUZZLEHASH is a distinct 32-byte type. AS_AMOUNT and AS_PUZZLEHASH validate at runtime, while AMOUNT_VALUE and HASH_BYTES explicitly extract their underlying representations. Same-type equality is supported; arithmetic and ordering require INTEGER. Calls remain forbidden in CONST. JSON uses canonical decimal strings for AMOUNT and exact hex objects for PUZZLEHASH. Generated guards also enforce canonical amount atoms and hash length on unused raw fields, including nested collections.
PUBLICKEY requires a canonical 48-byte BLS G1 encoding, subgroup membership, and a non-infinity point. AS_PUBLICKEY(BYTES) validates; KEY_BYTES(PUBLICKEY) explicitly extracts its encoding. Checked host decoding and generated strict point_add validation reject invalid keys even when unused or nested. JSON uses exact hex objects. Public-key validation does not verify ownership or authorize a spend.
check, build, run, and explain --stage ast|ir|clvm are implemented. AST inspection parses without semantic checking; IR inspection uses the checked, lowered program. AST/IR views include source spans and a source digest and require no bindings. The CLVM view applies build's binding rules and shows template/puzzle bytes, hashes and flat trees. All views write no artifacts and perform no CLVM execution. build --template-only produces an unbound template. Bound artifacts distinguish the template hash from the puzzle hash. ASSERT_HEIGHT_ABSOLUTE, ASSERT_MY_AMOUNT(AMOUNT), CREATE_COIN(PUZZLEHASH, AMOUNT), and AGG_SIG_ME(PUBLICKEY, BYTES) are available as condition constructors. CREATE_COIN has no memo argument in this subset. Constructors return CONDITION values; only EMIT adds them to the output. Argument expressions execute left-to-right, with existing AMOUNT/PUZZLEHASH validation. AGG_SIG_ME preserves the application message exactly and rejects messages over 1024 bytes at runtime, including unused calls. It does not append coin/network context or generate/verify a signature. No node, wallet, signing, or transaction submission integration is implemented.
The documentation index identifies the released language, ABI and CLI contracts, user guides and historical milestone records. Future roadmap items do not extend the released interface.
Compiler 0.1.0-m3.2.1 renames the solution-field declaration to SOLUTION name AS type. The former INPUT keyword is no longer accepted as a declaration. Contracts do not prompt, read a keyboard, or wait for user interaction. Fixed parameters are still declared in the contract header; solution fields are supplied by the spender.
Update older source declarations and rebuild artifacts with the current compiler. The ABI and generated boundary semantics are unchanged; manifests still require the matching compiler version. The README uses a fixed height-lock example without solution fields. That historical keyword-change checkpoint passed 199 Windows Rust tests; current release totals are listed above.
The counted-loop implementation is now promoted from the private checkpoints into the public activation candidate, following the activation compatibility plan. FOR/NEXT works in contracts and functions through ordinary library and CLI entry points. ABI/profile and frozen non-loop output baselines remain unchanged. Loop-specific spend/full-node and source-inclusive package validation remain later gates before a separately approved release.
| Stage | Scope | Status |
|---|---|---|
| M0 | Syntax, ABI, target profile, and independent vectors | Complete |
| M1 | Compiler-to-CLVM pipeline, artifact identity, CLI execution | Complete |
| M2 | Typed BASIC core, functions, bytes, strings, pairs, and lists | Complete |
| M3 | Contract boundaries, domain types, and condition constructors | Complete |
| First complete payment | Signature-authorized, exact-value payment with a height lock | Passed Windows/Linux in SpendSim |
| Spend validation | Local simulator success and rejection scenarios, then testnet integration | M4 and M5 full-node validation complete; testnet future |
| Developer experience | Richer explanations, documentation, and potential educational editor tools | Future |
M4-5 now has a complete report/reproducibility runner and a separate Windows/Linux simulator workflow. The user confirmed all Windows and Linux testing passed, including reporting tests and the complete aggregate runner. Both native reporting/reproducibility gates and hosted Windows/Linux CI passed. M4 is complete. M5-0 release-readiness design is recorded in the M5 work plan; M5-1a full-node block smoke passed on Windows and Linux. M5-1b compiled full-node payment and missing-signature rejection also pass on both platforms. M5-2 adds the experimental compatibility policy and diagnostic tests; format/lint and all Rust tests pass on Windows (277) and Linux (278). M5-3 generated-input and regression checks pass all 653 CLI invocations on Windows and Linux. M5-4 adds the implemented-feature reference and payment tutorial; all nine documented commands pass on Windows and Linux. M5-5 experimental packaging passes on Windows and native Linux. The M5-6 release review is complete for the experimental prerelease, including source/notices, hosted CI and explicit publication approval. SpendSim coverage is not full-node/network consensus validation.
The complete payment example binds the owner key, recipient, exact amount, and earliest height. It requires authorization, asserts the coin amount, enforces the height lock, and creates the intended payment. SpendSim demonstrates accepted and rejected spends; the isolated full-node harness also confirms the signed payment and exact outputs. Wallet discovery, fee selection, and transaction submission are separate concerns.
WHILE/DO loops, user recursion, floating point, a language server, and an IDE are outside the current implementation scope. There is no version 1 release date yet.
The payment-condition example emits an amount assertion, height lock and payment output using fixed bindings and a pure helper. It does not require a signature and is not the complete authorized-payment example. CLI cost remains CLVM execution cost; it does not include consensus condition costs.
The height-locked payment example now compiles and runs with the supplied bindings, producing the original M0 payment condition vector, including the application-message hash. Its former reserved parameter name amount is now paymentAmount. The M4-2 harness verifies one signed SpendSim payment on both platforms. M4-3 height/signature checks passed both platforms; M4-4 mutation checks passed on both platforms.
See CONTRIBUTING for local commands. The CI workflow defines the full Windows/Linux check matrix. Default Python verifiers use the standard library; selected scripts also offer optional upstream-reference modes. Those modes require the separately documented reference dependencies and are not needed for normal builds.
Golden fixtures and synthetic signing vectors are public test data, never wallet credentials. VM execution results do not establish that a spend will be accepted by consensus.