[RFC] Guardian set design and rotation

[rosspeili]

Summary

Decide how guardian sets are represented, how they participate in cancel handoff (see Issue #___ cancel/liveness RFC), and how rotation works without becoming a silent takeover vector.

Problem

Guardians are often proposed as the party that can veto a false dormancy escalation. If rotation is instant or single-key, a compromised owner or social-engineered guardian change can capture veto rights or block legitimate handoffs without going through the same delay as the original policy commit.

This issue depends on cancel/liveness semantics (Issue #___) but can be discussed in parallel for data-model choices.

Recommended direction (open for discussion)

• Guardians are explicit in the manifest (addresses + weights or M-of-N), hashed in policyRoot.
• Cancel handoff requires guardian quorum only when the manifest enables it; owner-only cancel remains for simpler profiles.
• Rotation of guardians:
  • Preferred: changes require a delay (timelock aligned with policy commit norms) or a new policy version bump with cooling-off before new guardians can cancel.
  • Discouraged: instant replace guardian set without owner delay (abuse path).
• Events for add/remove/rotate so indexers and heirs see governance of the veto set.

Discussion welcome: guardian = multisig contract vs EOAs; institutional guardians; recovery when guardian keys are lost.

What we need to decide (discussion checklist)

• Storage model: on-chain list vs manifest-only with proofs
• Quorum for cancel vs quorum for rotation
• Whether guardians can proveLiveness on behalf of owner (usually no)
• Expiry / term limits for guardians
• Interaction with social recovery wallets (informative, not normative for v1)

What will be affected

• Cancel/liveness RFC (Issue #___)
• Policy manifest (guardians, quorum fields)
• Vault roles and events
• Trust boundaries and README “who can lie / censor” table
• UX copy for non-legal guardian responsibilities

Target end behavior

1. Users understand who can veto and on what timeline.
2. Rotating guardians is visible and delayed, not a backdoor.
3. Lost guardian keys have a documented recovery path (e.g. owner commit + timelock, or policy version).

Suggested acceptance criteria

• Rotation rules chosen (delay vs new policy version)
• Quorum rules tied to cancel handoff from Issue #___
• Event list for guardian lifecycle agreed