@smartledger/bsv 9.7.0 → 9.9.0

package/docs/AUDIT_SCOPE.md

@@ -34,14 +34,14 @@ module sounds. That is a deliberate revision: an earlier version of this documen
 scoped Tier 1 as "the cryptographic core" and would have excluded four of the six real
 defects this codebase has produced. See §2.1.
 
-### Tier 1 — 11,247 lines
+### Tier 1 — 11,962 lines
 
 | Module | Lines | Why it matters |
 | --- | ---: | --- |
 | `lib/transaction/` | 2,779 | Sighash construction and signing — both BIP-143 and the Original Transaction Digest Algorithm. |
-| `lib/script/interpreter.js` | 2,684 | **Scoped to the flag and era surface, not opcode execution.** Consensus-flag selection and defaults, era derivation (Genesis/Chronicle), the limits derived from them, and the semantics of the exported `verify()`. Opcode execution is excluded — see §2.2. |
+| `lib/script/interpreter.js` | 2,821 | **Scoped to the flag and era surface, not opcode execution.** Consensus-flag selection and defaults, era derivation (Genesis/Chronicle), the limits derived from them, and the semantics of the exported `verify()`. Opcode execution is excluded — see §2.2. |
 | `lib/crypto/` | 2,519 | ECDSA, nonce derivation, signature encoding, the script-number type. **Scope this for an architectural judgement as well as for bugs** — see §2.3. |
-| `lib/notaryhash/` | 1,436 | BRC-220 signing and verification. Publicly reachable and relied on downstream. |
+| `lib/notaryhash/` | 2,014 | BRC-220 signing and verification. Publicly reachable and relied on downstream. |
 | `lib/privatekey.js`, `lib/publickey.js` | 843 | Key construction, serialisation, WIF. Recent defects here produced a *different* key without error. |
 | `lib/smart_contract/` (targeted) | 472 | `locks.js` and the covenant-facing entrypoints in `index.js`: CLTV and HTLC locking semantics, flag plumbing, and any wrapper claiming mainnet-equivalent verification. Not the whole 6,908-line module. |
 | `lib/covenant/` | 409 | The verification harness. Its flag word is what made covenants verify under 2019 rules while claiming to mirror mainnet. |
@@ -61,8 +61,10 @@ is not.
 
 ### 2.1 Why the boundary moved
 
-Six defects have been found in this codebase and fixed. Four of them were in code the
-previous version of this scope **excluded**:
+**Ten** defects have been found in this codebase and fixed. Four were in code the
+previous version of this scope excluded; the four most recent all landed on the
+interpreter's era and flag surface, which is why that surface is scoped and opcode
+execution is not.
 
 | Defect | Module | Was it in the old scope? |
 | --- | --- | --- |
@@ -72,11 +74,24 @@ previous version of this scope **excluded**:
 | The reachable RFC 8785 canonicalizer was non-conformant while a correct one sat private; three downstream packages copied the wrong one | `lib/util/jcs.js`, `lib/ltp` | partly |
 | `ECDSA.verify()` returned the instance, so `if (verify())` was always truthy — a fail-open accepting forged signatures | `lib/crypto` | yes |
 | ECDSA nonce reuse across two signings on one instance, leaking the private key | `lib/crypto` | yes |
+| `OP_BIN2NUM` capped every era at the pre-Genesis 4-byte script number, so covenants holding 21.47 BSV or more were unspendable and every `nLockTime` from 2038 was rejected | `lib/script/interpreter.js` | yes (9.4.0) |
+| `policy().lockUntil()` enforced one of `CheckLockTime`'s three rules: a final `nSequence` voided the lock, and a past timestamp cleared a future height floor | `lib/smart_contract` | yes (9.4.0) |
+| `SIGPUSHONLY`, `LOW_S` and `NULLFAIL` are consensus on BSV and were missing from the default flag word, so `verify()` accepted scripts the network judges invalid | `lib/script/interpreter.js` | yes (9.5.0) |
+| The `CHECKMULTISIG` op count read the static cap, refusing a post-Genesis multisig the line above had just permitted | `lib/script/interpreter.js` | yes (9.6.0) |
+| The stack cap was checked once at the end of the script rather than after every opcode, and was still applied after Genesis removed it | `lib/script/interpreter.js` | yes (9.7.0) |
 
 The pattern is not "the primitives are weak". It is that **code making claims about
 consensus behaviour was wrong about it**, and the tests agreed because they shared the
 same assumption. Scope has been moved onto that surface.
 
+**The four most recent are the sharpest evidence in this document**, because in every
+one the reference corpus passed 1,483/1,483 before the fix and 1,483/1,483 after it,
+with zero false accepts either way. A node vector states its own flags, so no vector
+can say which flags or which era belong in a *default*. Every `OP_BIN2NUM` vector, every
+`SIGPUSHONLY` vector and every `OP_COUNT` vector in that corpus runs pre-Genesis; both
+`STACK_SIZE` vectors end over the cap, which is the one case an end-of-script check does
+see. The mechanism was covered in each case. The selection was not.
+
 ### 2.2 Why `lib/script` shrinks rather than leaves
 
 `lib/script` has the strongest external evidence in the repository: 1,483/1,483 of the
@@ -84,10 +99,13 @@ reference node's own consensus vectors, zero false accepts and zero false reject
 is evidence about **opcode execution**, and re-auditing it by hand is the least
 productive money in this engagement.
 
-It is not evidence about which flags a caller ends up with. Both consensus defects above
-were flag-selection and era-derivation failures reachable through `interpreter.js`, and
-no vector covers them because every vector states its own flags. So the interpreter stays
-in scope, scoped to that surface, and the remaining 1,175 lines of `lib/script` leave.
+It is not evidence about which flags a caller ends up with. **Seven** of the ten defects
+above were flag-selection or era-derivation failures reachable through `interpreter.js`,
+and no vector covers them because every vector states its own flags. Five of those seven
+were found *after* this boundary was drawn, which is the strongest confirmation of it
+available: the surface predicted to be defect-bearing produced five more, while opcode
+execution produced none. So the interpreter stays in scope, scoped to that surface, and
+the remaining 1,175 lines of `lib/script` leave.
 
 ### 2.3 A specific instruction for `lib/crypto`
 
@@ -115,6 +133,14 @@ the tests were written from the same assumption. A file-by-file review finds non
 them. Checking a claim against something outside this repository finds all of them —
 which is exactly how each was eventually caught.
 
+Two of the ten make the point without needing to be taken on trust. `SIGPUSHONLY` was
+settled by broadcasting to mainnet a transaction that violated it and nothing else, and
+reading the node's reject code: 16 `mandatory-script-verify-flag-failed`, against 64
+`non-mandatory` for `MINIMALDATA` in the same run. And the `lockUntil` defect was found
+by comparing the compiled script against the node's `CheckLockTime`, rule by rule,
+rather than against what the library's own tests expected. Neither answer exists inside
+this repository.
+
 ## 3. Out of scope, and why
 
 | Component | Status | Reason |
@@ -124,14 +150,14 @@ which is exactly how each was eventually caught.
 | `lib/address.js`, `lib/networks.js`, `lib/opcode.js`, `lib/hdprivatekey.js`, `lib/hdpublickey.js` (2,391 lines) | Cut to pay for §2.1 | Formatting, network constants and BIP-32 derivation. No defect has originated here, and `networks.js` in particular defines addressing constants — pubkey hashes, xpub prefixes, ports, DNS seeds — and contains **no consensus-flag logic at all**. |
 | The rest of the application layer — `lib/gdaf/`, `lib/ltp/`, `lib/ordinals/`, `lib/block/`, `lib/didweb/`, `lib/vcjwt/`, `lib/statuslist/`, most of `lib/smart_contract/`, plus assorted top-level files | Excluded | ~26,000 lines. Worth a separate engagement; including it here would blur the question in §1. Note the parts of it with a demonstrated defect history have been pulled *into* Tier 1 rather than left here — see §2.1. |
 
-Totals reconcile against `lib/`, which is 38,879 lines across 131 files:
+Totals reconcile against `lib/`, which is 39,646 lines across 131 files:
 
 ```
-tier 1      11,247
+tier 1      11,962
 tier 2       1,607
-excluded    26,025
+excluded    26,077
             ------
-total       38,879
+total       39,646
 ```
 
 Measured 2026-08-29 at `a954c27`. These figures drift as the library changes — an
@@ -202,7 +228,7 @@ seeking a quote for an independent security review.
 
 Scope, and we would like these priced separately:
 
-  Tier 1 — 11,247 lines. Sighash construction and signing; ECDSA, nonce
+  Tier 1 — 11,962 lines. Sighash construction and signing; ECDSA, nonce
   derivation and signature encoding; the consensus-flag and era-derivation
   surface of the script interpreter; BRC-220 signing and verification;
   key construction and serialisation; the covenant verification harness and

package/docs/BRC220_BATCH_LEAF_AMENDMENT.md

@@ -3,8 +3,16 @@
 §On-chain record specifies *which* Merkle tree batch mode uses, but never says what goes
 in a leaf. This proposes the definition, with the reasoning that led to it.
 
-Prepared 2026-08-17 while implementing BRC-220 in `@smartledger/bsv`. The second gap of
-this kind, after `encoding` — see [BRC220_ENCODING_AMENDMENT.md](BRC220_ENCODING_AMENDMENT.md).
+Prepared 2026-08-17 while implementing BRC-220 in `@smartledger/bsv`.
+
+**Status: filed** as [bsv-blockchain/BRCs#246](https://github.com/bsv-blockchain/BRCs/pull/246)
+on 2026-09-11, together with a clarification of the ECDSA digest convention. Before filing
+it was checked against the BRC-220 reference implementation, whose batcher uses exactly
+this leaf (`leaves = batch.map(e => e.proofHash)`), and the vector below was rebuilt
+without any of this library's code — the root from the reference's own RFC 6962 tree.
+
+A companion draft on the `encoding` field was **wrong and has been withdrawn**; see
+[BRC220_ENCODING_AMENDMENT.md](BRC220_ENCODING_AMENDMENT.md).
 
 ---
 
@@ -104,9 +112,10 @@ states it in `lib/notaryhash/index.js` and enforces it in
 `test/notaryhash/batch_leaf.js` — including a test that a tree built over `canonicalBytes`
 is rejected, so the choice is checked rather than merely intended.
 
-No deployed batch certificates are known to use the other reading. If any exist, they were
-built against an ambiguous sentence and would need reissuing; batch mode is the least-used
-of the three and this is the moment to fix it, before that stops being true.
+The reference implementation uses the same reading, so certificates its service has
+issued in batch mode already conform. An implementation that chose `d = canonicalBytes`
+built against an ambiguous sentence and would need to reissue; the second root published
+below makes that diagnosable in one line.
 
 ---
 
@@ -129,7 +138,8 @@ regenerates byte-identically and any implementation can rebuild it from scratch:
 - private key `i` = `SHA-256("BRC-220/batch-vector/key/" + i)`
 - `payloadHash` `i` = `SHA-256("BRC-220/batch-vector/payload/" + i)`
 - `createdAt` `i` = `2026-01-0(i+1)T00:00:00.000Z`
-- `algorithm` = `ECDSA-secp256k1`, `hashAlgorithm` = `SHA-256`, `encoding` = `"raw"`
+- `algorithm` = `ECDSA-secp256k1`, `hashAlgorithm` = `SHA-256`, a 64-byte `r ‖ s`
+  signature normalised to low-S, and a 33-byte compressed public key
 
 **Signing.** The signer signs the 32-byte `payloadHash` directly — the digest *is* the
 scalar, big-endian. RFC 6979 makes the nonce deterministic, so the signatures, and every

package/docs/BRC220_ENCODING_AMENDMENT.md

@@ -1,100 +1,39 @@
-# Proposed BRC-220 amendment: define the `encoding` field
+# Withdrawn: proposed BRC-220 `encoding` amendment
 
-`encoding` is listed among the certificate's required fields, but its values are never
-enumerated. This proposes the definition, with the reasoning that led to it.
+**This proposal was wrong and has been withdrawn. It was never filed.**
 
-Prepared 2026-08-16 while implementing BRC-220 in `@smartledger/bsv`. The gap surfaced
-because an implementation cannot emit a required field whose values are undefined.
+It proposed defining the certificate's `encoding` field as `"raw"` or `"der"` — the
+signature's byte format — and requiring ECDSA signatures to be low-S, with a 33-byte
+compressed public key. It was written from this library's implementation alone.
 
----
+Checked against the BRC-220 reference implementation before filing, it contradicted
+it on every point:
 
-## Proposed text
+| | this proposal | reference implementation |
+| --- | --- | --- |
+| `encoding` means | the signature's byte format | how `publicKey` and `signature` are written into the JSON |
+| `encoding` values | `"raw"`, `"der"` | `"hex"`, `"base64"` |
+| signature bytes | 64-byte `r ‖ s` only, DER discouraged | 64-byte `r ‖ s` or DER, told apart by the bytes |
+| high-S signatures | rejected | accepted, deliberately |
+| public keys | 33-byte compressed | 33-byte compressed or 65-byte uncompressed |
 
-Insert into **§Certificate**, after the sentence listing the required fields.
+Every certificate the reference service has issued uses `"hex"` or `"base64"`. Filing
+this would have proposed a spec change incompatible with all of them.
 
-> #### `encoding`
->
-> `encoding` names the byte representation of `publicKey` and `signature` as they appear
-> in the certificate and in the canonical proof bytes.
->
-> Implementations **MUST** support `"raw"` and **SHOULD** emit it:
->
-> - **`"raw"`** — the scheme's native fixed-length byte string.
->   - For `ECDSA-secp256k1`, a signature is exactly **64 bytes**: `r ‖ s`, each a 32-byte
->     big-endian unsigned integer, zero-padded on the left. A public key is the 33-byte
->     compressed SEC1 form.
->   - For `ML-DSA-*` and `SLH-DSA-*`, the signature and public key are the byte strings the
->     scheme itself defines (FIPS 204, FIPS 205). No further framing is applied.
-> - **`"der"`** — ECDSA signatures in ASN.1 DER, as produced by Bitcoin tooling.
->   Accepted for compatibility with existing Bitcoin-native signers; **SHOULD NOT** be
->   emitted by new implementations, for the reason given below. Undefined for post-quantum
->   algorithms, which have no DER form.
->
-> For `ECDSA-secp256k1`, `s` **MUST** be in the lower half of the curve order
-> (`s ≤ n/2`). A signature with a high `s` **MUST** be rejected rather than normalised on
-> receipt: normalising changes the signature bytes, and the signature bytes are inside
-> `proofHash`.
+It also exposed that `@smartledger/bsv` 8.3.0–9.8.0 could not verify a single
+certificate the reference issued: its `version`, `mode`, `encoding`, `anchor` and batch
+`path` fields all differed. The library now reads both formats, and
+writes the reference one given `format: 'reference'` — the default from 10.0.0. See
+`lib/notaryhash/certificate.js`.
 
----
+## What is still true
 
-## Why `"raw"` rather than DER
+The gap this draft set out to close is real: BRC-220 lists `encoding` as a required field
+and never enumerates its values, and says nothing about the JSON form of `version`,
+`mode`, `anchor` or the batch `path`. A clarification defining those fields **as the
+reference writes them** is a separate, later proposal.
 
-### 1. DER is not canonical, and `proofHash` covers the signature bytes
-
-The canonical proof bytes include `lp(signature)`, so the signature's exact byte
-representation determines `proofHash`. DER does not have one representation per signature.
-Measured over 200 signatures from a single key with `@smartledger/bsv`:
-
-```
-DER lengths:  { "69": 1, "70": 108, "71": 91 }
-raw lengths:  { "64": 200 }
-```
-
-The variance is ordinary leading-zero handling in the two INTEGERs, and it is entirely
-legal DER. But it means the same signing act can yield different `proofHash` values
-depending on which library encoded it — and a certificate re-encoded in transit no longer
-matches its own integrity root.
-
-That is the property §Motivation names first: *"any implementation in any language
-reproduces identical bytes"*, and the reason the spec already rejects `JSON.stringify`.
-A non-canonical signature encoding reintroduces exactly the problem the binary encoding was
-chosen to avoid.
-
-### 2. Every other algorithm in the spec is already raw
-
-ML-DSA-65 signatures are 3,309 bytes; SLH-DSA-SHA2-128s are 7,856. Both are fixed-length
-byte strings with no DER form. With ECDSA on DER and the post-quantum schemes on raw,
-every verifier needs per-algorithm branching on `encoding`. With ECDSA on raw, all sixteen
-algorithm identifiers share one representation and the branch disappears.
-
-### 3. It matches what the signature actually is
-
-§Algorithms specifies that the signer signs the 32-byte `payloadHash` **directly**. This is
-a detached signature over a digest, not a Bitcoin script signature — the case ES256K
-(RFC 7515) and WebCrypto both address, and both use `r ‖ s`, not DER.
-
-### 4. Low-S is a separate malleability, and raw does not fix it
-
-For any ECDSA signature, `s` and `n − s` both verify. They are different bytes, so they
-produce different `proofHash` values. Without a normative rule, two valid certificates
-exist for one signing act — an ambiguity a notarization protocol should not carry.
-
-Requiring low-S at signing, and **rejecting** rather than normalising on receipt, keeps
-`proofHash` a function of the certificate as issued.
-
----
-
-## Note on `toCompact`
-
-Some Bitcoin libraries expose a 65-byte "compact" signature. That is not this format: it
-carries a leading recovery byte for public-key recovery. `"raw"` is the bare 64 bytes,
-with no recovery byte, because the public key is already a certificate field.
-
----
-
-## Impact on existing certificates
-
-None, if no certificate has yet been issued with `encoding: "der"`. If any have, they
-remain valid — `"der"` stays an accepted value, and the SPV envelope and `proofHash`
-semantics are untouched. This amendment defines a field that was previously unspecified;
-it does not change any field that was.
+The batch-leaf clarification written alongside this one was correct, and was confirmed
+against the reference implementation: it was filed as
+[bsv-blockchain/BRCs#246](https://github.com/bsv-blockchain/BRCs/pull/246). See
+[BRC220_BATCH_LEAF_AMENDMENT.md](BRC220_BATCH_LEAF_AMENDMENT.md).

package/docs/BRC220_PLAN.md

@@ -173,45 +173,44 @@ summarising rather than anything in the document.
 - **The service is a role, not a requirement.** §What a certificate proves: "any party
   holding a valid (hash, signature, publicKey) triple may re-anchor it; the attestation
   remains valid". A self-notarizing caller producing its own certificate is conformant.
-- **The batch Merkle leaf is NOT settled by the spec — it is a choice this
-  implementation made.** §On-chain record writes `leaf = SHA256(0x00 ‖ d)`, but that is
-  RFC 6962's own generic notation for the construction and `d` is never bound to a value.
-  `canonicalBytes` appears once in the whole document, in the `proofHash` definition, and
-  nowhere in the batch text. We read `d` as `proofHash`; reading it as `canonicalBytes` is
-  equally sound and produces a different root, so the two do not interoperate. Recorded as
-  an ambiguity rather than a settled question, with proposed spec text in
-  [BRC220_BATCH_LEAF_AMENDMENT.md](BRC220_BATCH_LEAF_AMENDMENT.md) and enforcement in
-  `test/notaryhash/batch_leaf.js`. This is the second gap of the kind, after `encoding`.
+- **The batch Merkle leaf is NOT settled by the spec.** §On-chain record writes
+  `leaf = SHA256(0x00 ‖ d)`, but that is RFC 6962's own generic notation for the
+  construction and `d` is never bound to a value. `canonicalBytes` appears once in the whole
+  document, in the `proofHash` definition, and nowhere in the batch text. We read `d` as
+  `proofHash`; so does the reference implementation's batcher, and given the same five
+  proofs it builds the same root. Reading it as `canonicalBytes` is equally sound and
+  produces a different root, so the two do not interoperate. Filed upstream as
+  [bsv-blockchain/BRCs#246](https://github.com/bsv-blockchain/BRCs/pull/246); see
+  [BRC220_BATCH_LEAF_AMENDMENT.md](BRC220_BATCH_LEAF_AMENDMENT.md), enforced in
+  `test/notaryhash/batch_leaf.js`.
 - **`createdAt` is advisory for trust but load-bearing for the hash.** §Verification calls
   it "an advisory client field only" — meaning proof-of-existence time comes from the
   block, not from this field. It is still inside the canonical bytes as `createdAtUnix`,
   so it cannot be altered after issuance.
 
-Decided, and proposed back to the spec:
+Decided here, then reversed against the reference implementation:
 
-- **`encoding` is `"raw"`.** The field is required by the spec but its values were never
-  enumerated, so this library defines them and proposes the definition upstream — see
-  `docs/BRC220_ENCODING_AMENDMENT.md`.
+- **`encoding` was defined as `"raw"` — the signature's byte format — and low-S was
+  required.** Both were wrong. The spec requires the field without enumerating its values,
+  and 8.3.0–9.8.0 filled that gap from this library's own reasoning: raw `r ‖ s` because DER
+  is not canonical, low-S because `s` and `n − s` both verify and hash differently.
 
-  For `ECDSA-secp256k1` that is 64 bytes, `r ‖ s`, each a 32-byte big-endian integer, with
-  a 33-byte compressed public key. NOT DER, and not the 65-byte `toCompact` form, which
-  carries a recovery byte the certificate does not need because it already has the key.
+  The reference implementation, which is what issued certificates are checked against,
+  decided otherwise on every point. `encoding` is `"hex"` or `"base64"` — how `publicKey`
+  and `signature` are written into the JSON, not what their bytes are. A signature may be
+  64-byte `r ‖ s` or DER, told apart by the bytes. A public key may be compressed or
+  uncompressed. High-S is accepted deliberately.
 
-  The deciding argument is that `proofHash` covers `lp(signature)`, and **DER is not
-  canonical**. Measured over 200 signatures from one key: DER came out at 69, 70 and 71
-  bytes depending on leading-zero handling, all of it legal. Raw was 64 bytes every time.
-  The same signing act producing different `proofHash` values is precisely the failure the
-  binary encoding exists to prevent — it is why the spec already refuses `JSON.stringify`.
+  The reasoning behind the reversal holds: `proofHash` covers the signature bytes exactly
+  as the signer produced them, so a DER or malleated form is a *different* certificate,
+  not a forgery of this one. What the original argument protected against — two
+  certificates for one signing act — is real, but it is the issuer's choice to make, and
+  every certificate still commits to exactly one form.
 
-  Two supporting reasons: ML-DSA and SLH-DSA have no DER form, so raw makes `encoding`
-  uniform across all sixteen algorithm identifiers instead of forcing per-algorithm
-  branching in every verifier; and the signature is detached over a digest rather than a
-  Bitcoin script signature, which is the ES256K/WebCrypto case, and both use `r ‖ s`.
-
-  **Low-S is required and must be rejected, not normalised.** `s` and `n − s` both verify
-  and hash differently, so without the rule two valid certificates exist for one signing
-  act. Normalising on receipt would change the signature bytes, which are inside
-  `proofHash`. This library already emits low-S and has `Signature.toCanonical()`.
+  The library now reads both formats and writes the reference one given
+  `format: 'reference'`. Per STABILITY.md the default stays the old format through 9.x,
+  with a one-time notice, and becomes 'reference' in 10.0.0. The proposed amendment
+  (`docs/BRC220_ENCODING_AMENDMENT.md`) was withdrawn before filing.
 
 ### The reference implementation
 
@@ -220,10 +219,16 @@ Decided, and proposed back to the spec:
 `txidFromRawTx` against the Bitcoin genesis coinbase, and the Merkle fold against the real
 block-170 two-transaction proof.
 
-Those vectors are worth more than anything in §6, and should be wired in as gates before
-Phase 2 goes far. This module's characteristic failure is being self-consistent and wrong
-— every local test green, no other implementation agreeing — and a golden vector from a
-second implementation is the only thing that actually rules it out. Our own tests cannot.
+Those vectors are worth more than anything in §6. This module's characteristic failure is
+being self-consistent and wrong — every local test green, no other implementation agreeing
+— and a golden vector from a second implementation is the only thing that actually rules
+it out. Our own tests cannot.
+
+That is exactly how it went. Until the reference was checked, every test here passed and
+this library could not verify one certificate the reference had issued: the cryptography
+agreed and the JSON did not. `test/notaryhash/reference_certs.js` now verifies certificates
+the reference produced — full and hybrid, hex and base64, DER, high-S, an uncompressed key,
+and a five-leaf batch — and rebuilds each one byte for byte.
 
 ## 8. Not in scope
 

package/docs/MODULE_REFERENCE_COMPLETE.md

@@ -55,19 +55,19 @@ Three advanced modules totaling **~2.7MB** of functionality:
 - **Purpose**: Threshold cryptography for secure secret distribution
 - **Use Cases**: Backup keys, multi-party security, key recovery
 - **Features**: Split secrets into N shares, require M to reconstruct
-- **CDN**: `unpkg.com/@smartledger/bsv@9.7.0/bsv-shamir.min.js`
+- **CDN**: `unpkg.com/@smartledger/bsv@9.9.0/bsv-shamir.min.js`
 
 #### **🌐 Global Digital Attestation Framework - GDAF (1184KB)**  
 - **Purpose**: W3C Verifiable Credentials and decentralized identity
 - **Use Cases**: Identity verification, attestations, zero-knowledge proofs
 - **Features**: DID creation, credential issuance, selective disclosure
-- **CDN**: `unpkg.com/@smartledger/bsv@9.7.0/bsv-gdaf.min.js`
+- **CDN**: `unpkg.com/@smartledger/bsv@9.9.0/bsv-gdaf.min.js`
 
 #### **⚖️ Legal Token Protocol - LTP (1184KB)**
 - **Purpose**: Legal compliance framework for tokenized assets
 - **Use Cases**: Property rights, obligations, compliant tokenization  
 - **Features**: Legal primitives, compliance checking, attestation anchoring
-- **CDN**: `unpkg.com/@smartledger/bsv@9.7.0/bsv-ltp.min.js`
+- **CDN**: `unpkg.com/@smartledger/bsv@9.9.0/bsv-ltp.min.js`
 
 ### **2. Incorrect File Sizes in Documentation**
 
@@ -81,18 +81,18 @@ Three advanced modules totaling **~2.7MB** of functionality:
 
 | Module | Size | Use Case | CDN Link |
 |--------|------|----------|----------|
-| **bsv.min.js** | 937KB | Core BSV + SmartContract | `unpkg.com/@smartledger/bsv@9.7.0/bsv.min.js` |
-| **bsv.bundle.js** | 937KB | Everything in one file | `unpkg.com/@smartledger/bsv@9.7.0/bsv.bundle.js` |
-| **bsv-smartcontract.min.js** | 937KB | Covenant development | `unpkg.com/@smartledger/bsv@9.7.0/bsv-smartcontract.min.js` |
-| **bsv-covenant.min.js** | 913KB | Covenant operations | `unpkg.com/@smartledger/bsv@9.7.0/bsv-covenant.min.js` |
-| **bsv-script-helper.min.js** | 26KB | Custom script tools | `unpkg.com/@smartledger/bsv@9.7.0/bsv-script-helper.min.js` |
-| **bsv-security.min.js** | 26KB | Security enhancements (opt-in helpers — see README › Security) | `unpkg.com/@smartledger/bsv@9.7.0/bsv-security.min.js` |
-| **bsv-ecies.min.js** | 71KB | Encryption | `unpkg.com/@smartledger/bsv@9.7.0/bsv-ecies.min.js` |
-| **bsv-message.min.js** | 26KB | Message signing | `unpkg.com/@smartledger/bsv@9.7.0/bsv-message.min.js` |
-| **bsv-mnemonic.min.js** | 681KB | HD wallets | `unpkg.com/@smartledger/bsv@9.7.0/bsv-mnemonic.min.js` |
-| **🆕 bsv-shamir.min.js** | 432KB | **Secret sharing** | `unpkg.com/@smartledger/bsv@9.7.0/bsv-shamir.min.js` |
-| **🆕 bsv-gdaf.min.js** | 1184KB | **Digital attestation** | `unpkg.com/@smartledger/bsv@9.7.0/bsv-gdaf.min.js` |
-| **🆕 bsv-ltp.min.js** | 1184KB | **Legal tokens** | `unpkg.com/@smartledger/bsv@9.7.0/bsv-ltp.min.js` |
+| **bsv.min.js** | 937KB | Core BSV + SmartContract | `unpkg.com/@smartledger/bsv@9.9.0/bsv.min.js` |
+| **bsv.bundle.js** | 937KB | Everything in one file | `unpkg.com/@smartledger/bsv@9.9.0/bsv.bundle.js` |
+| **bsv-smartcontract.min.js** | 937KB | Covenant development | `unpkg.com/@smartledger/bsv@9.9.0/bsv-smartcontract.min.js` |
+| **bsv-covenant.min.js** | 913KB | Covenant operations | `unpkg.com/@smartledger/bsv@9.9.0/bsv-covenant.min.js` |
+| **bsv-script-helper.min.js** | 26KB | Custom script tools | `unpkg.com/@smartledger/bsv@9.9.0/bsv-script-helper.min.js` |
+| **bsv-security.min.js** | 26KB | Security enhancements (opt-in helpers — see README › Security) | `unpkg.com/@smartledger/bsv@9.9.0/bsv-security.min.js` |
+| **bsv-ecies.min.js** | 71KB | Encryption | `unpkg.com/@smartledger/bsv@9.9.0/bsv-ecies.min.js` |
+| **bsv-message.min.js** | 26KB | Message signing | `unpkg.com/@smartledger/bsv@9.9.0/bsv-message.min.js` |
+| **bsv-mnemonic.min.js** | 681KB | HD wallets | `unpkg.com/@smartledger/bsv@9.9.0/bsv-mnemonic.min.js` |
+| **🆕 bsv-shamir.min.js** | 432KB | **Secret sharing** | `unpkg.com/@smartledger/bsv@9.9.0/bsv-shamir.min.js` |
+| **🆕 bsv-gdaf.min.js** | 1184KB | **Digital attestation** | `unpkg.com/@smartledger/bsv@9.9.0/bsv-gdaf.min.js` |
+| **🆕 bsv-ltp.min.js** | 1184KB | **Legal tokens** | `unpkg.com/@smartledger/bsv@9.9.0/bsv-ltp.min.js` |
 
 ## 🎯 **Updated Usage Examples**
 
@@ -100,22 +100,22 @@ Three advanced modules totaling **~2.7MB** of functionality:
 
 #### **1. Basic Development (~963KB)**
 ```html
-<script src="https://unpkg.com/@smartledger/bsv@9.7.0/bsv.min.js"></script>
-<script src="https://unpkg.com/@smartledger/bsv@9.7.0/bsv-script-helper.min.js"></script>
+<script src="https://unpkg.com/@smartledger/bsv@9.9.0/bsv.min.js"></script>
+<script src="https://unpkg.com/@smartledger/bsv@9.9.0/bsv-script-helper.min.js"></script>
 ```
 
 #### **2. Smart Contract Development (~2.7MB — each bundle re-embeds core BSV)**
 ```html
-<script src="https://unpkg.com/@smartledger/bsv@9.7.0/bsv.min.js"></script>
-<script src="https://unpkg.com/@smartledger/bsv@9.7.0/bsv-covenant.min.js"></script>
-<script src="https://unpkg.com/@smartledger/bsv@9.7.0/bsv-smartcontract.min.js"></script>
+<script src="https://unpkg.com/@smartledger/bsv@9.9.0/bsv.min.js"></script>
+<script src="https://unpkg.com/@smartledger/bsv@9.9.0/bsv-covenant.min.js"></script>
+<script src="https://unpkg.com/@smartledger/bsv@9.9.0/bsv-smartcontract.min.js"></script>
 ```
 
 #### **3. 🆕 Legal & Compliance Development (~3.2MB — each bundle re-embeds core BSV)**
 ```html
-<script src="https://unpkg.com/@smartledger/bsv@9.7.0/bsv.min.js"></script>
-<script src="https://unpkg.com/@smartledger/bsv@9.7.0/bsv-ltp.min.js"></script>
-<script src="https://unpkg.com/@smartledger/bsv@9.7.0/bsv-gdaf.min.js"></script>
+<script src="https://unpkg.com/@smartledger/bsv@9.9.0/bsv.min.js"></script>
+<script src="https://unpkg.com/@smartledger/bsv@9.9.0/bsv-ltp.min.js"></script>
+<script src="https://unpkg.com/@smartledger/bsv@9.9.0/bsv-gdaf.min.js"></script>
 <script>
   // Legal Token Protocol
   const legalToken = bsv.createLegalToken({
@@ -132,9 +132,9 @@ Three advanced modules totaling **~2.7MB** of functionality:
 
 #### **4. 🆕 Security & Cryptography (~1.4MB)**
 ```html
-<script src="https://unpkg.com/@smartledger/bsv@9.7.0/bsv.min.js"></script>
-<script src="https://unpkg.com/@smartledger/bsv@9.7.0/bsv-security.min.js"></script>
-<script src="https://unpkg.com/@smartledger/bsv@9.7.0/bsv-shamir.min.js"></script>
+<script src="https://unpkg.com/@smartledger/bsv@9.9.0/bsv.min.js"></script>
+<script src="https://unpkg.com/@smartledger/bsv@9.9.0/bsv-security.min.js"></script>
+<script src="https://unpkg.com/@smartledger/bsv@9.9.0/bsv-shamir.min.js"></script>
 <script>
   // Shamir Secret Sharing
   const shares = bsv.splitSecret('my_secret_key', 5, 3); // 5 shares, 3 needed
@@ -146,7 +146,7 @@ Three advanced modules totaling **~2.7MB** of functionality:
 
 #### **5. Everything Bundle (937KB)**
 ```html
-<script src="https://unpkg.com/@smartledger/bsv@9.7.0/bsv.bundle.js"></script>
+<script src="https://unpkg.com/@smartledger/bsv@9.9.0/bsv.bundle.js"></script>
 <script>
   // Everything available immediately
   const shares = bsv.splitSecret('secret', 5, 3);

package/docs/advanced/UTXO_MANAGER_GUIDE.md

@@ -722,7 +722,7 @@ interface UTXO {
 <html>
 <head>
     <title>UTXO Manager Demo</title>
-    <script src="https://cdn.jsdelivr.net/npm/@smartledger/bsv@9.7.0/bsv.min.js"></script>
+    <script src="https://cdn.jsdelivr.net/npm/@smartledger/bsv@9.9.0/bsv.min.js"></script>
 </head>
 <body>
     <script>

package/docs/audit-rfq/cure53.txt

@@ -15,9 +15,11 @@ seeking a quote for an independent security review of its cryptographic core.
 
 Scope, and we would like these priced separately:
 
-  Tier 1 — 12,391 lines, 33 files. Script interpreter, sighash and signing,
-  ECDSA and signature encoding, BIP-32 derivation, key and address
-  construction.
+  Tier 1 — 11,962 lines. Sighash construction and signing; ECDSA, nonce
+  derivation and signature encoding; the consensus-flag and era surface of the
+  script interpreter; BRC-220 signing; the covenant verification harness; RFC
+  8785 canonicalization; and the covenant-facing entrypoints of the smart
+  contract module.
 
   Tier 2 — 1,607 lines. BIP-39 mnemonics, ECIES, and the Base58Check/varint
   decoding surface.
@@ -25,18 +27,30 @@ Scope, and we would like these priced separately:
 JavaScript (CommonJS), Node >= 20.19. The code is public.
 
 Explicitly out of scope: elliptic-curve and hash primitives, which are supplied
-by the Noble libraries and already audited; and our 24,769-line application
-layer (credentials, tokens, ordinals), which we would treat as a separate
-engagement.
+by the Noble libraries and already audited; opcode EXECUTION in the script
+interpreter, which passes 1,483 of 1,483 of the reference node's own consensus
+vectors with zero false accepts and zero false rejects; and the remaining
+26,077-line application layer (credentials, tokens, ordinals), which we would
+treat as a separate engagement.
+
+Note the shape of that first exclusion, because it is what we want priced. The
+node's vectors each state their own flags, so they say nothing about which flags
+or which consensus era a caller ends up with by DEFAULT. Every consensus defect
+we have found has been in that selection rather than in the execution — the
+corpus passed 1,483/1,483 before each fix and after it.
 
 Context that should shorten discovery: the core is inherited from bitcore and
 has been fixed reactively but never independently reviewed. We can provide a
 test-backed threat model, a 452-case behavioural conformance corpus that a
 second independent implementation agrees with, and a documented history of the
-defects we have found ourselves.
-
-The failure mode we most want examined is code that reports a check as passed
-without performing it — several of our own findings have had that shape.
+ten defects we have found and fixed ourselves, with the module each was in.
+
+The failure mode we most want examined is an exported security claim, its
+default, and the test asserting it being wrong together, because all three were
+written from the same assumption. Every one of our ten findings has had that
+shape, and a file-by-file review would have found none of them. We would like
+the statement of work to require checking claims against an independent oracle
+or specification rather than against this repository's own tests.
 
 Could you indicate availability, an approximate cost range, and what you would
 need from us to firm that up?