[RFC] Cancel, liveness, and handoff abort semantics

[rosspeili]

Summary

Before we implement dormancy, attestations, or guardian veto flows, we need a normative definition of liveness and cancel signals: what each signal means in the state machine, who may send it, and whether it resets long-horizon timers (e.g. inactivity counters) or only aborts the current handoff attempt.

This RFC captures design discussion only. Implementation (Solidity, manifest schema, behavior-matrix tests) should wait until this issue is resolved or explicitly narrowed for v1.

Problem

Delayed handoffs sit on a tension between:

• False positives — a trigger fires while the owner is still active; they need a cheap way to stop or pause payout without redeploying everything.
• Key compromise — if a stolen key can spam “cancel” and reset a multi-month dormancy clock, heirs may never complete a handoff (denial of service). If cancel is too weak, a coerced or mistaken escalation may be hard to unwind.

Today the reference material mentions a cooling-off / veto window and revocation, but does not yet distinguish:

• Proving the owner is still alive
• Aborting one escalation (trigger satisfied → cooling → execute)
• Permanently revoking a policy
• Resetting dormancy / inactivity accumulators

Without that distinction, implementers and auditors will guess—and incompatible vaults will ship under the same brand.

Recommended direction (open for discussion)

We lean toward separate signals with different side effects, rather than one overloaded “owner cancel”:

Signal (working name)	Typical actor	Intended effect
Prove liveness / heartbeat	Owner	Pauses or blocks progression toward execution for a bounded period; does not by itself void the policy or reset a long inactivity clock
Cancel handoff	Owner and/or guardian quorum (per manifest)	Aborts the current satisfied→cooling→execute attempt; returns to an armed/listening state; does not reset long-horizon dormancy unless the manifest explicitly opts in
Revoke policy	Owner	Terminal: no further execution for that policyId
Reset dormancy clock	Not exposed by default	If ever allowed, only via a high bar (e.g. new policy commitment + delay) so a briefly compromised key cannot grief indefinitely

Discussion welcome: alternative models (e.g. any cancel always requires a full timelock cycle to re-escalate) and product-specific defaults for treasury vs personal profiles (may be split in a sibling RFC).

What we need to decide (discussion checklist)

• Exact state transitions for each signal (diagram: CONFIGURED_ARMED → ELIGIBLE → COOLING → EXECUTABLE → …)
• Whether cancel handoff clears triggerSatisfied, executeAfter, or both
• Whether prove liveness extends cooling-off, clears eligibility, or only sets a “blocked until” timestamp
• Guardian powers: cancel during cooling only vs any pre-terminal state; quorum rules
• Interaction with revokePolicy (already sketched in vault API): terminal vs revocable amend
• Compromise table: stolen owner key, stolen guardian, false attestor—expected outcome for each
• v1 subset: time-only policies may ship with revokePolicy only; which rows are mandatory before B-020 (inactivity) / B-021 (attestation)?

What will be affected

• Reference spec §6 (cooling-off, recovery)
• Vault v1 state machine and function surface (proveLiveness, cancelHandoff, events)
• Policy manifest (optional fields: guardian set, cancel quorum, liveness TTL)
• Behavior matrix (new P1 rows for cancel / liveness)
• Indexer/event schema (HandoffCancelled, LivenessProved, etc.)
• Security / trust-boundary narrative for “who can freeze vs who can steal”

Target end behavior (if we adopt the recommended direction)

1. Owner can stop a false escalation without nuking months of dormancy progress.
2. A compromised hot key cannot permanently freeze inheritance by repeatedly resetting or canceling a long clock.
3. Heirs and indexers see unambiguous events explaining why execution did not proceed.
4. Auditors can read one table: signal × actor × state before × state after × clock side effects.

Out of scope for this issue

• Choice of external attestation networks (UMA, Reality.eth, etc.)
• Governor/OZ integration details
• Legal probate validity

Suggested acceptance criteria (close when)

• Normative decision recorded in a follow-up comment or linked doc PR
• State diagram + compromise table agreed by maintainers
• Behavior-matrix IDs assigned for implementation tracking
• Explicit v1 vs post-v1 split documented