The recovery backend coordinates verification, approval on NEAR, signing, and sending the transaction without holding an approval key.
1
Open the casebefore anything reaches NEAR
Save it firstThe case is written down before anything is sent, so a crash cannot lose the request.
Early checksNo recovery policy, or a mismatched address, ends the case here.
2
Create the proofthe server holds this key alone
Sign the requestOnce verification succeeds, the server signs proof that the request came through the approved flow.
Cannot approveThe server has no watcher key, so it can open a case but cannot approve its own request.
3
Send the requestthe timelock starts
request_recoveryAccount, new owner, attempt number, and proof. The contract checks the proof against the approved key.
New attempt numberAn older request becomes invalid when a new one starts. The owner is notified and can stop it.
4
Collect approvalsfrom independent services
Independent approvalEach watcher approves this account, destination, attempt, and decision.
submit_verdictBlocked until the timelock ends. Enough valid approvals are required.
Cancellation is finalA cancellation returns the account to idle. Nothing continues after a refusal.
5
Finish the recoverya signature, never a stored key
finalize_recoveryMoves the account to resolving and asks the signer for a transaction signature.
MPC signs AddKeyWith a key created specifically for this account, so accounts never share one.
Can be retriedA failed signature returns the case to approved instead of getting stuck.
6
Send and closeconfirm, then let the owner claim it
Send to NEARThe signed transaction is sent and confirmed before the case is closed.
Check before retryingIf delivery is uncertain, the system checks NEAR instead of sending the transaction again.
The House of Stake (HoS) serviceData / recordContractWallet / keyRecoveryInfrastructure
The case is saved before anything is sent to NEAR.
After verification succeeds, the server signs a proof attached to the request.
The server calls request_recovery with the account, new owner, current attempt number, and proof. The attempt number increases and the timelock starts.
The server collects approvals from independent watcher services until enough have signed, then submits them.
The contract asks the MPC network to sign the AddKey transaction. The server sends that transaction to NEAR and confirms it arrived before closing the case.
A case moves through AwaitingVerification, AwaitingClaim, Verified, Requested, Approved, Finalizing, Broadcast, and Claimed. It can also end as Aborted or Failed, with the reason recorded. If delivery is uncertain, the system checks NEAR before trying anything again.
The contract tracks four states for each account: Idle, Requested, Approved, and Resolving. A request moves an idle account to Requested and increases the attempt number. An approval moves it to Approved once the timelock has ended and enough watchers have agreed; a cancellation returns it to Idle. Finalization moves it to Resolving and asks the signer for a key created specifically for that account, so accounts never share one. The owner claims the completed recovery only after the transaction arrives, which returns the account to Idle. A marketplace transfer removes the recovery policy and preserves the latest attempt number.