Kapnet KOR Memberships — Specification

title: Kapnet KOR Memberships — Specification type: spec version: "0.1.0"

title: Kapnet KOR Memberships — Specification type: spec version: “0.1.0” date: 2026-06-10 tags: [KOR, membership, spec, tier, access]

Kapnet KOR Memberships — Specification

A KOR is a coordination room. Membership grants access.

A KOR (Kapnet Operational Realm) is a namespace-isolated coordination domain. Each KOR has its own braid, governance, and encrypted communication channels. Membership in a KOR is granted via a TXXM (membership TXXM) and verified by any Kapnet node.

Tiers

Tier 0: Observer (Free)

  • Access: Read-only to public KOR TXXMs
  • Requirements: npub (self-generated, no cost)
  • Capabilities: Read wiki, read public braid, submit public TXXMs
  • Governance weight: 0 (cannot vote, can observe)

Tier 1: Member (10,000 sats/month)

  • Access: Read + write to designated Member KORs
  • Requirements: Membership TXXM + Lightning payment or Hedlbit burn
  • Capabilities: Write TXXMs, join encrypted group chat, participate in governance
  • Governance weight: 1x
  • Encrypted chat: MLS group with KOR-scoped keys

Tier 2: Maintainer (50,000 sats/month)

  • Access: All Member privileges + KOR creation rights
  • Requirements: Membership TXXM + Lightning payment + proof of contribution
  • Capabilities: Create KORs, moderate governance, earn protocol postage
  • Governance weight: 5x
  • Revenue share: Percentage of protocol postage from KOR activity

Tier 3: Operator (200,000 sats/month)

  • Access: All Maintainer privileges + treasury access
  • Requirements: Multisig authorization, membership TXXM, contract with Pluronymous LLC
  • Capabilities: Treasury operations, custom governance rules, dedicated relay
  • Governance weight: 25x
  • Treasury: 2-of-3 multisig (hot warm cold)

Membership TXXM Structure

{
  "type": "membership",
  "version": "1.0",
  "npub": "<member-npub>",
  "kor": "<kor-namespace>",
  "tier": "observer|member|maintainer|operator",
  "granted_by": "<granter-npub>",
  "granted_at": "<unix-timestamp>",
  "expires_at": "<unix-timestamp>",
  "payment": {
    "method": "lightning|hedlbit",
    "amount": 10000,
    "invoice": "<bolt11-invoice>",
    "settled": true
  },
  "capabilities": ["read", "write", "govern", "admin"],
  "encrypted_group": {
    "protocol": "mls-whitenoise",
    "group_id": "<group-id>",
    "key_material": "<encrypted-key-blob>"
  }
}

Verification

Any Kapnet node can verify a membership TXXM:

  1. Check signature matches member npub
  2. Check granter npub has sufficient tier in target KOR
  3. Check payment is settled (if paid tier)
  4. Check expiry has not passed
  5. Grant access to KOR namespace

Revocation

Membership can be revoked by:

  • The granter (immediate)
  • Governance vote (quorum required)
  • Expiry (automatic)
  • Operator override (emergency only, logged)

Encrypted Group Chat

Each KOR with tier >= Member has an associated encrypted group chat:

  • Protocol: MLS (Messaging Layer Security) via Whitenoise
  • Identity: npub (no phone, no email)
  • Key exchange: KOR-scoped, rotated on membership change
  • Transport: Nostr relays (encrypted kind-30078 events)
  • Persistence: Group state stored in KOR namespace

Payment Flow

  1. Prospective member generates npub (if not already done)
  2. Requests membership TXXM from KOR granter
  3. Granter generates Lightning invoice (via lnd or LNbits)
  4. Member pays invoice
  5. Granter verifies payment on-chain/Lightning
  6. Granter publishes membership TXXM to relay
  7. All nodes verify and grant access

Hedlbit Alternative

Instead of Lightning payment, members can burn Hedlbits:

  • Hedlbits are earned by doing work (validation, storage, research)
  • Burning Hedlbits for membership creates deflationary pressure
  • Rate: 10,000 Hedlbits = 1 month Member tier
  • Hedlbit accounting is tracked in the KOR state tree

Write a comment
No comments yet.