Role Separation Decisions — Addendum v1 ADDENDUM

Decisions on the four open questions from Role Separation & Warden-Based Auth v1, plus new design for canary-phrase duress lockdown and permissionless Warden admission. — April 18, 2026

1. Decisions on Open Questions #1 & #2

2. Canary Phrase — Duress Lockdown Design

Decision on Open #3: Yes to secondary admin password and canary phrase for duress scenarios. Here is the full design.

2.1 Registration

• Each admin registers two distinct phrases: a real password and a canary phrase.
• Both stored as separate argon2id hashes in admin_credentials.
• Registration-time validation rejects canaries that are within edit-distance 3 of the real password, eliminating "I accidentally typed the canary" incidents.
• Canary phrase is displayed once during registration, with a warning:
  "Memorize this. If you are ever coerced into logging in, type this instead of your real password."
• Minimum canary length enforced at 16 characters; recommend a passphrase rather than a password.

2.2 Runtime flow

2.3 The duress session behaves like this

• UI is indistinguishable from a real admin session. The attacker sees treasury balances, network stats, the usual navigation.
• All write operations silently no-op — they return HTTP 200 with fabricated success messages. Nothing actually mutates.
• All read operations return sanitized or frozen-in-time data. Sensitive values (bond amounts, private node keys, operator contact info) are replaced with plausible-looking placeholders.
• Every page visit and every attempted write is logged to duress_audit with timestamp, IP, user-agent, wallet, pathname. Evidence for post-incident review.

2.4 Alert channel

On canary match, a silent alert is triggered out-of-band:

• Discord DM (via the existing discord-bot service) to the other admin and an operator security channel.
• Email via the alerts-service.
• SMS via a pre-registered phone number (optional; requires Twilio or similar — design it now, wire it during implementation).
• Alert payload includes timestamp, source IP, wallet, user-agent, and which pages were visited during the duress session.

2.5 Unlock

• The other admin (the one not under duress) must sign an on-chain lift_duress(wallet) instruction on AdminRegistry.
• Requires: the other admin's wallet signature + their admin password (not canary) + confirming they spoke to the duressed admin via an out-of-band channel.
• 24-hour cooldown before the lifted admin can issue new write operations. This creates a forced "sleep on it, re-verify" window.

2.6 Edge case: both admins coerced simultaneously

2.7 On-chain additions

The AdminRegistry PDA gets a duress_state field per admin entry:

AdminEntry {
  wallet:         Pubkey,
  added_at:       i64,
  duress_locked:  bool,           // NEW
  duress_since:   Option<i64>,    // NEW
  duress_reason:  Option<String>, // NEW (free-form reason from unlock record)
}

New instructions:

• flag_duress(wallet) — signed by the Warden that detected the canary match. Sets duress_locked = true.
• lift_duress(wallet, reason) — signed by another admin + admin-password check. Clears the flag; records the reason.
• time_locked_recovery_lift(wallet) — signed by the recovery wallet; requires 7-day on-chain delay; clears all duress flags. v2.0.

3. Permissionless MainNet Warden Admission

Decision on Open #4: Yes, and the model is stronger than the base proposal described. DevNet tenure + community engagement + operator vote. Detailed design follows; scoping note at the bottom.

3.1 The pipeline

3.2 What gets tracked for "community engagement"

Most DePIN projects score only technical performance. Adding social contribution as a gate is the novel part, and it aligns well with the Bastion-network trust model.

3.3 Voting mechanics (rough shape)

• Quorum: 60% of existing MainNet Wardens must participate for the vote to count.
• Threshold: 2/3 of votes cast must be Yes.
• Admin veto: retained in the early network (≤20 MainNet Wardens). Phased out by governance proposal as the operator pool grows.
• Votes are on-chain with a short reason string (max 280 chars). Public, transparent, auditable.
• Failed applications can re-apply after 30 days with updated engagement evidence.

3.4 OperatorProfile PDA

A new on-chain object tracks operator identity and peer relationships:

OperatorProfile {
  operator_wallet:    Pubkey,
  handle:             String,           // Self-chosen display name
  devnet_nodes:       Vec<Pubkey>,      // Nodes this operator runs on DevNet
  mainnet_nodes:      Vec<Pubkey>,      // Nodes on MainNet
  vouches_received:   Vec<Vouch>,       // Who vouches for this operator
  vouches_given:      Vec<Vouch>,       // Who this operator vouches for
  first_seen:         i64,
  last_active:        i64,               // Updated by any on-chain op they sign
  metadata_uri:       Option<String>,   // Off-chain profile (bio, socials)
}

Vouch {
  voucher:            Pubkey,
  vouchee:            Pubkey,
  reason:             String,            // Max 280 chars
  signed_at:          i64,
  revoked:            bool,
}

3.5 Scope & sequencing

The base proposal's §9 will be updated: "permissionless in v2" becomes "admin-approved in v1.2 and v2.0; permissionless operator-voted admission in a dedicated follow-on proposal (v2.2+)."

4. Domain Name Flexibility

The concern: "I do NOT want to use the current domain name for the WardenRegistry. If this is permanent from the first step, we cannot do it until the domains are secured."

• WardenEntry.public_url is mutable via update_url(manager_wallet). Changing a Warden's domain is a normal on-chain operation, not a program redeploy.
• For DevNet (where we iterate freely), we seed Warden #1 with whatever URL is most convenient — placeholder, temporary subdomain, even localhost:8443 for local dev. We change it freely with signed update_url ops.
• For MainNet launch, the permanent domain(s) are secured first, then Warden #1 is registered with the real URL from the start.
• Clients cache the URL and invalidate on registry refresh (≤ 5 minutes), so URL changes propagate naturally.

4.1 Small addition

I'll include a convenience url_history field (last N URLs) stored in the entry or emitted as program logs, so clients can display "this Warden was previously at X" — helpful during operator migrations and for debugging cache invalidation issues.

5. Proposal Update Plan

On your approval of this addendum, I will revise the base proposal (proposal-role-separation-v1.html) with the following edits:

6. Resolutions to Questions A and B

6.1 Canary lockdown scope RESOLVED

Decision: Admin plane fully locked, and every other plane that wallet has access to shows a warning requiring network-acknowledgment before continuing.

Neither of my two earlier options was right. The correct shape is a two-tier response:

What "network acknowledge" means

On click of the acknowledgment button in a warned plane:

1. The wallet signs a canonical message: "SHARDKEEP_DURESS_ACK: plane=<plane> ts=<timestamp> session=<session_id>"
2. The signature is posted to an on-chain audit log (or, for frequent-access planes like User, buffered and batched every N minutes to avoid gas thrash).
3. Every other Warden sees the ack via registry sync and mirrors it to local audit logs.
4. The banner persists throughout the session — "I acknowledged" doesn't hide the fact that the wallet is under duress.
5. Acks are visible in the admin plane for the other (non-duressed) admin's investigation.

On-chain additions (updates to §2.7 of this addendum)

New instruction on AdminRegistry:

record_duress_ack(wallet, plane, session_id, timestamp, signature)
  — Appended to on-chain audit log
  — Signed by the wallet itself (proves the user clicked acknowledge)
  — Rate-limited: one ack per (wallet, plane, session_id) per hour

New read accessor for display:

get_duress_acks(wallet, since_timestamp)
  — Returns list of plane + timestamp tuples
  — Used by the non-duressed admin's investigation UI

6.2 DevNet bond & admission model RESOLVED

Decision: DevNet has a complete admin-gated admission model — stronger than any of my three original options.

The actual mechanism already in place (or planned):

• DevNet has its own DevNet-SHRD token.
• There is no faucet. The only way to obtain DevNet-SHRD is via admin-performed airdrop.
• To run a DevNet node, an operator must contact admins out-of-band (Discord, email, etc.) and request an airdrop to their operator wallet.
• Admins review the request, airdrop DevNet-SHRD, and approve the node registration.
• Only then can the operator bond and activate their DevNet Warden/Bastion/Sentry.

Implementation implications

• New admin instruction: airdrop_devnet_tokens(operator_wallet, amount, reason_uri) — admin multisig signature, records the airdrop with reason.
• New tracking table (shardkeep_devnet_airdrops): timestamp, admin who signed, operator wallet, amount, reason, planned node type. This is the substrate the later voted-admission proposal (v2.2+) reads from to surface "operator X was airdropped for what purpose, by which admin."
• DevNet and MainNet use the same on-chain programs, distinguished by cluster. DevNet-SHRD is a distinct token mint from MainNet SHRD.
• No DevNet faucet, ever. Admins are the sole source of DevNet-SHRD. This is a deliberate network gate, not an implementation stopgap.

Consequence for the voted-admission pipeline (v2.2+)

Because every DevNet operator has been admin-vetted at entry, the community-engagement portion of the voted admission is already partially answered. The voted-admission proposal simplifies to:

• "Has this DevNet operator maintained their DevNet node with good uptime for 30+ days?" — pure on-chain metric.
• "Have existing MainNet Wardens had productive interactions with this operator?" — subjective, weighted by peer vouches.
• The "is this operator a Sybil?" question is already resolved at the DevNet-airdrop gate.

This materially reduces the complexity of the v2.2+ admission proposal. I'll note this in its follow-on scope.

7. What Happens Next

1. You review this revised addendum (§6.1 canary warning design, §6.2 DevNet admin-gate model).
2. On approval, I revise proposal-role-separation-v1.html per the edit plan in §5, incorporating:
   • §3 — Sentry as extension-toggle (not exception)
   • §6 AdminRegistry — duress fields + instructions + record_duress_ack
   • §6 WardenRegistry — mutable public_url + url_history
   • §7 Impersonation — add Duress Alert Channel subsection
   • §9 Tracks — defer permissionless admission to v2.2+
   • §10 Open decisions — mark all 4 resolved
   • §11 Risks — both-admins-coerced with time-locked recovery
   • New §14 — Follow-on work (voted admission, time-locked recovery wallet)
   • New entry: DevNet admin-airdrop gate model as a first-class architectural feature
3. I create the progress log at /shardkeep/proposals/logs/v1.2.0-role-separation.log.
4. On final approval of the integrated proposal, Track 1 implementation begins (off-chain role plumbing + wallet class distinctions + duress-ack helper).

Proposed: April 18, 2026 · Status: All open questions resolved — awaiting approval to revise base proposal