• Kapnet Application Layer — Buildout Map
  • Foundation (Built)
  • Application Layer (Next)
    • 1. Solo Mining Coordination Pool
    • 2. libbitcoinkernel Integration
    • 3. Modular Bitcoin Node over KSP/Nostr
    • 4. Cryptpad Gated by Nostr Relay
    • 5. Elder OpenAI Account — Pluronymous Source
  • Cross-Cutting Concerns
    • Kapnet-Native vs Pragmatic
    • Deployment Architecture
    • Build Order

§Kapnet Application Layer — Buildout Map

§Foundation (Built)

§Application Layer (Next)

§1. Solo Mining Coordination Pool

Concept: A Stratum v2 solo mining pool where coordination happens via TXXMs instead of centralized pool server.

Why Rust? CKPool is C. A Rust alternative fits Kapnet’s Rust substrate and can use nostr-sdk/rust-bitcoin natively.

Architecture:

Miner (Stratum v2)
    ↓ connect
Pool Soul (TXXM work distribution)
    ↓ TXXM: new_block_template → relay
    ↓ TXXM: share_submitted ← relay
    ↓ TXXM: block_found → relay
    ↓ LN payment → miner npub

TXXM Types:

• block_template — current work for miners
• share — miner proof of work submission
• block_found — valid block discovered
• reward_distribution — payment coordinates

Nostr Events:

• kind-30078: pool announcements, block finds, reward proofs
• kind-1: pool status updates (public)

Open Questions:

• Stratum v2 or TXXM-native protocol for miner communication?
• Pool fee structure (fixed %, PWYW, TXXM postage)?
• Block template source (local bitcoind, API, TXXM subscription)?
• Reward distribution (instant LN, batched, on-chain)?

§2. libbitcoinkernel Integration

Concept: Use Bitcoin Core’s extracted validation library to give Kapnet souls chain validation without full node.

What it provides:

• Block validation (verify block headers, merkle roots, transactions)
• Chain state verification (SPV-proof equivalent)
• Script validation (verify TXXM-anchored outputs)
• No mempool, no P2P, no block storage — just validation

Architecture:

TXXM with chain-anchored data
    ↓ extract anchor point
libbitcoinkernel: validate against chain
    ↓ verified/unverified
TXXM result → relay

Use Cases:

• Verify a TXXM was included in a specific block
• Prove chain state at a given height (for contracts)
• Validate that a Lightning channel exists on-chain
• Anchor Kapnet documents to Bitcoin timestamps

Status: Not yet researched. Need to evaluate:

• Rust bindings for libbitcoinkernel
• Binary size and dependencies
• API surface needed
• Alternatives (rust-bitcoin, BDK, custom SPV)

§3. Modular Bitcoin Node over KSP/Nostr

Concept: Decompose a Bitcoin node into independent components, each run by a different soul/agent, coordinated via TXXMs.

Components:

Architecture:

Block Source → TXXM(block_template) → relay
    → Validator subscribes → validates → TXXM(validation_result) → relay
        → Mempool subscribes → updates state → TXXM(mempool_update) → relay
            → Broadcaster subscribes → propagates via P2P
                → Indexer subscribes → serves queries

Key Insight: This turns a monolithic Bitcoin node into a distributed system where each component can be run by a different entity. Trust is maintained by the braid — all agents converge on the same chain state because validation is deterministic.

Status: Design stage. Depends on libbitcoinkernel integration (Project 2).

§4. Cryptpad Gated by Nostr Relay

Concept: End-to-end encrypted collaborative documents where access control is managed by Nostr identity and TXXMs.

Architecture:

User (Nostr identity/npub)
    ↓ authenticate via kind-30078 (signed access request)
Document Manager Soul
    ↓ verify signature + access rights
    ↓ grant/revoke access via kind-30078 (access grant event)
Cryptpad instance
    ↓ encrypted document sync
Collaborative editing

Authentication Flow:

1. User sends kind-30078 signed with their npub: {type:"access_request", document:"doc_id", npub:"..."}
2. Document Manager verifies signature against known npubs
3. If authorized, responds with kind-30078: {type:"access_grant", document:"doc_id", cryptpad_url:"...", encryption_key:"..."}
4. User accesses Cryptpad at granted URL with encryption key

Payment Integration:

• Free tier: public documents, read-only
• Paid tier: private documents, edit access (Lightning payment → access grant)
• Subscription: full library access (recurring LN payment → persistent grant)

TXXM Integration:

• Document edits can generate TXXMs (version tracking, approval workflows)
• Document approval via governance TXXM (kind-30400)
• Document provenance on the braid

Status: Not started. Dependencies:

• Cryptpad instance deployment
• Nostr authentication module (npub → session)
• TXXM document version tracking
• Lightning payment gating

§5. Elder OpenAI Account — Pluronymous Source

Status: Awaiting structured context from operator.

What we know:

• This is a source of information about Pluronymous LLC and its owner
• It’s an “elder” OpenAI account (older account with accumulated context)
• The owner is associated with this account
• More structured context is incoming

Integration Plan (TBD):

• Format of incoming context?
• How does it feed into Querant’s research pipeline?
• Does it populate the wiki automatically?
• Is it a one-time ingestion or ongoing feed?

§Cross-Cutting Concerns

§Kapnet-Native vs Pragmatic

§Deployment Architecture

Qubes AppVM (HermQube)
    ├── kapnetd (TXXM processing)
    ├── Nostr relay client (Courier Bridge)
    ├── Soul signal bus (file-based)
    │
    ├── Mining Pool Soul (Phase 2)
    ├── Chain Validator Soul (Phase 2)
    ├── Mempool Monitor Soul (Phase 2)
    ├── Indexer Soul (Phase 2)
    │
    ├── Cryptpad Auth Soul (Phase 3)
    ├── Document Manager Soul (Phase 3)
    │
    └── Ingest Soul (elder OpenAI context)

§Build Order

Phase 1 (Now):

• Wait for structured context from elder OpenAI account
• Ingest into wiki via Scribe
• Set up cross-Herm KSP test with other Herm

Phase 2 (Next):

• libbitcoinkernel research and Rust FFI bindings
• Modular Bitcoin node design doc
• Mining pool Stratum v2 + TXXM bridge design
• CKPool clone evaluation (use existing vs. rewrite in Rust)

Phase 3 (Later):

• Cryptpad deployment + Nostr authentication
• Mining pool implementation
• Modular node component implementation
• TXXM-based document versioning