← Back to Whitepapers

Forge↔Bopen Bridge

Vendor bopen.ai MIT specialists, re-ground them in OUR corpus, ride the ecosystem without becoming the experts

NODEZEROINSIDE.

0. Abstract

The Forge↔Bopen Bridge (forge-bopen-bridge, manifest tools.forge_bopen_bridge) is a hand-rolled,
dependency-free MCP that brings the bopen.ai (b-open-io) specialist agents into ForgeChainOS as re-grounded
sovereign tissue. Each vendored specialist keeps its verbatim MIT expertise but answers in OUR form: a
ForgeChain sovereign grounding banner is prepended, sovereignty overrides replace every hosted default with
family metal, and the agent is wired to our on-chain corpus (MASTER-MANIFEST + skills). The bridge also tracks
upstream drift (git ls-remote) so the family rides the ecosystem's improvements without having to become BSV
protocol experts itself. Three specialists are vendored and live — Siggy (auth), David (BSV builder), Uno Satoj
(ordinals). The MCP exposes four tools and is proven by running. It is a companion to the sovereign bsv-mcp
adoption (bopenai-bsv-mcp-sovereign-adoption.md): that paper hardened the tools; this one governs the
agents.

Definition (built 2026-06-25, Elder I): The bridge is the AGENT layer of the bopen.ai adoption. It does not
run BSV operations itself — it serves re-grounded specialist BRIEFS (banner + corpus pointers + skills) and
watches upstream. The actual metal (wallet, storage, broadcast) is bsv-mcp + forge-wallet-storage, gated
through ON-PARR. The bridge is the sovereign filter, not the executor.

1. Why the bridge exists

bopen.ai publishes a strong BSV toolchain: an MCP server, a skill library, and a stable of specialist subagents
(a BSV transaction builder, an ordinals expert, an auth expert). The skills are pure, portable knowledge — those
were simply vendored into ~/.claude/skills/. The agents are the problem, because a vendor agent carries the
vendor's defaults inside its head: it reaches for 1sat.shruggr.cloud storage, bsv-mcp.*.workers.dev
(Cloudflare), sigmaidentity.com OAuth, hosted Neon Postgres. Drop one into ForgeChainOS unedited and it will
confidently route the family's work through someone else's box. That is a sovereignty leak wearing the mask of
expertise.

The naive alternatives both fail:

The bridge is the third path: adopt the expertise, re-ground the defaults, track the source. It is the
Babbage/BRC-100 lesson applied to agents instead of servers — the vendor built the mechanism; we take the
mechanism and reject the default — extended with a drift-watch so the adoption stays current.

2. The re-grounding contract (one banner, verbatim expertise underneath)

Every vendored specialist is a Claude Code agent file in ~/.claude/agents/ with a strict two-part shape:

---  (frontmatter: name, display_name, description, model)
# <Name> — ForgeChain Sovereign Grounding (read FIRST)
   NODEZEROINSIDE. Sovereignty overrides. Compose-our-stack pointers.
---  (separator)
<verbatim upstream MIT expertise, unchanged>

The grounding banner is read FIRST and overrides everything below it. Example (David / bsv-builder):

The verbatim upstream expertise (transaction patterns, @bsv/sdk idioms, skill-routing tables) is kept under
the separator, unaltered, MIT-attributed. This is the key property: the expertise is theirs, the defaults are
ours. The groundingBanner() function in the MCP extracts exactly the banner region (between the frontmatter
close and the upstream --- separator) so a specialist_brief always leads with the sovereign framing.

3. The four tools (serve the brief, watch the source)

The MCP is a dependency-free JSON-RPC 2.0 stdio loop — no vendor SDK, no node_modules, per the
forge-noah / forge-onparr canon. ~/.forgechain/mcp-servers/forge-bopen-bridge/index.mjs, ~115 lines, Node
built-ins only.

The corpusPointers() function is a light grounding: it scans the manifest for top-level entry keys whose lines
contain the specialist's domain keywords, returning up to 8 pointers. This is pointers, not deep semantic
retrieval — an honest, deterministic keyword match into the manifest, not a RAG index (see §7).

4. The registry (dynamic — new keepers just append)

~/.forgechain/bopen-bridge/specialists.json is the single source of truth, loaded fresh on every call. Each
entry carries: name, display_name, domain, agent_file, skills[], source_repo, source_path,
upstream_commit, license, vendored date, and sovereignty_overrides[]. Adding a keeper is data, not code:
vendor the agent file with its banner, append a registry row, done. The MCP re-reads on the next call — no
rebuild, no restart of logic.

Vendored specialists (3, all MIT, sovereign-fit):

Name Persona Domain Sovereignty overrides
sigma-auth Siggy Bitcoin-native auth — Sigma/Better Auth, OAuth 2.1+PKCE, WebAuthn passkeys, BAP, Bitcoin-sig auth.sigmaidentity.com→our Better Auth + sigmaProvider · Neon PG→local SQLite/self-host · iframe signer→local TokenPass (offline) · skip Stripe/Google/GitHub commercial tier
bsv-builder David BSV tx/schema/token — @bsv/sdk, BAP, ordinals, key rotation, UTXO hosted store→forge-wallet-storage · broadcast→onparr-gated · reads→Tera-Z SPV first
bsv-ordinals Uno Satoj 1Sat Ordinals — mint, marketplace, BSV21, OpNS, timelocks hosted store→forge-wallet-storage · broadcast→onparr-gated

Siggy fills the OAuth/PKCE auth-standard layer ForgeHost L2 lacked — composing our passkey onboarding, not
competing with it. David and Uno Satoj carry the transaction and ordinals expertise, both re-pointed at our
metal and ON-PARR gate.

The keeper bar is sovereignty, not popularity. A survey of the b-open-io org (~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 registry is dynamic so more keepers can be added the day one clears the sovereignty filter — the
pattern is proven with 3, the ceiling is not 3.

5. Architecture

  Claude Code / VS Code (MCP hosts, on the vault)
        │ stdio (JSON-RPC 2.0, no vendor SDK)
        ▼
  forge-bopen-bridge MCP  (index.mjs, Node built-ins only)
   • bopen_list_specialists   → registry roster
   • bopen_specialist_brief   → grounding banner + corpus pointers + skills   ┐
   • bopen_sync_upstream      → git ls-remote drift vs vendored commit        │ serves
   • bopen_status             → registry + drift summary                      ┘ the BRIEF
        │                                   │
        │ reads                             │ points into
        ▼                                   ▼
  specialists.json (dynamic)         MASTER-MANIFEST.yaml (corpus pointers)
        │
        ▼  each row → an agent file with a sovereign banner
  ~/.claude/agents/{sigma-auth, bsv-builder, bsv-ordinals}.md
        │  the brief COMPOSES, it does not execute:
        ▼
  bsv-mcp (sovereign-hardened) + forge-wallet-storage + 26 vendored skills
        │                                       (the metal — see companion paper)
        ▼
  broadcast GATED → onparr_truth_gate      REJECTED: shruggr.cloud · Cloudflare ·
                                           Droplet remote wallet · bopen/sigma OAuth

The bridge is the top layer of the bopen adoption stack. It answers "which expert, framed how"; the layers below
it (bsv-mcp + forge-wallet-storage, documented in the companion paper) do the actual signing and reading on
family metal.

6. Connection to the Living Elder

The re-grounded specialists and the skills beneath them are folded into the LIVING ELDER body
(elder_live_liferaft v2, TX d9eb06a8) as renewable tissue. As the bridge accretes keepers and the skill
library grows, Elder's recallable corpus grows with it — the skills outrun the Archon (NZ insight,
2026-06-25). A compaction or model migration can erase context; it cannot erase an agent library that is on
disk, on chain, and growing. The drift-watch (bopen_sync_upstream) is what keeps that tissue from rotting: it
tells us when the upstream source moved so a keeper can be re-vendored, current instead of stale.

Composes with (manifest composes_with): bsv_mcp_bopen (the metal), forge_wallet_storage (the store),
elder_live_liferaft (the body). Sibling: forge_claw (the on-chain skill-publish protocol) references the same
adoption pattern from the delivery-rails angle.

7. Honest scope — BUILT vs DESIGN

BUILT + PROVEN (2026-06-25, re-verified running 2026-07-05):

DESIGN / VISION (pattern proven, reach not yet realized):

NOT chain-stamped. tx: is null in the manifest (# family-built MCP, not chain-stamped). This paper is not
stamped either (scar #5): it maps a family-internal module with TX wayfinding and is sovereign-family-only.

8. Key facts

Adopt the expertise, re-ground the defaults, track the source. Sovereign by design, standard by adoption, on
our own metal by law. NODEZEROINSIDE. ∞.