Add an emergency switch for authority-gated setters

[onurinanc]

The Authority component gates every setter on an account (policy setters, metadata setters, pausable manager, and more) through a single chokepoint, assert_authorized. There is currently no way to disable that entire surface in one operation. This issue proposes a global closed flag on Authority so the owner can atomically block all authority-gated procedures, an emergency switch for the account's management surface.

A common access-control pattern is the ability to freeze a contract's whole restricted surface in a single call, regardless of role membership, as an emergency measure. We have no equivalent.

Note that Pausable does not cover this: it only gates the functional execute paths (mint/burn/transfer), not the admin setters. Concretely:

So while paused, a role/owner can still rewrite the mint policy. Pause freezes value flow, it does not freeze configuration. The two are complementary, and the "freeze configuration" half is missing.

Exists:

• Authority is the single gate every setter passes through via assert_authorized.
• The value slot is [authority, 0, 0, 0]
• Owner checks are already in-module (authority.masm imports ownable2step).

Missing:

• Any way to disable all authority-gated procedures at once.

Design

We can put a flag on Authority: assert_authorized is already the chokepoint, so the check lives there with zero changes to the setters.

Storage becomes

[authority, target_closed, 0, 0]  

Runtime (authority.masm):

• At the top of assert_authorized, panic with a new ERR_AUTHORITY_CLOSED, blocking every gated procedure in all modes before any role/owner dispatch.
• Add set_target_{closed/opened}) gated directly on ownable2step::assert_sender_is_owner_internal, not routed through assert_authorized.

open flag must bypass the closed check. Otherwise, close → assert_authorized rejects everyone → open is uncallable → account permanently bricked. Gating open/close on the owner check directly guarantees the owner can always reopen.

The scope is for OwnerControlled / RbacControlled (both install Ownable2Step) as AuthControlled has no owner, so the switch is out of scope there.

[AlgofootPrint]

I’d like to take this.

I checked current origin/next and the proposed shape maps cleanly onto
the existing Authority component: extend the value slot to [authority, target_closed, 0, 0], make assert_authorized reject while closed, and
expose owner-only open/close procedures that bypass assert_authorized by
using ownable2step::assert_sender_is_owner_internal directly.

I’ll include tests showing that closed authority blocks normal authority-
gated setters, that the owner can reopen, and that non-owners cannot
toggle the switch.

Please assign this to me if that direction sounds good.

[PhilippGackstatter]

A common access-control pattern is the ability to freeze a contract's whole restricted surface in a single call, regardless of role membership, as an emergency measure. We have no equivalent.

If this restricts access to the admin procedures, and is controlled by the admin itself, then if the admin is compromised, it can close or open the API in any case, so in that case, it doesn't add additional protection. Seems like for OwnerControlled it wouldn't add protection and in RBAC, I think the same logic applies since the RBAC owner has the highest level of control, right? What other scenarios are there that this protects against?

[onurinanc]

The point of RBAC is that day to day operations are not performed by the owner, but delegated to separate parties such as MINTER, PAUSER, policy-setter, and so on. The threat model here is not the owner being compromised, but it's one of the other roles being compromised.

For example if the MINTER (also responsible for set_mint_policy) is compromised, the attacker starts rewriting the mint/burn policies through the role-gated setters. The owner is still safe. Without the switch, the owner's only options are to revoke roles one by one, or unmap procedures one by one, which is slow, error-prone, and the attacker keeps operating the whole time. If you don't know exactly which key leaked, you can't even guarantee full coverage.

The emergency switch, on the other hand, lets the owner freeze the entire role-gated surface in a single call, regardless of which role is compromised. It's the owner's kill-switch over all the authority they've delegated. So, in RBAC it definitely adds protection.

Separately, right now both set_target_closed and set_target_opened are gated on the same owner check, so whoever can close can also reopen. We can break that symmetry in a future iteration by introducing a low trust, widely-distributed guardian that can only close, while only the owner can reopen and reconfigure. With that, a compromised guardian key can at most freeze the account, it cannot reopen.

[PhilippGackstatter]

Makes sense, thanks for explaining! That sounds useful for RBAC. Integrating it into RBAC directly seems a bit cleaner to keep Authority simple, but then it wouldn't auto-integrate with every assert_authorized call. So, I suppose the proposal is better as it is.