@bsv/overlay 2.0.3 → 2.0.4

package/docs/BRC-136-BASM.md

@@ -0,0 +1,285 @@
+# BRC-136 BASM Synchronization & Admin/Janitor Removal
+
+This document explains how the BRC-136 Block-Anchored synchronization layer
+([spec](https://bsv.brc.dev/overlays/0136)) is implemented in this engine, and —
+critically — **how it interacts with admin and janitor removal of outputs from a
+topic**. The two systems are deliberately decoupled. Read the final section
+("How BASM and removal interact") before operating a node that runs the janitor
+or removes tokens via the admin API.
+
+## What BRC-136 gives you
+
+GASP ([Synchronization.md](./Synchronization.md)) replicates transaction *data*
+between peers. BRC-136 sits alongside it and answers a different question:
+
+> Do two overlays **agree about which transactions were admitted to a topic** at
+> every block height, from the topic's genesis to the chain tip?
+
+It does this with a per-topic **Topic Anchor Chain (TAC)** — a cumulative hash
+that commits to every block's admitted-transaction set. If two nodes report the
+same `TAC(topic, H)`, they provably agree on every admitted transaction for that
+topic from genesis through height `H`. A single round trip detects agreement; a
+binary search over heights localizes any divergence in `O(log H)` rounds.
+
+### Core data structures
+
+| Concept | Type | Source of truth |
+|---|---|---|
+| Admitted set at a block | `AdmittedTxRef[]` | `applied_transactions` table |
+| Block anchor | `TopicBlockAnchor` | `topic_block_anchors` table |
+| Cumulative chain hash | `tac` field on the anchor | derived |
+
+- **`basmRoot`** — Merkle root over the admitted txids at one block height, in
+  canonical block order. Empty set → 32 zero bytes; single txid → the txid
+  itself (unhashed); multiple → `SHA256d` binary tree with Bitcoin odd-leaf
+  duplication. See `computeBasmRoot` in `src/BASM.ts`.
+- **`tac`** — `SHA256d(prevTac ‖ blockHash ‖ basmRoot)`, all inputs in internal
+  byte order. See `computeTac` in `src/BASM.ts`.
+
+### Gap-free chains
+
+The TAC must advance on **every** block — including blocks with no admitted
+transactions — or peers could not distinguish "no transactions here" from "I
+haven't synced this height." The engine keeps chains contiguous:
+
+- `advanceTopicAnchorChains(toHeight)` extends each topic forward with empty
+  anchors (zero root, zero count) up to `toHeight`.
+- `rebuildTopicAnchorChain(...)` / `recomputeTopicBlockAnchor(...)` rebuild a
+  contiguous slice after an admission (including out-of-order proofs), filling
+  any missing heights with empty anchors rather than leaving a hole.
+
+A chain only *starts* at the topic's first admitted height (its genesis).
+Covered by `src/__tests/BASMChain.test.ts`.
+
+## The admitted set is a historical fact, not current UTXO state
+
+This is the key design decision, and the source of the assurance this layer
+provides.
+
+The admitted set for `(topic, height)` is read by
+`Storage.findAdmittedTransactionsForBlock`, which queries:
+
+```
+applied_transactions WHERE topic = ? AND blockHeight = ? AND proven = true AND blockIndex IS NOT NULL
+```
+
+It is **append-only for proven transactions**. A row lands here when a
+transaction is admitted to the topic and has a merkle proof
+(`buildAppliedTransactionRecord` sets `proven: true` only when proof metadata is
+present). From that point the row — and therefore the `basmRoot` and `tac` that
+commit to it — is an immutable record of "this overlay received and admitted
+this txid at this block height."
+
+It is **not** derived from current unspent outputs. Spending an output, pruning
+its history, or removing it from lookup does not change the admitted set.
+
+## The lookup set is separate, mutable, and policy-driven
+
+What an overlay *serves* in lookup responses is a different set, in different
+storage:
+
+- The engine `outputs` table, filtered to `spent: false`.
+- The lookup service's own index (e.g. the Mongo `shipRecords` / `slapRecords`
+  collections for the discovery services).
+
+This set is mutable by design. Outputs get marked spent, pruned from history,
+removed by an admin, or deleted by the janitor.
+
+## Removal paths — exactly what each one touches
+
+| Path | Code | Touches lookup set | Touches admitted set (`applied_transactions`) |
+|---|---|---|---|
+| Spend / history prune | `Engine.deleteUTXODeep` → `deleteOutput` | yes | **no** |
+| Admin remove-token | `/admin/remove-token` → `evictFromServices` → `LookupService.outputEvicted` | yes (lookup index) | **no** |
+| Janitor (dead SHIP/SLAP host) | `JanitorService.handleUnhealthyOutput` → `deleteOne` + ban | yes (lookup index) | **no** |
+| Ban enforcement | `BanAwareLookupWrapper.outputAdmittedByTopic` | blocks re-entry into lookup index on GASP re-sync | **no** |
+| Unproven eviction | `Engine.evictUnprovenTransactions` → `deleteAppliedTransaction` | yes | yes — **but only `proven: false` rows** |
+
+Notes:
+
+- **`deleteUTXODeep` never deletes the applied-transaction record.** It calls
+  `deleteOutput` only. The admission proof survives a normal spend or prune.
+- **Admin and janitor removal operate on the lookup layer only.** Admin
+  `evictFromServices` calls `LookupService.outputEvicted`; the janitor deletes
+  from its own Mongo collection and writes to the ban list. Neither calls
+  `deleteAppliedTransaction`, `deleteOutput` on proven engine state, or anything
+  that mutates `topic_block_anchors`.
+- **The ban list is a lookup-layer filter.** `BanAwareLookupWrapper` blocks
+  banned outpoints/domains at `outputAdmittedByTopic`, preventing a removed token
+  from re-entering the *lookup index* when GASP re-syncs it from a peer. It does
+  not — and must not — block the BRC-136 admitted record.
+- **`evictUnprovenTransactions` is the only path that deletes an
+  applied-transaction row**, and it filters to `proven: false`. Such rows never
+  appear in any anchor (the anchor query requires `proven: true`), so evicting
+  them cannot change any `basmRoot` or `tac`.
+
+## How BASM and removal interact
+
+This is the question operators most need answered.
+
+### You can always prove you received and processed a token
+
+Even after the janitor deletes a dead host's advertisement, or an admin removes a
+malicious output via `/admin/remove-token` (with or without a ban), the overlay
+**retains full proof that it received and admitted that token**:
+
+- the `applied_transactions` row (`proven: true`, with `blockHeight`,
+  `blockIndex`, `blockHash`, `merkleRoot`),
+- the `topic_block_anchors` row whose `basmRoot` commits to that txid, and
+- the ability to serve a compound merkle path for it via the BRC-136 endpoints.
+
+Removal is a **lookup-serving policy decision**. It changes what the node returns
+to lookup queries. It does not, and cannot, rewrite the historical admitted set
+or the TAC.
+
+### TAC agreement means agreement on *admission*, not on *lookup results*
+
+This is the most important operational caveat:
+
+> **A matching TAC proves two overlays agree on which transactions were admitted.
+> It does NOT prove they will return identical lookup results.**
+
+Bans and removals are **per-node policy and are not synchronized between peers**.
+Two honest overlays running the same topic manager can therefore:
+
+- report the **same** `TAC(topic, H)` (identical admitted sets), while
+- returning **different** lookup results — because one node banned a malicious
+  output that the other still serves.
+
+This is correct and intended. BRC-136 anchors *receipt and admission*, which is
+an objective, deterministic function of chain state and the topic manager. It
+intentionally does not anchor each node's local moderation policy.
+
+### Consequence: divergence diagnosis
+
+- **TACs match** → the two nodes admitted exactly the same transactions. Any
+  difference in lookup output is explained by local removal/ban policy, not by a
+  sync problem.
+- **TACs diverge** → the nodes genuinely disagree about admission at some height
+  (e.g. different topic-manager versions, a missed transaction, or a reorg
+  handled differently). This is a real sync issue; the binary-search localizes
+  the height.
+
+Removing a token from lookup will **not** cause TAC divergence. If you ever see
+TAC divergence after only running the janitor/admin removal, that is a bug —
+something is incorrectly deleting proven `applied_transactions` rows or mutating
+anchors.
+
+### Caveat for the GASP validation guidance
+
+[Synchronization.md](./Synchronization.md) suggests validating sync by comparing
+per-topic SQL row counts across nodes. Once the janitor or admin removal is
+active, **lookup-set counts can legitimately differ between nodes even when their
+TACs match**. To validate BRC-136 agreement, compare `TAC(topic, tip)` between
+peers — not lookup row counts.
+
+## Reorg handling
+
+A blockchain reorganization can orphan a block whose transactions were already
+admitted and anchored. Since anchors and the admitted set are keyed by
+`(topic, blockHeight, blockHash)`, an orphaned block would otherwise leave stale
+`applied_transactions` rows and an anchor whose `basmRoot`/`tac` commit to a
+block hash that is no longer canonical — permanently diverging the TAC from peers
+that observed the reorg. The engine reconciles this automatically.
+
+### Chaintracks is the reorg authority
+
+Reorg detection is **not** reinvented here. The production chain tracker is
+Arcade, which wraps go-chaintracks; its reorg SSE is the source of truth:
+
+- **`GET /v2/reorg/stream`** emits `data: <JSON>\n\n` frames (no `event:`/`id:`
+  lines; `: keepalive` comments between events). Each frame is a `ReorgEvent`:
+
+  ```jsonc
+  {
+    "orphanedHashes": ["<blockHash>", ...], // blocks removed from the active chain
+    "commonAncestor": { "height": 100, "hash": "..." },
+    "newTip":         { "height": 103, "hash": "..." },
+    "depth": 3
+  }
+  ```
+
+- The same go-chaintracks service answers the merkle-root checks
+  (`isValidRootForHeight`) the engine already trusts for all SPV verification.
+
+`packages/overlays/overlay-express/src/ReorgStream.ts` consumes this stream and
+maps each event to the engine: `orphanedHashes` → blocks to reconcile,
+`commonAncestor.height + 1` → rebuild floor, `newTip.height` → rebuild ceiling.
+Block hashes are lower-cased to match stored display-hex hashes (go-sdk
+`chainhash.Hash` marshals as reversed/display hex).
+
+> **No replay on this stream.** It carries no event ids, so a reorg that fires
+> while the SSE client is disconnected is lost. Every (re)connect therefore runs a
+> catch-up revalidation sweep (below), and the periodic block poll runs the same
+> sweep as a standing fallback for chain trackers that expose no reorg stream.
+
+### What the engine does on a reorg — `Engine.handleReorg`
+
+1. **Demote orphaned admissions.** For each orphaned block hash, every **proven**
+   `applied_transactions` row anchored to it is demoted to unproven
+   (`demoteAppliedTransactionToUnproven`): block height/hash/index/merkleRoot are
+   cleared and `proven` is set to `false`, **but `firstSeenHeight` is kept**. The
+   transaction immediately leaves the admitted set.
+2. **Rebuild affected anchor chains.** Every topic whose chain intersects the
+   reorged height range is rebuilt over the **canonical** block hashes (the rebuild
+   forces header re-resolution rather than reusing the stale stored hash). Topics
+   with no demoted transaction are rebuilt too, because the canonical block hash
+   for those heights changed and the `tac` must re-chain over it.
+
+`handleReorg` is **idempotent**: a clean window demotes nothing and reproduces an
+identical TAC, so it is safe to run on every reorg event, SSE reconnect, and poll.
+
+### Fallback / catch-up — `Engine.revalidateRecentAnchors(depth = 3)`
+
+Scans proven `applied_transactions` in `[tip - depth + 1, tip]`. Any row whose
+proof root no longer validates (`isValidRootForHeight`) or whose block hash
+diverges from the canonical header is treated as orphaned and fed into
+`handleReorg`. This is the reorg path for chain trackers without a reorg stream,
+and the catch-up step on every SSE reconnect. Default depth is 3 blocks
+(`reorgScanDepth`, configurable via `configureReorgStream`).
+
+### Interaction with admin/janitor removal
+
+Reorg recovery and lookup-layer removal are independent and do not interfere:
+
+- Removal/bans touch only the lookup layer; they never demote `applied_transactions`.
+- Reorg demotion touches only the admitted set (proven → unproven) via the chain
+  tracker; it never consults the ban list or lookup index.
+
+A demoted transaction follows the engine's existing unproven lifecycle: if it is
+re-mined, Arcade/ARC re-notifies `/arc-ingest` → `handleNewMerkleProof` re-proves
+it at its new height and the anchor includes it again; if it is never re-mined,
+`evictUnprovenTransactions` removes it after the threshold. The "we received it"
+record survives until one of those resolves.
+
+### Configuration
+
+```ts
+server.configureReorgStream('https://arcade.example/v2/reorg/stream', 3)
+```
+
+- `reorgStreamUrl` — when set, the SSE adapter reconciles reorgs in real time.
+- `reorgScanDepth` — sweep depth from tip (default `3`).
+- The block poll (`basmBlockPollIntervalMs`) runs the sweep as a fallback even
+  when no stream is configured.
+
+## Verification checklist for operators
+
+1. After removing a token, confirm its `applied_transactions` row still exists
+   (`proven: true`) and the `topic_block_anchors` row for its height is unchanged.
+2. Confirm `TAC(topic, tip)` is unchanged by the removal.
+3. Confirm the token no longer appears in lookup responses (and, if banned, does
+   not reappear after a GASP re-sync).
+
+If all three hold, removal is behaving correctly: the node no longer serves the
+token, yet can still prove it was received and admitted.
+
+### Reorg verification
+
+4. After a reorg orphans an admitted transaction's block, confirm its
+   `applied_transactions` row is demoted (`proven: false`, block fields cleared,
+   `firstSeenHeight` retained) and the affected `topic_block_anchors` rows now
+   carry the canonical block hashes with a recomputed `tac`.
+5. Confirm `TAC(topic, tip)` reconverges with peers that observed the same reorg.
+6. If the orphaned transaction is re-mined, confirm `/arc-ingest` re-proves it and
+   the anchor re-includes it; otherwise confirm it is eventually evicted as unproven.

package/docs/README.md

@@ -5,6 +5,8 @@ The documentation is split into various pages, each covering a set of related fu
 ## Main Documentation
 
 - [API](./API.md) — How to interact with the Overlay Services Engine
+- [Synchronization](./Synchronization.md) — GASP peer synchronization
+- [BRC-136 BASM](./BRC-136-BASM.md) — Block-anchored sync, and how it interacts with admin/janitor removal
 - [Concepts](./concepts/README.md) — High-level concepts
 - [Examples](./examples/README.md) — Guides, tutorials and examples of using the Engine
 - [Internal](./internal/README.md) — References for working with internal system components

package/docs/Synchronization.md

@@ -200,4 +200,13 @@ Example (adapt the table/query to your schema):
 +-------------+------+
 ```
 
-**What you’re looking for:** the topic(s) you care about (e.g. tm_plite, tm_blockbeta) should move toward the same counts/data across nodes after sync, and your lookup results for identical queries should converge as well.
+**What you’re looking for:** the topic(s) you care about (e.g. tm_plite, tm_blockbeta) should move toward the same counts/data across nodes after sync, and your lookup results for identical queries should converge as well.
+
+> **Caveat (BRC-136 / janitor / admin removal):** Row-count comparison is only a
+> valid convergence check on nodes that do **not** remove outputs locally. Once
+> the janitor or `/admin/remove-token` is active, lookup-set counts can
+> legitimately differ between peers even when they fully agree on what was
+> admitted, because bans/removals are per-node policy and are not synchronized.
+> To verify that two nodes agree on which transactions were admitted to a topic,
+> compare their per-topic Topic Anchor Chain (`TAC`) at the tip rather than
+> lookup row counts. See [BRC-136 BASM](./BRC-136-BASM.md).

package/docs/examples/README.md

@@ -4,11 +4,11 @@
 
 ---
 
-Here, you will find documentation for common example usages of the Overlay Services Engine. These examples focus on direct `@bsv/overlay` integration. For a ready-to-run HTTP overlay node, use [`@bsv/overlay-express`](https://github.com/bsv-blockchain/overlay-express) and [`overlay-express-examples`](https://github.com/bsv-blockchain/overlay-express-examples).
+Here, you will find documentation for common example usages of the Overlay Services Engine.
 
 ## Available Examples
 
-- [Getting Started](./gs-wip.md) — Introduction and low-level engine setup guide
+- [Getting Started (WIP)](./gs-wip.md) — Introduction and getting started guide
 
 ---
 

package/docs/examples/gs-wip.md

@@ -6,114 +6,106 @@
 
 ## Introduction to BSV Overlay Services Engine
 
-The BSV Overlay Services Engine is the low-level runtime for topic managers and lookup services. It validates candidate outputs, stores admitted UTXOs, tracks spends, answers lookup questions, and coordinates synchronization between overlay nodes.
-
-If you want to run an HTTP overlay node, start with [`@bsv/overlay-express`](https://github.com/bsv-blockchain/overlay-express). If you want a local or cloud application runtime, use LARS or CARS with the BRC-102 `deployment-info.json` structure. Use `@bsv/overlay` directly when you are building custom infrastructure around the engine.
+The BSV Overlay Services Engine is designed to process transactions and manage data within a blockchain-based system, specifically targeting the Bitcoin SV (BSV) blockchain. It integrates various components such as Topic Managers, Lookup Services, Storage, and Chain Tracker to provide a robust environment for managing transaction data and overlay services.
 
 ### Components of the System
 
-1. **Topic Managers** decide which transaction outputs are admitted for a topic.
-2. **Lookup Services** index admitted and spent outputs and answer domain-specific lookup questions.
-3. **Storage** persists admitted outputs, spend state, history, sync state, and interaction timestamps.
-4. **Chain Tracker** verifies SPV data for transactions unless the engine is configured for script-only validation.
-5. **Broadcaster** submits accepted transactions to the network.
-6. **Advertiser** publishes SHIP and SLAP availability records when peer discovery is enabled.
+1. **Topic Managers**: Responsible for managing the admittance of transactions related to specific topics.
+2. **Lookup Services**: Handle the lookup of UTXO (Unspent Transaction Output) data for transactions.
+3. **Storage**: Manages persistent data storage, tracking UTXOs and their states within the system.
+4. **Chain Tracker**: Verifies SPV (Simplified Payment Verification) data associated with transactions to ensure their validity.
 
 ### Setting Up the Engine
 
-Install the current packages:
+Before you can use the engine, you must initialize it with the required components:
 
-```bash
-npm i @bsv/overlay @bsv/sdk knex
-```
+```ts
+import { Engine, KnexStorage } from "@bsv/overlay";
+import { HelloTopicManager, HelloLookupService } from 'hello-services';
+import { WoChain } from "@bsv/sdk";
 
-Create the engine with your concrete implementations:
+// Initialize components
+const managers = {
+    "exampleTopic": new HelloTopicManager()
+};
 
-```ts
-import { Engine, KnexStorage } from '@bsv/overlay'
-import { WhatsOnChain, NodejsHttpClient, ARC } from '@bsv/sdk'
-import knexFactory from 'knex'
-
-import { ExampleLookupService } from './services/ExampleLookupService.js'
-import { ExampleTopicManager } from './services/ExampleTopicManager.js'
-
-const knex = knexFactory({
-  client: 'mysql2',
-  connection: process.env.KNEX_URL
-})
-
-const engine = new Engine(
-  {
-    tm_example: new ExampleTopicManager()
-  },
-  {
-    ls_example: new ExampleLookupService()
-  },
-  new KnexStorage(knex),
-  new WhatsOnChain('test', { httpClient: new NodejsHttpClient() }),
-  process.env.HOSTING_URL,
-  process.env.SHIP_TRACKERS?.split(',') ?? [],
-  process.env.SLAP_TRACKERS?.split(',') ?? [],
-  new ARC(process.env.ARC_URL ?? 'https://arc.taal.com', {
-    apiKey: process.env.ARC_API_KEY
-  }),
-  undefined,
-  {
-    tm_example: 'SHIP'
-  }
-)
-```
+const lookupServices = {
+    "exampleLookup": new HelloLookupService()
+};
 
-Use the string `'scripts only'` for the chain tracker only when the service intentionally skips SPV validation and relies only on script-level checks.
+const storage = new KnexStorage();
+const chainTracker = new WoChain();
+
+// Create the engine instance
+const engine = new Engine(managers, lookupServices, storage, chainTracker);
+```
 
 ### Submitting a Transaction
 
-Submit tagged BEEF bytes with the topics that should evaluate the transaction:
+To submit a transaction for processing by the Overlay Services:
 
 ```ts
 import { Transaction } from '@bsv/sdk'
 
-const tx = new Transaction(/* ... */)
+const tx = new Transaction(/* ... */);
 
-const steak = await engine.submit({
-  beef: tx.toBEEF(),
-  topics: ['tm_example']
-})
+const transaction = {
+    beef: tx.toBEEF(),
+    topics: ['exampleTopic']
+}
 
-console.log('Transaction processed:', steak)
+// Submit transaction
+engine.submit(transaction).then(steak => {
+    console.log("Transaction processed:", steak);
+}).catch(error => {
+    console.error("Error processing transaction:", error);
+});
 ```
 
 ### Lookup Queries
 
-Ask a lookup service a domain-specific question:
+To perform a lookup query using the engine:
 
 ```ts
-const answer = await engine.lookup({
-  service: 'ls_example',
-  query: {
-    identityKey: '03...'
-  }
-})
-
-console.log('Lookup result:', answer)
+const question = {
+    service: 'exampleLookup',
+    query: {
+        name: 'Bob'
+    }
+}
+
+// Perform a lookup
+engine.lookup(question).then(answer => {
+    console.log("Lookup result:", answer);
+}).catch(error => {
+    console.error("Error performing lookup:", error);
+});
 ```
 
-### Service Documentation
+### Managing UTXOs
 
-Overlay clients and dashboards can retrieve service documentation and metadata directly from the engine:
+The system's core functionality involves managing UTXOs:
 
-```ts
-const topicDocs = await engine.getDocumentationForTopicManger('tm_example')
-const lookupDocs = await engine.getDocumentationForLookupServiceProvider('ls_example')
+1. **Inserting a New UTXO**: Store new UTXO data when transactions are processed.
+2. **Deleting a UTXO**: Remove UTXOs that are no longer needed or have been consumed by newer transactions.
+3. **Tracking UTXO Consumption**: Monitor which transactions consume which UTXOs.
 
-const topics = await engine.listTopicManagers()
-const lookupServices = await engine.listLookupServiceProviders()
-```
+### Retrieving Documentation
 
-### Deployment Path
+To retrieve documentation for specific managers or services:
 
-For a public overlay node, wire the engine into HTTP routes using `@bsv/overlay-express` instead of hand-rolling routes. Overlay Express already exposes the standard submit, lookup, sync, health, documentation, and admin surfaces expected by the rest of the BSV overlay ecosystem.
+```ts
+// For a topic manager
+engine.getDocumentationForTopicManger("exampleTopic").then(doc => {
+    console.log("Documentation for Topic Manager:", doc);
+});
+
+// For a lookup service
+engine.getDocumentationForLookupServiceProvider("exampleLookup").then(doc => {
+    console.log("Documentation for Lookup Service:", doc);
+});
+```
 
 ### Conclusion
 
-The BSV Overlay Services Engine is the shared core for overlay validation, indexing, lookup, and synchronization. Keep direct engine usage focused on infrastructure-level integrations, and use Overlay Express, LARS, and CARS for the standard application path.
+The BSV Overlay Services Engine provides a powerful toolset for managing transactions and data on the Bitcoin SV blockchain. It's designed to handle complex data structures and ensure the integrity and security of transactions through rigorous validation and management processes. By following this tutorial, developers can effectively integrate and utilize these capabilities within their blockchain applications.

package/mod.ts

@@ -10,7 +10,31 @@ export type { TaggedBEEF, STEAK, LookupQuestion, LookupAnswer, AdmittanceInstruc
 export type { LookupFormula } from './src/LookupFormula.js'
 export type { Advertisement } from './src/Advertisement.js'
 export type { AdvertisementData, Advertiser } from './src/Advertiser.js'
+export {
+  BASM_ZERO_HASH,
+  computeBasmRoot,
+  computeTac,
+  extractMerkleProofMetadata
+} from './src/BASM.js'
+export type {
+  AdmittedListRequest,
+  AdmittedListResponse,
+  AdmittedTxRef,
+  BASMPeerSyncReport,
+  CompoundMerklePathRequest,
+  CompoundMerklePathResponse,
+  MerkleProofMetadata,
+  RawTransactionRecord,
+  RawTransactionRequest,
+  RawTransactionResponse,
+  TopicAnchorHeader,
+  TopicAnchorHeaderResolver,
+  TopicAnchorRangeRequest,
+  TopicAnchorRangeResponse,
+  TopicAnchorTip,
+  TopicBlockAnchor
+} from './src/BASM.js'
 
 // The Knex storage system
 export { KnexStorage } from './src/storage/knex/KnexStorage.js'
-export * as KnexStorageMigrations from './src/storage/knex/all-migrations.js'
+export * as KnexStorageMigrations from './src/storage/knex/all-migrations.js'

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bsv/overlay",
-  "version": "2.0.3",
+  "version": "2.0.4",
   "type": "module",
   "description": "BSV Blockchain Overlay Services Engine",
   "main": "dist/cjs/mod.js",
@@ -35,20 +35,10 @@
       "types": "./dist/types/src/storage/*.d.ts"
     }
   },
-  "scripts": {
-    "test": "npm run build && jest",
-    "test:watch": "npm run build && jest --watch",
-    "test:coverage": "npm run build && jest --coverage",
-    "lint": "ts-standard --fix src/**/*.ts",
-    "lint:ci": "ts-standard src/**/*.ts",
-    "build": "tsc -b && tsconfig-to-dual-package tsconfig.cjs.json",
-    "dev": "tsc -b -w",
-    "prepublish": "npm run build",
-    "doc": "ts2md --inputFilename=mod.ts --outputFilename=docs/API.md --filenameSubstring=API --firstHeadingLevel=1"
-  },
   "repository": {
     "type": "git",
-    "url": "git+https://github.com/bsv-blockchain/overlay-services.git"
+    "url": "git+https://github.com/bsv-blockchain/ts-stack.git",
+    "directory": "packages/overlays/overlay"
   },
   "keywords": [
     "BSV",
@@ -60,21 +50,33 @@
   "author": "BSV Association",
   "license": "SEE LICENSE IN LICENSE.txt",
   "bugs": {
-    "url": "https://github.com/bitcoin-sv/overlay-services/issues"
+    "url": "https://github.com/bsv-blockchain/ts-stack/issues"
   },
-  "homepage": "https://github.com/bitcoin-sv/overlay-services#readme",
+  "homepage": "https://github.com/bsv-blockchain/ts-stack/tree/main/packages/overlays/overlay#readme",
   "devDependencies": {
-    "@types/jest": "^29.5.12",
-    "jest": "^29.7.0",
-    "ts-jest": "^29.1.1",
+    "@types/jest": "^30.0.0",
+    "@types/node": "^25.9.3",
+    "jest": "^30.4.2",
+    "ts-jest": "^29.4.11",
     "ts-standard": "^12.0.2",
     "ts2md": "^0.2.0",
     "tsconfig-to-dual-package": "^1.2.0",
-    "typescript": "^5.2.2"
+    "typescript": "^6.0.3"
   },
   "dependencies": {
-    "@bsv/gasp": "^1.2.2",
-    "@bsv/sdk": "^2.0.14",
-    "knex": "^3.1.0"
+    "@bsv/gasp": "^1.2.3",
+    "@bsv/sdk": "^2.1.4",
+    "knex": "^3.2.10"
+  },
+  "scripts": {
+    "test": "npm run build && jest",
+    "test:watch": "npm run build && jest --watch",
+    "test:coverage": "npm run build && jest --coverage",
+    "lint": "ts-standard --fix src/**/*.ts",
+    "lint:ci": "ts-standard src/**/*.ts",
+    "build": "tsc -b && tsconfig-to-dual-package tsconfig.cjs.json",
+    "dev": "tsc -b -w",
+    "prepublish": "npm run build",
+    "doc": "ts2md --inputFilename=mod.ts --outputFilename=docs/API.md --filenameSubstring=API --firstHeadingLevel=1"
   }
-}
+}