Contract 0eb4038ea129be586d5b324c62c672c8203547b61146f17452693e587a9f92d8

Permissionless TTL maintenance for named, already-existing guardians and requests — extending TTL creates no authority (§16.1). Also covers any pending threshold change and any pending removal for the given guardians: those are only bumped otherwise at propose_* time, so a proposal left unapplied long enough after its delay elapses could archive before apply_* is ever called, silently losing an already-authorized governance action rather than just delaying it (independent security review finding). bump_ttl no-ops on keys that don't exist, so calling this with no pending changes is safe. Initialized/Admin/GuardianThreshold/PendingGuardianThreshold live in instance storage (one shared TTL, refreshed automatically by ensure_initialized on every call that reaches it), so a single extend_ttl call below covers all of them together.

Registers a guardian. The guardian is recorded immediately (is_guardian reflects it right away), but its approval does not count toward any threshold until GUARDIAN_ACTIVATION_DELAY_LEDGERS have passed — see the constant's doc comment for why. Removing a guardian, unlike adding one, is itself timelocked — see propose_remove_guardian.

Opens a recovery request. Callable by admin/owner or by any currently-active guardian — this is a deliberate fix, not the original design: requiring the admin's own authorization to open a recovery request means recovery is unusable in exactly the scenario it exists for (the owner's key is lost or destroyed, not merely "compromised but still controllable by its holder"). A guardian who suspects the owner is compromised, or who is trying to help an owner who has genuinely lost access, can start the process unassisted; approve_recovery's threshold and finalize_recovery's timelock are what actually gate the outcome, not who was allowed to open the request.

replacement_signers/replacement_policies must describe a satisfiable context rule (at least one signer or one policy) — see RecoveryRequest's doc comment for why recovery needs to carry this at all, not just replacement_owner. Rejected fast, here, if replacement_signers is empty, rather than letting a genuinely unsatisfiable recovery r

Recomputes, from current guardian registrations, how many of this request's historical approvers are still valid right now. This is the number finalize_recovery actually checks against the threshold — never the raw approvers.len().

Permissionless view of the current freeze epoch — see request_guardian_freeze's doc comment for why this is a monotonic counter rather than a consumable flag. smart_account:: apply_guardian_freeze compares this against the last epoch it applied to decide whether there is a genuinely new, not-yet-applied freeze request.

Applies a pending guardian removal once its delay has elapsed. Permissionless: the authorization decision (the admin proposing this specific removal) already happened, so when an already-authorized removal lands needs no further gate. Does not touch any open request's stored approvers list — that history is preserved as an audit trail — but the removed guardian's past approval stops counting toward live_approval_count / finalize_recovery from this point on, because both recompute against current guardian registration rather than trusting the historical approval.

Applies a pending guardian threshold change once its delay has elapsed. Permissionless: the authorization decision (the admin proposing this specific change) already happened, so when an already-authorized change lands needs no further gate. Doesn't call ensure_initialized (there is nothing to permission-check), so it explicitly extends the instance TTL itself on this write, the same way smart_account::apply_adapter_change does for its own instance-storage write.

Cancels a pending guardian removal before it takes effect. Admin-gated, letting a legitimate admin walk back an erroneous or no-longer-wanted proposal before its delay elapses.

Cancels a pending guardian threshold change before it takes effect. Admin-gated, letting a legitimate admin walk back an erroneous or no-longer-wanted proposal before its delay elapses.

Proposes removing a guardian. Does not take effect immediately — see apply_guardian_removal. The guardian remains fully active (still counted by is_guardian, live_approval_count, and able to approve requests or request a freeze) until the proposal is applied. Independent security review finding: immediate removal under single-admin control meant a compromised admin could dismantle the guardian set with no delay for anyone to notice.

Real gap this session found: docs/TECHNICAL_ARCHITECTURE.md §12.7 documents the canonical recovery workflow as starting with "Guardian ... triggers freeze" — but smart_account::freeze() was owner-only, with no guardian-facing path at all. A single active guardian requesting freeze is enough to raise the flag (unlike recovery itself, which needs quorum + timelock to replace authority, stopping active bleeding while recovery is still pending doesn't need the same bar — the worst case is an unnecessary pause, not a loss of funds or authority). smart_account::apply_guardian_freeze pulls this epoch the same way apply_recovery pulls a finalized request: permissionlessly, and this contract has no knowledge of, or dependency on, the treasury that pulls it.

Stores a monotonically increasing epoch rather than a boolean flag. Security review finding on an earlier revision of this function: a plain bool, consumed (cleared) by a permissionless consume_guardian_freeze_request call, let any third party

Proposes a new guardian threshold. Does not take effect immediately — see apply_threshold_change. Once applied, it takes effect for any request not yet finalized: finalize_recovery always reads the threshold fresh rather than the value in effect when the request was opened or approved.