recoverWalletAccess
Restore access without silently changing control mode or authority.
Status
Proposed target SDK behavior for implementation. It is not an available recovery protocol or cryptographic implementation.
Business action#
Restore an owner's ability to authorize the same wallet after loss or compromise of a device or authorization factor, without importing a different wallet.
Proposed call#
recoverWalletAccess(
input: RecoverWalletAccessInput,
options?: CallOptions,
): Promise<Operation<RecoverWalletAccessResult>>
TypeScript uses requestId, walletId, recoveryBasis, newRecipientIdentity, actor, and owner proof supplied through the authorization continuation. The recovery basis is a stable string-union DTO, not free-form implicit authority.
async def recover_wallet_access(
input: RecoverWalletAccessInput,
*,
options: CallOptions | None = None,
) -> Operation[RecoverWalletAccessResult]: ...
Python uses request_id, wallet_id, recovery_basis and new_recipient_identity; enum members serialize to the shared wire value. Task cancellation after SDK dispatch requires get_operation recovery, even when backend acceptance was not observed.
RecoverWalletAccess(
ctx context.Context,
input *RecoverWalletAccessInput,
) (*Operation[RecoverWalletAccessResult], error)
Go uses RequestID, WalletID, RecoveryBasis and NewRecipientIdentity; the basis is a named string type. A context error after SDK dispatch is not proof that bindings were unchanged, even when backend acceptance was not observed.
Required input: requestId, wallet ID and current controlMode. Embedded recovery also requires basis, new owner-controlled recipient, actor and independent trusted owner proof. Server recovery requires service/admin recovery basis and configured approvers. Recovery never changes mode.
Result and effects#
Success rotates only the authorization/device/share binding, preserves the wallet signing key, wallet ID, network and address, establishes the approved new access binding, revokes or makes unusable the superseded binding according to the accepted contract, and returns the durable operation disposition. Reconstruction, re-encryption and rotation mechanics remain internal.
Same-ID/same-material replay converges; changed material conflicts. Unknown outcome uses getOperation. Account recovery is not custody recovery: email linking, recovered login or the lost factor cannot authorize embedded recovery. A backend credential cannot impersonate an embedded owner; a server wallet instead follows its explicit service recovery policy. Neither path silently changes address, mode or controlling identity class.
Authorization flow#
The SDK either uses the application handler and submits its response once or returns requiresAction for explicit continuation; it cannot do both. Proof binds recovery basis, wallet, new recipient, actor, request ID and expiry and is accumulated separately from immutable operation material. Denial, expiry or insufficient agreement preserves the old state and reports an explicit outcome.
Acceptance#
- Positive: authorized mode-preserving recovery restores the same signing key/address and a valid new embedded-owner or server-service binding.
- Negative: the lost factor alone, foreign wallet, changed recipient, replay with changed material or incomplete agreement cannot recover access;
importWalletis not used as recovery.
See importWallet and getOperation.