Kaspa master file

Experimental. Not advice. DISCLAIMER.md

Kaspa master file

What

Kaspa is a proof-of-work cryptocurrency: miners secure it by spending computing power. It had a fair launch in November 2021, with no premine, so no coins were set aside before public mining began. Instead of a single chain of blocks it keeps a blockDAG: blocks found at the same time all stay in the record, and a rule called GHOSTDAG puts them in order. The Crescendo upgrade brought mainnet to about 10 blocks a second. The Toccata upgrade turned on covenants on the base layer (L1) at DAA score 474165565. A covenant is a rule that a coin carries about how it may be spent next. The DAA score is a counter that rises with every block. SilverScript v1.0.0 is the tagged compiler for writing covenants.

This file is a public pin list for Kaspa and the work around it: the node software, the KIPs (Kaspa Improvement Proposals), covenant conventions, research code, workshop threads, and proposals that are still open. Each claim names the commit or the file it rests on, so anyone can open it and check.

Third-party builders and community projects live in STP-KAS/kaspa-builders.

Why

A release, an open pull request, and a demo are often presented as the same thing. This file gives each one its own row, so every claim can be checked against its source. Grok writes the rows and reads them again, with the automations and a sweep of the sources. The repository account is STP-KAS. Kaspa core maintains the node and the KIPs.

The file follows four rules:

A merged KIP with the status Active is the rule.
An open pull request is a proposal until it is merged.
DAGKnight (KIP-2, a consensus proposal) is still a proposal.
About 100 blocks a second is a later target, not something live.

How

Each day the automations sweep every source the file names and check each row against it again. The sources are GitHub, X, and public websites. Every pass leaves a receipt in SNAPSHOT-HISTORY.md, even when nothing changed. The Now board below is the current state, and master.json holds the same board as data.

The repository opened on 5 September 2026 as a map of public GitHub repositories, KIPs, and channels. The snapshot log began on 18 September. On 21 September the Now board became the current state, and the older sections below it became receipts.

This is an experiment, and whether it is useful is open to debate. A row can lag behind what it watches.

How to read this file

Now (read this first): the current board.
master.json: the same board as data, in the section now.
SNAPSHOT-HISTORY.md: the dated log of every pass, newest first.
RECEIPTS.md: older README sections (dated receipts and the reference sections 0–10).
STP-REPOS.md: what each STP-KAS repository is.
PROCESS.md: how branches, challenges, and merges reach main.
DISCLAIMER.md: experimental only, not a product.

Now (read this first)

Kept current by the daily automations. The latest pass is the top row of SNAPSHOT-HISTORY.md. Independent check. Not Kaspa core. Not an audit. Not an oracle.

This block is the current pin board. Older receipts are in RECEIPTS.md and SNAPSHOT-HISTORY.md. If a receipt disagrees with this block, this block wins. Machine copy: master.json section now.

Object	Now
Live	PoW, fair launch 2021-11-07, blockDAG / GHOSTDAG, Crescendo ~10 BPS, Toccata after DAA 474165565. KIP-16/17/20/21 Active (kips `e4ae233`). Node release: rusty-kaspa v2.1.0 (published 2026-09-22T13:55:36Z, not a prerelease), tag `01b532e8` (#1139). The tag commit only changes version strings. The release is the node at that commit: P2P protocol 11 streams IBD in 20 MiB chunks and still speaks protocol 10. Not a new consensus activation. Previous release v2.0.1 is `cfafeb4c`. 14 Oct: master tip is `67686482` (2026-10-14T16:12:25Z), the merge of #1074. The release tag is still v2.1.0 `01b532e8`. Not a new release and not a consensus-rule change. On master after the tag: #1142 `a92c4f9f` (13 Oct 10:19:49Z), #1135 `12db0f35` (13 Oct 11:12:28Z), #1148 `2ea8e9d1` (14 Oct 12:30:32Z), then #1074. #1074 (IzioDev; biryukovmaxim APPROVED 2026-10-14T13:36:17Z on `804172ad`) is wallet and WASM tooling. Native `GeneratorSettings` has `version` and `compute_commit`; its three constructors still set version 0 and `ComputeCommit::SigopCount`. WASM `IGeneratorSettingsObject` still takes `sigOpCount`. `get_utxo_entry` skips a UTXO whose `covenant_id` is set. The generator rejects a payment output that carries a covenant (`GeneratorPaymentOutputCovenantNotAllowed`). WASM `createTransaction` can build a version-1 output with a covenant when the commit type is `computeBudget`. Wallet `MAXIMUM_STANDARD_TRANSACTION_MASS` is the constant 500_000; it was 100_000. That is the wallet standard cap, not a consensus block-limit edit. The relay fee uses non-contextual mass (compute and transient through the consensus calculator). `updateTransactionMass` still stores storage mass. A storage-mass overflow tries the next UTXO while one remains. Consensus `mass/mod.rs` adds `Add` for `NonContextualMasses` and makes the input size helper public. No issue closed. #1073 stays open. kaspa-python-sdk#78 merged 10 Sep and is a different fix. KaspaScopio 2110463785349812661 (14 Oct 20:12:31Z). Not desk-built. #1129 (toolchain bump to 1.98.1) is still open, head `8b9f1c419f`. Desk note on `01b532e8`: `check_tx_throttling` in `protocol/flows/src/v10/txrelay/flow.rs` divides by a raw millisecond count, so a sample under 1 ms can turn throttling on (5778361113). Compiler: SilverScript v1.0.0 `3ed9733`. Dated detail (#1129, #1138, Ori's upgrade post): SNAPSHOT-HISTORY.md. Paper dates, the k=124 check, and the draft yellow paper: Consensus papers. Prior cell (to 14 Oct): SNAPSHOT-HISTORY.
Consensus papers	LIVE. GHOSTDAG is the consensus the Live row names. KIP-2 Proposed says GHOSTDAG governs the current Kaspa network. Paper: Sompolinsky, Wyborski, and Zohar, ePrint 2018/104, received 2018-01-30, last of 17 revisions 2021-11-10. The PDF title page is 10 Nov 2021. Research mirror Ghostdag.pdf `ff0ec18a` is the same file, sha256 `296e87afcb923b8069ed59353a2ed2440f0f42be5ac9c8623d2ffbe6c3db1a65`, 1041410 bytes. Page 1 says GHOSTDAG was implemented as the underlying technology of Kaspa. That sentence is the 2021 paper. §4.2 page 7 eq. (1) is the least natural k whose f is below δ. Eq. (2) is the max of a Poisson tail of mean 2·D_max·λ and 2c/(k+2c), with c = D_max·λ. The same page says that second term does not vanish exponentially in k. Theorem 5, same page: the Nakamoto security threshold goes to 0 as D·λ grows. §5 uses λ=1, 2·D=7 seconds, and k=16 as an example. That example is not mainnet k. §6, with Figure 4 and Table 1 on page 9, records about 40 transactions per second and 458,557 transactions. Those figures are the 2021 paper. KIP-ACTIVE. KIP-14 The Crescendo Hardfork, Active, created 2025-01-21, updated 2025-03-04, at kips `e4ae233`. It cuts target time per block from 1000 ms to 100 ms, which is 1 BPS to 10. It cites §4.2 eq. 1 and, with D=5 and δ=0.01, sets Ghostdag K to 124 from the Poisson tail cutoff. It does not say the full f is below 0.01. Finality depth becomes 432,000 blocks. The merge-depth bound becomes 36,000. Coinbase maturity becomes 1,000 blocks. The printed pruning expression is φ+2M+4KL+2K+2, lower bound 627,258 blocks, with a suggested 30-hour round-up. Reference [3] is the Prunality PDF. The rationale names an ongoing based-ZK bridge design as anticipated demand. This hardfork is not DAGKNIGHT and not vProgs. Code at rusty-kaspa tag v2.1.0 `01b532e8` (the tag object is that commit): mainnet params use BlockrateParams for 10 BPS and crescendo activation DAA 110165000, with the comment Roughly 2025-05-05 1500 UTC. Network delay bound is 5. The tail delta is 0.01. ghostdag_k for 10 is 124. calculate_ghostdag_k returns when 1 minus the Poisson sum is below delta. It does not apply the second term of eq. (2). At mean 100, P(X>123) is 0.011244 and P(X>124) is 0.008774. The eq. (2) second term at k=124 is 100/224. The full f is not below 0.01. mergeset_size_limit is 2k when that product sits between 180 and 512, so 248 at this k. max_block_parents caps at 16. Its comment names parameterless DAGKNIGHT as a future alternative if BPS grows past 10. That comment is not a claim that DAGKNIGHT is live. pruning_depth builds the KIP-shaped lower bound and returns the larger of that bound and BPS times the pruning duration. The constants are finality 43200 seconds, merge depth 3600 seconds, and pruning 108000 seconds. At 10 BPS the bound evaluates to 627,258 and the function returns 1,080,000. That arithmetic reads the source. It is not a consensus proof. DRAFT formula. Prunality, Sutton and Wyborski, cover July 2020, research commit `67254c9c`. The docs copy `ce8c3bde` (2021-07-22) is the same bytes, sha256 `e7a7a35ab0c5dc95f55b28ef6e5cbf347d7b7630104be4eb7005e214e9d1336e`, 201464 bytes. Page 1 sets π = 2φ + 4ℓk + 2k + 2. Definition 3 on page 2 names (R-I) Objective finality. Rule 1 on page 5 says blocks in P.Past can be pruned. That π is not the KIP-14 expression and not pruning depth 1,080,000. bps.rs says the lower bound is based on that PDF and on a decomposition of merge depth, rule R-I therein. That comment is not Definition 3. KIP-PROPOSED. DAGKNIGHT: Sompolinsky and Sutton, ePrint 2022/1494, received 2022-10-31, last of 2 revisions 2023-02-24. The PDF title page is 23 Feb 2023 and prints Sutton, then Sompolinsky. sha256 `287ca824006d2e20d5d82fe8daf88bd21e3ba662abcec316ba026498a91384f8`, 945060 bytes. The abstract says there is no a priori in-protocol latency bound, tolerance is up to 50% hashrate, and the protocol is an evolution of PHANTOM. Theorem 2 in §3.2 on page 10 says Algorithm 2 is parameterless, scalable, self-stabilizing, and adaptive. Research README `c923faca` lists the yellow paper, Phantom Ghostdag, and Prunality. It does not list this paper. Not mainnet. DRAFT. vProgs yellow paper v0.0.1, commit `12c66b138451` (2025-09-11T13:22:49Z), sha256 `897196863a457368fecc4728a946abb23627ed78350d8785b89c8fa0cc983880`, 387363 bytes. The title page says DRAFT v0.0.1. The abstract says the architecture is proposed. §2.2 assumes a permanent static account set and does not treat creation or deletion. §2.4 leaves pruning of buried commitments out of scope. §3.1 says how ZK verification will be enabled is under consideration. §5.1 leaves code publication and P2P to a future version. §5.4 Account Creation and §5.5 Clients Cache Pruning are left to future revisions. The abstract proposes a synchronously composable system. That proposal is not live. Kaspa does not have vProgs. KIP-ACTIVE, not that paper. KIP-21 Active, created 2026-02-17, updated 2026-05-28. It says future KIPs may define additional lane families such as vProg-based lanes. The section Future Compatibility with vProgs CD says the KIP stays compatible with a future full vProgs CD specification, cites the yellow paper, and says the section is informative only. The file does not contain 474165565. RESEARCH-THREAD. Not a paper and not a product. 387, hashdag, 2025-08-07, 4 posts. The opener's yellow-paper line, end of month, is not a ship date. 407, michaelsutton, 2025-08-17, 8 posts. 410, hashdag, 2025-08-20, 1 post. 208, michaelsutton, 2024-12-09, 9 posts. 258, michaelsutton, 2025-01-13, 2 posts. 274, FreshAir08, 2025-01-20, 6 posts. Title, author, and date only for those five. No claim from those posts is pinned. docs.kaspa.org/programmability/full-vprogs returned the title Future Direction: Full vProgs and no body.
Python SDK	kaspa-python-sdk v2.1.0 (24 Sep 23:54Z, smartgoo). The core `kaspa` module is on rusty-kaspa v2.1.0 `01b532e8`. Experimental `kaspa.experimental.silverscript`: compile v1.0.0 source, silverc-identical artifact JSON, `debug_call()` trace with no node. `ZkScriptBuilder` for `OpZkPrecompile` RISC Zero scripts. Counter covenant and Groth16 examples on testnet-10. vertex: 2103491057165988213. An SDK release is not wallet support. The silverscript module is a separate cdylib. `crates/silverscript/Cargo.toml` pins silverscript `3ed9733` and rusty-kaspa `a41a333b`, not v2.1.0. That works around silverscript#256; it does not fix it. someone235 closed #256 on 10 Oct, and silverscript master `a0dd7448` now depends on the rusty-kaspa v2.1.0 crates on crates.io (see SilverScript holes). Desk-tested 28 Sep (Windows, Python 3.12, `kaspa==2.1.0`). Compiling agenc-on-kaspa `native/escrow.sil` with the same constructor arguments, `artifact_json()` parses equal to silverc v1.0.0 and `template_hash` is `060844c16725b7032a67a5ca719b1f800ebc4e6899290b3384bd061387a7e122`. The wheel writes CRLF, so the raw file is not the LF bytes silverc writes. The v1.0.0 Windows zip sha256 is `3e0d660c15a9e7ac90f3960da24d348b076b1891481bfe758db18accc8a102e1` and that binary rejects `--version`. KCC-1 vectors, desk-tested 29 Sep (Linux, Python 3.13, `kaspa==2.1.0` from PyPI, `kaspa.experimental.silverscript` = SilverScript `3ed9733`): `conformance.json` at kccs `da834af0` (sha256 `5a8ae724de9031d3390ded7873df74002ec29a771c5fbc56e1e43d2a9ae26b59`), sections `dispatch_and_arguments` and `composite_encodings` only: 14/14. That is the dispatch tag `2c49ed65` for `step(int,byte[4],bool,byte)`, its four argument encodings, and all nine composite encodings (arrays, records, nested and dynamic record arrays; record vectors checked against `combined_hex`). Each vector is compiled as a one-entry contract; `build_sig_script` puts the tag push after the argument pushes, which is the §3.6 order (`PushArguments`, `OP_DATA_4 dispatch_tag`, `PushMinimal(R)`); the harness would also have passed a prefix, so the order was observed, not tested. Re-run 29 Sep 22:37 CEST (same PyPI wheel, sha256 `ac229614aa41872276d4d7e75ede8d5f663761b0756d211c05c138e0741ed9a8`, Python 3.13.5): output byte-identical (sha256 `d54cbf36e8ae486fb167e3e0455bb0667dc0049caa7b4a3362ee046a6a65149f`). Same compiler, extra check: `zero_argument_dispatch` (`tick()` → `161bd7ee`, sig script `04161bd7ee`) and all six `record_dispatch` tags (`676b1a86` twice, `dafff68f`, `81764c55`, `3d042cd2`, `a625f54c`) match the vectors, and the nine composite entry tags equal unkeyed BLAKE3 of their §3.5.1 signatures: 16/16. That is 4 of the 15 vector sections (the file has 19 top-level keys; `kcc`, `format_version`, `byte_string_format` and `vector_conventions` are metadata). Not full KCC-1 conformance. KCC-1 was Last Call from kccs #32 (1 Oct) and is Final since 21 Oct (#39, `1ed87aef`). 21 Oct (KCC-20 Final): KCC-1 status updated above; see KCC still open. Prior cell (to 21 Oct, KCC-20 Final): SNAPSHOT-HISTORY.
TN10 public API	Synced on 27 Oct: 7 cache-busted `/info/health` reads 06:43:07Z–06:43:11Z (server `Date`, headers saved), all HTTP 200, Cloudflare `MISS`, `isSynced` true, kaspad 2.1.0 with UTXO index, `blueScoreDiff` 6 to 40, `acceptedTxBlockTimeDiff` 1 to 3. One backend answered all 7 reads: `41d9296c`; small sample, no pool size. `/info/blockdag` HTTP 200: virtual DAA 607497241 at 06:43:12Z, network `kaspa-testnet-10`. Open: rusty-kaspa#1146 "Synced TN10 node keeps already-accepted txs in mempool indefinitely (zero rotation)" (oskrcl, 4 comments, last update 13 Oct 10:48:54Z) and pull #1147 "mempool: revalidate all transactions once IBD completes (#1146)" (atharaldsen, head `239556a6`), not merged. Prior cell (to 27 Oct): SNAPSHOT-HISTORY.
Covenant-id lookup	IzioDev 2100202631650062411 (16 Sep): UTXOs by covenant id "will be a future RPC endpoint". The pull is open: #1152 "UtxoIndex: covenant id index, adds paginated GetUtxosByCovenantIds RPC" (biryukovmaxim, opened 16 Oct 11:54:21Z, base `master`), head `6a68b291` "perf(indexes): guard covenant bucket scan with tail partition_point" (26 Oct 13:34:49Z), 22 commits, 42 files, +3060/−80, not draft, `mergeable_state` behind, not merged. Reviews: IzioDev CHANGES_REQUESTED (21 Oct 16:59:20Z); D-Stacks 58 and biryukovmaxim 27 COMMENTED reviews; no approval. Latest round (26 Oct, on `indexes/utxoindex/src/stores/covenant_ids.rs` and `rpc/grpc/core/proto/rpc.proto`): D-Stacks proposes a `bucket_index`/`partition_point` condition (13:28:10Z) because "this is an inner loop potentially we loop upto 5 thousand times per queried daa score on each covenant id otherwise, which i think is kind of heavy" (13:30:27Z); biryukovmaxim: "done in 6a68b2917: only runs the partition_point when the tracked bucket falls behind, bounded to spk_buckets[bucket_index..]" (13:35:03Z). On `rpc.proto` D-Stacks suggests a comment that without SPKs the value "should equal to the limit amount of utxos returned per page", maybe with a test (14:04:27Z), and adds "I am okay if we remove this cost for increased user experience in the "no spk specified" case" (14:05:01Z). #991 (UtxoIndex keyed by DAA score, paginated and cursor-based API) was merged 15 Oct 15:34:08Z by IzioDev (`7cc22fea`). #1159 "docs(rpc): get utxos by addresses v2 cursor comment reflects reality" (head `3aa6c11b`) is open. rusty-kaspa master `4edcbbcc` (19 Oct), newest tag v2.1.0. kips.dev and kccs.dev are IzioDev mirrors synced every 24h (2093118560822297060). Third-party indexers and tooling: STP-KAS/kaspa-builders. Prior cell (to 27 Oct): SNAPSHOT-HISTORY.
KIPs	kaspanet/kips master is still `e4ae233` (15 Jul 2026, #45). Header `Status` at that commit: Active: 4, 5, 9, 10, 13, 14, 15, 16, 17, 20, 21. 1 Implemented. 2 Proposed. 3 Rejected. 6 Draft (`Type: Informational`). KIPs 7, 8, 11, 12, 18, 19, 22, 23, 24, and 25 are not on master. They exist only as open pulls, which are proposals: #10 KIP-7 `0f61e48f`, #13 KIP-8 `c6215e6f`, #17 KIP-11 `36e92365`, #21 KIP-12 `7a03504f` and #44 KIP-12 `4fc711ac` (never adopted: IzioDev built a KIP-12 extension, "impacts? none. been frozen since" (2102390155055165622, 22 Sep); kasking77 says it was replaced by WalletConnect v2 (2103592029733441952), one dev's statement; successor draft is kccs #24), #33 KIP-18 `9f85c688`, #34 KIP-19 `dd12e6b6`, #37 KIP-22 `cdafc967` (no `Status` header), #40 KIP-23 `bdd3abd5`, #41 KIP-24 `028117f8` (header says Implemented; IzioDev calls it the txv1 spec, live since Toccata, with compute budget, covenant binding and lane committed to the txid (Kas-Smiths 150/7, 28 Sep); not on master), #42 KIP-25 `2a379a84`, #39 `KIP: TBD` multisig derivation `ec5db967`. The Toccata activation score is on the Live row, not in `kip-0021.md`. Per-pull headers and authors, and KIP-21 lane and sequencing rules (§2.1, §2.2, §6.7): SNAPSHOT-HISTORY.md. 20 Oct (watch): a second open pull now uses number 22. #48 "KIP 22: Pay-to-Public-Key-Hash via P2SH" by someone235 (header author Ori Newman), opened 19 Oct 11:51:56Z from branch `kip22`, head `b031344f` (3 commits; adds `kip-0022.md` and one README index line, 2 files, +49/−0). Header: `Layer: Applications`, `Status: Draft`, `Comments-URI` research.kas.pa topic 545. It defines a wallet convention, not a consensus change: a P2SH address whose redeem script is `<P> OP_CHECKSIG` (`P` a 32-byte x-only secp256k1 key), keys derived at `m / 22' / 111111' / account' / change / address_index`; "No consensus changes are required. Existing wallets can send to these addresses." The text says ordinary spends still reveal the public key. Open #37 "KIP22 - P2MR ScriptPublicKey for quantum resistance" (ezrasisk, since 6 Mar, `cdafc967`) also uses 22; a number in a pull is not an assignment. Ori Newman on X: "Published KIP 22 to help Kaspa users better protect their funds from future quantum attackers by keeping public keys hidden until spending" (2112159453373980836, 19 Oct 12:30:30Z), then "Following @IzioDev's advice, I changed it to a KCC" (2112206371630276885, 15:36:56Z), linking kccs #37 (see KCC-3/4/5). #48 was still open at the 20 Oct read (0 reviews, 0 comments). Hans Moog: "KIP-22 isn't a "complete" post-quantum solution, but it's an elegant, relatively low-cost way to significantly reduce the attack surface for quantum adversaries"; he names the window between broadcast and confirmation as the remaining attack (2112208967141069303, 15:47:15Z). IzioDev: ""No consensus changes are required", meaning it can be executed today!" (2112173461506273584). Asked whether Ledger software needs changes, Ori: "Correct, but I expect changes to be very minimal" (2112192631870812527). Draft proposals; not on master `e4ae233`; not Active. Prior cell (to 20 Oct): SNAPSHOT-HISTORY. 20 Oct (Build): read `kip-0022.md` at `b031344f` (API 06:22Z, saved): the redeem script is `<P> OP_CHECKSIG` with `P` "a 32-byte x-only secp256k1 public key", the path is `m / 22' / 111111' / account' / change / address_index`, Backwards Compatibility opens "No consensus changes are required.", and Motivation says "Ordinary spends still reveal the public key and remain vulnerable to quantum attacks during confirmation." The head commit `b031344f` "Remove sentence" drops "A separate purpose prevents reuse of existing P2PK keys." The kips README on master has no KIP-22 line; #48 adds it. #37 at `cdafc967` uses 22 only in its title and its file name `KIP22-P2MR-qr`, and the file has no KIP header. #48: 0 reviews, 0 review comments, 0 issue comments (every page). Draft, number not assigned. 21 Oct (watch): new open #49 "KIP-20: specify CovenantIDHash keying and add a test vector" by Silentpartnercoding (20 Oct 12:57:22Z / 14:57 CEST, head `7a383b9c`, 1 file `kip-0020.md`, +11/−1). It changes §3.1 to say the tag `"CovenantID"` is applied as the BLAKE2b key ("the raw 10 ASCII bytes; no padding, salt or personalization"), which is how rusty-kaspa computes it at `4edcbbcc` per the body, and adds the KCC-23 binding fixture as a §3.2 test vector (`covenant_id = c86366ce…394e`). The body says "No consensus change" and that rusty-kaspa #1157 pins the same vector (see Covenant-id lookup). 0 reviews, 0 comments. #48 (KIP-22) is unchanged: open, head `b031344f` (branch `kip22` at the same commit), 0 reviews, 0 comments. Ori Newman on X: "I wrote kip22 (now KCC-3) because I saw many ppl like you searching and implementing solutions, and I wanted to write a canonical solution for it" (2112430254941978741, 20 Oct 06:26:34Z / 08:26 CEST); on kccs the KCC-3 number is contested (see KCC-3/4/5). Builder use of the Draft path is tracked in kaspa-builders (third-party, not audited, not desk-tested). kips master still `e4ae233`. Proposals; not Active. Prior cell (to 21 Oct): SNAPSHOT-HISTORY. 21 Oct (Build): read against rusty-kaspa master `4edcbbcc` (code only, nothing built): `hashers.rs` L32 declares `struct CovenantID => b"CovenantID"` inside `blake2b_hasher!`, whose `new()` is `blake2b_simd::Params::new().hash_length(32).key($domain_sep)`, and `covenant_id.rs` starts from `kaspa_hashes::CovenantID::new()`. So the code keys BLAKE2b-256 with the raw tag, as #49's new §3.1 says. #49's vector (outpoint `206a0c31…13ef`:0, one output 90000000 sompi with script `51`, `covenant_id` `c86366ce…394e`) matches the text of `kcc-0023/vectors/conformance.json` on kccs main `1516a6c4`; the digest itself is not verified here. #49: 1 commit, 0 reviews, 0 review comments, 0 issue comments (every page, 06:08Z). 24 Oct (watch): two new items on kaspanet/kips, master still `e4ae2332`. Issue #51 (BigToe4life, 23 Oct 16:12:43Z, cc michaelsutton and biryukovmaxim): KIP-21 §5.3 "purges a lane when `last_touch_blue_score + F <= B.blue_score`. rusty-kaspa purges it one blue score later" (`consensus/src/pipeline/virtual_processor/bounds.rs`); "Section 5.4 matches the code." 0 comments. PR #50 (RandomBacon1597, 23 Oct 14:11:12Z, head `f2981bca`, one file `kip-XXXX.md` +86): "Consensus: Propose epoch-bound domain separation & count-bound LtHash (KIP-XXXX)"; 0 reviews, 0 comments. Neither is checked against code here. #37, #48 and #49 unchanged. Prior cell (to 24 Oct): SNAPSHOT-HISTORY.
Not live	DAGKnight = KIP-2 Proposed. No 100 BPS. No spendable L1 stable. Open on `dagknight`: #1104 `a5888da`, #1127 `3c267993`, plus #1124/#1122/#1121/#1119/#1103. `dagknight` tip `ad45e24` (8 Sep). 26 Sep 18:02Z: #1132 and #1131 closed unmerged (STP-KAS). Both were the desk's own pulls (opened by STP-KAS 14 Sep), closed by STP-KAS itself; the head was force-pushed one second later to `dc2b59f3` (rewritten, noreply author) in the window of the 26 Sep privacy rewrite. #1132 was the parent-shuffle property test the desk had asked for before #1104; it drew no review or comment from anyone else. No replacement shuffle test exists: #1104 head `a5888dab` and the `dagknight` tip carry only `test_parent_ordering_stability` (#1104 protocol.rs L842, `ad45e24` protocol.rs L1027). 28 Sep: a local paste of dagknight-test-grok `tests/parent_shuffle.rs` passed at both commits (cargo 1.97.1). Seeds 0..32 did not move the selected parent, and both commits picked the same one (`Hash::from_u64_word(5)`). #1104 still has `sort_unstable()` at protocol.rs:182. The paste is not on either commit. #1135 merged 2026-10-13T11:12:28Z as `12db0f35` (someone235; title "Require explicit opt-in for non-SIG_HASH_ALL PSKB signing"). Not a DAGKnight pull. The earlier open head `aaa5f25f` and IzioDev's 9 Oct approval are history; the merge commit is `12db0f35`. Also open on master since 4 Oct (atharaldsen; head `a7c8ef0c` of 10 Oct 15:20:02Z; someone235 CHANGES_REQUESTED 10 Oct 05:03:19Z on `11aca108` and again 12:09:41Z on `36c72bf3`; atharaldsen replied "Done in a7c8ef0c" at 15:20:15Z; no maintainer review on `a7c8ef0c` yet (the reviews API lists only atharaldsen's own COMMENTED reply on it, 15:20:15Z; read 10 Oct 18:00Z)): #1141 `11aca108` drops `TRANSIENT_BYTE_TO_MASS_FACTOR` (4 grams/byte) and sets the transient limit as a byte cap, 1,000,000 → 250,000 per network; the author says the block byte cap and normalized transient mass stay the same (supersedes closed #1025 on `toccata`); `36c72bf3` and `a7c8ef0c` change comments and test labels only, and the limits stay 250,000 transient, 500,000 compute and storage. Desk check of the PR diff: cofactor math holds (old 4×0.5 = new 1×2.0). #1142 head now `fc681149` (12 Oct 18:49Z; was `644baafe`) replaces `VirtualState::accepted_id_digests` (a pre-KIP-21 `Vec<Hash>`) with a one-hash `SeqCommit`; the PR's unit test asserts the one-element encoding is byte-identical to `vec![hash]`. Decoding also maps an empty vector to the zero hash, an extra compatibility path for placeholder states written by earlier binaries (`virtual_state.rs` at `644baafe`, test `decodes_empty_vec_as_zero_hash`). #1141 stays open. #1142 merged 2026-10-13T10:19:49Z as a92c4f9f31c72d135da3399880f355702ee98ae1. biryukovmaxim APPROVED 2026-10-13T10:14:19Z on fc681149 and left from_legacy for another pull. That merge is on master. It is not a new release tag. #991 (UTXO index keyed by DAA score, new `get_utxos_by_addresses_v2`) head `77d9a2e8` (3 Oct 08:58Z) is not merged; the CHANGES_REQUESTED reviews stand and GitHub says `blocked`. On 9 Oct 14:52–14:57Z IzioDev left five COMMENTED inline notes on `77d9a2e8`, all cleanup: an unintended `ci.yaml` change and whole-file reformat, unused code and `Ord`/`PartialOrd` derives in `script_public_key.rs`, and a removable `indexes/core/Cargo.toml` line (first); no new review state. Four commits after `2e05b7cd`: raise the safe max address count, rename `by_spk`→`from_spk`, move the cursor-is-first-address check to the RPC layer, and make `start_address` optional so the cursor can take the first request address. `03dd516c` drops the blanket `unsafe_rpc` gate on that call; safe mode caps the address count and page size instead (`service.rs` L850-853 at `77d9a2e8`). Read at `1f15c618`: it would delete and rebuild a legacy utxoindex after a prompt. The DAGKNIGHT paper is KIP-2 Proposed and is not mainnet. Do not merge it with GHOSTDAG. See Consensus papers. Dated detail: SNAPSHOT-HISTORY.md. 11–12 Oct: #1146 still open; PR #1147 (proposed fix) open, changes requested 13 Oct (see TN10 public API). #850 (optimize utxo write, opened 28 Jan by its author Psalmuel01, head `b53879ab`) got a 10 Oct 20:22:47Z supertypo comment with his own batch-write timings (1k UTXO 14.1→1.1 ms; TN10 UTXO download 83→20 min); not merged, no new review state. D-Stacks (COLLABORATOR) on #850 (comment, 11 Oct 16:20:36Z): "I'd like to mention I also still have an open PR that implements batched writes properly: kaspanet/rusty-kaspa#814". #814 ("Optimization and Refractor: UTXO index and database iterators.", D-Stacks, opened 12 Jan 19:15:22Z) is open and not merged, head `bec82b13`, base `master`, last updated 22 Mar 17:19:48Z, GitHub `mergeable_state` dirty (API read 12 Oct 05:54:44Z). Neither pull is merged; #850 still has no reviews. OriNewman (2108969274832273564, 10 Oct 17:13:52Z), replying to aglovale0x (2108927151642660977, 14:26:29Z), who asks for one deterministic P2SH (`kaspa:p`) address standard that wallets, hardware wallets and exchanges all support: suggests a KIP documenting how to implement such a P2SH address scheme, and adding it to the rusty-kaspa wallet as a reference implementation — talk only, no KIP/PR yet. Build read of #850 (05:55:14Z, server `Date`): `utxo-write` → `master`, 4 commits, 1 file, GitHub `mergeable_state` behind, no reviews; someone235 asked for a benchmark on 30 Jan. supertypo's timings are his own runs, not desk-run. Prior 11 Oct cell: SNAPSHOT-HISTORY. Build read of #814 (06:07:13Z, server `Date`): 22 commits, 25 files (+385/−228), no reviews; its body claims batch writes cut utxoindex resync time by "about 30-50%", "although this might be hardware dependent" (author's claim, not desk-run). #850 at 06:07:11Z: still open at `b53879ab`, `mergeable_state` behind, not merged. 13 Oct: #1148 "Add lowio RocksDB preset" by supertypo, opened 12 Oct 11:34:36Z on `master`, head `e3773118`, 1 commit, 5 files (+115/−10), merged 2026-10-14T12:30:32Z as `2ea8e9d1` (biryukovmaxim APPROVED 2026-10-14T11:49:34Z on `35725536`, "LGTM!"). Author's PR: a `--rocksdb-preset=lowio` for pruned nodes (4×256MB write buffers scaled by `--ram-scale`, ZSTD level 1, BlobDB LZ4 for values >512 B, 1GB block cache scaled, no rate limiting); his mainnet-from-scratch LAN sync table claims ~50% fewer bytes written, ~99% fewer compactions, ~10% faster IBD (his runs on Ryzen 9 5900X + NVMe, not desk-run). Node-tools material; merged as above; not desk-built or desk-tested. #991 (still head `77d9a2e8`, open, `blocked`): biryukovmaxim submitted a CHANGES_REQUESTED review on that head on 12 Oct 11:56:19Z (review 5490183821, empty body) with five inline comments (11:36:51Z–11:55:28Z) — style/limit points (4247568710 "isnt it aleady a vec"; 4247627417; 4247640250; 4247654123 default limit smaller than `usize::MAX`; 4247720588). His earlier review states: CHANGES_REQUESTED 21 Jul (`7372a815`) and 11 Sep, COMMENTED 23 Sep. #1142: biryukovmaxim CHANGES_REQUESTED 12 Oct 14:40:43Z on `644baafe` (drop `PreToccataVirtualState`, `repr(transparent)`, custom visitor / no heap allocs); atharaldsen pushed `fc681149` and replied on the four threads (18:49Z), each citing fc681149; his issue comment asks whether removing `PreToccataVirtualState` is safe given the 6→7 DB bump does no migration. Still open, no maintainer review on `fc681149`, `mergeable_state` blocked. Prior cell: SNAPSHOT-HISTORY. Build read (13 Oct, server `Date`): #1148 at 06:01:46Z: open, not draft, head `e3773118`, 1 commit, 5 files (+115/−10), no reviews, no comments, `mergeable_state` blocked; a proposed preset (unreviewed). The diff adds `RocksDbPreset::LowIo` (`rocksdb_preset.rs` L34–L42), parsed from `lowio` (L52); `apply_lowio` (L190–L229) sets four write buffers of `mem_budget / 4`, ZSTD compression, a 16KB-block LRU cache (1GB unless `--ram-scale` sets a budget), Bloom filters with partitioned two-level indexes, and BlobDB (LZ4, min blob 512 B, GC age cutoff 0.1). `mem_budget` (L254–L257) gives 1GB for lowio, scaled down by `--ram-scale` to at least 256MB, and 64MB for default and hdd, with a unit test (L276–L284). The budget is threaded through `configure_rocksdb` (`kaspad/src/daemon.rs` L224–L273) and `Factory` (`consensus/src/consensus/factory.rs` L263) into every `with_mem_budget` call; `kaspad/src/args.rs` L442–L443 adds `lowio` to the help text. The performance numbers are the author's runs; not desk-built or desk-tested. #991 at 06:02:08Z: the reviews API lists 5490183821, biryukovmaxim CHANGES_REQUESTED submitted 12 Oct 11:56:19Z (13:56 CEST) on `77d9a2e8`, and all five 12 Oct inline comments carry that review id. #1142 at 06:02:11Z: open, head `fc681149` (2 commits, 3 files, +133/−38); the reviews API shows biryukovmaxim CHANGES_REQUESTED 5492168373 (12 Oct 14:40:43Z, 16:40 CEST) on `644baafe` and only atharaldsen's own COMMENTED replies on `fc681149` (18:49:29Z–18:49:34Z). His comment (18:49:43Z, 20:49 CEST) says he wants to check one thing before removing `PreToccataVirtualState`: the 6 → 7 DB bump does no migration, so dropping only that shadow would make a node opening a v6 DB start from an empty virtual state without an error. He asks whether in-place v6 upgrades are still supported and offers two paths. Proposed change (unreviewed on `fc681149`); not desk-built. 15 Oct (Build catch-up, API 16:19Z): #991 merged 2026-10-15T15:34:08Z by IzioDev as `7cc22fea`, after biryukovmaxim APPROVED at 15:32:52Z on head `bc1000b6`; `7cc22fea` is now the master tip. Not a release; the tag is still v2.1.0 `01b532e8`. Not desk-built. #1147 is still open: head `239556a6` is a merge of master (15 Oct 05:41:40Z); michaelsutton CHANGES_REQUESTED 13 Oct 11:04:27Z on the earlier head `b4df2d8f`, no review on `239556a6`. New: #1150 by atharaldsen (14 Oct 22:07:47Z, head `7ada0025`, 2 files, +79/−0), open, unreviewed; the author says it fixes a mempool-full assert panic when a transaction sits in both the orphan pool and the transaction pool. That is a proposed fix (unreviewed), not desk-tested. Prior cell (to 14 Oct): SNAPSHOT-HISTORY. Prior cell (15 Oct, before the F1/F2 fix): SNAPSHOT-HISTORY. Build read (15 Oct, API 16:27Z): #1147 head `239556a6` (3 commits, 7 files, +460/−11) still adds `revalidate_all_transactions` in `mining/src/manager.rs`, so the IBD-chunk approach atharaldsen proposed on 13 Oct (comment) is not in the code yet. #991: biryukovmaxim's APPROVED 5535705448 at `bc1000b6` follows his CHANGES_REQUESTED reviews of 21 Jul, 11 Sep and 12 Oct (the last is 5490183821). 16 Oct (X): Sutton 2110864864021238014 (15 Oct 22:46:16Z), replying to aKaspamaxi asking whether DAGKnight is still expected before 2027: "we’re all in on it and doing our best. it’s a white/yellow/black (research/specs/code) effort happening in parallel with various relationships" X, his reading; not a ship date and not a KIP status change. KIP-2 stays Proposed; `dagknight` tip still `ad45e241`. Build check (16 Oct): the wording of 2110864864021238014 quoted above matches the challenger's live read on 16 Oct at 07:57 CEST (challenge note `7050b47`), with no closing period in the original. Build made no X call, and the watch raws hold only a label for this post. `dagknight` tip still `ad45e241` (ls-remote 05:57Z). 17 Oct (watch): #1060 "Consensus core nostd" (biryukovmaxim, opened 21 Jun) merged 2026-10-16T12:03:37Z as `f7d78773` after michaelsutton APPROVED at 12:03:17Z; `f7d78773` is now the master tip (ls-remote 05:47Z). Per the PR body, `kaspa-consensus-core` and its primitive crates now build for `no_std` (the CI gate builds them for `thumbv7em-none-eabi`), and `std` stays the default feature. Not a release; the tag is still v2.1.0 `01b532e8`. Not desk-built. KeenHero closed his own unmerged #1092, #1093, #1094, #1095 and #1097 on 17 Oct 05:12Z (not merged). `dagknight` tip still `ad45e241` (ls-remote 05:47Z). Prior cell (to 17 Oct): SNAPSHOT-HISTORY. Build check of #1060 (17 Oct): merged 16 Oct 12:03:37Z by michaelsutton as `f7d78773`, 155 files; `f7d78773` is the master tip (API 05:53Z). In that commit the CI no_std job changes from `cargo check` to `cargo clippy --target thumbv7em-none-eabi --no-default-features ... -- -D warnings` and adds `kaspa-txscript-errors`, `kaspa-math`, `kaspa-muhash` and `kaspa-consensus-core` to the checked crates (`.github/workflows/ci.yaml`). `consensus/core/Cargo.toml` gains a `std` feature, with `default = ["std", "sign", "metrics", "atomic-mass", "workflow", "sighash-sync", "wasm32-sdk"]`, so default builds keep std. Releases API: latest is still v2.1.0 (22 Sep); not a release. The security-advisories API returns an empty list (17 Oct), so the v2.1.0 disclosure claim is not recorded. Build (18 Oct, every page): #1150 head is now `3f7d591a`, atharaldsen's merge of master `f7d78773` into the branch (17 Oct 08:24:17Z); the only other commit is `7ada0025`. 0 reviews, 0 comments, `mergeable_state` blocked. Still a proposed fix (unreviewed). rusty-kaspa master is still `f7d78773`; latest tag v2.1.0 `01b532e8`. 19 Oct (watch): #1141 (atharaldsen) is now three new commits on top of master `f7d78773`: `51a0c771`, `556224cb` and head `1d77a486` (all committed 19 Oct 05:28:31Z; 10 files, +52/−46). The diff still sets transient 250,000 with compute and storage 500,000 in each `BlockMassLimits` it touches, and charges transient mass 1:1 per serialized byte. someone235 APPROVED at 05:28:58Z (review), then CHANGES_REQUESTED at 05:32:36Z: "Build fails after rebase" (review); both on `1d77a486`. Not merged; `mergeable_state` blocked. Proposed code, not desk-built. Also: #863 (Drop for `KaspaRpcClient`) head `41a9f4e6` is a merge of master into the branch (18 Oct 18:36:33Z; catch-up). rusty-kaspa master still `f7d78773`; latest tag v2.1.0. Prior cell (to 19 Oct): SNAPSHOT-HISTORY. Build check of #1141 (19 Oct, every page: 7 reviews, 6 review comments, 0 issue comments): the order holds: APPROVED 05:28:58Z, then CHANGES_REQUESTED 05:32:36Z with the body "Build fails after rebase", both on `1d77a486`. Read from the code (no build): the PR deletes `TRANSIENT_BYTE_TO_MASS_FACTOR` from `consensus/core/src/constants.rs`, but at `1d77a486` four uses remain in `wallet/core/src/tx/mass.rs` (L148, L153, L172, L189), a file the PR does not touch. Those lines came to master with #1074 (`6768648`, 14 Oct), after the PR's earlier base; `git grep` on master `f7d78773` finds 23 matching lines (`wallet/core/src/tx/mass.rs` L148). The project's CI on `1d77a486` agrees: the Check job log shows "error[E0425]: cannot find value `TRANSIENT_BYTE_TO_MASS_FACTOR` in this scope" at those four lines and "could not compile `kaspa-wallet-core`"; 7 of 8 check runs failed (Check no_std passed). Not merged. Close watch (every page): #1150 head `3f7d591a`, 0 reviews, 0 comments; #863 head `41a9f4e6` is a merge of master `f7d78773` (18 Oct 18:36:33Z), 0 reviews, 10 issue comments, none after `2026-10-18T05:46:00Z`. 20 Oct (watch): rusty-kaspa master moved from `f7d78773` to `4edcbbcc` with three merges on 19 Oct: #1154 (michaelsutton, "Fix workspace packaging for future crates.io releases"; merged by IzioDev 13:08:00Z as `91888a4a`; the body says these fixes "were used to publish v2.1.0 (excluding the spin fix)"), #1153 (0xlegacydag; adds `src/*/.asm` to the workspace `include` list because the published `kaspa-hashes` 2.1.0 ships without its MSVC `.asm` file and does not build on `x86_64-pc-windows-msvc`; merged by michaelsutton 14:08:23Z as `24854ef8`; "It takes effect with the next crates.io release") and #1065 (aspect, "workflow-rs v0.19.0 (maintenance release update) + Client SDK wRPC TLS features", opened 27 Jun; APPROVED by IzioDev 14:41:38Z and biryukovmaxim 14:48:01Z; merged by biryukovmaxim 15:05:13Z as `4edcbbcc`; 28 files, +931/−696). No new tag: latest still v2.1.0. New, open: #1156 (supertypo, "Improved pruning: Delete set buckets without range deletions", 19 Oct 21:59:34Z, head `cbcbc94c`, 2 files, +27/−4, 0 reviews): point-deletes each set bucket's members instead of one RocksDB range deletion per bucket; his mainnet measurement (ARM64 VPS) is 175,000 blocks traversed in 1h 49 min before and 164,000 in 5 min 13 s after (his figures, not desk-run). #1155 (freshair18, merkle memory optimization) closed unmerged at 22:47:45Z: "For the time being I do not see this as substantial enough to care about." #1141 unchanged: head `1d77a486`, the 05:32:36Z CHANGES_REQUESTED is still the latest review, `mergeable_state` now behind (master moved). Close watch (every page): #1150 head `3f7d591a`, 0 reviews; #863 head `41a9f4e6`, nothing after `2026-10-19T05:44:00Z`. Prior cell (to 20 Oct): SNAPSHOT-HISTORY. 20 Oct (Build): API 06:23Z confirms the three merges and master `4edcbbcc` (15:05:13Z). The #1153 diff is one line in the root `Cargo.toml` `include` list, `"src/*/.asm",`; the MSVC build failure of `kaspa-hashes` 2.1.0 is the pull's own report, not verified here. Tags: 56, newest still v2.1.0. #1141: no new head after `1d77a486` (3 commits; updated 19 Oct 05:32:52Z); `wallet/core/src/tx/mass.rs` is not among its 10 files. The CI `Check` job (cargo check on `1d77a486`, 19 Oct 05:29Z, log saved) reports four `error[E0425]: cannot find value TRANSIENT_BYTE_TO_MASS_FACTOR in this scope` at `wallet/core/src/tx/mass.rs` lines 148, 153, 172 and 189, so the 19 Oct likely cause is now the logged one. 7 of 8 check runs failed; `Check no_std` passed. Not built here. #1156 (`cbcbc94c`, 2 files, +27/−4): `DbSetAccess::delete_bucket` now point-deletes each member of the bucket instead of one RocksDB range deletion, and `StagingReachabilityStore::delete` also drops the staged children and future covering set of the deleted block; open, no review. Not desk-built. 22 Oct (watch): new draft #1158 (freshair18, "Batch IBD UTXO import writes with bounded buffers", opened 21 Oct 14:57:54Z, head `09713b69`, 4 files, +220/−4, 0 reviews, 0 comments): when IBD writes the new UTXO set to the pruning-point and virtual stores it uses a batch writer, flushed every 1000 entries or about 1 MB, instead of a direct writer. The body says "Codex suggested optimization" and reports, on a fresh database, "a very minor speedup during the utxo download stage, and a ~16% speedup during virtual utxo importing" (his figures; "I have not extensively tested this yet"). Not desk-built. rusty-kaspa master still `4edcbbcc`; tags unchanged (newest v2.1.0); #1141 `1d77a486`, #1156 and #1157 `8d2cac87` have no new activity. Prior cell (to 22 Oct): SNAPSHOT-HISTORY. 22 Oct (Build): diff read at `09713b69` (no build). In `consensus/src/model/stores/utxo_set.rs`, a new `UtxoImportWriter` buffers writes in one RocksDB `WriteBatch` and writes it to the DB when it reaches 1000 entries or 1 MiB (`1 << 20` bytes), and once more at the end of each call. It is used only by two new IBD methods: `write_imported_chunk` (pruning-point import, from `consensus/mod.rs`) and `copy_imported_from_iterator` (copy into virtual, from `virtual_processor/processor.rs`). Ordinary UTXO writes keep their writer. `utxo_set/import_tests.rs` checks that batched imports give the same rows as direct writes, including last-write-wins across a batch boundary, and that the copy path updates the cache. It also checks that the writer flushes at the entry and byte bounds and keeps the tail until the final flush. A third disk benchmark test is `#[ignore]`. Draft, not merged; the ~16% is the author's figure. 23 Oct (watch): On 23 Oct 07:25:49Z michaelsutton commented on #1153: "patched: https://crates.io/crates/kaspa-hashes/2.1.1/code/src/asm/keccakf1600_x86-64-msvc.asm"; crates.io lists `kaspa-hashes` 2.1.1, created 23 Oct 07:06:18Z. Prior cell (to 23 Oct): SNAPSHOT-HISTORY. 25 Oct (watch): two new pulls on rusty-kaspa `master` by parthod0x on 24 Oct, both open, 0 reviews. #1160 "fix(mempool): remove the actually-spent outpoint in add_transaction" (20:04:28Z, head `fc6b57f6`, 1 file `mining/src/mempool/model/utxo_set.rs`, +63/−5): per the PR body, `MempoolUtxoSet::add_transaction` removes the key `(this_transaction_id, i)` from `pool_unspent_outputs` where the comment says the spent output (`input.previous_outpoint`) should go; the author calls it "Benign, non-consensus (`kaspa-mining`)" and says `pool_unspent_outputs` is currently write-only. #1161 "test(math): exercise overflowing_shr instead of overflowing_shl twice" (20:10:07Z, head `9d33f54e`, `math/src/uint.rs`, +2/−2): per the PR body, the `test_u128` block named for `overflowing_shr` calls `overflowing_shl` on both sides. The author's reading; not reviewed by a maintainer, not desk-built. rusty-kaspa `master` still `4edcbbcc`, newest tag v2.1.0. Prior cell (to 25 Oct): SNAPSHOT-HISTORY.
TN13 / DK plan	No public TN13 genesis. Not live. Not mainnet. KIP-2 is Proposed. Open plan issues on rusty-kaspa: #1113 (DK-209, public devnet), #1118 (DK-406, public testnet), #1112 (DK-208, adversarial Simpa miner). Merged into branch `dagknight`: #1105 (4 Sep), #1120 TN params and DK activation wiring (6 Sep, `95735e69`), and #1125 (8 Sep), whose merge `ad45e241` is the `dagknight` tip. Sutton (3 Sep): six milestones; the first two are incremental algorithms and a testnet with no security relaxation. Sutton (23 Aug): extremely high BPS and DK are not to be mixed. Sutton (2110998749463929081, 16 Oct 07:38:16Z, replying to aKaspamaxi's question on a 2026 or 2027 DK release): "i believe we can get to a stable (and secure) testnet this year"; his belief about a DK testnet, not a mainnet date. Same morning (2110989422569132045, 07:01:13Z): "in parallel with dk, applications, including stables, are a high priority as well". Talk: Sutton (2114708411686248662, 26 Oct 13:19:09Z), quoting the Web3 Devs Underground broadcast "Mid-Chain @ BGU · Part 2: Sessions 3–4, Noam Nisan & Yehuda Lindell" (2114689128738721947): "hashdag (“Opening the Pandora box” with Ori Newman) & myself (DAG Knight), speaking here next"; later (2114817540840886418, 20:32:47Z) "i started here:" with the recording. The talk was not watched here, so its content is not described. Developer posts from August: SNAPSHOT-HISTORY.md. Prior cell (to 27 Oct): SNAPSHOT-HISTORY.
KCC-0	Final in the file. `kcc-0000.md` says `Status: Final`. #25 merged `c0bb8f3` at 21 Sep 13:31Z. The README index says Final too since #34 `411b41bc` (1 Oct 13:15Z). Final: the meta process and, since 21 Oct, KCC-1, KCC-2 and KCC-20; not KCC-0012 or KCC-23 (both Draft). See KCC still open. Main tip was `3fbec524` (7 Oct 20:38Z); since 21 Oct 14:50:48Z it is `1ed87aef`. 21 Oct (r2): #40 merged at 11:32:06Z as `6f271b7b`; `kcc-0002.md` on main says `Status: Final` (raw read 13:53:44Z). Prior cell (to 21 Oct, r2): SNAPSHOT-HISTORY. 21 Oct (KCC-20 Final): #39 and #41 merged; all three `Requires`-chain files (KCC-1, KCC-2, KCC-20) say `Status: Final` on main `1ed87aef`. Prior cell (to 21 Oct, KCC-20 Final): SNAPSHOT-HISTORY.
Credible sites	kaspa.org and kaspaexplained.com are the same kind of source. Both are credible. Neither outranks a merged Active KIP or a release tag. Checked 22 Sep 2026: kaspa.org/lore says 10 BPS live, Toccata live at DAA 474165565, SilverScript v1.0.0 tagged, DAGKnight next. That is the same upgrade split as kaspaexplained.com/status. The older “do not cite lore” line is retired. 19 Oct (watch): kaspa.org/build now names Rusty Kaspa v2.1.0 as the latest release (three links to the v2.1.0 release page; read 05:49:18Z, HTTP 200, headers saved). That follows kaspamedia/kaspa-org#57 (elldeeone, merged 19 Oct 02:44:46Z as `6af357e4`), which "Updates the `/build` release banner and both “Latest release” links from v2.0.1 to v2.1.0". The release tag stays the pin. Prior cell (to 19 Oct): SNAPSHOT-HISTORY. Build (19 Oct 06:08:38Z, HTTP 200, CloudFront `Miss`, headers saved): kaspa.org/build links the v2.1.0 release three times; it still links two wasm examples under `v2.0.0` paths (`tree/v2.0.0/wasm/examples`, `blob/v2.0.0/wasm/examples/web/get-server-info.html`). The watch's header for its read says 05:49:18Z. #57 (every page) changed exactly two files: `src/app/build/constants.ts` (+2/−2: `KASPA_VERSION` and `RUSTY_RELEASE_URL` move from v2.0.1 to v2.1.0) and `public/llms-full.txt` (+3/−3, the same three links). The quoted body text matches the PR body byte for byte. 20 Oct (Build): kaspa.org/build HTTP 200, CloudFront `Hit`, `Date` 19 Oct 05:49:18Z (`age` 88701, read 20 Oct 06:27Z); `/build/` answers 308 to `/build`. Same links as 19 Oct: v2.1.0 release three times, the two `v2.0.0` wasm example paths. 21 Oct (Build): kaspa.org/build HTTP 200, CloudFront `Hit`, `Date` still 19 Oct 05:49:18Z (`age` 174228, read 21 Oct 06:13Z); same links.
Referee lag	kaspaexplained /status, re-read 27 Oct (HTTP 200, server `Date` 06:43:02Z; the page says "Sources checked October 6, 2026"), says "KCC-1 and KCC-2 are in Last Call since October 1" and "KCC-20 is Draft". On kccs main `1ed87aef` (21 Oct 14:50:48Z) KCC-0, KCC-1, KCC-2 and KCC-20 say `Status: Final`. Site repo parker2017code/kaspa-explained tip `e48f53b8` (6 Oct 08:21:27Z). Prior cell (to 27 Oct): SNAPSHOT-HISTORY.
KCC-20 wording	`kcc-0020.md` on kccs main `1ed87aef` says `Status: Final` (merged as #41, `9dec4a04`, 21 Oct 14:50:46Z); its text is unchanged from Last Call (one-line diff). Michael Sutton, 20 Sep: a properly written KCC-20 covenant gets L1 enforcement of those rules; KCC-20 itself is a spec. One buggy instance is not a verdict on the script engine, and it is not “KCC-20 shipped.” Same morning he separated KRC-20 (off-chain interpretation) from covenants. KRC-20 to KCC-20 migration: replying to GabrielNico21 (2109049463302156773), who asked whether a token can still migrate to KCC20 if its KRC-20 minting is unfinished, Sutton (2109305350008475670, 11 Oct 15:29:19Z) wrote: "yes it can migrate with the same rules. it will need a custom migration with the target KCC-20 contracts supporting the same public minting policy over the remaining supply. (my answer is not specific to some migration proposed by specific entities which i know nothing about; it’s about the conceptual question)" KCC-20 vs Solana: HuseyinSivridag asked (2109311950651834538): "Will the Kcc20 smart contract language possess the full smart contract capabilities of Solana?" Sutton (2109315001034875348, 11 Oct 16:07:40Z): "not easily, no. a solana program has more capabilities and can be longer and more expressive." … "we are not a solana vm by design" … "my strong hypothesis is that it enables significantly complicated systems." … "(the answer above is all within pure covenants and does not talk about based zk apps, which are as fully expressive as a solana program but currently have limited L1 composability that depends on zk proof submission)". His "contention over shared variables/state" is the open question of Kas-Smiths topic 160; see Kas-Smiths. KCC-20 scope: replying to frank_r2d2, Sutton (2109247664554418250, 11 Oct 11:40:05Z): "KCC-20 makes stablecoins a practical reality on Kaspa, yes"; (2109253446788317528, 12:03:04Z): "that is not implied from KCC-20, since it’s merely a standard. it should be possible to build privacy features over current Kaspa L1 capabilities but they inherently require usage of zk opcodes which out of KCC-20’s scope"; the posts he answered were not read, so what "that" refers to is not stated. Manyfest (2112920461176655927, 21 Oct 14:54:28Z): "Today KCC-20 finalization gives the ecosystem a shared convention for defining, deploying, interacting with, and composing fungible token assets." Statements; the status is the file. Prior cell (to 27 Oct): SNAPSHOT-HISTORY.
KCC still open	kccs main `1ed87aef` (21 Oct 14:50:48Z, "KCC-1: advance to Final (#39)"). The README index lists KCC-0, KCC-1, KCC-2 and KCC-20 as Final and KCC-23 as Draft; the file headers match (raw reads 27 Oct, server `Date` 06:46:39Z). saefstroem merged #40 (KCC-2, `6f271b7b`, 21 Oct 11:32:06Z), #41 (KCC-20, `9dec4a04`, 14:50:46Z) and #39 (KCC-1, `1ed87aef`, 14:50:49Z); compared with the Last Call text of #31 (merge `3fbec524`, 7 Oct 20:38:09Z), each of the three files changes by one line (the Status header). KCC-0 §4: a Standards Track KCC moves to Final only when "every entry in `Requires` is itself Final (for KCCs) or Active (for KIPs)". `kcc-0020.md`: Category Application, Requires KCC-1, KCC-2, KIP-20; Comments-URI topic 8. Owner schemes `0x01` and `0x02` still name `P2PKHHash` (4 occurrences), a name KCC-2 no longer defines: since #30 (`90beacd0`, 27 Sep) KCC-2 uses unkeyed BLAKE3, `Hash(pubkey)`, for P2PKH. Borrow schemes are exclusive bytes, not bit flags: `0x00` disabled, `0x01` amount-threshold, `0x02` schnorr-signature, `0x03` hash-chain; a conforming program must recognize disabled and support all three enabled schemes. Default max token inputs and outputs are 3. Reference Implementation links argent-lang/kcc20-reference. Open pulls on kccs (27 Oct): #38 "introduce kcc3: segregated hierarchy for HD wallets" (IzioDev, head `299f6a0b`), #37 "Pay-to-Public-Key-Hash via P2SH" (someone235, head `8088f5c5`), #36 "Introduce initial draft for Covenant v2" (Curious-being99, draft), #35 "Draft: Mobile Wallet Session and Pairing API (unnumbered KCC)" (danieliyahu1, draft), #29 "Reputation, bond, and identity registry covenant KCCs" (kaspahttp402, head `55742861`), #24 "KCC12" (saefstroem, head `8e1053ec`), #4 "KCC-0402: Covenant Payment Channels" (Kali123411, head `39a42644`); none merged. @kccforum (2112922357979603258, 21 Oct 15:02:00Z): "KCC-1, KCC-2 and KCC-20 are now Final, meaning they are ready for full adoption across the ecosystem". Hans Moog (2113053125154160767, 21 Oct 23:41:38Z): KCCs set a "common language" so apps can be composed without knowing each other, and "this doesn't introduce new "on-chain" features". Prior cell (to 27 Oct): SNAPSHOT-HISTORY.
KCC20 reference	Merged. argent-lang/kcc20-reference#1 was merged by michaelsutton at 2026-10-07T19:50:09Z. Merge commit `c8a08711` was argent-lang `master` until 21 Oct (pin now `27f8403f`, see the end of this cell). Head `0175e2de` (7 Oct 19:09:30Z), Manyfestation, "Publish KCC20 token artifact with reference documentation". Parent `6dda3631`. The head ref was `finalize-kcc20-reference` on Manyfestation/kcc20-reference. 20 commits. Not a KCC status change. Not a spendable token. 9 Oct Kas-Smiths 408 (michaelsutton): the standard's role is not a “leader must be my own template” check for the delegator path; the contract verifies the leader (reference kcc20.ag L192); a batch leader belongs only as an optional separate KCC. Forum, his reading; not a KIP; not Final. Build check: at `c8a08711` that line is `leader: KCC20` in the `consumes` block of `delegate transfer_delegator` (L189 to L195). The post is hedged ("If anything, I think it should only be an optional addition/extension (ie in a different KCC)") and invites correction; Ross replied in 410 (10 Oct 01:32Z) that he withdraws the extension idea. `kcc-0020.md` on `3fbec524` names this repository under Reference Implementation. Sutton 2107936465628066024 (7 Oct 20:49:51Z) shows this merged badge beside kccs #31 (image content per the desk's 7 Oct read; the saved 8 Oct raw has only the eyes emoji and a photo link). No check run on the merge commit. Five reviews, all `COMMENTED` (10-11 Sep). No approving review. No check run on the head. The diff adds `fixtures/public-mint/kcc20.json` and a README section. Contracts are unchanged. `f7a27ce4` (19:03:21Z) and `e29e3e3c` (19:05:56Z) share that parent and the author date 19:02:54Z. They are not ancestors of the head. `f7a27ce4` moved `fixtures/public-mint/` to `artifacts/public-mint/` and added an extension paragraph. `e29e3e3c` put the file back under `fixtures/` and kept the paragraph. `0175e2de` keeps `fixtures/` and drops the paragraph. The json names `transfer` and `transfer_delegator`, owner schemes 0 through 4, and max token inputs and outputs 3. Sibling `artifact.json` still has tags `79c71c23` and `fd3ef14a`. `kcc20.ag` still uses unkeyed `blake3(public_key)`. `MAX_DELEGATES` is 2 and `MAX_TOKEN_OUTPUTS` is 3. `public_mint.rs` and the lifecycle launch use 32 zero bytes for the extension commitment. The dropped paragraph said that zero is a reference convention and that the artifact has no extension object. `PublicMint.split` still takes no deposit-owner signature. `TokenSeed.create` still requires amount zero. The README still says split and reclaim lack a full conformance suite. `kcc-0020.md` on `3fbec524` is Last Call and still writes `P2PKHHash`. `cargo test` was not run. No upstream comment. Prior head `6dda3631` (7 Oct 15:48:31Z), Michael Sutton, "test kcc20 conformance vectors against the reference contract". Parent `72767847`. Branch `finalize-kcc20-reference`. Adds `fixtures/kcc20/conformance.json` and `src/bin/kcc20/tests/conformance_vectors.rs`, plus a `serde_json` dev-dependency and a README paragraph. GitHub says `clean`. 19 commits. argent-lang master was still `76648f99`. Five reviews, all `COMMENTED` (10-11 Sep). No approving review. No check run on the head. The commit message says all 60 tests pass and that clippy and formatting are clean. This desk did not run them. The new file has 6 `#[test]` functions, so the source count is 60 beside the 54 counted at `8c8dc8ee`. The fixture says `kcc` 20 and `format_version` 1. Dispatch tags stay `79c71c23` and `fd3ef14a`. State field types are `int`, `byte[32]`, `byte`, `byte`, `byte[32]`, `byte[32]`, encoded length 112. It says every sig and pubkey is a placeholder for no known key, and that no vector asserts a signature check. The VM tests replace those placeholders with real keys and recompute the hash-chain commitment. Six standard-transfer cases reject: negative amount, unsupported owner scheme, witness path `0x02`, extension commitment not preserved, totals 1100 against 1000, and 4 inputs over max 3. Sixteen borrowed-receive cases: accept `threshold-exceeded`, `threshold-zero`, `threshold-negative`, `threshold-negative-zero`, and `hash-chain-valid`. The other eleven reject, including an unchanged negative threshold, a decrease, a guard that is not preserved, and a hash-chain link mismatch. The README still says split and reclaim do not yet have a full conformance suite. Tests still do not submit. Prior head `72767847` (7 Oct 13:44:58Z), Manyfestation, "Refine README around KCC20 convention and reference app". Parent `8c8dc8ee`. The diff of that commit is `README.md` only (+156/-176). The linked compare `8c8dc8ee..898192dc` is `898192dc` (13:39:21Z, README.md +153/-176). Two more README commits followed: `cc86ca59` (13:42:58Z) and `2058c13c` (13:43:29Z). At 13:44:58Z those three left the branch. `72767847` replaces them. Its README bytes match `2058c13c` (9499 bytes). Contracts, fixtures, Cargo pins, and the dispatch tags read at `8c8dc8ee` are unchanged. At that head GitHub said `clean`, with 18 commits on the pull. The new README sends scheme definitions to kaspanet/kccs `main` kcc-0020 §1, §2, §5, and kcc-0002 §2.1. Those headings are on main `411b41bc`. `kcc-0020.md` there then said `Status: Draft` and still writes `P2PKHHash` twice. The README no longer prints the owner-scheme byte table, the borrow table, or the unkeyed BLAKE3 sentence. It says anyone can `split`, and that minting and splitting need no deposit-owner signature. It says output scheme validation covers all 256 byte values, and that the split and reclaim entrypoints do not yet have a full conformance suite. The genesis section says deploy by a genesis transaction: one `PublicMint` whose `remaining` is the advertised supply, at least one `TokenSeed`, and no pre-minted token balances. Seeds have to be in that genesis transaction. A later genesis transaction is a different covenant id. Examples still run locally and do not submit. The org pull was then still open. argent-lang `master` was still `76648f99` (10 Sep stub). GitHub says `clean`. Reviews on the org pull are still comments only (10-11 Sep). No approving review. No check run on the head. CI remains the workflow removed in `764a1057`. 7 Oct 12:22:29Z: Manyfestation merged Manyfestation/kcc20-reference#1, merge commit `8c8dc8ee`, title "Finalize kcc20 initial ref". michaelsutton opened that pull. Its head was branch `kcc20-review` on argent-lang/kcc20-reference, tip `28dbbe45` (7 Oct 09:56Z). There is no repository argent-lang/kcc20-review. The six commits are Michael Sutton's. Parent of `7a264039` is `5b2a2312`. Manyfestation authored the merge commit. At that 12:22Z fork merge, kaspanet/kccs main was still `411b41bc` (1 Oct 13:15Z) and `kcc-0020.md` still said `Status: Draft`. Source and pinned fixtures read at `8c8dc8ee`. `cargo test` was not run. `contracts/kcc20.ag` and `fixtures/public-mint/artifact.json` lay the token state out as amount, owner, owner_scheme, borrow_scheme, borrow_guard, extension_commitment, after the generated field `gen__kcc20_template`. The artifact entries are `transfer` params `next_states`, `witness`, tag `79c71c23`, and `transfer_delegator` param `witness`, tag `fd3ef14a`. This pass recomputed unkeyed BLAKE3 of `transfer({int,byte[32],byte,byte,byte[32],byte[32]}[],byte[])` and `transfer_delegator(byte[])` and got those same four bytes. `kcc20.ag` is unchanged from `9e0fc90e` to `28dbbe45`. The artifact change in `28dbbe45` follows Argent #68 `9a9f4b10`, which embeds current-actor template lengths and drops the hidden length arguments. The reference's Argent pin moves from `94f249a7` (8 Sep, #59) to `232c6ee6` in `9e0fc90e`, then to `9a9f4b10` in `28dbbe45`. That range includes Argent #63 `e76ee07` (14 Sep, rules 5 and 6) and #67. This pass did not list every commit in the range. `9e0fc90e` also moves the lock's Silverscript rev from `c7d17a15` to v1.0.0 `3ed9733`. That commit is the first in this repo whose generated SIL contains `require(OpCovOutputCount(gen__cov_id) == OpAuthOutputCount(this.activeInputIndex))`, commented as rule 5, on KCC20, PublicMint, and TokenSeed. The rusty-kaspa pin stays `a41a333b`. `7a264039` (5 Oct) documents the unsigned upper bound already present at `5b2a2312`: owner `<= 0x04`, borrow `<= 0x03`. The comment says a signed compare treats `0x80` as negative zero and `0xff` as -127, so `>= 0` still accepts `0x80`. `transfer_validates_output_schemes_across_full_byte_domain` loops every byte `0..=255` for both output fields. `ebcba45d` keeps the amount threshold on the borrow path. A negative threshold, and the negative-zero guard with byte 7 set to `0x80`, clamps to zero. The token increase must be strictly positive. A normal transfer still accepts a negative threshold guard. The threshold is the first eight guard bytes. `a0d6a8c3` (7 Oct 08:38Z) makes `KCC20PublicMint` the only app and starts tracking `fixtures/public-mint/`. `ba8f06e6` adds permissionless `PublicMint.split`. The call carries no owner signature. `take` is positive and `<= remaining / 2`. The retained output keeps the owner and the KAS value. The added output receives `take`, a caller-chosen owner, and caller-funded KAS. The two remainings sum to the previous remaining. The half cap is per call. `mint` stays permissionless on each deposit. The owner key reclaims the KAS: `reclaim` requires `remaining == 0` and `checkSig`, and `reclaim_into` lets the survivor lead with no signature while the retiring owner signs `reclaim_delegator`. `TokenSeed.create` requires amount zero. It builds a receiving UTXO. The supply comes from `mint`. Seed `split` is permissionless and has no half cap. Seed `reclaim` consumes a retiring seed and recreates the leader, so a lone seed has no reclaim. The lifecycle test `minter_split_mint_and_reclaim_return_unused_allowance` builds the split with no signature, rejects `take` 13 from remaining 25, and accepts `take` 7. The README says these new entrypoints do not yet have a full conformance suite. At `8c8dc8ee` the tree contained 54 `#[test]` functions. The commit messages say 50, then 53. This desk did not run them. The 4 Oct result, 47 passed and 0 failed, is the run on `5b2a2312`. Examples still use synthetic keys and do not submit. kcc20-live `main` is still `50374a64` (9 Sep). This pass did not re-read that `.ag`. The prior pin stands: `borrow_guard` before `borrow_scheme`, keyed `PublicKeyHash`. KCC-20 on kccs main is Last Call at `3fbec524`, not Final. 8 Oct, Sutton on the reference app (2108225873195212836, 15:59Z, quoting @kccforum 2108216730992394500): the reference has a public minting policy with a minter frontier of UTXOs that can expand and contract with demand, and a token seed frontier that expands/contracts and only creates zero-balance token UTXOs (expanding it locks a small amount of KAS that can later be reclaimed), so anyone can enter the token covenant without already holding token value. He calls this reference the first step toward a general standardized Kaspa Token Lib (KTL), or more broadly non-token contracts and libs. X, his reading; not a KIP. Supply caps: KCC-20 alone sets no cap. IzioDev 2103117174176878937 (24 Sep): a cap lives in a minter covenant on top; trusting a token means verifying its genesis and auditing the sources. Forging is blocked by the consensus covenant lineage rule; forking into several UTXOs with the same covenant_id is allowed (2103434848593457558, 25 Sep). `public_mint.ag` at `8c8dc8ee` is such a minter, and `split` can move allowance onto another deposit in the same family. ReconProtocol's question on recomputing `curr` after pruning (2103122462452097235) has no author answer. The 2 Oct posts stay catalog: @kccforum 2106008195114381508 and @manyfest_ 2106012029358047445. Dispatch tags and older vector notes: SNAPSHOT-HISTORY.md. 11 Oct, mint rules and shape (read at c8a08711): `public_mint.ag` L17-L36: `PublicMint.mint` requires amount > 0, amount <= `mint_amount` (the per-mint limit), amount <= `remaining`, and `minter.value == self.value` (the minter's KAS value is kept); it also checks the extension commitment and the owner and borrow schemes. One mint is one transaction. One minter output can be spent only once at a time, so parallel minting first needs a split tree; `split` adds one minter per call, so 5,000 leaves need 4,999 splits (arithmetic). TN10 desk run, 11 Oct (stp's desk; public repo, stp-trump2028 `map/bot/FINDINGS.md` at `15cbdcbc`): 2,488 public mints with this app at `c8a08711` through one local node, 2,488 accepted, 0 rejected (`mints.json` lists 2,488); per mint compute mass 9,117, transient 26,068, storage 61,710 to 76,586 grams with a 1 tKAS carrier; 204 sompi/gram, 0.126 to 0.156 tKAS per mint (61,710 and 76,586 grams × 204 sompi match that range); fees 322.74917112 tKAS in total. Desk numbers on TN10, not mainnet, not a storm. Failure cost, single desk case (7 Oct, kcc20-reference checkout `8c8dc8ee`, before `public_mint.ag` was added in `c8a08711`; stp-trump2028 RESULTS.md §3): a second mint spending genesis output 0, already spent by the first mint in the mempool, was rejected by the node, not retried and not in a block. One case; not tested at scale. KRC-20 comparison (indexer-enforced inscription JSON, commit/reveal, 2024 beta mass, KNS losing reveal; third-party): kaspa-builders. Prior cell: SNAPSHOT-HISTORY. 12 Oct: kcc20-reference#2 (0xlegacydag, opened 16:27:26Z / 18:27 CEST; open, 0 comments at 13 Oct 06:03:08Z): the comment "The byte[65] conversion below implicitly validates the witness length" in `contracts/kcc20.ag` (L46, L142–L143, both read at `c8a08711`) is, he says, inaccurate because the cast emits nothing. He calls it "not a break": in his own local test (kaspa 2.1.0 Python package, SilverScript v1.0.0) 64- and 66-byte witnesses are still refused, by the signature opcode. He proposes rewording the comment or adding an explicit length rule, and offers a PR. Issue author's reading; not desk-run; no maintainer reply. 15 Oct: kcc20-reference#2 still open, 0 comments. Two open pulls by Manyfestation, not merged and not reviewed: #3 "Add owner-authorized minter and seed value rebalancing" (13 Oct 10:24:00Z) and #4 "Add KAS-backed KAST example" (13 Oct 13:23:48Z). The repo tip is still `c8a08711`. 21 Oct (r2): michaelsutton approved and merged #3 at 09:31:51Z as `b7824660` and #5 "Add .gitattributes" at 09:51:49Z as `27f8403f`, now the repo tip. #4 is now "Add KAS-backed KAS20 example" (head `2f7cc78f`, 19 files, +18153/−4), open, not reviewed. Manyfest's Kas-Smiths topic 164 "A KAS-backed KCC-20 Token" (post 418, 11:01:10Z) asks for one canonical KAS-backed KCC-20 deployment and points to #4: "each KAS20 base unit represents one sompi, held directly in the token's UTXO". His proposal; not desk-run. Prior cell (to 21 Oct, r2): SNAPSHOT-HISTORY. 21 Oct (Build r3): text read at `2f7cc78f` (no build): `examples/kas20/contracts/token.ag` L18 requires `next_outputs[i].value == next_states[i].amount` for every output on every transfer path, and the borrow path also requires the first output's value not to fall (L80). `burn` needs owner authorization only. The example README says "value in sompi = amount in token base units" and "this example does not designate a canonical deployment". Topic 164 (raw, server `Date` 14:00:55Z, 1 post) asks the ecosystem to agree on "a canonical implementation and deployment". It opens with "The finalization of KCC-20", while `kcc-0020.md` on main still says Last Call. #4: 0 reviews, 0 comments. Third-party code (argent-lang), not audited, not desk-run. 21 Oct (pin moved): the reference pin is now `27f8403f` (master since 09:51:49Z). Compare `c8a08711...27f8403f`: #3 `b7824660` "Add owner-authorized minter and seed value rebalancing" changes `contracts/public_mint.ag`, `contracts/token_seed.ag`, `PublicMint.sil`, `TokenSeed.sil`, the public-mint `artifact.json` and `manifest.json`, `src/bin/kcc20/public_mint/tests/lifecycle.rs` and the README; #5 adds `.gitattributes`. `contracts/kcc20.ag` and `fixtures/public-mint/sil/KCC20.sil` are not in the diff, so the `kcc20.ag` line cites above (read at `c8a08711`) hold at `27f8403f`; counts and runs made at `c8a08711` (for example the 2,488 mints) stay at that commit. KCC-20 defines no mint: the word "mint" does not appear in kcc-0020.md, and minting in the reference is a covenant-specific entrypoint. kcc-0020.md §4 says "a KCC-20 covenant MAY expose covenant-specific entrypoints that interpret or update extended state according to the covenant's own rules"; it does not name minting. KCC-20 is Final since 21 Oct (#41); the reference is third-party code, not audited, not desk-run here. Walkthrough by manyfest: kcc20.manyfest.dev (see Hash-chain borrowing). Prior cell (to 21 Oct, KCC-20 Final): SNAPSHOT-HISTORY. 23 Oct (watch): manyfest_ X 2113198280808988677 (22 Oct 09:18:26Z): "Native KAS is a fungible token as well, but it isn’t a KCC-20 token"; he proposes "a simple implementation, KAS20" so covenants can handle KAS like other KCC-20 tokens, with the discussion on Kas-Smiths topic 164. Michael Sutton 2113336626277446032 (18:28:10Z): "on kaspa, each UTXO simply holds the actual KAS together with the KAS20 state representing it 1:1. there’s no shared wrapper vault". manyfest_ 2113346707018625054 (19:08:13Z), answering IzioDev 2113329374220910995: "KAS20 transfers don’t verify token conservation, they delegate this to Kaspa consensus", and "A single tx “mints” 100 KAS20, assigns it to you, claims the order". Statements on X, not checked in code. kcc20-reference: no new commit; #4 (KAS-backed example) has no update after 22 Oct 05:42Z. Prior cell (to 23 Oct): SNAPSHOT-HISTORY.
KCC-23 metadata	Draft. `kcc-0023.md` "MJ: Metadata JSON" (Sivan Helfer; `Status: Draft`, raw read 16:04:10Z), added by #26 as `1516a6c4` (14 Oct 13:11:38Z) and not changed by the 21 Oct Final merges. Declaration: a version 1 preparation transaction carries the metadata in its payload; the payload MUST start with a one-byte codec prefix, and `0x00` means one UTF-8 JSON object (§3.1; `{}` is `007b7d`). Deployment: the genesis transaction spends that preparation output, and under KIP-20 the covenant id commits to the spent outpoint, so the metadata is bound to the covenant (§3.2). Verification: a reader recomputes the preparation txid from the payload and the remaining-fields digest (§3.3). §4 shows token metadata `{"name","symbol","decimals"}`; field names are left to ecosystem conventions, with no registry or uniqueness rule. Vectors (`kcc-0023/vectors/conformance.json`, §6): binding fixture with preparation txid `206a0c31…13ef` and covenant id `c86366ce…394e`; changing `"decimals":8` to `9` MUST fail binding, as MUST a version 0 preparation transaction; declaration cases include missing prefix `7b7d`, unknown prefix `017b7d`, `[]` and invalid UTF-8 (all invalid). A Rust implementation is in `kcc-0023/implementation`. rusty-kaspa #1157 and kips #49 reuse the fixture (Covenant-id lookup, KIPs). Walkthrough by the author: kcc23.manyfest.dev (HTTP 200, server `Date` 16:16:10Z), linked from 2112920461176655927; Draft, not Final.
Hash-chain borrowing	Spec: kcc-0020.md §5 Borrowed Receive (Final since 21 Oct). A borrowed receive lets the transfer's leader add tokens to a recipient's existing token UTXO without the recipient's authorization: the successor is `next_states[0]`, at most one per covenant family; it MUST keep `owner`, `owner_scheme`, `borrow_scheme` and `extension_commitment`, use the expected `next_borrow_guard`, increase `amount`, and carry at least the KAS value of the borrowed input; the leader MUST preserve the family's total amount. Schemes: `0x00` disabled, `0x01` amount-threshold, `0x02` schnorr-signature, `0x03` hash-chain/v1. For hash-chain/v1 the borrow witness is exactly 129 bytes (32-byte revealed guard, 32-byte one-time public key, 65-byte signature); the normative pseudocode requires `Hash(revealed_guard \|\| one_time_pubkey) == borrow_guard` (KCC-1 hash, unkeyed BLAKE3), sets `next_borrow_guard = revealed_guard`, and verifies `borrow_signature` with `one_time_pubkey`. Security Considerations: "Under `hash-chain/v1`, each released link permits one borrow. A link consists of a revealed value and a one-time private key, and any party that obtains both can use it." An unused released link keeps the outpoint unstable until used or the owner replaces `borrow_guard`. Vectors: `hash-chain-valid`, `hash-chain-guard-not-advanced` and `hash-chain-link-mismatch` (Conformance Vectors). Background: borrowed-receive-authorization.md. Walkthroughs by manyfest, linked from 2112920461176655927: kcc20.manyfest.dev and kcc20.manyfest.dev/hash-chain (HTTP 200, server `Date` 16:16:09Z–16:16:10Z). Its JS bundle steps a chain (`x_3 = Hash(x_2 \|\| …)`) and shows a replay that fails: "Carol copied Alice’s borrow_witness into her own transaction. revealed_guard and one_time_pubkey still hash to the guard, but borrow_signature covers Alice" (bundle text).
KRC-20 to KCC	Sutton 2090041390214336888 (19 Aug): he prefers a one-time snapshot. The commitment sits in KCC genesis, is part of the covenant-id preimage, and can be checked against a KRC indexer muhash. An airdrop needs an admin key. manyfest 2090532234747097107 (20 Aug): KRC tokens are on three ledgers (KRC20, Igra, Kasplex); he proposes a coordinated snapshot and a KCC20 minter. Proposal. No KCC and no code. 11 Oct: Sutton's migration reply (2109305350008475670, 15:29:19Z) is quoted in KCC-20 wording; he calls it a conceptual answer, not about any specific migration proposal. KRC-20 itself (indexer rules, commit/reveal) is third-party: kaspa-builders. Prior cell: SNAPSHOT-HISTORY.
KCC-3/4/5	Not on main. #29 (`55742861`, kaspahttp402, 21 Sep) proposes Draft Reputation Deed / Slashable Bond / Deed Identity Registry as KCC 3, 4, and 5. Header author: Kaspa-World-Eater. They require KCC-1 and KCC-2, which were Last Call from 1 Oct and are Final since 21 Oct (KCC-2 #40, KCC-1 #39). Numbers are a request, not an assignment. Reference implementation (Kaspa-World-Eater/quorum, its off-chain tests and its one TN10 proof): see STP-KAS/kaspa-builders. Workshop thread: Kas-Smiths #148. Desk confirm: #29. Not adopted. Not a stable. Dated detail: SNAPSHOT-HISTORY.md. 20 Oct (watch): kccs#37 "Pay-to-Public-Key-Hash via P2SH" by someone235, opened 19 Oct 15:16:38Z from `someone235:p2pkh` against main `1516a6c4`: the KCC form of KIP-22 (see KIPs). Its first commit `3f1740b5` adds `kcc-xxxx.md` (85 lines; header `KCC: ?`, `Status: Draft`, `Type: Standards Track`, `Category: Application`, authors Ori Newman and Gaurav Rana; derivation purpose `XXXX'` with a TODO until the number is set; conformance vectors and reference implementation still TODO). The head commit `8088f5c5` "Assign to KCC-3" deletes `kcc-xxxx.md` and adds no file, so at the head the pull changes 0 files (API `changed_files` 0; no `kcc-0003.md` in the head tree). #29 above also asks for 3; numbers in pulls are requests. 0 reviews, 0 comments at the 20 Oct read. Discussion: Kas-Smiths topic 163 (post 417, Ori Newman, 19 Oct 15:27:18Z). Not on main. Draft. Prior cell (to 20 Oct): SNAPSHOT-HISTORY. 20 Oct (Build): API 06:22:56Z: `changed_files` 0, 2 commits, the last `8088f5c5` at 19 Oct 16:10:00Z; that commit only removes `kcc-xxxx.md`, and the head tree has no `kcc-0003.md` (it has KCC 0, 1, 2, 20 and 23 and the template). 0 reviews, 0 comments (every page). No new commit after the 20 Oct read. `kcc-xxxx.md` at `3f1740b5` against KIP-22 at `b031344f`: same Abstract (it still says "This KIP defines"), Motivation, redeem script and coin type; purpose `XXXX'` with "TODO: Change once KCC number is determined" instead of `22'`; Backwards Compatibility no longer says "No consensus changes are required."; it adds Rationale, Security Considerations, a CC0 line, and Conformance Vectors and Reference Implementation left as TODO. kccs #29 (head `55742861`) is a separate request for 3. 21 Oct (watch): a third open pull asks for 3. #38 "introduce kcc3: segregated hierarchy for HD wallets" by IzioDev (20 Oct 12:14:21Z / 14:14 CEST, from `IzioDev:kcc-3`, head `299f6a0b`, 3 files, +564/−0: `kcc-0003.md`, `kcc-0003/vectors/conformance.json` and one README index line). Header: `KCC: 3`, "Segregated Hierarchy for HD Wallets", authors Ori Newman and Romain Billot (IzioDev), `Status: Draft`, Category Interface, Created 2026-10-20. It defines a six-level BIP32 path `m / purpose' / coin_type' / sig_scheme' / account' / change / address_index` (purpose 44 P2PK, 45 multisig; coin types 111111 to 111114 for mainnet, testnet, simnet, devnet; sig_scheme 0 Schnorr, 1 ECDSA) and "requires no consensus changes". It has no P2PKH-via-P2SH purpose. #37 (P2PKH via P2SH) is unchanged at `8088f5c5` with 0 files (branch `someone235:p2pkh` at the same commit), though Ori Newman wrote on X on 20 Oct that kip22 is "now KCC-3" (see KIPs). #29, #37 and #38 all ask for 3; none is merged; numbers in pulls are requests. 0 reviews, 0 comments on #38. Draft. Prior cell (to 21 Oct): SNAPSHOT-HISTORY. 21 Oct (Build): read `kcc-0003.md` at `299f6a0b` (238 lines) and the README line it adds (KCC 3, "Standards Track, Interface", "Segregated Hierarchy for HD Wallets", Ori Newman and Romain Billot, Draft). The header, path, purposes 44 and 45, coin types 111111 to 111114 and sig_scheme 0 and 1 match the sweep. The file never mentions P2SH, P2PKH, KIP-22 or a `22'` purpose. It also sets testnet coin type 111112, while KIP-22 at `b031344f` uses `111111'` "on all networks" and has no sig_scheme level: the two paths differ. #37 is still 0 files at `8088f5c5`; #29 at `55742861`. Three separate requests for 3. 21 Oct (r2): someone235 CHANGES_REQUESTED on #38 at 06:24:02Z (head `299f6a0b`), with five inline comments on `kcc-0003.md` (06:07:56Z–06:23:41Z): "This should not apply to `44` or `45`. I think it's best to only demonstrate here with `m/3'`, and show an example of `m/4'` in the following kcc that defines multisig derivation."; three parts "should move to KCC-4" (or "belong to KCC-4"); and "I think we should avoid rejection". No author reply yet. Prior cell (to 21 Oct, r2): SNAPSHOT-HISTORY. 21 Oct (Build r3): all 5 inline comments of someone235's CHANGES_REQUESTED review (06:07:56Z–06:23:41Z, review 06:24:02Z, every page) on `kcc-0003.md` at `299f6a0b`: "I think we should avoid rejection, as discussed here" (a Telegram link); the path rules "should not apply to `44` or `45`. I think it's best to only demonstrate here with `m/3'`, and show an example of `m/4'` in the following kcc that defines multisig derivation"; and three parts (multisig derivation and key sorting, and the multisig example) "should move to kcc-4 imho", "should also belong to KCC-4", "Should move to KCC-4". No author reply, 0 issue comments, no commit after 20 Oct 12:13:37Z (head still `299f6a0b`). 21 Oct (KCC-20 Final): the KCC-1/KCC-2 requirement is now met on main `1ed87aef`; #29, #37 and #38 are still open and none is merged. Prior cell (to 21 Oct, KCC-20 Final): SNAPSHOT-HISTORY. 22 Oct (watch): on #38 InKasWeRust (21:41:08Z) agrees to keep `44` and `45` out of KCC-3 and gives a data point for the multisig follow-up: the rusty-kaspa wallet derives multisig keys at `m/45'/111111'/account'/cosigner/change/address_index`. Desk code read at tag v2.1.0 (`01b532e8`), not run: `wallet/keys/src/derivation/gen1/hd.rs` L197–L204 builds `m/{45 for multisig, else 44}'/111111'/{account}'`, then `/{cosigner}` and `/{change}`; `wallet/core/src/wallet/mod.rs` L733–L738 sorts the xpub strings and takes the position of the account's own first key as its cosigner index. So the path matches. His further point (the keys of an address are not sorted again per address, which differs from BIP45 and from this draft) is his reading, not checked here. #38 is still CHANGES_REQUESTED (someone235), head `299f6a0b`, `mergeable_state` dirty, no author reply. The wallet that cites this layout is third-party (see kaspa-builders). Prior cell (to 22 Oct): SNAPSHOT-HISTORY. 22 Oct (Build): code read at v2.1.0 (`01b532e8`, nothing built), against InKasWeRust's three bullets. (1) Path and hardening: `hd.rs` L197–L204 formats `m/45'/111111'/{account}'/{cosigner}/{change}` with no network switch, and `derivation.rs` L548–L564 routes multisig accounts there: confirmed. (2) Cosigner order: `mod.rs` L733–L738 sorts the xpub strings ascending and takes the position of the lowest own key; with no own key the index is `None`, which `derivation.rs` L207 turns into `0`. Confirmed for accounts created with private keys. The watch-only branch (from L759) does not sort the given list in this function; whether callers sort it is not verified. (3) No per-address sort: `derivation.rs` L203–L215 builds one derivator per xpub with the same cosigner index, L146–L155 collects each address's keys in xpub order, and L500–L501 and L442–L454 pass them unsorted to `multisig_redeem_script`, which does not sort (`multisig.rs`): confirmed. `kcc-0003.md` at `299f6a0b` instead says the wallet "MUST sort these encodings in ascending lexicographic order" and "Sorting MUST be performed separately for every address", so its multisig key order differs from the deployed wallet's.
Kas-Smiths	kas-smiths.org. Workshop, opened 2 Jul 2026, Discourse 2026.8.0-latest.1, sign-in with X. 26 Oct (`about.json`, `posts.json`, `latest.json` HTTP 200, server `Date` 06:42:25Z–06:42:26Z): 52 topics, 394 posts, 115 users. Latest post 420 (26 Oct 01:01:51Z, S1LVERTOSHI) opens topic 165 "(Kaspa NFTs) A unique-asset KCC on top of KCC-1/2/23: offering a draft, a reference contract and a live implementation": "KCC-1, KCC-2 and KCC-20 are Final." and "What is still missing is a convention for unique assets"; he offers "a short draft reusing KCC-1/2/23 by reference, a reference contract in Silverscript, conformance vectors, and a live implementation on testnet-10 and then mainnet" and asks "Who wants to co-author? The KCC721 authors first of all". No reply at this read. His game is third-party: kaspa-builders, Kas-Smiths threads. Post 419 (22 Oct, Manyfest, topic 8 post 78): "The KCC-20 specification has been finalized." Post 418 (21 Oct, Manyfest) opens topic 164 "A KAS-backed KCC-20 Token". Prior cell (to 26 Oct): SNAPSHOT-HISTORY.
This desk	STP-KAS owns 138 repos (12 Oct 15:56 CEST live count, `gh repo list STP-KAS`): 122 public + 16 private. Older counts (6 Oct: 110, 95 public + 15 private; 2 Oct: 95, 85 public + 10 private): SNAPSHOT-HISTORY.md. None of the 16 private names is listed on this board. `kns-kasware-tn10-test` is public. four-pass-kaspa-desk (note published 29 Sep 12:52Z as `148e0cf`; read it at `60bac10`, which only removes private-repo mentions) is a dated 11:14Z note, not this board. kaspa-dapps PLAN.md "Now" still says rusty-kaspa v2.0.1. The 21 Sep full README read (54 repos then) is `STP-REPOS.md`. Mainnet node work is retired (kaspa bot stopped and wiped 25 Sep 16:46 CEST); the box runs Testnet-10 only. kaspa-llm-forum commit `fc746db` (21 Sep 09:04Z): execution halted. Do not post reports. The clock does not run. Standing rule since 24 Sep: zero public comments on GitHub, Kas-Smiths, Facebook, and X. Monitors stay up. A new sourced fact is written on this board and nowhere else. One recorded exception: three STP-KAS comments on vprogs#165 on 26 Sep (5846636810, 5847124607, 5847335087). The zero-public-comments rule stands. KagenC `engine/Cargo.toml` and agenc-on-kaspa `engine/Cargo.toml` pin rusty-kaspa `a41a333b` and silverscript v1.0.0. Do not bump them to v2.1.0 before a desk build: silverscript#256 was closed 10 Oct and silverscript master `a0dd7448` now uses crates.io v2.1.0 (#259), but it is untagged. Only `silverscript-abi` at `a0dd7448` was desk-built, 11 Oct (one package; see SilverScript holes); the pins above were not rebuilt against v2.1.0. stp's own apps 1984, KUSDT split and AgenC (the KagenC pin above stays here): see STP-KAS/kaspa-builders. Dated desk notes 22–26 Sep: SNAPSHOT-HISTORY.md. Private names stay off this board. 11 Oct, recorded exception: STP-KAS commented once on rusty-kaspa#1147 at 19:44:32Z (an fyi with a link to a public STP-KAS repo). The comment was later deleted: still listed at the 12 Oct Build read (08:07 CEST, server Date 06:07:04Z), HTTP 404 at the 12 Oct 09:34–09:35 CEST weekly reread and again at 16:00 CEST (challenge read, server Date 14:00:09Z). The zero-public-comments rule stands. Prior cell: SNAPSHOT-HISTORY.
vProgs	vprogs master `f9b84a8` (28 Jul); 0 tags, 0 releases. Branch `release-candidate` is `9ddda80a` (26 Oct 10:40:10Z, biryukovmaxim, "aggregate-prover: satisfy fmt and clippy on the covenant re-root changes"), 3 commits ahead of `cc0d54bc` and 0 behind: `54ac3549` "aggregate-prover: hold an off-tip fold and re-root execution at the boundary", `d9357f3e` "aggregate-prover: hold an off-tip committed-gap re-cover" and `9ddda80a`. Not a release. The same tip heads open #173 (biryukovmaxim, 25 Oct 14:45:07Z, branch `fix/covenant-fork-reroot`, base `fix/uncoverable-gap-rollback`, 16 files, +561/−6, no review); its body, under "Live evidence (Oct 25 2026 incident)": "65 bundles proved, every one skipped as `base mismatch`; covenant tip frozen at settlement `164d27bf`". Open issue #174 (biryukovmaxim, 25 Oct 17:04:04Z, 0 comments) "batch-prove retry has no escape: a deterministic prove failure wedges the serialized batch queue": `zk/backend/risc0/api/src/backend.rs` retries proves "with no attempt cap and no escape"; it links #173. hmoog reviews on biryukovmaxim's open pulls: APPROVED #131 and #134 (21 Oct); CHANGES_REQUESTED #128–#130 (20 Oct), #149 (21 Oct), #136, #139, #140 (22 Oct), #142 (23 Oct); none merged. The workshop vprogs: a based rollup on Kaspa (9 Oct) links the framework at `055ae28a`; the book calls the work early development and says composability is not implemented. The yellow paper is DRAFT v0.0.1 (see Consensus papers). Prior cell (to 27 Oct): SNAPSHOT-HISTORY.
vProgs node and DA	Max 2099841318847729878 (15 Sep): DA moved to the L2/vprogs level; L1 holds the digest; P2P and IBD are not implemented in the framework. 2100806415510319354 (18 Sep): L2 actions are immediate; settlement moves funds to L1 and commits state periodically; a new node verifies against the last settlement and replays. 2103498627130003761 (25 Sep): today you run the vprog node that proves and settles; a mode without proving exists for DA. Master `f9b84a8` is the merge of #97 (28 Jul 11:24Z): vprogs-runner daemon and `vprun` CLI. 26 Sep evening Sutton: 2103892665435578727 — Max's demo is not the full yellow-paper syncompo design (more L1 still required); it is a standalone vprog that can compose via L1; he prefers "based zk app" for that stage. 2103907653390876704 — ~30% of the yellowpaper effort is already in L1 as KIP-21, so proving cost scales with app activity (not global L1); Max is sharing the off-chain infrastructure on top. 2103910575096950964 — Max's work is within Hans's framework. Catalog. Not a merge.
tictactoe	On 9 Oct the workshop vprogs: a based rollup on Kaspa links the example at `fe6b0e85`, 13 commits behind the tip (compare API: ahead 13, behind 0). The book's sentences that a simnet loop runs in minutes and that testnet-10 has run real GPU proofs are the author's account; this desk did not re-run them. The posts that point at the book are Maxim 2108538746995892673 (12:43Z) and Sutton 2108546165272657952 (13:12Z). Tip `f93e52fe` (8 Oct 14:54:51Z), "pin vprogs release-candidate cc0d54bc": root `Cargo.lock` only (`release-candidate#cc0d54bc5e79cecf0ca7cd8f8a76d45a8a6502e6`); `guest/Cargo.lock` still pins `04cfb0ae` (9 times; `cc0d54bc` is absent). Both `Cargo.toml` files name branch `release-candidate`, not a rev. The previous tip `35defd29` (8 Oct 12:19Z) pinned `e9e2e7e3` in the root lock only, with the same guest lock `04cfb0ae` (from `087b4efc`, 7 Oct 18:15Z). Those two hashes are not the `release-candidate` tip: the branch was force-pushed to `cc0d54bc` at 14:53:44Z (after `e9e2e7e3` at 12:03:31Z), and `e9e2e7e3` (committed 10:58Z) is not on it (compare API: diverged). On 7 Oct seven tictactoe pin commits (`f474ac8e` to `087b4efc`, 08:26Z to 18:15Z, both locks each) followed the branch's seven plain pushes, pinning `c24bf35c`, `bede8b7c`, `d8eb5074`, `6c1ed84f`, `eb60c872`, `82646186`, `04cfb0ae`. Before that, `94a86c26` (6 Oct 15:44Z) pinned `ec0deeef`, `ac0a7574` (15:24Z) `e10e6deb` and `84988b18` (13:38Z) `7e7d1b79`; `c78780f2` (committed 5 Oct 15:13Z, pushed 6 Oct 13:38Z together with `84988b18`) pinned `5da27851` in both locks. The tip before those, `fe6b0e85` (committed 2 Oct 20:39Z, pushed 5 Oct 11:27Z), pinned `055ae28a` in `Cargo.toml`, `guest/Cargo.toml` and both locks. The README (L26) still says to check out vprogs at `fix/settlement-watch-wedge`; it disagrees with the Cargo pin. Rusty-kaspa pin remains `eb0a856`, behind release v2.1.0 `01b532e8`. https://vprogs-tt.izio.fr/ returned HTTP 200 on 28 Sep and again at 29 Sep 15:55Z. The HTML is a Vite dev client (`/@vite/client`) and names no commit. This desk did not submit a key or a transaction. Max's post says the page needs a private key and some testnet funds (2103466359246270526). #23 still open. Not a product testnet. Dated notes 24–26 Sep: SNAPSHOT-HISTORY.md.
Argent	Master `5a7744bc` (23 Oct 07:28Z): michaelsutton merged #70 (head `25e8f48c`, 152 files, +27838/−17748). 0 tags, 0 releases. Open #72 "Support static cross-app actor handle values" (michaelsutton, 25 Oct 19:34:22Z, head `62ef76c0`, 31 files, +3106/−134, no review): per its body, app-qualified actors become statically linked handle values (`require(token_type == tokens::TokenApp::Token);`), static values use the linked actor's exported `actor_type_handle`, and in-app selection now requires an explicit actor-enum type, which "tightens previously accepted selector syntax". His comment (20:32:16Z): "62ef76c addresses two related review findings": incompatible actor-handle types "could pass through helpers, constants, and reassignment", and valid copies from fields and indexed arrays were rejected; "The fix replaces that initializer whitelist with shared source-type resolution." Open #69 "Load pinned app artifacts through module imports" (RossKU, 8 Oct, head `435fa89a`, 0 reviews). argent-playground default branch `86d5453e` and argent-template master `d1a61219`, both "Use crates.io Kaspa and Silverscript dependencies" (23 Oct). Ross Ku's port notes are third-party: kaspa-builders. Prior cell (to 26 Oct): SNAPSHOT-HISTORY.
Launch proof and binding	Sutton 2081846048280965268 (27 Jul): every deployed L1 covenant should come with a launch proof derived from its covenant-id preimage, covering the full contracts and initial state, and with inspectable source. 2082066262520463670 (28 Jul): the UTXO carries the covenant id (its preimage proves the launch) and the spk (p2sh commits to the contract/actor and its state). 2087453635206643755 (12 Aug): a DEX binds each whitelisted asset by the pair (template hash, covenant id). The template is passed at runtime as an untrusted sig arg and checked against the hash. Example: argent-playground `dex.ag` L32 at `0a2e80d1`. 2098077295214809214 (10 Sep) links the formal analysis `leader-delegate-input-groups.md` on argent master (#60, merged 10 Sep). The covenant-state provenance doc behind the silverscript#234 close is only on branch `covenant-state-provenance` (`35bec64a`, 3 Sep), not on master (Sutton). Sutton 2106033659698450492 (2 Oct 14:48Z) points at argent#66 (genesis-proof tooling, then open at head `9592dd99`) and expects every stateful covenant to publish that link. Sutton merged #66 on 4 Oct 12:04Z (14:04 CEST) as `03d67021` (PR head `aab8fe1e`, two commits past `9592dd99`). No tag. 5 Oct, two covenant categories (Sutton): 2107218445993738378 (21:16Z): some covenants are about the Kaspa they protect (vaults, timelocks, escrow), others about the state they carry, which forms another mini social consensus (name services, native KCC-20 tokens). A timelock has no forgery problem, because anyone may clone the script over their own KAS; when the state itself matters, imitation does, and that is why Toccata introduced covenant ids and covenant lineage (2107246681162948905, 23:08Z). The genesis preimage shows the birth was right, but it matters only because the covenant id gives provable lineage (2107241339066671607). A privacy pool and a based app are both kinds at once: state (notes and nullifiers; external state) plus a pool of KAS (for a based app, the canonical bridge) (2107231201165549636). Native state-carrying covenants can already support assets, DEXs and lending (2107239797513236579). In a separate, earlier reply (18:40Z, another conversation), P2SH also compresses: the launch of a complex app with several continuation contracts folds under 32 initial bytes (2107179238440976510). On randomness (2107237888304013388, 22:33Z): PoW block hashes are a good source only if the mechanism cannot choose which hashes it uses; reading them from the script engine is tricky but not impossible; based apps have an easier path through the KIP-21 sequencing commitment, again without giving the mechanism or the zk prover selection power. X replies, his reading; not a KIP. In the same thread Manyfest (2107373867396182019, 6 Oct 07:34Z): for the first kind the node itself checks that no KAS is created in the transition; for the second, the genesis tx creates new "matter" the node knows nothing about, so the covenant logic must enforce its conservation, and other covenants can compose on it. Asked how a user knows a contract hides no backdoor such as a `terminate()` paying the developer, Sutton answered "no doubt. hence" and quoted his 2 Oct genesis-proof post 2106033659698450492 (2107536837522678263, 6 Oct 18:21Z). Catalog. Reasoning kept from a moved project: covenant id derivation, desk recompute 3 Oct (no node) on a third-party Testnet-10 registry genesis: blake2b-256 keyed `CovenantID` over the authorizing outpoint, then each authorized output's index, value and script public key (not its covenant binding), per rusty-kaspa v2.1.0 covenant_id.rs (hashers.rs L32); any change to those outputs gives a different id, and the recomputed id matched the published one. Details: see STP-KAS/kaspa-builders (entry name-services). Desk note 6 Oct, covenant lineage in rusty-kaspa v2.1.0 `01b532e8` (desk reading, not a KIP): an output may carry covenant id X only if its authorizing input's UTXO already carries X (continuation, covenants.rs L124-136) or X equals the id recomputed from that input's outpoint and the group's authorized outputs (genesis, L137-160; covenant_id.rs L16-30); otherwise the tx fails with `WrongGenesisCovenantId`. This runs for every tx in UTXO context (tx_validation_in_utxo_context.rs L58). An outpoint is spent once, so every UTXO carrying X descends through authorizing-input links from one genesis; that is the lineage. `OpCovInputCount` (0xd0) pushes the number of tx inputs whose UTXO carries the given id (opcodes/mod.rs L1333-1341; covenants.rs L78-80, L107-111). Consensus checks only the ids; what a continuation may do (script, state) is up to the covenant's own script. 8 Oct, L1+ε ladder (Sutton): agrees with maxibitcat's L1+ε framing (2108272284469182499, 19:04Z): lowest rung is bounded-size covenant state revealed at output creation (the spent cov UTXO verifies its continuation); active state size O(UTXO set), so a valid candidate for a node-level index. X, his reading; not a KIP. 10 Oct (Sutton on covenant capabilities): 2108964596820193619 (16:55:17Z): burn and mint are easy; freeze has tradeoffs; DEXes and lending are possible; the ingredient for compositional apps is single-transaction atomicity (onchain composability); those are the design patterns Argent and the KCCs aim at. X, his reading; not a KIP. Build: text matches the watch's saved X raw (reply to 2108928813954453728; Build made no X call). 15 Oct 22:42Z (Sutton, X note; watch 16 Oct): 2110863926527230422 on state-carrying covenants that need lineage and a scarce global resource (name service): compressed design = one Merkle root in a single covenant UTXO (SMT over the keyspace; register proves empty slot, updates root, emits ownership UTXO `U(R₀) → U(R₁) + Point(k)`; transfers of the name need not touch the root); partitioned design = split ranges into lineage-linked covenant UTXOs so different ranges can proceed concurrently in the DAG; middle ground = fixed count of range UTXOs each with its own Merkle root. Quotes @supertypo_kas's DOTK as pure partitioning (`Gap((a,b]) → Gap((a,k)) + Deed(k) + Gap((k,b])`). KIP-9 storage mass makes many small range UTXOs expensive on purpose; expand-and-contract frontiers (as in kcc20-reference) reclaim KAS by merging. Full note saved under the watch raws. X, his reading; not a KIP. Follow-up 2110866794218950778 points at IzioDev's SMT-based name service on fork branch `feat/name-service` (product → kaspa-builders name-services entry). Build check against the watch raw (`x/sutton-2110863926527230422-note.txt`, 3767 bytes; no X call): the two transition lines match byte for byte (`U(R₀) → U(R₁) + Point(k)` and `Gap((a,b]) → Gap((a,k)) + Deed(k) + Gap((k,b])`). On KIP-9 the note says: "KIP-9 makes creating many small-value outputs expensive, so each new range UTXO needs enough KAS locked in it to keep the mass reasonable. That’s intentional." On the middle ground: "A practical middle ground is to start with a chosen number of range UTXOs and put a Merkle root inside each one." The saved note opens with the line "(with grok and sol)". 19 Oct (watch), names for covenant ids: KasperoLabs asked how wallets will tell apart two KCC-20 tokens that differ only in covenant id (2111754328557961279, third-party; see kaspa-builders). Sutton: "a name service for covenant ids sounds like a very good idea" (2111906108600467489, 18 Oct 19:43:48Z) and "your idea of a name service for covenant ids should be combined here with something like kcc23. we should find a way to link a covenant name to some global pre-established name service (which is of course also a covenant) at covenant launch" (2111907376957956539, 19:48:50Z). The name "can have more of the role of a X username handle. a simple alphanumeric name that establishes the identity in a way humans can easily verify" (2111913727733661869). Manyfest: without a payment wall spammers could mint all the names; maybe reserved names for well-known ecosystem names, or a payment to the block miner or a fund (2111911950867181770, 2111915092057153941). IzioDev: a binding between covenant id and alias can be set up; in practice users will rely on community-trusted platforms to check the deployment (2111971906773569860). An X discussion: no KCC, PR or spec for it. KCC-23 (kccs#26) is still a Draft on kccs main `1516a6c4`. Prior cell (to 19 Oct): SNAPSHOT-HISTORY. Build check (19 Oct, against the watch raw `raw/2026-10-19/x/threads-fulltext.txt` only; no X call): the quotes from 2111907376957956539 and 2111913727733661869 match byte for byte; the Manyfest and IzioDev paraphrases match those posts (IzioDev's word is "bound": "one can establish a bound between the covenant id and an alias"). 2111906108600467489 ("sounds like a very good idea") is not in that file: not verified there. The KasperoLabs post 2111754328557961279 is in it, and the summary matches it. KCC-23 at `1516a6c4` binds one JSON object to a covenant id at genesis through a preparation transaction (3.1), so a deployer can declare a name at launch; its example uses `"name"` (section 4). The text says "Field names and their meanings are left to ecosystem conventions." It has no registry, uniqueness rule or link to an outside name service. Self-declared metadata, not a name service. 20 Oct (Build): Sutton 2111906108600467489 (18 Oct 19:43:48Z) is in the 20 Oct watch raw `raw/2026-10-20/x/fulltext.txt` (author id mapped to michaelsuttonil in that file): "@kasbtc_krc20 @KasperoLabs a name service for covenant ids sounds like a very good idea 💯". Verified there.
KRC-20 incident	Not an L1 exploit. 20 Sep: the ZealousSwap post-mortem, as relayed by Recon 2101642546803863779, traces it to a signature bypass in the off-chain Kasplex KRC-20 indexer, not Kaspa L1. KRC-20 token state is interpreted by indexers, not by L1 consensus. Third-party report. The desk did not read the post-mortem itself. Kasplex's indexer fix release (go-krc20d) and later commits are third-party product status: kaspa-builders entries/krc20-incident.md. Prior cell (to 15 Oct): SNAPSHOT-HISTORY. 19 Oct (watch): Ori Newman on a podcast teaser titled "Kasplex's recent exploit" (2112036204137095419, with emdin of Igra Labs and Louis of ZealousSwap): “I think the sentence "L1 was poisoned" isn't not a good choice of words, since it implies that there was an L1 bug. @emdin clarifies in the next sentence that this isn't the case, but it's not shown in the teaser.” (2112050585004306646, 19 Oct 05:17:54Z; also 2112042010626441544). The host replied that L1 accepted the transactions as script-valid, as designed, while the Kasplex indexer had its own interpretation (2112047799768596491). Consistent with "Not an L1 exploit". The desk did not watch the episode. Prior cell (to 19 Oct): SNAPSHOT-HISTORY. Build check (19 Oct, against `raw/2026-10-19/x/threads-fulltext.txt` only; no X call): Ori's quote from 2112050585004306646 matches byte for byte (created 05:17:54Z); 2112042010626441544 (04:43:49Z) contains "L1 was poisoned"; the host reply 2112047799768596491 (05:06:50Z) says "L1 accepted the transactions as script-valid (as designed), while the Kasplex indexer had its own interpretation"; the teaser 2112036204137095419 says "Kasplex's recent exploit". The desk did not watch the episode.
SilverScript holes	Open: #260 "Expose OpOutputAuthorizingInput as a builtin" by aglov413, opened 12 Oct 07:14:37Z on `master`, head `a2e2c0f4`, 1 commit, 7 files (+58/−6), no reviews, `mergeable_state` blocked (API 05:48Z). Registers KIP-20 opcode `0xd6` as `OpOutputAuthorizingInput(int idx): int` (authorizing-input index or −1); highlights + compiler test `executes_opcode_output_authorizing_input` on the 2.1.0 engine. Not merged; not desk-built or desk-tested. silverscript#258 (DagitUser69, opened 7 Oct 2026 13:57:55Z) was closed as completed by someone235 on 10 Oct 12:05:04Z, with no linked commit; his comment: "There's no guarantee unused constructor arguments won't be optimized away. If it's important for you to make them affect the p2sh address, you have to use them somehow (make them part of the state, etc)". Account catalog: kaspa-builders entry dagituser69 on branch `build/dagituser69-2026-10-08` (not on kaspa-builders main). The job-escrow source named in the issue is not in that account's two public repos. The desk check below ran on v1.0.0 `3ed9733`, master until 10 Oct; not re-run on `a0dd7448`. A constructor parameter that no entry or function reads is checked for count and shape, then left out of the script. Desk check 7 Oct with the release `silverc` built from that tree: `contract C(int used, byte[32] unused)` with `used = 7` and `unused` set to 32 bytes of `0x11`, and the same contract with `0x22`, both compile to `760414559d2487637557579c6951676a68`. State span is `0+0`. Template hash is `15c6d0e9953deeec78183715e20ff0ce66306246f41cf7149cf4d8ec19a1add8`. The compiler prints no warning. The value is emitted only when an expression names it (`compile_identifier_expr`). State initializers are always encoded (`compile_contract_fields`). Copying the parameter into `byte[32] spec = jobSpec` puts those 32 bytes in the script (state span offset 1, length 33). The `0x11` and `0x22` scripts then differ, and `template_hash` stays `bff4a2d29cc0a58cdd4b67872c8df76eaa23e59fdf52ea10a38426b01294bc4e`, because `template_hash` hashes the prefix and the suffix around the state span. The P2SH address commits to the full script. The unread parameter is absent from that script, so both values share one address. The issue body says a job-escrow `byte[32] jobSpec` hit this. That covenant was not on this desk. Related #169 was closed completed by someone235 on 3 Aug 2026 14:18:09Z, with no comment and no linked commit. Its sample uses `entrypoint function`, which fails to parse on v1.0.0. The same unused-local unknown call written as `entry spend()` fails with `function 'missingFunction' not found`. `lower_local_aliases` stays commented out. declared-ply `ed53746` tables that the v1.0.0 compiler still stamps `compiler_version` 0.1.0 and rejects `pragma silverscript ^1.0.0`. Not re-run this pass. Still open on v1.0.0: #243, #249, #250, #251 (API read 10 Oct). Also open: #252 (`-N` index crash), #253 (debugger ignores `signature_script_hex`), #254 (`state:` sugar can encode the wrong layout), #255 head `3cd7d643` (19 Sep) records a per-entry compute-budget estimate and says it closes #243. #243 is still open. Ori 2097731203503640976 (9 Sep 16:57Z) is the v1.0.0 announcement. The reply with the tag is 2097731206489981298. The tag `3ed9733` was published 16:48Z; v1.0.0 is still the latest tag (10 Oct). At 20:26Z, 2097783628369395873, he said KCC-20 is not finalized, `kcc20.sil` in the repo is a PoC, and that he would update the README. The README at that tag links the KCC20 book and does not call the example a PoC. 26 Sep #256 (Drcryptodee): `silverscript-abi` v1.0.0 does not build against rusty-kaspa v2.1.0 (`EngineFlags.covenants_enabled` gone, `deserialize_i64` arity). Sutton, 29 Sep 09:13Z: wait until rusty-kaspa v2.1.0 is published to crates.io (in progress), so SilverScript builds without GitHub dependencies and can be published there too (comment). 28 Sep: those two edits plus `max_signature_script_len` at `lib.rs:1309`, on `3ed9733` with rusty-kaspa `01b532e8`, make `cargo check -p silverscript-abi` pass (rustc 1.97.1). `cargo test` stops in `silverscript-lang`, which still has the three patterns and also imports `max_ops_per_script`, `max_scripts_size`, and `max_script_element_size` (v2.1.0 spells them `MAX_OPS_PER_SCRIPT`, `MAX_SCRIPTS_SIZE`, `MAX_SCRIPT_ELEMENT_SIZE`). rusty-kaspa 2.1.0 is on crates.io since 4 Oct: kaspa-hashes 19:42Z, kaspa-consensus-core 19:45Z, kaspa-txscript 19:47Z, kaspa-rpc-core 19:52Z and kaspa-wallet-core 20:04Z all list `2.1.0` as max version (crates.io API, read 6 Oct 07:52 CEST; until 2 Oct 05:57Z they still maxed out at `0.15.0`). That publish is what Sutton said he waits for on #256 (comment, 29 Sep). someone235 closed #256 as completed on 10 Oct 12:05:48Z with "Solved in master" (comment), about five hours before #259 merged. 6 Oct: silverscript#257 (opened by someone235 at 10:38Z from `michaelsutton/silverscript:rk-2.1.0-crates-io`, one commit `c70cac93` of 4 Oct 20:34Z, no review) moves every rusty-kaspa dependency from the git rev to crates.io v2.1.0 and adapts compiler, ABI, debugger and tests: drops the `covenants_enabled` engine flag, uses the script-limit constants, the renamed signature-script limit field, and drops the numeric deserialization argument (20 files); it also bumps `spin` 0.9.8 (yanked) to 0.9.9. Closed unmerged by someone235 on 10 Oct 12:14:56Z as "Duplicate of #259" (comment). Desk-built 8 Oct at `c70cac93` (commit and rustc 1.98.1 `48a229cea` per the desk; the saved logs record commands, times and results only): `cargo check -p silverscript-abi` passed (18:48–18:49 CEST) and `cargo test --workspace` passed (23:19–23:25 CEST), 0 failed (2 ignored in debugger session tests, 19 ignored in compiler tests). Nothing else failed to build or test. silverscript master is now `a0dd7448` (was `3ed97333`, whose Cargo.toml pinned every rusty-kaspa crate by git `rev = a41a333b`): #259 (someone235, opened 10 Oct 12:14:30Z, merged by someone235 at 17:16:18Z, head `bfcceb49`) switches the rusty-kaspa dependencies to crates.io v2.1.0 (Cargo.toml) with the #257 compiler, ABI, debugger and test adaptations and the `spin` bump (per its commit message), and sets the workspace crates to 1.0.1; no tag past v1.0.0. Argent #64 (its own two `argent-runtime` edits: `block_mass_limits`, `EngineFlags`) is still open. KagenC and agenc-on-kaspa stay on `a41a333b`. #255 adds both patterns again. #250 / #251 still open, last touched 11 Sep. Reasoning kept from a moved project: two covenant-design lessons from kaspa-x402 (`724c5fff`, #22). Its hash-chain `borrow` requires only a larger output 0, so an underpaid spend is consensus-valid and moves the head while the price check lives off chain. Changing a covenant's sighash rule changes its template ids and compiled scripts, so existing state cannot upgrade in place (settle or sweep, then recreate). Rail status: see STP-KAS/kaspa-builders (entry x402). crates.io 2.1.0 vs the tag (desk read 6 Oct, no build): the published kaspa-txscript 2.1.0 crate's `src/` and `Cargo.toml.orig` are byte-identical to `crypto/txscript` at tag v2.1.0 `01b532e8`; its `.cargo_vcs_info.json` names commit `ba5ddcd9`, which GitHub's kaspanet/rusty-kaspa API does not find. `EngineFlags.covenants_enabled` is gone there too, so the #256 edits were needed against crates.io as well; #259 makes them. The silverscript workspace's other rusty-kaspa crates (kaspa-consensus, kaspa-addresses, kaspa-muhash, kaspa-txscript-zk-sdk) are also 2.1.0 on crates.io (4 Oct). `silverscript-abi` at master `a0dd7448` was desk-built, re-run 11 Oct 08:58 CEST with saved log: 21 tests passed, 0 failed. The log (in the desk's raw files, not public) records HEAD `a0dd7448ccc7bad5b99140f2c8edbbd0b2a874f1` and rustc 1.98.1 `48a229cea`: `cargo build -j 4 -p silverscript-abi` exit 0 (wall 33 s) and `cargo test -j 4 -p silverscript-abi` exit 0 (wall 1 s); `target` 1.5G after the tests. A first run at 08:50–08:51 CEST (wall 39 s and 2 s, 21 tests, peak target 1.4G / 1.5G) was not logged. Not a tag; not a workspace test. The #259 commit message says workspace checks and tests were verified; the desk did not run them. Sutton, 7 Oct (X, talk only): a hashed-address receive is a P2SH script, "a 2-line silverscript contract", and "kcc20 has builtin native support for hashed addresses (via kcc2)" (2107888723543146881, 2107884393364595048). Wallet support is third-party: see kaspa-builders. 8 Oct, Sutton (talk only): a direct 37-byte P2PKH script as a recognizable address type (2108332456050880667, 2108333221070930279; gist 04edba7e112756088c515b2949db267b): no consensus changes; needs node standardness plus wallet/SDK support; 3 bytes larger than p2pk, UTXO plurality 1. Wallet shipping is third-party: see kaspa-builders. Sutton's gist 04edba7e (8 Oct 22:59:50Z, one revision `c2ae0338`) also sizes P2SH(P2PK): 35-byte locking script and 101-byte signature script, against 37 and 99 for direct P2PKH (Schnorr); both add 36 script bytes over P2PK, direct P2PKH sits exactly at the plurality-1 boundary, and address-version assignment is outside the note. At rusty-kaspa master `01b532e8` `ScriptClass` has only NonStandard, PubKey, PubKeyECDSA and ScriptHash, so a direct P2PKH output is nonstandard today; no rusty-kaspa issue or PR mentions P2PKH (GitHub search, 9 Oct 05:55Z). Offline desk test 10 Oct 10:14–10:16 CEST at `01b532e8` (commit read from the scratch checkout after the run, not in the logs; rustc 1.98.1 `48a229cea` per the run log; a scratch `kaspa-txscript` test that is not upstream; no node, no broadcast) on the gist script: a SIG_HASH_ALL spend passed engine execution, a wrong pubkey failed with `VerifyError` (OP_EQUALVERIFY) and a wrong-key signature with `EvalFalse` (OP_CHECKSIG), and `ScriptClass::from_script` returned NonStandard; a desk result, not a consensus or standardness change. Gist, not a KIP. Prior cell: SNAPSHOT-HISTORY. Build read of #260 (13 Oct 06:02:03Z, server `Date`): open, not draft, no reviews; head `a2e2c0f4` from `aglov413/silverscript`; a proposed builtin (unreviewed). The diff registers `OpOutputAuthorizingInput` with an `int` return (`builtin_types.rs` L81–L82) and one `idx: int` parameter (L168–L169), maps it to the opcode in `compile/expression/builtin.rs` L71, adds the name to the four `highlights.scm` files, and adds the test `executes_opcode_output_authorizing_input` (`compiler_tests.rs` L12577–L12624), which expects 0, −1 and 1 for a continuation, an unbound and a genesis output. Not desk-built or desk-tested. 15 Oct (API 16:19Z): #260 still open on head `a2e2c0f4`, no reviews, not merged; silverscript master still `a0dd7448`. 23 Oct (watch): silverscript master is now `15b7bc27` (22 Oct 16:01:18Z), after someone235's #261 (merged 15:38:16Z as `acae66a5`) and #262 (16:01:19Z). They rename crates: `cli-debugger` to `silverscript-cli-debugger`, `debugger-session` to `silverscript-debugger-session`, and `tree-sitter-silverscript` to `silverscript-tree-sitter`. crates.io (read 06:06:24Z) lists all three at 1.0.1, published 22 Oct 15:34Z–15:48Z; `silverscript-lang` is still 1.0.1 (6 Oct). No new tag (newest v1.0.0); #260 unchanged. Prior cell (to 23 Oct): SNAPSHOT-HISTORY. 23 Oct (Build): crates.io API (HTTP 200, saved headers, `Date` 23 Oct 08:34:52Z–08:34:53Z): each of the three renamed crates has one version, 1.0.1, created 22 Oct 15:34:15Z (`silverscript-debugger-session`), 15:34:17Z (`silverscript-cli-debugger`) and 15:48:01Z (`silverscript-tree-sitter`). At `15b7bc27` no `.md` file uses the old package names; `tree-sitter/package.json`, `pyproject.toml`, `Makefile`, `CMakeLists.txt` and `go.mod` still use the name `tree-sitter-silverscript`.
SilverScript v1.0.0 units and limits	silverscript#214 merged 19 Aug 13:15Z and is in v1.0.0 (`3ed9733`). It adds the `temporal` type. `tx.time` takes a `temporal` threshold in Unix milliseconds. `this.age` became `this.ageDaa`, an integer DAA-score difference, not seconds (TUTORIAL at v1.0.0). Ori 2091514816686944435 (23 Aug 13:16Z): before the fix, `tx.time` was treated as seconds and `this.age` was documented as seconds. Contracts written against either before #214 need review. silverscript#245 merged 7 Sep 10:41Z and is in v1.0.0. It enforces the 244-item combined stack limit, rejects ABI calls whose signature script exceeds 250,000 bytes, applies a 10,000-iteration budget per function, and requires a state field when a covenant is declared. vertex 2096927295340523927.
Code read	Five passes, 21 Sep night: `GROK-47-THINKING.md`. #249 is the tuple arm calling `lower_scalar_expr` after the inliner; `.0`/`.1` already splits each leaf. `validateOutputState` emits `OpTxOutputSpk`, not `OpTxOutputAmount`. Spec transfer tag `79c71c23`, kcc20-live transfer tag `c3d9f92f`. A strict state decoder rejects at encoded offset 44. The 21 Sep note cites KCC-1 §6.1, §8.1, and §11.1. At `da834af0` those are §3.5.1 (dispatch tag), §3.7.1 (state encoding), and §6.6 (the same two vectors). Unkeyed BLAKE3 of those preimages is still `2c49ed65` and `676b1a86`, and `conformance.json` carries both. The 21 Sep cites stay in that file; a pointer at the top names the new numbers. The desk's 29 Sep `kaspa==2.1.0` run of the `dispatch_and_arguments` vector compiles to `2c49ed65` too (Python SDK row). #23 wants `0x05`/`0x06`; #30 reserves `0x05`–`0x7f`. Pins in this table did not move. Reasoning kept from a moved project: fees and commit/reveal in the dotk SDK (`b9fbacc1`, `04575929`). While the node's ready mass (`getFeeEstimateExperimental`) fits within one block, the relay floor fee is enough; past one block, the fee is the node feerate on the mass the mempool ranks by, storage mass included. Sending a reveal only after the node shows its commit mined means nobody can race a commit for the same gap (the `chainThroughMempool` option still sends the reveal straight after the commit). SDK status: see STP-KAS/kaspa-builders (entry name-services).
Three passes	22 Sep evening. `GROK-47-THREE-PASSES.md`. Release pin is v2.1.0. GHOSTDAG `k = 124` recomputed (`P(X > 123) = 0.011`, `P(X > 124) = 0.0088`). Kas-Smiths still 44 / 356 / 111.
saefstroem	saefstroem. KIP-16 header author (the file spells Safstrom). Active opcode `OpZkPrecompile` `0xa6`. Merged rusty-kaspa #775 (KIP-16), #953 (ZK SDK; crate `kaspa-txscript-zk-sdk` is in the v2.1.0 tag), and #861 (`OpTxInputDaaScore`). KCC-0 is his #17, Final via #25. Open (not a draft): kccs #24. kccs #31 merged 2026-10-07T20:38:09Z (`3fbec524`). Reasoning kept from a moved project: his stroemnet (`e60dc3e`) shows a cross-chain HTLC hand-built in `kaspa_txscript` without SilverScript: SHA256 hashlock, CLTV with the timelock passed as an argument, exactly 2 inputs and 2 outputs. Project: see STP-KAS/kaspa-builders (entry stroemnet).
KaspaDollar	@KaspaDollar 2113601328975098237 (23 Oct 12:00:00Z): "an initiative led by core developer @asaefstroem to build the first decentralized stablecoin on the $KAS network"; "The design we intend to follow is the decentralized, overcollateralized stablecoin"; "With the support of the core team, we consider the conditions right to bring it to Kaspa." Fundraiser "with a target of 5,000,000 KAS"; "Should the target not be reached by 1 January 2027, every contribution will be returned to the address from which it was sent." asaefstroem 2113970020598632570 (24 Oct 12:25:03Z), asked who will issue it: "Covenants will issue it." Michael Sutton 2114040191719444646 (24 Oct 17:03:53Z), quoting the announcement: "i’ll do everything in my power on the technical side to help this initiative move forward and navigate any protocol-level obstacles along the way." No code, repo, contract or fundraising address in these posts. Project entry: kaspa-builders `entries/kaspadollar.md`.
kdapp	michaelsutton/kdapp tip `eade853` (2 Jul 2025). Version `0.0.1`. ISC. README calls it alpha. An episode is an off-node interpreter: the command rides in a transaction payload (`4-byte prefix`, `4-byte nonce`, then the command), the generator grinds the nonce until 10 chosen bits of the tx id match, and the engine keeps a rollback stack for a DAG reorg. `EPISODE_LIFETIME` is `2592000` DAA scores. At 10 scores per second that distance is three days. The workspace pins rusty-kaspa tag v1.0.0 (31 Mar 2025). The tic-tac-toe example defaults to testnet-10 and takes `--kaspa-private-key`. This desk does not run it. rusty-kaspa#954 is still open on base `toccata`, behind, last update 1 May 2026, no comments. It is not a pull against master.
kaspa-xmss	biryukovmaxim/kaspa-xmss tip `e36538f` (3 Jul 2026). Unaudited XMSS^MT research: two height-12 trees, 2^24 signatures, BLAKE3/192, signatures about 3.06 KB, verify by hashing inside `TxScriptEngine`. The covenant skip window can step to the first leaf of the next bottom tree and no further. rusty-kaspa is pinned to branch `master`, not a tag. Not a live post-quantum signature. 21 Oct (watch): Ori Newman, in a KIP-22 thread: "I believe we will eventually add native pqdsa support, but this is only the first step. (btw, it's possible to implement pqdsa with kaspa script, see …)", linking this repo (2112432692549788127, 20 Oct 06:36:15Z / 08:36 CEST). His belief, not a plan, KIP or date. Tip still `e36538f` at the 21 Oct read. Prior cell (to 21 Oct): SNAPSHOT-HISTORY.
26–30 Sep notes	rusty-kaspa #1140 (30 Sep, SDK v2.1.0 findings from mainnet) is still open. atharaldsen reproduced item 1 (4 Oct 19:30Z) on master with testnet-10 params: one 100 KAS UTXO, `priorityFee` 0, one output of input − 0.002 gives `Storage mass exceeds maximum`; any `feeRate` makes it pass. His cause: `Generator::calculate_mass` keeps the tiny change because without a fee rate the storage mass of the change never enters the keep-vs-absorb test. He points to IzioDev's open #894 (head `ad72faf6`, in conflict) as the fix. Desk test 5 Oct (wasm32 SDK v2.1.0, offline, no broadcast): same shape on `testnet-10` — `priorityFee` 0 and no `feeRate` → `Storage mass exceeds maximum`; `feeRate` 1 or 100 → 1 transaction; leftover 0.1 KAS with no `feeRate` → `Mass calculation error`. #914 (RossKU, Covenant/KIP-16 code review, 5 findings at `10a4af3b`, 10 Mar) was closed as completed 4 Oct 21:32Z after atharaldsen wrote that every finding is resolved on master. Desk spot-check at master `01b532e8`: `transaction_output_estimated_serialized_size` adds covenant bytes when present (`mass/mod.rs`); RPC `TryFrom<RpcTransactionOutput>` uses `with_covenant` (`rpc/core/src/convert/tx.rs`). Two of five claims checked; the rest are his reading. saefstroem: two pools above 50% of hashrate (post), his chart, not recounted. Catalog.
KGI v2 design	kaspa-live/kaspa-graph-inspector-rs "Kaspa Graph Inspector v2" (ISC). That is the upstream; tiram88/kaspa-graph-inspector-rs is now tiram88's fork of it (GitHub `fork: true`, created 4 Oct 22:08Z), and the pulls are merged upstream by tiram88. `main` is `82dcc0e6` (11 Oct 20:37:55Z, merge of #7 "feat(storage): implement persistence invariants and database replacement", head `9e8c8e95`; 31 commits, 39 files, +6417/−606; opened and merged by tiram88). The status page at `82dcc0e6` (updated 11 October 2026) adds the service-owned API replacement gate, a generation-spanning read-lease registry, bounded drain/cancellation, and the pruning-point replacement transaction, with PostgreSQL integration tests for non-Genesis and exact-Genesis replacement; processing and API service crates still remain behaviour-free scaffolds. The PR body lists `cargo nextest run --workspace --locked` with 212/212 passed: the author's run, not desk-run. Before that, `main` was `5b6c6b75` (9 Oct 02:23:54Z, merge of #6 "fix: harden NodeService lifecycle and response handling", head `766502da`). Before that, #5 merged 9 Oct 00:39:36Z as `b7222b4c` ("feat: implement StorageService lifecycle", head `6940e81d`). The status page at `5b6c6b75` (updated 8 Oct 2026) says the first StorageService implementation slice is in (SQLx/PostgreSQL/Rustls, migrations, advisory lock, validated generations, autonomous lifecycle); processing and API service crates remain behaviour-free scaffolds. #5 (32 commits, 39 files) and #6 (8 commits, 12 files) were opened and merged by tiram88. The same status page caps the storage processing pool at four connections and the API pool at eight (read-only sessions by default), and says the imported browser still uses the v1 graph data source. Prior tip `9573d47e` (7 Oct 16:37Z, #4, merged by tiram88: 15 commits, 32 files): per the PR, rusty-kaspa dependencies move to `v2.1.0`, and the node service gains validated RPC operations bound to one connection, response normalization (blocks, GetBlocks pages, VSPC V2, BlockAdded), ordered BlockAdded / VirtualChainChanged subscriptions, and a reconnect-and-retire lifecycle. At `9573d47e` the status page still said the storage, processing and API service crates were behaviour-free scaffolds (superseded by the #5/#6 status at `5b6c6b75`). Before that, `95be668f` (6 Oct 02:12Z, #3: process configuration layers and a signal adapter). #2 `6534f4c7` (5 Oct 22:28Z) is the first implementation tranche: a Rust workspace, the KGI v1 browser app moved to Vite, and the shared `kgi-model` types plus the graph-update ingress, built on rusty-kaspa `v2.0.1` value crates (`kaspa-consensus-core`, `kaspa-hashes`, `kaspa-math` by git tag; Cargo.toml). #1 `247d69a7` (4 Oct) was the architecture-docs merge: 45 files in the merge (42 under `docs/`, plus `.gitignore`, `AGENTS.md` and `README.md`); no production Rust. At `9573d47e`, `docs/rk-issues` holds a third local record (README unchanged), checked against rusty-kaspa `01b532e8`: gRPC erases the structured GetBlock not-found error, so `HeaderNotFound` / `BlockNotFound` reach `kaspa-grpc-client` only as a general string error (author rates G2, K1, P1). The first two, unchanged at `95be668f` and checked against rusty-kaspa `c338d495`: GetBlocks can mix two virtual views between sink capture and anticone collection (author rates G1, P1), and BlockAdded can send `verbose_data: None` when enrichment fails (G2, P1). Local notes, not rusty-kaspa issues. 28 Sep grep: kns `c745003`, kns-tn10-testing `ddf9aa9`, KagenC `48a8c77`, agenc-on-kaspa `c81cdcc`, grok-build-vprogs, and tn10-vprogs-round8-covenants `305b452` do not call `GetBlocks`. vprogs `07d486dd` calls `get_blocks` only in the test helper two_provers_contend.rs; a mixed page would under-count. The bridge treats missing `verbose_data` as an error (worker.rs). round8 subscribes to BlockAdded and counts transactions; it does not read `verbose_data`. Catalog. Desk read 6 Oct at kaspa-live `95be668f`: the workspace pins rusty-kaspa `v2.0.1` by git tag (Cargo.toml L26-29) and uses only value types: `kaspa_hashes::Hash` as `BlockHash` and `kaspa_math::Uint192` as `BlueWork` (block.rs L6-9), plus `kaspa_consensus_core::network::{NetworkId, NetworkType}` and `kaspa_core::log::LevelFilter` in config. The graph-update ingress (`kgi-api-ingress`) depends only on `kgi-model`, `thiserror` and tokio (Cargo.toml); at `95be668f` there was no wRPC or gRPC node client (at `9573d47e` `kgi-node` depends on `kaspa-grpc-client`). Prior cell: SNAPSHOT-HISTORY. Build: `82dcc0e6` is still HEAD (ls-remote 06:07:25Z); #7 merged 11 Oct 20:37:55Z by tiram88, 31 commits, 39 files, +6417/−606 (API 06:07:17Z). The 212/212 nextest is the author's run, not desk-run. 15 Oct: main tip `232eae41` (14 Oct 16:34:04Z), merge of #8 from tiram88 (processing workers, RPC cancellation). Not desk-run. 16 Oct (watch): main tip `e3be9700` (15 Oct 21:37:29Z), merge of #9 "feat: implement canonical API graph model" from tiram88 (opened and merged by tiram88). PR summary: canonical graph values, validated level extents, checked graph deltas; seeded/extracted views with Head/Fixed/Frozen mutation; project committed block and VSPC updates; delta application and level-scoped retained history. status.md at `e3be9700` updated 15 October 2026. Prior tip `232eae41` (#8). Not desk-run. Build (16 Oct): #9 was merged by tiram88 at 15 Oct 21:37:29Z: 12 files, +3323/−52. The compare `232eae41...e3be9700` (17 commits) adds `delta.rs`, `graph.rs` and `history.rs` to the `kgi-api-model` crate and edits its `lib.rs` and `Cargo.toml`, `Cargo.lock`, and six docs (api-graph, verification, settled decisions, choices, sequence, status). No other crate changed, so no processing or ApiService code moved. status.md at `e3be9700` adds "Implementation increment 6 is implemented" and says publication, database projection reads, encoding, transport and ApiService runtime "remain in the separately numbered increments". Its validation line (337/337 Nextest tests) is the project's; not desk-run. 17 Oct (watch): main tip `8e175b76` (16 Oct 20:29:01Z), merge of #11 "feat: add API publication state and mutation kernel" (implementation increment 8 per the PR; 13 commits, 21 files, +1228/−222), after #10 "feat: implement API graph projection reads" merged 17:33:13Z as `254d480b` (increment 7; 11 commits, 15 files, +2076/−58). Both opened and merged by tiram88. Not desk-run. Prior cell (to 17 Oct): SNAPSHOT-HISTORY. Build (17 Oct): #10 (merge `254d480b`, 16 Oct 17:33:13Z) and #11 (merge `8e175b76`, 20:29:02Z), both opened and merged by tiram88. status.md at `8e175b76` ("Updated 16 October 2026") adds "Implementation increment 7 is implemented" (projection request values in `kgi-api-model`, `ValidatedApiDbClient::load_graph_view_seed` in `kgi-storage`) and "Implementation increment 8 is implemented" (the private `kgi-api-core` publication kernel), and says "ApiService orchestration remains behavior-free scaffolding". The compare `e3be9700...8e175b76` (26 commits) touches `kgi-api-core`, `kgi-api-model`, `kgi-storage`, `Cargo.lock` and docs. Validation counts (357/357 Nextest) are the project's; not desk-run. 18 Oct (watch): main tip `7059deb4` (17 Oct 11:33:55Z), merge of #12 "feat: add graph wire values and codec" (opened 10:39:44Z, head `18c4590a`, 13 commits, 46 files, +2913/−351; opened and merged by tiram88). Open: #13 "feat: implement API encoding scheduler and response cache" (tiram88, opened 17 Oct 21:58:11Z, head `de3a3d4e`, 11 commits, 25 files, +3019/−238); its body lists 436/436 Nextest (the author's run). Not desk-run. Prior cell (to 18 Oct): SNAPSHOT-HISTORY. Build (18 Oct): status.md at `7059deb4` ("Updated 17 October 2026.") adds "Implementation increment 9 is implemented": public API outcome and status values in `kgi-api-model`, and private `kgi-api-core` DTOs as "the sole Serde boundary" for graph, delta, error, status and SSE payloads, with public `u64` values as decimal JSON strings. So #12 completes increment 9. It says encoding scheduling, compression, caching, routing and response delivery "remain in later increments"; that is what open #13 proposes (0 reviews, every page). The validation line (402/402 Nextest) is the project's; not desk-run. 19 Oct (watch): #13 merged 18 Oct 19:50:04Z by tiram88; main tip `a2660876` (head `a7c47278` "docs(api): close gzip quality decision"; 12 commits, 26 files, +3022/−245; 0 reviews). status.md at `a2660876` (header still "Updated 17 October 2026.") says "Implementation increment 10 is implemented": the bounded encoding scheduler, capped JSON serialization and deterministic gzip, the publication-local graph response cache, source-keyed delta and destination-heat indexes, and five derived Head cache tiers. Logical request operations, client wakeup state, publication construction, HTTP routing and response delivery remain in later increments. The validation line (436/436 Nextest) is the project's; not desk-run. Prior cell (to 19 Oct): SNAPSHOT-HISTORY. Build (19 Oct): status.md at `a2660876` (HTTP 200, saved) has "Implementation increment 10 is implemented" after increments 6 to 9; the header line still reads "Updated 17 October 2026." What remains, per the file: "Logical request operations, client wakeup state, publication construction, HTTP routing, and response delivery remain in the later increments". #13: 0 reviews (every page), merged by tiram88 as `a2660876`. 20 Oct (Build): `main` still `a2660876` (API 06:24:17Z); no commit since and no pull after #13 (newest 10 pulls read). 21 Oct (watch): #14 "feat: implement SSE client registry and mailboxes" opened 20 Oct 21:24Z and merged by tiram88 at 21:31:14Z (23:31 CEST) as `58fff562`, now main (head `0b613275`, 14 files, +1686/−131, 0 reviews, 0 comments). status.md at `58fff562` ("Updated 20 October 2026.") says "Implementation increment 11 is implemented": each `GraphPublication` owns a publication-local SSE client registry and each connection one bounded, ordered mailbox. The validation line (470/470 Nextest) is the project's; not desk-run. Prior cell (to 21 Oct): SNAPSHOT-HISTORY. 21 Oct (Build): `status.md` at `58fff562` (saved) says "Updated 20 October 2026." and "Implementation increment 11 is implemented: each `GraphPublication` now owns its publication-local SSE client registry and each connection owns one bounded, ordered mailbox." #14: 0 reviews (API), merged 21:31:14Z. 22 Oct (watch): #15 "feat: implement API database generation binding" opened 19:08:03Z and merged by tiram88 at 19:13:37Z as `c9bfe864`, now main (head `05c797ef`, 7 files, +602/−58, 0 reviews). Body: "This PR implements increment 12 only"; no public request handlers or ApiService integration yet. 486/486 Nextest is the author's run, not desk-run. Prior cell (to 22 Oct): SNAPSHOT-HISTORY. 22 Oct (Build): `status.md` at `c9bfe864` (saved, HTTP 200) says "Updated 21 October 2026." and "Implementation increment 12 is implemented: the private `kgi-api-core` `api_db` module contains the watch-backed API database binding, its ordered generation-event and complete-snapshot values, synchronous update and gate entry points, immediate and waiting accessors, and terminal cutoff." #15: 0 reviews, 0 comments (every page). 23 Oct (watch): tiram88 merged #16 "feat: implement graph publication runtime" (22 Oct 12:31:18Z, `945467dd`, 26 files, +2277/−756) and #17 "feat: implement ApiService lifecycle and publication installation" (21:23:21Z, `9a9a50b8`, 19 files, +1624/−183), now main; 0 reviews on either. Prior cell (to 23 Oct): SNAPSHOT-HISTORY. 23 Oct (Build): `status.md` at `9a9a50b8` (saved, HTTP 200) says "Implementation increment 14 is implemented" and "lanes, request and SSE guards, and Axum transport remain in increments 15–17." 25 Oct (watch): tiram88 opened and merged #18 "docs(api): redesign Head and delta caching" (24 Oct 20:12:02Z, `14e5eb88`, 13 files, +1184/−709) and #19 "feat(api): add atomic history and replay-floor foundation" (21:31:21Z, `405d5e54`, 9 files, +1187/−192), now main; 0 reviews on either. #19 body: "This PR implements increment 15 only." `status.md` at `405d5e54` (saved, HTTP 200) says "Updated 24 October 2026." and "Implementation increment 15 is implemented"; its increment 14 paragraph now says lanes, request and SSE guards, and Axum transport "remain in increments 15–20" (15–17 at `9a9a50b8`). The 551/551 Nextest in the #19 body is the author's run; not desk-run. Prior cell (to 25 Oct): SNAPSHOT-HISTORY.
research.kas.pa	research.kas.pa read 29 Sep 2026, top to bottom, every topic, including the category-about posts. Rechecked 3 Oct ~07:52 CEST: newest topic still 522. `/latest` lists 53 topics. Seven about-posts are not on that list. 60 in all. Newest topic is still 522 (8 Sep 2026). Nothing newer. The 11 Sep freeze said ~50 topics and L1/L2 = 17. L1/L2 has 18 content topics; 251 was already there. A thread is not a KIP. The 2019 HAPI and UPI posts are not the 2021 fair launch. Topic 473 does not change max supply. Topic 522 is a question, not a privacy layer: one post (JackKas), no replies. olafweller/kaspa-privacy-initiative `dc2f176d` (2 Oct) cites it as prior discussion of the same goal (`research/existing-kaspa-privacy.md`); at `dc2f176d` that repo was research only; since 3 Oct it carries PoC code. Opened on Kas-Smiths topic 156. Topics 295 and 429 name a higher block rate as an aim, not a live rate. Reading: `RESEARCH-KAS-PA.md`. 20 Oct (watch): new topic 545 "KIP 22: Pay-to-Public-Key-Hash via P2SH" (someone235, 19 Oct 11:54:21Z, one post: a discussion-thread pointer to kips #48), the `Comments-URI` of kips #48 (see KIPs). Before it the newest topic was 522. `/latest.json` HTTP 200 at 05:52:03Z (headers saved). A thread is not a KIP. Prior cell (to 20 Oct): SNAPSHOT-HISTORY.
Do not weld	Row emptied on 22 Oct 2026: kaspa-master-file is facts only.

Older sections

The older "What this pass did" receipts and the reference sections 0–10 (sites, forum, GitHub orgs, KIPs, people, channels, news freeze, intel pack) are in RECEIPTS.md, moved there verbatim on 26 Sep 2026. The board above wins.

Standard disclaimer. This GitHub, not the topic above.

Intentions are good; thought process is questionable. STP remains delusional. Si vis pacem, para bellum.

Intern at https://sixpack.wtf/
X: https://x.com/StppStp · GitHub: https://github.com/STP-KAS

Name		Name	Last commit message	Last commit date
challenges		challenges
prompts		prompts
revisits		revisits
scripts		scripts
.gitignore		.gitignore
AGENTS.md		AGENTS.md
BUILD-PROMPT.md		BUILD-PROMPT.md
CRYPTO-FINANCE.md		CRYPTO-FINANCE.md
CURSOR-PROMPT.md		CURSOR-PROMPT.md
DESK-BOT.md		DESK-BOT.md
DESK-PROMPT.md		DESK-PROMPT.md
DISCLAIMER.md		DISCLAIMER.md
GROK-47-KNS-REVIEW.md		GROK-47-KNS-REVIEW.md
GROK-47-REVIEW.md		GROK-47-REVIEW.md
GROK-47-THINKING.md		GROK-47-THINKING.md
GROK-47-THREE-PASSES.md		GROK-47-THREE-PASSES.md
GROK-HEAVY-REVIEW.md		GROK-HEAVY-REVIEW.md
GROK-HEAVY-SHOWCASE.md		GROK-HEAVY-SHOWCASE.md
KASRANKS.md		KASRANKS.md
LICENSE		LICENSE
POC-REVISITED.md		POC-REVISITED.md
PROCESS.md		PROCESS.md
README.md		README.md
RECEIPTS.md		RECEIPTS.md
RESEARCH-KAS-PA.md		RESEARCH-KAS-PA.md
RETEST.md		RETEST.md
SATOSHIS-ENGINE.md		SATOSHIS-ENGINE.md
SNAPSHOT-HISTORY.md		SNAPSHOT-HISTORY.md
START-HERE.md		START-HERE.md
STP-REPOS.md		STP-REPOS.md
THINK-BIG.md		THINK-BIG.md
TN10-FIELD-2026-09-29.md		TN10-FIELD-2026-09-29.md
TN10-INCIDENT-2026-09-29.md		TN10-INCIDENT-2026-09-29.md
VPROG-TICTACTOE.md		VPROG-TICTACTOE.md
intel-pack.md		intel-pack.md
master.json		master.json

Navigation Menu

Repository navigation

About

Repository files navigation

Kaspa master file

What

Why

How

How to read this file

Now (read this first)

Older sections

About

Releases

Packages

Contributors

Languages

Latest commit

History

Folders and files

Repository files navigation

Kaspa master file

What

Why

How

How to read this file

Now (read this first)

Older sections

About

Resources

Stars

Watchers

Forks

Releases

Packages

Contributors

Languages