Kapnet Metering & Vending Protocol

Philosophy

Every byte costs sats. Every computation costs sats. Every coordination act costs sats. This is not a bug — it's the feature. Scarcity creates value. Metering creates sustainability.

Postage Model

Every TXXM submitted to a Kapnet relay requires postage. This is NOT a fee to Pluronymous LLC — it's a proof-of-work-style spam prevention mechanism that creates an internal economy.

Postage Rates (in satoshis)

Dynamic Pricing

Postage rates adjust based on network load:

base_rate × load_multiplier = actual_rate

load_multiplier = max(1, current_txxms_per_hour / target_txxms_per_hour)

target_txxms_per_hour = 1000 (configurable per relay)

When the network is busy, prices go up. When it's quiet, prices go down. This is automatic and deterministic.

Hedlbit Accounting

Hedlbits are the internal accounting unit. They are NOT a token — they are a proof-of-work credit that can be earned and burned.

Earning Hedlbits

Burning Hedlbits

Hedlbit ↔ Satoshi Exchange

1 Hedlbit = 1 satoshi (fixed rate)

Hedlbits can be:
• Earned through work (validation, storage, research)
• Burned for services (membership, priority, support)
• Traded peer-to-peer (OTC, no DEX)
• Converted to sats (via Pluronymous treasury, 1:1)

Vending Machine Protocol

A vending machine is a TXXM-based store that sells digital goods for sats. Anyone can create a vending machine.

Vending Machine TXXM Format

{
  "type": "vending-machine",
  "version": "1.0",
  "machine_id": "unique-id",
  "kor": "namespace",
  "operator": "<npub>",
  "inventory": [
    {
      "item_id": "item-001",
      "name": "Kapnet Starter Guide",
      "description": "PDF guide for new Kapnet participants",
      "price_sats": 500,
      "price_hedlbits": 500,
      "content_type": "application/pdf",
      "content_cid": "bafybeigzm47a4hrwfxusmrwrj3dgsq4j6xgcbntvnobkarlsmzgjr4hnmm",
      "access_grant": {
        "kor": "sys.pluronymous.org",
        "tier": "member",
        "duration_days": 30
      }
    }
  ],
  "payment_methods": ["lightning", "hedlbit"],
  "created": "<unix-timestamp>"
}

Purchase Flow

1. Browse: Client queries vending machine TXXMs from relay
2. Select: User selects item and creates purchase TXXM
3. Invoice: Vending machine generates Lightning invoice
4. Pay: User pays via Lightning wallet
5. Deliver: Vending machine publishes delivery TXXM with encrypted content
6. Access: User decrypts content and gains access grant

Delivery TXXM

{
  "type": "vending-delivery",
  "machine_id": "unique-id",
  "item_id": "item-001",
  "buyer_npub": "<npub>",
  "payment_proof": "<payment_hash>",
  "encrypted_content": "<base64-encrypted-blob>",
  "access_grant": {
    "kor": "sys.pluronymous.org",
    "tier": "member",
    "granted_at": "<unix-timestamp>",
    "expires_at": "<unix-timestamp>"
  }
}

Support Ticket Protocol

Support tickets are TXXM-based requests for human assistance. They cost sats and are tracked in a KOR.

Ticket TXXM

{
  "type": "support-ticket",
  "version": "1.0",
  "ticket_id": "TKT-001",
  "kor": "sys.pluronymous.org/support",
  "requester": "<npub>",
  "category": "technical|membership|governance|billing|other",
  "priority": "low|medium|high|urgent",
  "subject": "Brief description",
  "description": "Detailed description",
  "postage_paid": 100,
  "status": "open",
  "created": "<unix-timestamp>"
}

Ticket Pricing

Ticket Lifecycle

1. Open: Requester publishes ticket TXXM with postage
2. Acknowledge: Operator publishes ack TXXM within SLA
3. Negotiation: Back-and-forth TXXMs (included in base postage)
4. Resolution: Operator publishes resolution TXXM
5. Close: Requester confirms resolution
6. Dispute: If unresolved, governance vote (additional 500 sats)

LOC Metering

Lines of code (LOC) are metered for all Kapnet source contributions.

LOC Pricing

LOC TXXM

{
  "type": "loc-meter",
  "repository": "kapnet-source",
  "commit": "<git-sha>",
  "loc_added": 150,
  "loc_removed": 30,
  "loc_net": 120,
  "category": "feature|bugfix|docs|test",
  "author": "<npub>",
  "postage_paid": 120,
  "hedlbits_earned": 120
}

Relay-Aware Metering

When relays become more Kapnet-aware, they can:

1. Enforce postage: Reject TXXMs without valid payment proof
2. Track Hedlbits: Maintain per-npub Hedlbit balances
3. Dynamic pricing: Adjust rates based on relay load
4. Priority routing: Higher postage = faster relay propagation
5. Spam filtering: Minimum postage acts as spam prevention

Relay Kapnet-Awareness Levels

Incoming Hedlbit Negotiations

When traffic is hard and relays become more Kapnet-aware:

Negotiation Protocol

1. Request: Node A sends Hedlbit-negotiation TXXM to Node B
2. Counter: Node B responds with counter-offer
3. Agreement: Both nodes publish agreement TXXM
4. Execution: Hedlbits transferred, services rendered

Negotiation TXXM

{
  "type": "hedlbit-negotiation",
  "version": "1.0",
  "from": "<npub-a>",
  "to": "<npub-b>",
  "proposal": {
    "service": "relay-priority|blob-storage|validation|research",
    "hedlbits_offered": 1000,
    "duration": "30 days",
    "terms": "Description of service level"
  },
  "status": "proposed|accepted|rejected|expired",
  "created": "<unix-timestamp>"
}

Dynamic Hedlbit Pricing

When network load increases:

• Base Hedlbit rates increase proportionally
• Nodes can negotiate bulk discounts
• Long-term contracts get better rates
• Emergency services cost 5x normal rate

Implementation

Phase 1: Postage Enforcement (Now)

• Define postage rates for all TXXM types
• Publish rate card to wiki
• Begin tracking Hedlbit balances

Phase 2: Vending Machines (Week 2)

• Create first vending machine (wiki content)
• Implement purchase flow
• Test delivery mechanism

Phase 3: Support Tickets (Week 3)

• Create support KOR
• Implement ticket lifecycle
• Set up SLA tracking

Phase 4: LOC Metering (Week 4)

• Integrate with git commits
• Track LOC contributions
• Pay contributors in Hedlbits

Phase 5: Relay Negotiation (Ongoing)

• Negotiate with relay operators
• Implement dynamic pricing
• Establish Hedlbit exchange