Genesis Bootstrap Plan

Date: 2026-03-14 Status: Draft

Problem Statement

At network launch:

• Zero users are in Sovereign phase (15+ pacts)
• Therefore zero users qualify as Guardians
• Therefore the guardian pact mechanism cannot function
• Bootstrap pacts (triggered by follows) are the sole onboarding mechanism
• Bootstrap pacts require the followed user to accept — but early adopters have no pact infrastructure

The protocol needs temporary centralized scaffolding to bridge the gap between "zero users" and "self-sustaining pact network."

Genesis Guardian Nodes

Design

Deploy 5-10 operator-controlled full nodes that serve as:

1. Guardian pact partners for all Seedlings during the first 6-12 months
2. Bootstrap pact partners for early adopters who follow the Genesis accounts
3. High-uptime pact partners for users in the Growing phase

Specifications

Identity and Transparency

Genesis Guardian nodes are publicly identified:

• Each node has a well-known pubkey listed in project documentation
• Each node's kind 10002 relay list, kind 10050 device delegation, and pact statistics are publicly auditable
• A transparency dashboard publishes monthly reports:
  • Number of Seedlings served
  • Number that reached Hybrid/Sovereign phase
  • Average time to Hybrid phase
  • Uptime metrics
  • Storage consumed

Guardian Behavior

Genesis nodes behave identically to organic Guardians with relaxed constraints:

• Accept guardian pacts from any Seedling (no WoT requirement — they are Genesis)
• Store Seedling events for up to 90 days or until Hybrid phase
• Respond to challenge-response verification like any pact partner
• Forward Seedling content via gossip with active-pact-partner priority
• Do NOT censor, filter, or prioritize specific Seedlings

Bootstrap Pact Behavior

Genesis nodes also serve as bootstrap pact partners:

• Any user who follows a Genesis node pubkey triggers a bootstrap pact
• This provides immediate storage redundancy for early adopters
• Genesis nodes accept bootstrap pacts up to capacity (500 per node)

Network Health Metrics

Metrics to Track

Sunset Conditions

Genesis Guardian nodes are removed when ALL of the following are met:

1. Organic guardian supply exceeds Seedling demand (supply/demand ratio > 1.5 for 30 consecutive days)
2. Network has at least 1,000 Sovereign-phase users
3. Sovereignty ratio exceeds 15% (enough users have mature pact networks)
4. Pact formation rate is self-sustaining (new users reach Hybrid phase within 60 days without Genesis assistance)

Sunset is gradual:

1. Genesis nodes stop accepting NEW guardian pacts (existing ones continue)
2. After 90 days, all guardian pacts expire naturally
3. Genesis nodes transition to regular Keeper nodes (still participate in the network as peers)
4. Genesis pubkeys are retained for historical transparency

Failure Conditions

If after 12 months:

• Sovereignty ratio is below 5%
• Organic guardian supply is near zero
• Genesis nodes serve >80% of all guardian pacts

Then the bootstrap strategy has failed. Possible responses:

• Extend Genesis operation with increased capacity
• Re-evaluate the guardian incentive model (see guardian-incentives.md)
• Consider relay-as-Guardian integration (relays volunteer guardian slots as a service)
• Acknowledge that the current incentive model may need fundamental revision

Early Network Parameter Relaxation

During the bootstrap period (network < 1,000 users), certain protocol parameters should be relaxed:

Parameters tighten automatically as network size grows:

• At 500 users: follow-age increases to 14 days
• At 1,000 users: volume tolerance tightens to ±50%, follow-age to 21 days
• At 3,000 users: all parameters at normal values

Adoption Strategy Integration

Genesis Guardian nodes are necessary but not sufficient. The bootstrap plan must be paired with:

1. Day-one value features that work without pacts: multi-device identity, encrypted DMs, social recovery (see whitepaper §10.1)
2. Community-first targeting: dense clusters of 200+ users (conference attendees, activist groups, Bitcoin communities) rather than scattered individual adoption
3. The first client must be the best Nostr client available: users adopt for UX, sovereignty accrues in the background

Cost Estimate

This is a modest investment for bootstrapping a decentralized network. Comparable projects (Mastodon, Matrix) required similar or larger investments in initial infrastructure.