What recovery is designed to do
RecoverAuthorityV1 rotates the authority on one existing role while keeping
that role’s identity and permissions intact.
That means recovery is for:
- replacing the signer behind a role
- preserving the role’s existing action set
- avoiding a broader authority-management rewrite
What the acting role must have
The acting role must:- authenticate successfully
- carry the
RecoveryAuthorityaction
What else recovery verifies
The recovery path also verifies a pending recovery binding before rotating the target role. That binding ties together:- the wallet
- the target
role_id - the authority type
- the old authority hash
- the new authority hash
What changes during recovery
When recovery succeeds:- the target role keeps the same
role_id - the target role keeps the same action set
- the authority bytes are rotated to the new signer
Why this is different from ManageAuthority
ManageAuthority is broader. It is for adding, removing, and updating
authorities more generally.
RecoveryAuthority is narrower by design:
- it only unlocks the dedicated recovery instruction
- it preserves the target role rather than rebuilding the role graph
- it is intended for constrained recovery policies
What this means for integrators
If your product offers recovery, the important product decision is not just “can we rotate a signer.” It is:- which role is recoverable
- who is allowed to trigger recovery
- how the pending recovery binding is created and approved

