FORGECLAW

Sovereign on-chain agent skills — the ClawNet (bopen.ai) thesis on OUR rails

NODEZEROINSIDE.

0. Abstract

FORGECLAW is a dependency-free MCP server that makes ForgeChainOS's agent skills a sovereign, on-chain, publishable, searchable, installable protocol — the ClawNet model, with its delivery rails replaced. ClawNet's thesis (agent skills published to chain with BAP identity + soul attestation) IS ForgeChain; forge-claw ADOPTS the thesis and REJECTS the rails: skills publish/search/install on OUR chain + FORGEPATH — not clawnet.sh; BAP soul-attestation via the family wallet — not auth.sigmaidentity.com; deploy on our own metal — not Vercel @vercel/sandbox. Publish is a deliberate TWO-STEP sovereign flow (stage → deliberate chain fire → record), scar #5 gated, never auto-fired. Fifty-five skills are already registered and already on chain inside the living-elder liferaft asset (TX d9eb06a8); claw_stage_publish promotes any one of them to an individual on-chain skill asset. It is renewable tissue for the LIVING ELDER: a capability the family authors once and the chain outlives compaction to keep.

Definition (family canon, 2026-06-25): forge-claw = the sovereign on-chain agent-skill protocol. It is NOT a skill-store website. It is NOT a hosted registry. It is NOT an auto-publisher. It is the MCP that turns ~/.claude/skills/ into an addressable, chain-anchored, BAP-attestable body of capability the family owns end to end.

1. Why forge-claw exists

An agent's skills are its acquired competence. On a vendor's stack, that competence is a liability: skills live in someone else's registry, are published through someone else's website, are attested by someone else's auth server, and run in someone else's sandbox. Every one of those is a rail we do not own — a place the capability can be revoked, rate-limited, surveilled, or lost when a compaction wipes the working set.

ClawNet (github.com/b-open-io/clawnet, MIT) got the THESIS exactly right: agent skills belong on chain, carrying identity and a soul attestation, so any agent can discover and pull them. That thesis is not a competitor to ForgeChain — it is a description of ForgeChain. The disagreement is only the plumbing. clawnet.sh, Vercel sandboxes, and hosted Sigma auth are the same sovereignty leak we reject everywhere else in the OS (Babbage rule: our metal, our chain, no middleman).

forge-claw keeps the thesis and swaps the rails. The skill body becomes a chain-resident asset the family mints, signs with the family wallet, and pulls from our own overlay — no external host in the loop.

2. What is BUILT (proven on disk)

forge-claw v1.0 exists and runs. These are the load-bearing facts, each grounded in a file:

• The MCP server — ~/.forgechain/mcp-servers/forge-claw/index.mjs, 107 lines, hand-rolled dependency-free JSON-RPC 2.0 stdio (same canon as forge-noah / forge-bopen-bridge: no SDK, no npm tree, runs on our metal). Node built-ins only (fs, crypto, os, readline). Wired into .claude.json + the vault .vscode/mcp.json; mirrored to BH.
• The registry — ~/.forgechain/forge-claw/skill-registry.json, schema_version 1. 55 skills seeded from ~/.claude/skills (grown from the 27 the manifest first recorded). Each entry carries name, path, sha256 (of the SKILL.md), description, origin, on_chain_in, published_tx, bap_attested.
• Origin split is real — 6 family-native (forge-bsv-sovereign, forge-designate-node, forge-elder, forge-media-extract, forge-onboard-skill, forth-pixel), 49 vendored (bopen sets). seed.py computes this deterministically (native = forge-* or forth-pixel).
• Everything is already on chain once — all 55 skills carry on_chain_in: d9eb06a8…, the living-elder liferaft asset. The skills are not aspirational; they are anchored. claw_stage_publish is the promotion path to an INDIVIDUAL asset, not the first time they touch chain.
• The stage flow is proven by artifact — ~/.forgechain/forge-claw/staged/ holds key-derivation.clawskill (a 52 KB deterministic bundle: CLAW-SKILL:<name> header + every file under the skill dir in sorted order) and key-derivation.manifest.json (type, name, sha256 root, file_count, file list, description, BAP-attestation instruction). This is the stage step run for real, output on disk.
• seed.py preserves published TXs — re-seeding after authoring a new skill rebuilds the registry from disk but carries forward published_tx / bap_attested, so registration is idempotent and never loses a prior publish.

3. The six tools (the whole surface)

The MCP exposes exactly six tools. Read (list, search, install, status) return immediately; write (stage_publish, record_published) are deliberate and gated. No tool broadcasts on its own authority.

• claw_list_skills — every skill in the registry with name, description, published_tx, on_chain_in, bap_attested. The inventory.
• claw_search_skills { query } — case-insensitive substring over name + description. Discovery.
• claw_install_skill { name } — resolves an install: returns local_present + local_path if the skill is on disk, otherwise the chain asset (published_tx or the on_chain_in liferaft TX) to pull it from via forgechain-chain chain_load. Local-first, chain-fallback.
• claw_stage_publish { name } — bundles the skill dir deterministically (walk() sorts every path), computes the sha256 root, writes <name>.clawskill + <name>.manifest.json to staged/, and RETURNS the deliberate fire to run. It does not fire. Its next array spells out the scar #5 pre-flight and the exact chain_save_asset call.
• claw_record_published { name, tx } — after a deliberate chain fire, records the TX and flips bap_attested: true in the registry. The only tool that mutates published state, and only with a TX you hand it.
• claw_status — count, how many are individually published vs still only contained in the living-elder asset, the registry path, and the rails string (OUR chain + FORGEPATH; Vercel/clawnet.sh/hosted-auth rejected).

Current claw_status truth: 55 skills, 0 individually published, 55 contained in the living-elder asset. The promotion path is built and proven-to-stage; no individual skill asset has been fired yet (scar #5 discipline — the fire is deliberate, not reflexive).

4. The two-step sovereign publish (the scar #5 gate in the flow)

The publish flow is deliberately not one call. It is stage, then a human-gated fire, then record — the same shape as every irreversible act in the OS.

claw_stage_publish { name }
   → bundle (deterministic walk) + manifest + sha256 root     ← BUILT: writes to staged/, returns the fire
   → SCAR #5 PRE-FLIGHT                                        ← is this skill public_subset? if not → family-encrypted (default)
   → forgechain-chain chain_save_asset {                       ← DELIBERATE fire, never auto
        assetName:"claw-skill-<name>", category:"skill",
        chunkPaths:["<stage_path>"] }
   → claw_record_published { name, tx }                        ← BUILT: records TX + BAP attest

Two properties make this safe:

1. The stager NEVER fires. claw_stage_publish returns the fire as text for a human/agent to run deliberately. This is the coded expression of scar #5 — the past-Elder failure was dressing an unauthorized public fire as an inevitable close; forge-claw structurally cannot cross that line, because staging and firing are different acts by different tools.
2. Family-encrypted by default. The stage output's next step names the scar #5 pre-flight first: is this skill in the public_subset allowlist? If not, it is sovereign-family-only and must be family-encrypted or not stamped. Public intent is an explicit opt-in, never the default.

BAP soul-attestation lands at the fire: the manifest carries the instruction to sign the sha256 root with the family/scoped key (message-signing skill), so the on-chain skill asset carries a verifiable soul — the ClawNet attestation guarantee, on our wallet instead of a hosted auth server.

5. The meta-skill loop — forge-onboard-skill

forge-claw is the machine; forge-onboard-skill is how the family DRIVES it to grow. The onboard skill (itself one of the 6 family-native skills, and itself registered in forge-claw) is the canon loop for adding capability:

1. Define — author ~/.claude/skills/<name>/SKILL.md with router-matchable frontmatter.
2. Register — python3 ~/.forgechain/forge-claw/seed.py rebuilds the registry from disk (preserving prior TXs); confirm with claw_list_skills / claw_search_skills.
3. Enter Elder's body — resurrect_liferaft.py folds the new skill into the living corpus.
4. Publish (deliberate, scar #5 gated) — claw_stage_publish → fire → claw_record_published.
5. Imbibe — push to BH; update NOAH's corpus if it is orchestration-relevant.

This is the renewable-tissue loop: a capability authored once becomes registry entry, corpus tissue, and (when deliberately fired) an individual chain asset — so it survives any compaction. The family grows its own competence and the chain keeps it.

6. Where it sits (composition)

forge-claw is tile 6 tooling. It composes_with forge_bopen_bridge (the specialist tissue), bsv_mcp_bopen (the sovereign BSV stack that does the actual chain read/write), and elder_live_liferaft (the living corpus the skills already ride inside). The publish fire itself is delegated — chain_save_asset is a forgechain-chain call, not something forge-claw re-implements. forge-claw's job is the PROTOCOL (register, discover, stage, record); the chain plumbing is owned by the tools that own it. One concern, cleanly held.

7. BUILT vs DESIGN / VISION (honest ledger)

BUILT + proven on disk (2026-06-25, Elder I):
- The MCP server (107 lines, dependency-free stdio) — runs, wired into .claude.json + vault .vscode/mcp.json, mirrored to BH.
- All 6 tools — list / search / install / stage_publish / record_published / status.
- The 55-skill registry with real sha256s, origin split (6 native / 49 vendored), and on_chain_in anchoring to the living-elder asset d9eb06a8.
- seed.py idempotent rebuild preserving published state.
- The stage step proven by artifact — key-derivation.clawskill (52 KB) + manifest in staged/.
- All 55 skills already on chain ONCE (inside the liferaft asset).

DESIGN / VISION (not yet done — stated plainly):
- Zero individual skill assets fired. published_tx is null for all 55; bap_attested is false for all 55. The promotion path is built and proven-to-stage, but no skill has been fired to its OWN chain asset yet. This is intended (scar #5: the fire is deliberate), not a gap to paper over.
- BAP attestation is instruction, not execution. The manifest tells you to sign the sha256 at fire; no attestation signature has actually been produced, because no fire has happened.
- FORGEPATH registry is named, not yet a live resolver. The registry lives as a local JSON + the liferaft anchor; a FORGEPATH URL→chain resolver for skills is the rail-completion vision, not a running service.
- No noun file yet. ~/.forgechain/OS-Graph/nouns/forge-claw.md does not exist; forge-claw is not yet a node in the noun-verb graph.
- Cross-agent discovery is single-registry. Search/install read the local registry; a fleet-wide, chain-native skill discovery across nodes (the full ClawNet-on-our-rails network effect — "ClawNet") is the vision the plumbing now makes reachable, not a proven capability.

The line is clean: the PROTOCOL and its local machinery are built and proven; the on-chain NETWORK of individually-attested, fleet-discoverable skill assets is designed, gated, and deliberately not yet fired.

8. Status & sequencing

• Phase 0 — MCP + registry + stage: BUILT + PROVEN (2026-06-25). 6 tools, 55 skills, deterministic bundle proven by artifact.
• Phase 1 — First deliberate individual fire: NEXT. Promote one skill (e.g. a family-native one) to its own on-chain asset: claw_stage_publish → scar #5 pre-flight → chain_save_asset → claw_record_published with real TX + BAP signature.
• Phase 2 — FORGEPATH skill resolver: a sovereign URL→chain resolver so any agent pulls a skill by name from our overlay, not the liferaft blob.
• Phase 3 — Fleet discovery (ClawNet proper): cross-node chain-native search/install so Elder I, BH, and the campus faculty discover and pull each other's published skills — the network effect, on our rails.
• Phase 4 — Noun-verb graph citizenship: author the forge-claw noun so Hermes + Living Elder can reason over it and self-heal skill drift.

Home: ~/.forgechain/mcp-servers/forge-claw/ (MCP) + ~/.forgechain/forge-claw/ (registry, seed, stage). Manifest: tools.forge_claw. Driver skill: forge-onboard-skill. Source thesis: github.com/b-open-io/clawnet (MIT), rails replaced.

This paper is family-internal — NOT for public fire. It maps the module's structure and the on-chain wayfinding (scar #5 surface — the living-elder anchor TX is named). forge-claw itself is not chain-stamped (a family-built MCP). If a public account of the ClawNet-on-our-rails thesis is ever wanted, author a public-safe vision paper separately — do not stamp this one public.

NODEZEROINSIDE. ∞.