The Unbreakable Governance Model PROPOSAL v2

This proposal finalizes governance decisions across two prior proposals and the Q1–I3 decision walkthrough conducted 2026-04-21.

Two Realms DAOs, one for each network

ShardKeep operates on two Solana networks. Each gets its own DAO via realms.today:

Two authority tiers within each DAO

Operations are split between individual admin actions (fast, logged) and DAO-wide council votes (slow, deliberative). This prevents both bottlenecking routine ops on council availability and letting single individuals make structural decisions.

Starting composition

At DAO genesis, the DevNet council is seeded with three human members. A 3-of-5 threshold (with 5 council seats, 3 required) accommodates losing one member without paralysis and makes seat-by-seat compromise economically infeasible.

Every node has three wallets associated with it, at different temperatures and with sharply different privileges.

Why the node_wallet is a PDA

A Program-Derived Address has no private key. There is nothing to steal, nothing to lose, nothing to transfer. The PDA's address is deterministic — computable from seeds like ["warden", operator_wallet, node_id] — so it's knowable the moment a node is registered in the ShardKeep system, before any on-chain transaction. The account is initialized on-chain at Gate 1 execution.

Once the node_wallet holds a soulbound cNFT, that credential is physically impossible to move without going through program logic. Program logic gates all such movements behind DAO proposals. An attacker who compromises the operator or manager wallets still cannot touch the cNFT. An attacker who compromises the program's upgrade authority cannot redirect a cNFT without going through a full upgrade proposal with timelock.

Wallet lifecycle and rotation

• Operator wallet rotation: Requires the current operator wallet to sign the rotation. If lost, the operator's node is exit-unbonded and a new application is required. Cold wallet loss is catastrophic by design — it forces hardware-wallet discipline.
• Manager wallet rotation: Operator wallet signs the change. Fast, common, expected. A hot wallet compromise is survivable because its only privileges are routine heartbeat attestation.
• Node wallet (PDA): Cannot be rotated — it IS the node's permanent identity. The PDA is the on-chain expression of the node itself.

Adding a new Warden or Bastion to MainNet requires passing through five gates across both networks. Council and operator community alternate as the voting body, so no single group makes all admission decisions.

Gate details

admin_airdrop_and_activate(
  operator_wallet,
  node_type,         // Warden or Bastion
  node_id,
  airdrop_amount,    // differs per node_type; Warden bond >> Bastion bond
  reason_uri         // link to the conversation that justifies this
)

vote_weight = Σ ( node_bond × sqrt(node_epochs) )
  for each Active or Probation node owned by the voter on DevNet
  where node_epochs ≥ 1

Warden track vs. Bastion track — same shape, different criteria

Both node types follow the identical 5-gate pipeline. What differs is the specific thresholds applied at each gate.

What the cNFT does

At Gate 3 passage (plus MainNet probation clearance) and at Gate 5 passage, compressed NFTs are minted as soulbound credentials — non-transferable tokens tied to a specific PDA wallet. These credentials are the public, visible proof of a graduation decision.

ShardKeep already runs a Bubblegum + Helius DAS stack (shipped in v1.1.0 for shard maps). The governance cNFTs use the same infrastructure: compressed for cost, soulbound via program policy, and updateable by the tree authority (held by the DAO treasury PDA on each network).

Bidirectional binding

The critical security property is that both chains point at each other. Neither credential stands alone — they attest to each other.

{
  node_type: "warden" | "bastion",
  devnet_node_id: "sk-abc123...",
  mainnet_wallet: <MainNet PDA address>,
  graduated_at: <slot>,
  graduation_proposal_url: "..."
}

Minted to: MainNet node_wallet PDA

{
  node_type: "warden" | "bastion",
  mainnet_node_id: "sk-xyz789...",
  devnet_wallet: <DevNet PDA address>,
  devnet_cnft_mint: <tree leaf address>,
  activated_at: <slot>,
  gate3_proposal_url: "...",
  gate5_proposal_url: "..."
}

Minted to: DevNet node_wallet PDA

Verification (anyone with a block explorer can do this in seconds)

1. Read DevNet cNFT metadata → mainnet_wallet = MW
2. Read MainNet.WardenRegistry[node] → node_wallet = MW  ✓
3. Read MainNet cNFT metadata → devnet_wallet = DW
4. Read DevNet.WardenRegistry[node] → node_wallet = DW  ✓
5. If all four match, the operator's credential is cryptographically legitimate.

Lazy mint timing (locked)

The DevNet cNFT is not minted the moment Gate 3 passes. It's minted only after the operator has:

1. Physically started their MainNet node
2. Triggered MainNet PDA initialization
3. Completed the MainNet probation period (1 epoch bonded + current+1 epoch operating)

This way the cNFT always points at a MainNet PDA that already exists — no ghost addresses, no pre-minted credentials that might never correspond to real infrastructure.

Immutability and revocation

Soulbound cNFTs cannot be transferred by any wallet, including the PDA that holds them. Only the tree authority (DAO treasury PDA on each network) can revoke them, and doing so requires a passed governance proposal on that network.

This means: an attacker who compromises an operator's wallets cannot touch the credential. An attacker who compromises the program's upgrade authority cannot instantly revoke credentials — upgrades require a proposal with timelock. The upper bound on attacker power is "compromise a council majority" — below that, the credential is effectively immortal.

The core formula

operator_vote_weight = Σ ( node_bond_i × sqrt(node_epochs_i) )
  for each node_i owned by operator_wallet where:
    - node status is Active or Probation
    - node has been bonded for ≥ 1 full epoch (node_epochs_i ≥ 1)

Why each term

What the sqrt curve produces

What bonds do NOT count

• Bonds on nodes with status Pending, Dormant, Paused, Slashed, Exited — zero weight
• Bonds with less than 1 epoch of locked time — zero weight (prevents airdrop-and-vote-same-day)
• SHRD held in an operator's spendable wallet, not bonded — zero weight

Per-gate thresholds summary

Recusal

No enforced recusal at the program level. Bastion-to-Warden pairing is proximity-driven (Bastions select their nearest Warden automatically) rather than politically negotiated, so there is no built-in conflict of interest between a Warden and "its" Bastions. Operators who believe they have a conflict may voluntarily mark themselves recused; their weight is subtracted from the participation floor denominator.

Public vote visibility on a small operator set means conflicts are observable and reputationally costly.

Slashing is program-enforced, not DAO-voted

Slashing rules are defined in tokenomics-v3.2. The shardkeep_authority program enforces them automatically based on cryptographic or observable evidence. Council does not vote on individual slashing decisions.

How slashing actually happens

• Cryptographic triggers. Anyone can submit evidence (tx hash, signature, message) via report_misbehavior(node_id, evidence). Program verifies cryptographically; if valid, program executes slash atomically. No vote.
• Observable triggers. Program tracks uptime, missed challenges, failed proofs. At epoch boundaries, program applies slashes per the tokenomics-v3.2 schedule. No vote.
• Duress-linked triggers. When a canary-phrase duress event is confirmed and a coercer continues into non-admin planes, record_duress_ack produces on-chain evidence that can trigger slashing of the compromised wallet.
• Security Council outcomes. If a node is paused by the Security Council and subsequently exonerated, the false-flag slashing applies to the flagger and confirmer per tokenomics-v3.2 rules.

Slash severity → tenure impact

The permanent criminal record

Every slashing event, regardless of severity, creates a permanent entry in the node's on-chain slash_history: Vec<SlashEvent>. This history is:

• Public and immutable. Never pruned, never removed, even after tenure is rebuilt.
• Displayed prominently on Gate 2 vouching proposals and Gate 4 community votes for the operator.
• Visible to any observer. Block explorers, operator dashboards, admin UI — the record follows the node identity for its entire existence.

SlashEvent {
  timestamp:     i64,
  severity:      enum { Small, Medium, Large },
  reason_code:   u16,        // maps to tokenomics-v3.2 schedule
  amount:        u64,
  tenure_impact: enum { None, Halved, Reset },
  evidence_uri:  String,     // on-chain tx hash or off-chain memo
}

What slashing does NOT do

• Slashing never requires a DAO vote. It is a program-enforced consequence.
• Slashing does not revoke the node's on-chain cNFT automatically — the cNFT stays with its slash_history attached, serving as permanent record. Only a council vote can revoke credentials (e.g., for major malice warranting full excommunication).
• Slashing does not auto-trigger from uptime alone below the defined thresholds. ISP outages, hardware failures, and other no-fault interruptions drop a node to Probation or Dormant, not slashed.

The two-operator pause mechanism

The Security Council is not a body of named individuals — it's a mechanism. Any two operators in good standing can, acting independently, pause another operator's node when they observe concerning behavior. Pauses are time-limited and require council review if they exceed 72 hours.

Anti-abuse provisions

• False flagging is slashable. A flag that reaches Step 2 and is subsequently exonerated triggers program-enforced slashing on the flagger, and possibly the confirmer. Frivolous flagging has real financial cost.
• Per-operator rate limits. Each operator can have at most one active self-initiated flag at a time. A single compromised operator wallet can't cascade-pause the network.
• No self-confirm. Step 1 and Step 2 signers must be different operator wallets. One person controlling two wallets still can't pause alone, because the program records both signers and operator wallets are public.
• No retaliation flags. An operator with an active unresolved flag of their own cannot file or confirm flags on others. Prevents counter-flag retaliation during disputes.

DNS is ShardKeep-administered, not operator-controlled

DNS records for Warden domains (master.shardkeep.io, and future regional names like tokyo.shardkeep.io, frankfurt.shardkeep.io) are controlled by ShardKeep admins. This is a deliberate choice:

• Admins provide geographic coordination across timezones
• DNS propagation (24-48h) is a centralized logistics problem that doesn't belong in per-operator workflows
• GeoDNS routing is a convenience layer; per the role-separation-v1 guidance, DNS is "not trust-bearing — the on-chain registry is the trust root. DNS compromise = availability bug only."

What operators DO change: their server IP

Emergency IP changes

If an operator's hosting provider pulls the plug or their server is compromised, the normal "future epoch" announcement isn't fast enough. In those cases:

1. Any operator files a Security Council flag (Step 1 of §8)
2. A second operator confirms, pausing the node
3. During the 72h pause window, admins coordinate with the operator and update DNS to the new IP
4. Council reviews and lifts the pause once infrastructure is verified
5. Node resumes service on the new IP

This way, emergencies route through the same oversight mechanism that handles security concerns — no unilateral admin action to enable an IP change during a suspected compromise.

The real root of trust

Whoever holds the upgrade_authority on the shardkeep_authority program can replace the program with any new version — including a version that redefines "valid Warden" to mean whatever they choose. This is more powerful than the council multisig itself.

Three-phase authority transfer

What it takes to upgrade after transfer

1. Developer writes the new program version
2. Community proposal opened on MainNet DAO with the new program buffer hash
3. Community vote (bond-weighted per §6) with supermajority threshold
4. Council confirmation vote
5. On passage, program upgrade executes; timelock of 72 hours before new program becomes active
6. During the 72h timelock, anyone can spot a malicious upgrade and raise an alarm

Program upgrade as a Tier-4 operation

Per §11 (operation tiering), program upgrades are community + council (Tier 4), matching MainNet economic parameter changes. Routine state transitions (registry reads, heartbeat records, reward distributions) never touch upgrade authority at all.

Why sequencing matters

If the ShardKeep extension shipped with "enforce on-chain registry" enabled before the WardenRegistry had any entries, every user would be instantly locked out. Today's heartbeat outage on a single URL change hints at the scale of that risk if applied network-wide. The rollout plan below avoids that class of failure.

Phased deployment

Graceful degradation — the signed cache

Every successful registry read by the extension produces a locally-cached, signed snapshot. The signature is from any registered Warden's node key, covering (registry_snapshot, timestamp). If the live registry read fails (program bug, RPC outage, Solana outage), the extension falls back to the cache — as long as the cache is < 7 days old.

Beyond 7 days without a successful live read, the extension surfaces an error to the user with a "proceed with manual risk acknowledgement" button. Fail-closed on the default, but provide a recovery path for prolonged outages.

Extension-side hardening

• No-frame embedding. The extension's sign-hook refuses all framed contexts. If window !== window.top, refuse to sign. Prevents iframe-based phishing.
• Program ID cross-check. Extension reads program ID from both its hardcoded constant AND a signed response from a registered Warden's version-check.php. Mismatch → refuse + alert user.
• RPC quorum. Query 3 independent Solana RPCs. If they disagree about registry contents, alert rather than trust either.
• SPKI pinning with --reuse-key. All Wardens run certbot renew --reuse-key so TLS cert renewals don't change the SPKI fingerprint. Extension pins SPKI, not cert; renewals become silent; real MITM still trips the alarm.
• Reproducible builds. Source public, build reproducible, anyone can verify the shipped .zip matches the source tag.
• Code-signed agent updates. Python bastion/warden agent verifies signature on update payloads before applying. Signed by a release key held by the DAO treasury PDA — not an individual admin.

Who's grandfathered

Grandfather terms

• Auto-admitted to both DevNet and MainNet WardenRegistry / BastionRegistry at DAO genesis. No 5-gate pipeline for these nodes. They earned their position by bootstrapping the network before the DAO existed.
• Tenure honored from first_seen in the existing shardkeep_nodes table. Early operators are not punished for pre-DAO service — their real operational history counts.
• Bonds retroactively staked at grandfather amounts per tokenomics-v3.2.
• No grandfather for Sentries. Sentries are ephemeral browser participants, not infrastructure commitments. They remain opt-in via the wallet extension as they are today.

Operator #2 and beyond go through the full pipeline

Any Warden operator beyond the grandfathered one, and any Bastion operator beyond the grandfathered twelve, passes through all 5 gates. No exceptions. The grandfather clause is a one-time genesis provision.

This proposal deliberately does not address:

• Bond amounts and reward rates. Those live in tokenomics-v3.2. This proposal says "per tokenomics-v3.2" wherever a numeric bond or slash amount is needed.
• User vault mechanics (shard map, rotation, beneficiaries). Those live in on-chain-shard-map-v3.
• Reward distribution logic. Program-enforced per epoch based on registry state; mechanics defined in tokenomics-v3.2.
• SHRD-holder voting as a governance chamber. Deferred to a future bicameral proposal (v2.5+ or v3). v2 is pure operator governance.
• Sentry admission or slashing. Sentries are opt-in user participation, not infrastructure commitments. They remain outside the DAO.
• Admin set expansion beyond 3 humans. Initial admins are the three named seats. Adding more admins is a Tier-3 council operation once v2 is live.
• Multi-chain deployment beyond Solana DevNet + MainNet. Explicitly scoped to these two networks. Other chains are future work.

Every design decision resolved during the Q1–I3 walkthrough on 2026-04-21, with the final disposition.