@smartledger/bsv 9.2.0 → 9.3.0

package/covenant-entry.d.ts

@@ -0,0 +1,17 @@
+/**
+ * Covenant construction.
+ *
+ * The default export is `SmartContract.Covenant`; `reconstructP2pkhScript` is
+ * exported alongside it at runtime.
+ */
+import { SmartContract, Script, PublicKey } from '@smartledger/bsv';
+
+declare const covenant: typeof SmartContract.Covenant & {
+  /**
+   * Rebuild the P2PKH locking script a covenant spends from, for preimage
+   * construction.
+   */
+  reconstructP2pkhScript(publicKey: PublicKey | Buffer | string): Script;
+};
+
+export = covenant;

package/didweb-entry.d.ts

@@ -0,0 +1,7 @@
+/**
+ * did:web issuer keys and DID documents.
+ *
+ * Same surface as `require("@smartledger/bsv").DIDWeb`.
+ */
+import { DIDWeb } from '@smartledger/bsv';
+export = DIDWeb;

package/docs/AUDIT_SCOPE.md

@@ -29,14 +29,14 @@ testing.
 Two tiers, to be **priced separately** so the boundary can be drawn against a number
 rather than before seeing one.
 
-### Tier 1 — core, 12,268 lines across 33 files
+### Tier 1 — core, 12,391 lines across 33 files
 
 | Module | Lines | Why it matters |
 | --- | ---: | --- |
-| `lib/script/` | 3,751 | Consensus script interpreter. Divergence from the node means accepting a transaction the network rejects, or the reverse. |
+| `lib/script/` | 3,859 | Consensus script interpreter. Divergence from the node means accepting a transaction the network rejects, or the reverse. |
 | `lib/transaction/` | 2,779 | Sighash construction and signing — both BIP-143 and the Original Transaction Digest Algorithm. |
 | `lib/crypto/` | 2,519 | ECDSA, nonce derivation, signature encoding, the script-number type. |
-| `lib/hdprivatekey.js`, `lib/hdpublickey.js` | 1,168 | BIP-32 derivation, including hardened paths. |
+| `lib/hdprivatekey.js`, `lib/hdpublickey.js` | 1,183 | BIP-32 derivation, including hardened paths. |
 | `lib/privatekey.js`, `lib/publickey.js` | 843 | Key construction, serialisation, WIF. Recent defects here produced a *different* key without error. |
 | `lib/address.js` | 543 | Address derivation and network binding. |
 | `lib/networks.js`, `lib/opcode.js` | 665 | Network parameters and the opcode table, which BSV upgrades have reassigned. |
@@ -58,19 +58,25 @@ is not.
 | Component | Status | Reason |
 | --- | --- | --- |
 | `@noble/curves`, `@noble/hashes`, `@noble/ciphers` | Already audited | The primitives come from the Noble libraries, which **Cure53 has audited and published on**. We do not implement curve or hash arithmetic ourselves. State this explicitly to vendors — otherwise they price work we do not need. |
-| `lib/smart_contract/`, `lib/ltp/`, `lib/gdaf/`, `lib/ordinals/`, `lib/block/`, plus 9 further directories and 6 top-level files | Excluded | Application layer, 24,447 lines — 18,600 in the five named modules and 5,847 in the remainder. Written in-house and covered by adversarial tests. Worth a separate engagement; including it here would blur the question in §1. |
+| `lib/smart_contract/`, `lib/ltp/`, `lib/gdaf/`, `lib/ordinals/`, `lib/block/`, plus 9 further directories and 6 top-level files | Excluded | Application layer, 24,769 lines — 18,706 in the five named modules and 6,063 in the remainder. Written in-house and covered by adversarial tests. Worth a separate engagement; including it here would blur the question in §1. |
 
-Totals reconcile against `lib/`, which is 38,322 lines across 130 files:
+Totals reconcile against `lib/`, which is 38,767 lines across 131 files:
 
 ```
-tier 1      12,268
+tier 1      12,391
 tier 2       1,607
-excluded    24,447
+excluded    24,769
             ------
-total       38,322
+total       38,767
 ```
 
-Core + optional = 13,875.
+Measured 2026-08-28 at `aa551a1`. These figures drift as the library changes — the
+previous set was taken on 2026-08-16 and was 445 lines light by the time it was
+read, most of it in `lib/script/interpreter.js`, which is tier 1 and therefore the
+number a vendor prices against. **Re-run §7 immediately before sending**, and update
+the date above with the commit measured.
+
+Core + optional = 13,998.
 
 ## 4. What an auditor gets on day one
 
@@ -133,7 +139,7 @@ seeking a quote for an independent security review of its cryptographic core.
 
 Scope, and we would like these priced separately:
 
-  Tier 1 — 12,268 lines, 33 files. Script interpreter, sighash and signing,
+  Tier 1 — 12,391 lines, 33 files. Script interpreter, sighash and signing,
   ECDSA and signature encoding, BIP-32 derivation, key and address
   construction.
 
@@ -143,7 +149,7 @@ 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,447-line application
+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.
 

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.2.0/bsv-shamir.min.js`
+- **CDN**: `unpkg.com/@smartledger/bsv@9.3.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.2.0/bsv-gdaf.min.js`
+- **CDN**: `unpkg.com/@smartledger/bsv@9.3.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.2.0/bsv-ltp.min.js`
+- **CDN**: `unpkg.com/@smartledger/bsv@9.3.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.2.0/bsv.min.js` |
-| **bsv.bundle.js** | 937KB | Everything in one file | `unpkg.com/@smartledger/bsv@9.2.0/bsv.bundle.js` |
-| **bsv-smartcontract.min.js** | 937KB | Covenant development | `unpkg.com/@smartledger/bsv@9.2.0/bsv-smartcontract.min.js` |
-| **bsv-covenant.min.js** | 913KB | Covenant operations | `unpkg.com/@smartledger/bsv@9.2.0/bsv-covenant.min.js` |
-| **bsv-script-helper.min.js** | 26KB | Custom script tools | `unpkg.com/@smartledger/bsv@9.2.0/bsv-script-helper.min.js` |
-| **bsv-security.min.js** | 26KB | Security enhancements (opt-in helpers — see README › Security) | `unpkg.com/@smartledger/bsv@9.2.0/bsv-security.min.js` |
-| **bsv-ecies.min.js** | 71KB | Encryption | `unpkg.com/@smartledger/bsv@9.2.0/bsv-ecies.min.js` |
-| **bsv-message.min.js** | 26KB | Message signing | `unpkg.com/@smartledger/bsv@9.2.0/bsv-message.min.js` |
-| **bsv-mnemonic.min.js** | 681KB | HD wallets | `unpkg.com/@smartledger/bsv@9.2.0/bsv-mnemonic.min.js` |
-| **🆕 bsv-shamir.min.js** | 432KB | **Secret sharing** | `unpkg.com/@smartledger/bsv@9.2.0/bsv-shamir.min.js` |
-| **🆕 bsv-gdaf.min.js** | 1184KB | **Digital attestation** | `unpkg.com/@smartledger/bsv@9.2.0/bsv-gdaf.min.js` |
-| **🆕 bsv-ltp.min.js** | 1184KB | **Legal tokens** | `unpkg.com/@smartledger/bsv@9.2.0/bsv-ltp.min.js` |
+| **bsv.min.js** | 937KB | Core BSV + SmartContract | `unpkg.com/@smartledger/bsv@9.3.0/bsv.min.js` |
+| **bsv.bundle.js** | 937KB | Everything in one file | `unpkg.com/@smartledger/bsv@9.3.0/bsv.bundle.js` |
+| **bsv-smartcontract.min.js** | 937KB | Covenant development | `unpkg.com/@smartledger/bsv@9.3.0/bsv-smartcontract.min.js` |
+| **bsv-covenant.min.js** | 913KB | Covenant operations | `unpkg.com/@smartledger/bsv@9.3.0/bsv-covenant.min.js` |
+| **bsv-script-helper.min.js** | 26KB | Custom script tools | `unpkg.com/@smartledger/bsv@9.3.0/bsv-script-helper.min.js` |
+| **bsv-security.min.js** | 26KB | Security enhancements (opt-in helpers — see README › Security) | `unpkg.com/@smartledger/bsv@9.3.0/bsv-security.min.js` |
+| **bsv-ecies.min.js** | 71KB | Encryption | `unpkg.com/@smartledger/bsv@9.3.0/bsv-ecies.min.js` |
+| **bsv-message.min.js** | 26KB | Message signing | `unpkg.com/@smartledger/bsv@9.3.0/bsv-message.min.js` |
+| **bsv-mnemonic.min.js** | 681KB | HD wallets | `unpkg.com/@smartledger/bsv@9.3.0/bsv-mnemonic.min.js` |
+| **🆕 bsv-shamir.min.js** | 432KB | **Secret sharing** | `unpkg.com/@smartledger/bsv@9.3.0/bsv-shamir.min.js` |
+| **🆕 bsv-gdaf.min.js** | 1184KB | **Digital attestation** | `unpkg.com/@smartledger/bsv@9.3.0/bsv-gdaf.min.js` |
+| **🆕 bsv-ltp.min.js** | 1184KB | **Legal tokens** | `unpkg.com/@smartledger/bsv@9.3.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.2.0/bsv.min.js"></script>
-<script src="https://unpkg.com/@smartledger/bsv@9.2.0/bsv-script-helper.min.js"></script>
+<script src="https://unpkg.com/@smartledger/bsv@9.3.0/bsv.min.js"></script>
+<script src="https://unpkg.com/@smartledger/bsv@9.3.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.2.0/bsv.min.js"></script>
-<script src="https://unpkg.com/@smartledger/bsv@9.2.0/bsv-covenant.min.js"></script>
-<script src="https://unpkg.com/@smartledger/bsv@9.2.0/bsv-smartcontract.min.js"></script>
+<script src="https://unpkg.com/@smartledger/bsv@9.3.0/bsv.min.js"></script>
+<script src="https://unpkg.com/@smartledger/bsv@9.3.0/bsv-covenant.min.js"></script>
+<script src="https://unpkg.com/@smartledger/bsv@9.3.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.2.0/bsv.min.js"></script>
-<script src="https://unpkg.com/@smartledger/bsv@9.2.0/bsv-ltp.min.js"></script>
-<script src="https://unpkg.com/@smartledger/bsv@9.2.0/bsv-gdaf.min.js"></script>
+<script src="https://unpkg.com/@smartledger/bsv@9.3.0/bsv.min.js"></script>
+<script src="https://unpkg.com/@smartledger/bsv@9.3.0/bsv-ltp.min.js"></script>
+<script src="https://unpkg.com/@smartledger/bsv@9.3.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.2.0/bsv.min.js"></script>
-<script src="https://unpkg.com/@smartledger/bsv@9.2.0/bsv-security.min.js"></script>
-<script src="https://unpkg.com/@smartledger/bsv@9.2.0/bsv-shamir.min.js"></script>
+<script src="https://unpkg.com/@smartledger/bsv@9.3.0/bsv.min.js"></script>
+<script src="https://unpkg.com/@smartledger/bsv@9.3.0/bsv-security.min.js"></script>
+<script src="https://unpkg.com/@smartledger/bsv@9.3.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.2.0/bsv.bundle.js"></script>
+<script src="https://unpkg.com/@smartledger/bsv@9.3.0/bsv.bundle.js"></script>
 <script>
   // Everything available immediately
   const shares = bsv.splitSecret('secret', 5, 3);

package/docs/ORDINALS_ENVELOPE_FIELDS.md

@@ -0,0 +1,159 @@
+# Envelope fields in `buildInscription` — handoff
+
+**Commit:** `0242542` `feat(ordinals): write envelope fields, and refuse the ones that unbind`
+**Touched:** `lib/ordinals/inscription.js`, `test/ordinals/inscription.js` — nothing else.
+**Suite:** 4768 passing, 0 failing.
+**Date:** 29 August 2026
+
+This landed in your repo from the OrdinalSource side. It is finished and tested,
+but it is **not releasable as-is** — see *What I did not touch*, which is the
+part that needs you.
+
+---
+
+## What it does
+
+`buildInscription` wrote the content type and the body and stopped. Tag 5 —
+`metadata`, the spec's own home for an object's own record — could not be
+written at all, and neither could any other field.
+
+That mattered beyond convenience. The only way to produce one was to assemble
+envelope bytes by hand, which is the most dangerous thing an integrator can do
+on this stack: the bytes are permanent, already paid for, and nothing local
+reports a mistake, because a builder agreeing with its own parser proves only
+that they agree.
+
+```js
+bsv.Ordinals.buildInscription({
+  address: owner,
+  contentType: 'image/jpeg',
+  content: image,
+  fields: { 5: manifest, 21: thumbnail }
+})
+```
+
+Fields are emitted between the content type and the body, in **ascending tag
+order** so the same input always produces the same bytes. Order carries no
+meaning to a parser before the body opens; reproducibility does.
+
+## What it refuses, and why each one is silent otherwise
+
+| Refused | Why it cannot be a warning |
+| --- | --- |
+| **Tag 0** | Opens the body. Everything after it *is* the body, so a field there does not fail — it silently becomes part of the file, and the inscription still looks fine. |
+| **Tag 1** | Is the content type. A second one declares it twice. |
+| **Unrecognized even tag** | The spec requires such an inscription to be "displayed as unbound, that is, without a location". It is indexed nowhere, permanently, and nothing local reports it. |
+| Negative / non-integer tag | Not expressible as a script number. |
+| Empty field value | Inscribes a zero-length field permanently for no reason. |
+
+Build time is the last moment any of these is catchable before the money is
+spent, which is why they throw rather than warn.
+
+## The design decision most worth your review
+
+`allowUnknownEvenFields` exists, and I went back and forth on it.
+
+My first instinct was a hard wall — never emit an unrecognized even tag, no
+exceptions. I changed my mind. The set of named tags grows as the protocol does,
+so a library that can *never* be overridden eventually becomes both wrong and
+unbypassable, and the workaround it forces — hand-assembled envelope bytes — is
+considerably more dangerous than the thing the check prevents.
+
+So it throws by default and can be overridden by a flag long enough that nobody
+passes it by accident. If you disagree, this is the knob to turn; the reasoning
+is in the JSDoc on `assertTagIsSafe` so it can be argued with rather than
+guessed at.
+
+## Byte-level details, since they are easy to get wrong
+
+- Tags **1–16** are emitted as their opcodes; anything larger as a **minimal
+  data push**. `OP_16` is the largest numeric opcode, so tag 21 has no opcode
+  form at all.
+- An indexer reads the resulting **stack element**, so `OP_5` and a one-byte
+  push of `0x05` are the same tag. The distinction still matters, because a data
+  push of a small number is non-minimal and non-minimal pushes are non-standard.
+- Script numbers carry sign in the high bit of the last byte, so a tag ending
+  `>= 0x80` is zero-padded or it reads back **negative**.
+
+## What was verified
+
+Round-tripped through `@smartledger/ordinals` — a **separate** implementation,
+not this library's own parser:
+
+```
+fields written : { 5: manifest, 21: thumbnail }
+keys read back : ["01", "05", "15", ""]     content-type, 5, 21, body
+values         : intact
+warnings       : []          errors: []          valid: true
+```
+
+All five refusals fire with their own messages, and the override builds while
+the independent parser correctly warns about the result.
+
+---
+
+## What I did not touch — this is the part that needs you
+
+**`CHANGELOG.md`, `version.js` and `package.json` all have uncommitted changes
+in the working tree** — the TypeScript-declarations work, `types-test/`,
+`scripts/check-types.js` and the `9.3.0` bump. Staging any of those to write a
+changelog entry would have swept up half-finished work that is not mine.
+
+So the feature is committed with **no changelog entry and no version**, which is
+deliberate and needs closing out. Two options:
+
+1. **Fold into 9.3.0.** It is already a minor bump and is not published yet
+   (npm `latest` is 9.2.0). Cleanest, if the declarations work ships with it.
+2. **Hold for 9.4.0**, if you would rather 9.3.0 stay exactly what you scoped.
+
+Ready to paste under whichever heading you choose:
+
+```markdown
+### Added — `buildInscription` can write envelope fields
+
+`fields` takes tag numbers to values and emits them between the content type and
+the body, in ascending tag order so identical input always produces identical
+bytes. Tag 5 is `metadata`, the spec's own home for an object's own record; it
+previously could not be written at all, so the only way to produce one was to
+assemble envelope bytes by hand.
+
+Three tags are refused at build time because each is silent afterwards. Tag 0
+opens the body, so a field there does not fail — it becomes part of the file.
+Tag 1 is the content type, and a second one declares it twice. An unrecognized
+EVEN tag costs the inscription its location everywhere: the spec requires such
+an inscription to be treated as unbound. Odd tags are ignored by an indexer that
+does not know them, which is why the spec says it is okay to be odd.
+
+`allowUnknownEvenFields` overrides the last of those. It exists because the
+named tag set grows with the protocol, and a library that could never be
+overridden would eventually be wrong AND unbypassable — sending people back to
+hand-assembled bytes, which is worse than what the check prevents.
+
+Tags 1..16 are emitted as opcodes and anything larger as a minimal data push,
+since OP_16 is the largest numeric opcode. Script numbers carry sign in the high
+bit of the last byte, so a tag ending >= 0x80 is zero-padded rather than read
+back negative.
+```
+
+## Related, already shipped
+
+`@smartledger/ordinals@0.1.6` went to npm the same day, fixing a matching blind
+spot on the reading side: its parity check opened with `if (key.length !== 2)
+return null`, so it only ever inspected single-byte tags. Tag 10 warned; tag
+258 — `0x02 0x01`, even and unrecognized — did not, while a conformant indexer
+still unbound the inscription.
+
+Worth knowing here because the two are the same rule from opposite ends: this
+library now refuses to *write* the hazard, and that one now reports it when it
+*reads* one. Parity is settled by the least significant byte, which little-endian
+puts first, so the rule holds at any tag width.
+
+## Not investigated, flagged only
+
+`test/smart_contract/ordinal_transfer.js` and `covenants.js` could not be run
+from an installed copy of the package — they need dev dependencies that are not
+in the published tarball. That is fine for you here in the repo, but it means a
+consumer cannot independently confirm that covenants verify under mainnet flags.
+Given 9.0.0 disclosed that they previously verified under *pre-Genesis* flags
+while the network would have behaved differently, that is a claim worth having
+independently checkable.

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.2.0/bsv.min.js"></script>
+    <script src="https://cdn.jsdelivr.net/npm/@smartledger/bsv@9.3.0/bsv.min.js"></script>
 </head>
 <body>
     <script>

package/docs/audit-rfq/README.md

@@ -0,0 +1,41 @@
+# Audit RFQ — ready to send
+
+Three per-vendor copies of the enquiry in [`../AUDIT_SCOPE.md`](../AUDIT_SCOPE.md) §6.
+
+| File | Vendor | Route |
+| --- | --- | --- |
+| `cure53.txt` | Cure53 | `mail@cure53.de` |
+| `ncc-group.txt` | NCC Group — Cryptography Services | enquiry form |
+| `trail-of-bits.txt` | Trail of Bits | contact form |
+
+**Verify each route on the vendor's own site before sending.** They are recorded here
+as the commonly published ones, not as confirmed current addresses.
+
+## What differs between them
+
+Only the greeting. The scope section — everything from *"We maintain
+@smartledger/bsv"* to the sign-off — is byte-identical in all three, checked by hash:
+
+```
+cure53          78cfa6aba956d1ed
+ncc-group       78cfa6aba956d1ed
+trail-of-bits   78cfa6aba956d1ed
+```
+
+That is the point of `AUDIT_SCOPE.md`: every vendor prices the same thing, so the
+spread in how they scope it back is informative. The one-sentence opener is drawn
+from the vendor rationale in §5 and changes nothing priced — delete it if you would
+rather they all receive identical text.
+
+## Regenerating
+
+These are generated from `AUDIT_SCOPE.md` §6, never hand-written, so the figures
+cannot drift between the scope document and what a vendor receives. If you edit the
+enquiry text, regenerate rather than editing these files.
+
+**Before sending, re-run §7 of `AUDIT_SCOPE.md`.** The figures are measured at a
+commit and go stale: the previous set was 445 lines light after twelve days, most of
+it in `lib/script/interpreter.js`, which is tier 1 and therefore the number a vendor
+quotes against. Current figures were measured 2026-08-28 at `aa551a1`.
+
+Reply address in all three: `support@smartledger.technology`.

package/docs/audit-rfq/cure53.txt

@@ -0,0 +1,49 @@
+To:       Cure53
+Route:    mail@cure53.de  —  verify on cure53.de before sending
+Reply-to: support@smartledger.technology
+
+Subject: Audit enquiry — BSV cryptographic library core (~13k LOC JavaScript)
+
+Hello,
+
+We are approaching you first because you audited the Noble libraries our
+primitives come from, so the layer beneath this code is already familiar to
+you.
+
+We maintain @smartledger/bsv, a Bitcoin SV library published on npm. We are
+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 2 — 1,607 lines. BIP-39 mnemonics, ECIES, and the Base58Check/varint
+  decoding surface.
+
+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.
+
+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.
+
+Could you indicate availability, an approximate cost range, and what you would
+need from us to firm that up?
+
+Repository: https://github.com/codenlighten/smartledger-bsv
+Package:    https://www.npmjs.com/package/@smartledger/bsv
+
+Thank you,
+SmartLedger Technology
+support@smartledger.technology

package/docs/audit-rfq/ncc-group.txt

@@ -0,0 +1,49 @@
+To:       NCC Group — Cryptography Services
+Route:    nccgroup.com — Cryptography Services enquiry (verify route)
+Reply-to: support@smartledger.technology
+
+Subject: Audit enquiry — BSV cryptographic library core (~13k LOC JavaScript)
+
+Hello,
+
+We are approaching your Cryptography Services team specifically rather than
+a general assurance engagement, because the sighash construction and key-
+derivation portions are the parts we are least able to review ourselves.
+
+We maintain @smartledger/bsv, a Bitcoin SV library published on npm. We are
+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 2 — 1,607 lines. BIP-39 mnemonics, ECIES, and the Base58Check/varint
+  decoding surface.
+
+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.
+
+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.
+
+Could you indicate availability, an approximate cost range, and what you would
+need from us to firm that up?
+
+Repository: https://github.com/codenlighten/smartledger-bsv
+Package:    https://www.npmjs.com/package/@smartledger/bsv
+
+Thank you,
+SmartLedger Technology
+support@smartledger.technology

package/docs/audit-rfq/trail-of-bits.txt

@@ -0,0 +1,49 @@
+To:       Trail of Bits
+Route:    Contact form on trailofbits.com  —  verify current route
+Reply-to: support@smartledger.technology
+
+Subject: Audit enquiry — BSV cryptographic library core (~13k LOC JavaScript)
+
+Hello,
+
+We are approaching you for the exploit-oriented methodology in particular:
+the failure mode described below — a check reported as passed without being
+performed — is the one our own findings keep taking.
+
+We maintain @smartledger/bsv, a Bitcoin SV library published on npm. We are
+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 2 — 1,607 lines. BIP-39 mnemonics, ECIES, and the Base58Check/varint
+  decoding surface.
+
+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.
+
+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.
+
+Could you indicate availability, an approximate cost range, and what you would
+need from us to firm that up?
+
+Repository: https://github.com/codenlighten/smartledger-bsv
+Package:    https://www.npmjs.com/package/@smartledger/bsv
+
+Thank you,
+SmartLedger Technology
+support@smartledger.technology