• n0-space KAP Integration — Design Layer
  • What We Found
  • Key Repos from n0-space
  • KAP Protocol Structure (from KAP-000)
    • Class A: Informational
    • Class B: Overlay Protocol Specifications
    • Class C: Bitcoin Interface Specifications
    • Class D: Hypothetical Consensus Proposals
  • How Our Implementation Maps to KAP
  • What We Need to Adjust
  • ZeroClaw Integration
  • Immediate Actions
  • Repos Cloned to SSD

§n0-space KAP Integration — Design Layer

§What We Found

The n0-space/-kapnet repo on GitHub contains the Kapnet Improvement Proposals (KAP) — a BIP-style protocol specification with 30+ sub-proposals. This is the formal protocol spec that our implementation should conform to.

§Key Repos from n0-space

§KAP Protocol Structure (from KAP-000)

The Kapnet protocol family is decomposed into 30+ sub-BIPs organized in 4 classes:

§Class A: Informational

• KAP-000: Terminology, Notation, Conformance Language
• KAP-001: Network Identity and Transport Registry
• KAP-041: AggWit Policy Gradients
• KAP-081: Hedlbit Accounting
• KAP-101: Nostr Interoperability Profile
• KAP-131: Units, Measures, Oracle Interfaces
• KAP-141: Bitcoin Policy Compatibility

§Class B: Overlay Protocol Specifications

• KAP-002: Node Handshake and Capability Discovery
• KAP-003: Canonical Serialization (big-endian, sorted maps, compact ints)
• KAP-010: TXXM Envelope Format (the core message format)
• KAP-011: TXXM Message Classes (submission, validation, vote, governance, etc.)
• KAP-012: Dependency Graph and Replay Semantics
• KAP-013: Blob and Attachment Commitments
• KAP-020: Weakwork Claim Object
• KAP-021: Weakwork Validation and Scoring
• KAP-022: Weakwork Markets and Transfer Receipts
• KAP-030: Heavy Auxiliary Proof-of-Work Commitment
• KAP-031: Heavy Auxiliary Proof Contribution Rules
• KAP-040: AggWit Aggregate Witness Container
• KAP-050: Braid Structure and Heaviest-Braid Selection
• KAP-051: Knot Formation and Checkpointing
• KAP-052: State Commitment Tree
• KAP-060: KScript Virtual Machine Core
• KAP-061: KScript Resource Bounds and Determinism
• KAP-062: KScript State Access and Cross-Domain Rules
• KAP-070: Kapplet Package Format
• KAP-071: Kapplet Runtime Interface
• KAP-080: Relay Policy, Admission Control, Postage Classes
• KAP-090: Provider Lookup and Retrieval Proofs
• KAP-100: Kapnet-to-Nostr Event Mapping
• KAP-110: Identity, Keys, Capability Delegation
• KAP-111: Membership Proofs and Reputation Objects
• KAP-120: DAO Object Model and Governance Actions
• KAP-121: Guild, Room, Submission Namespaces
• KAP-130: Market Objects
• KAP-140: Bitcoin Settlement Hooks and Anchoring Templates
• KAP-150: Conformance Test Vectors

§Class C: Bitcoin Interface Specifications

• KAP-140: Bitcoin Settlement Hooks (OP_RETURN, coinbase commitments)

§Class D: Hypothetical Consensus Proposals

• KAP-141: Bitcoin Policy Compatibility (informational only)

§How Our Implementation Maps to KAP

OUR CONCEPT          → KAP EQUIVALENT
─────────────────────────────────────────
TXXM envelope        → KAP-010
TXXM types           → KAP-011 (submission, review, governance, etc.)
Canonical encoding   → KAP-003 (big-endian, sorted maps)
Braid structure      → KAP-050
Knot checkpointing   → KAP-051
State tree           → KAP-052
Weakwork             → KAP-020, KAP-021
Hedlbit claims       → KAP-081
Nostr projection     → KAP-100
Session management   → KAP-110 (identity, keys, capability delegation)
Reputation           → KAP-111
DAO governance       → KAP-120
Guild/Room namespace → KAP-121
Market objects       → KAP-130
BTC anchoring        → KAP-140
KScript VM           → KAP-060, KAP-061, KAP-062
Kapplet packages     → KAP-070, KAP-071
Relay policy         → KAP-080
OP_RETURN parsing    → KAP-140 (carrier surface)
Canonical serial     → KAP-003

§What We Need to Adjust

Our current implementation uses some different names/concepts. Here’s the alignment:

OUR TERM            → KAP TERM
─────────────────────────────────────────
TXXM type enum      → KAP-011 Message Class
TXXM payload        → KAP-010 Payload
Braid tips          → KAP-050 Frontier
Knot                → KAP-051 Knot
State root          → KAP-052 State Root
Session             → KAP-110 Key Role
npub auth           → KAP-110 Identity
OP_RETURN filter    → KAP-140 Anchoring Template
Mining pool         → KAP-130 Market Object
Lightning payment   → KAP-130/081 Postage/Hedlbit

§ZeroClaw Integration

n0-space/zeroclaw is a lightweight Rust AI agent framework:

• 5MB binary, <10ms startup
• Pluggable providers (OpenAI, Anthropic, etc.)
• Pluggable channels (Discord, Telegram, etc.)
• Pluggable tools (web, file, shell, memory)
• MIT license

For Mac Kapnet: ZeroClaw could be the agent runtime that hosts Hermes souls on the Mac. Instead of running full Hermes+Courier, Mac agents could run as ZeroClaw instances with:

• Kapnet provider plugin (Nostr relay client)
• Kapnet tool plugin (TXXM submission/validation)
• Kapnet memory plugin (SSD-backed state)

This would be MUCH lighter than full Hermes. A 5MB binary vs 10GB+.

§Immediate Actions

1. Study KAP-010 (TXXM Envelope) — align our TXXM format
2. Study KAP-011 (Message Classes) — align our TXXM types
3. Study KAP-050/051/052 (Braid/Knot/State) — align our braid implementation
4. Clone zeroclaw — evaluate as Mac agent runtime
5. Clone btcresearch — ingest CABRA research archive into wiki
6. Clone whirlpool — evaluate for treasury privacy
7. Clone lnd — evaluate for Lightning integration

§Repos Cloned to SSD

All n0-space repos are at: shared-rw/repos/n0-space/ Total: ~110MB