The Trust Anchor PROPOSAL v3

Program structure: 1 core + modular extensions

Capabilities are split across programs based on upgrade cadence and complexity. The core program handles operations that touch every user interaction. Extension programs handle specialized features.

The user's journey (every step on-chain)

2.1 Shard Map Authority CORE

The program stores encrypted shard location maps in PDAs. All on-chain data is AES-256-GCM ciphertext — publicly readable but useless without the user's wallet key.

PDA: ShardMap

Seeds: ["shard_map", user_pubkey, vault_id (u64)]
Fields:
  owner: Pubkey
  vault_id: u64
  version: u32          // incremented on each rotation
  encrypted_map: Vec<u8> // AES-256-GCM ciphertext (~300-500 bytes)
  nonce: [u8; 12]       // encryption nonce
  map_hash: [u8; 32]    // SHA-256 of plaintext (integrity check)
  status: u8            // Active=0, Locked=1, Rotating=2, Deleted=3
  created_at: i64
  updated_at: i64

Instructions:

2.2 Subscription Management CORE

Tier status managed on-chain. Users deposit payment into program-controlled escrow. Verifiable by anyone — no trusting ShardKeep's server to report tier correctly.

PDA: Subscription

Seeds: ["subscription", user_pubkey]
Fields:
  owner: Pubkey
  tier: u8              // Free=0, Guardian=1, Sentinel=2, Fortress=3
  payment_mint: Pubkey  // USDC or SHARDKEEP mint address
  paid_through: i64     // subscription valid until
  auto_renew: bool
  escrow_balance: u64   // pre-deposited for auto-renewal

Instructions:

Why on-chain? If ShardKeep's server says "you're not subscribed," the user can prove otherwise by pointing to the Subscription PDA. Third-party apps can verify tier without calling our API (see Auth-as-a-Service). The blockchain IS the receipt.

2.3 Access Control + 2FA Backup Wallet CORE

The kill switch. Primary wallet and backup wallet registered on-chain. Backup can freeze everything. Social recovery via guardians.

PDA: AccessControl

Seeds: ["access_control", user_pubkey]
Fields:
  primary_wallet: Pubkey
  backup_wallet: Option<Pubkey>
  guardian_wallets: Vec<Pubkey>  // max 5, for social recovery
  guardian_threshold: u8         // how many guardians needed
  lockdown_active: bool
  lockdown_initiated_by: Option<Pubkey>
  recovery_cooldown: i64        // e.g., 48 hours
  last_primary_action: i64

Instructions:

2.4 Rotation Scheduling CORE

The program defines rotation rules per tier. A permissionless crank checks if rotation is due. The user or a delegated agent executes.

PDA: RotationDelegate

Seeds: ["rotation_delegate", user_pubkey]
Fields:
  owner: Pubkey
  delegate: Pubkey     // authorized agent's key
  permissions: u8      // bitfield: can_rotate=1
  authorized_at: i64
  expires_at: i64      // delegation expiry

The delegation model solves "user must be online": User pre-authorizes a rotation agent (keypair held by ShardKeep's infrastructure or community-operated). The agent can execute rotations on schedule but CANNOT delete, lock, or transfer — only rotate. User revokes at any time.

2.5 Fee Collection CORE

Every shard operation collects a micro-fee into the program-controlled treasury PDA. Fees fund operator rewards, protocol development, and insurance.

PDA: FeeConfig

Seeds: ["fee_config"]
Fields:
  authority: Pubkey          // governance multisig
  store_fee: u64             // per shard_map store
  rotate_fee: u64            // per rotation
  operator_share_bps: u16    // % to operator reward pool
  treasury_share_bps: u16    // % to protocol
  insurance_share_bps: u16   // % to insurance pool

Fee distribution is transparent: anyone can read FeeConfig and verify where fees go. No hidden margins.

2.6 Audit Trail CORE

Every shard operation is a Solana transaction → immutable audit log by default. The program emits structured events for indexing.

AuditEvent (via Anchor emit!()):
  user: Pubkey
  operation: u8      // Store=0, Rotate=1, Delete=2, Lock=3, Unlock=4
  vault_id: u64
  timestamp: i64
  metadata_hash: [u8; 32]

Enterprise users (Fortress) can enable log_access for read-level audit trails. Individual users get it free via transaction history.

3.1 Node Registration & Staking (shardkeep_nodes) Phase 2

Operators register on-chain, stake bonds, earn based on performance. Currently tracked in MySQL — moving on-chain makes it trustless.

PDA: NodeRegistry

Seeds: ["node", operator_pubkey]
Fields:
  operator: Pubkey
  node_id: [u8; 32]
  stake_amount: u64
  status: u8          // Pending=0, Active=1, Jailed=2, Deregistered=3
  last_heartbeat: i64
  shards_held: u32
  shard_capacity: u32
  uptime_score: u16   // basis points (0-10000)
  slash_count: u8
  region: u8          // geographic region code

Slashing (enforced by program):

What operators gain: Their stake is safe from arbitrary seizure. They can verify their bond balance on-chain. They can join permissionlessly (no ShardKeep gatekeeping). New operators register, stake, and start earning — all via transactions.

3.2 Reward Distribution (shardkeep_rewards) Phase 2

Emissions distributed via Merkle tree. Off-chain indexer computes reward tree each epoch, publishes root on-chain. Operators submit Merkle proofs to claim. Program verifies and prevents double-claims.

Why Merkle? On-chain computation for thousands of operators would exceed Solana's compute limits. Merkle proofs shift computation off-chain while maintaining on-chain verifiability. Same pattern used by Jupiter, Marinade, and most major Solana protocols.

3.3 Estate / Inheritance (shardkeep_estate) Phase 3

Dead man's switch on-chain. No ShardKeep involvement required for execution.

3.4 Login with ShardKeep (Auth-as-a-Service) Phase 3

Third-party dApps verify ShardKeep identity by reading on-chain PDAs. No API call to ShardKeep required.

shardkeep_core
  ├── VaultIndex          ["vault_index", user]           per-user metadata
  ├── ShardMap            ["shard_map", user, vault_id]   encrypted shard locations
  ├── Subscription        ["subscription", user]          tier + payment state
  ├── SubscriptionEscrow  ["sub_escrow", user]            token account (USDC/SHARDKEEP)
  ├── AccessControl       ["access_control", user]        wallets, guardians, lockdown
  ├── RotationDelegate    ["rotation_delegate", user]     authorized rotation agent
  ├── FeeConfig           ["fee_config"]                  global fee parameters
  ├── Treasury            ["treasury"]                    fee collection account
  └── ProgramConfig       ["program_config"]              global config + authority

shardkeep_nodes
  ├── GlobalNodeConfig    ["node_config"]                 staking params, totals
  ├── NodeRegistry        ["node", operator]              per-operator registration
  └── NodeStakeVault      ["node_stake", operator]        staked token account

shardkeep_rewards
  ├── RewardPool          ["reward_pool"]                 emission config + pool
  ├── OperatorRewards     ["operator_rewards", operator]  accrued rewards
  └── MerkleDistributor   ["merkle_dist", epoch]          root per epoch

shardkeep_estate
  ├── EstatePlan          ["estate", user]                beneficiary + timeout
  └── EscrowedKey         ["escrowed_key", user]          encrypted master key

Per-user rent costs (at $200/SOL):

Rent is recoverable when accounts are closed. Protocol can subsidize rent from subscription fees so users never handle SOL directly.

Can ShardKeep the company disappear?

Censorship resistance

Design decision: NO blocklist, NO pause instruction, NO admin override.

The program processes any valid instruction from any wallet. There is no geographic restriction, no KYC gate, no way for ShardKeep (or anyone) to prevent a wallet from using the program. This is a deliberate and permanent design choice.

ShardKeep's client applications (browser extension, website) could theoretically geo-block users. But the program is permissionless — alternative clients, CLI tools, or direct RPC calls bypass any client-level restriction.

Upgradability path

1. Launch: Upgrade authority = 3-of-5 governance multisig (ShardKeep team)
2. Year 1: All upgrades require 7-day public timelock + verifiable builds (anchor verify)
3. Year 2: Upgrade authority transitions to SPL Governance (SHARDKEEP token holders vote)
4. Year 3+: Core program upgrade authority revoked (immutable). Extension programs remain upgradable via governance.

Progressive lockdown: ship fast early, decentralize authority as the protocol matures, lock it permanently when stable.