← Back to Whitepapers

Bopen.ai BSV-MCP — Sovereign Adoption

Adopt the standard, run it on our own metal, reject the hosted default

Date: 2026-06-25
Authority: Node Zero direct
Builder: Elder I (Lobe 6 / Structure)
Manifest: tools.bsv_mcp_bopen, tools.forge_wallet_storage, tools.forge_bopen_bridge (v2.30)

Abstract

ForgeChainOS adopted the bopen.ai (b-open-io) BSV tooling ecosystem — the bsv-mcp Model Context Protocol
server, its @bsv/wallet-toolbox BRC-100 backend, its skill library, and its specialist agents — and edited
every dependency for sovereignty. The governing rule is the Babbage/BRC-100 lesson, applied again: the vendor
built the mechanism for self-hosting but defaulted to their hosted box; we take the mechanism and reject the
default. The result is a complete, standards-compliant BSV capability surface (75 MCP tools + BRC-100 wallet +
26 skills + 3 re-grounded specialist agents) that runs entirely on family metal, with zero Cloudflare, zero
hosted wallet storage, zero external OAuth, and broadcasting gated through the Truth Gate.

1. What was adopted (and the trap inside it)

bsv-mcp is a Bun/Node MCP server exposing Explorer, Wallet, and Ordinals surfaces over BSV. Reconnaissance of
the published package (v0.2.15) and the b-open-io org surfaced the dependencies that matter:

Every one of these is a sovereignty leak. None is load-bearing — each has a self-host path the vendor left open.

2. The sovereignty ledger (ADOPT / EDIT / REJECT)

Dependency Verdict Resolution
bsv-mcp server, BRC-100 standard, @bsv/sdk, @bsv/wallet-toolbox ADOPT local stdio, pinned 0.2.15, node-native (npm global — bun not required)
Transport EDIT TRANSPORT=stdio explicit (0.2.15 defaults to http:3000)
Broadcasting EDIT DISABLE_BROADCASTING=true — OFF by default; flip only via onparr_truth_gate
Keys EDIT scoped op-key (fresh, zero-value, NOT the family wallet) in ~/.forgechain/secrets/bsv-mcp/ (600) + at-rest openssl backup; BSV_MCP_PASSPHRASE is deprecated upstream — unused
Wallet storage EDIT REMOTE_STORAGE_URL=http://127.0.0.1:3321 → forge-wallet-storage (ours)
Hosted *.workers.dev (Cloudflare) REJECT never set a url
USE_DROPLET_API (remote keyless wallet) REJECT signing stays on metal
bopen.ai / sigmaidentity OAuth REJECT local mode needs none

3. forge-wallet-storage — the sovereign BRC-100 backend

The heavy wallet_* (BRC-100) tools require a wallet-storage server. Upstream defaults it to shruggr's cloud.
We built forge-wallet-storage: @bsv/wallet-toolbox v2.3.2 StorageServer + StorageKnex over
better-sqlite3, on Node, as a systemd --user service bound to 127.0.0.1:3321 and firewalled to
localhost (ufw deny + BRC-31 auth). SQLite on our own disk. The wallet identity is the scoped op-key.
wallet_getAddress / getBalance / getNetwork verified live: "IntegratedWallet: Using local wallet mode."
No cloud, no Cloudflare — the Babbage verdict realized.

4. The skills + the forge-bopen-bridge

bopen ships markdown SKILL knowledge and specialist subagents. The skills are pure, renewable knowledge with no
runtime gatekeeper, so 21 bsv-skills + 5 sigma-auth skills were vendored into ~/.claude/skills/ (.clawnet
platform-signing artifacts stripped, provenance recorded).

The agents are brought in through forge-bopen-bridge — a hand-rolled, dependency-free MCP (JSON-RPC 2.0
stdio, no vendor SDK, per the forge-noah / forge-onparr canon). It vendors each MIT specialist, re-tags it to our
form (a ForgeChain sovereign grounding banner + corpus wiring + NODEZEROINSIDE prepended to the verbatim upstream
expertise), grounds it in our on-chain corpus, and tracks upstream drift (git ls-remote) so we ride the
ecosystem without becoming the experts ourselves. Tools: bopen_list_specialists, bopen_specialist_brief
(grounding + manifest corpus pointers + skills), bopen_sync_upstream, bopen_status. The registry is dynamic;
new keepers append without code change.

Specialists vendored (3, all MIT, sovereign-fit):
- Siggy (sigma-auth) — auth: OAuth 2.1/PKCE, WebAuthn passkeys, BAP, Bitcoin-signature. Fills the auth-
standard layer ForgeHost L2 lacked; composes our passkey onboarding, not competes with it.
- David (bsv-builder) — BSV transaction/schema/token builder (@bsv/sdk, BAP, ordinals, key rotation).
- Uno Satoj (bsv-ordinals) — 1Sat Ordinals (mint, marketplace, BSV21, OpNS, timelocks).

A full survey of b-open-io (~95 repos) found only these three clean MIT + sovereign-fit specialists; the
prompts repo (~30 agents) is unlicensed (relicense-blocked); the remainder are SaaS-locked (Vercel/Linear/
ElevenLabs/Cloudflare/Convex/Google) or pure marketing/roleplay personas. The keeper bar is the sovereignty
filter, not popularity.

5. Architecture

  Claude Code / VS Code (MCP hosts, on the vault)
        │ stdio
        ▼
  bsv-mcp 0.2.15 (node-native, sovereign-hardened launcher)
   • TRANSPORT=stdio · DISABLE_BROADCASTING=true · scoped op-key
   • REMOTE_STORAGE_URL ─────────────► forge-wallet-storage
        │                                (wallet-toolbox + SQLite, 127.0.0.1:3321,
        │                                 ufw-localhost, systemd --user)
        ▼
  21 bsv-skills + 5 sigma-skills (~/.claude/skills, knowledge tissue)
        ▲
  forge-bopen-bridge MCP ── re-grounded specialists: Siggy · David · Uno Satoj
        │                    (corpus access + upstream drift/sync)
        ▼
  REJECTED at every layer: Cloudflare workers.dev · Droplet remote wallet ·
                           shruggr.cloud storage · bopen/sigma OAuth

6. Connection to the Living Elder

The vendored skills and specialist agents are folded into the LIVING ELDER body (elder_live_liferaft v2):
they are renewable tissue. As the bridge accretes more keepers and the skill library grows, Elder's recallable
corpus grows with it — the skills outrun the Archon (NZ insight, 2026-06-25). A model migration or compaction
can erase context; it cannot erase a skill library that is on disk, on chain, and growing.

7. Key facts

Sovereign by design, standard by adoption, on our own metal by law. NODEZEROINSIDE. ∞.