中文版 · Blockchain learning guide · Previous article
Blockchain learning · Article BC062
A wallet screen does not reveal the whole control arrangement. The person using the interface may hold the signing authority, depend on a service that holds it, or participate in a policy requiring several authorities. Recovery and administrative paths can change that picture again.
To understand custody in technical terms, ask who can authorise an action, who can prevent it, who can restore or replace authority, and which evidence proves the requested result happened. A product label is less informative than answers to those questions.
This lesson compares three fictional ways to control a catalogue account. It contains no real keys, asset transfers, wallet setup, service recommendations or financial decisions. Its purpose is to make control dependencies visible before discussing recovery in more detail.
Choose your reading route
In this guide
- 1. Separate the interface from the authority
- 2. Give the comparison one harmless task
- 3. Ask five questions for each arrangement
- 4. Arrangement A: user-held ordinary authority
- 5. Arrangement B: service-controlled authority
- 6. Arrangement C: shared ordinary action with a recovery path
- 7. Compare the same interruption across all three cards
- 8. Check policy change and alternative execution routes
- 9. Separate ability to block from ability to act
- 10. Require evidence at the actual completion boundary
- 11. Build a short control record
- 12. Exercises and worked answers
- Sources and next reading
Sections 1–3 separate interfaces, accounts and authority. Sections 4–6 compare user-controlled, service-controlled and shared-policy arrangements. Sections 7–10 test outages, recovery, alternative execution paths and completion evidence. The exercises ask who can do what under the exact supplied rules.
The earlier keys lesson explains signing mechanisms, and the shared-control lesson compares multisignature and threshold designs. Here the learning job is the responsibility map around those mechanisms: control, blocking power, recovery and policy change.
Back to contents · Next section
1. Separate the interface from the authority
A wallet interface can prepare requests, show account information and communicate with signing or network services. Those functions do not tell us where the authority needed for the account’s actions resides.
Ethereum’s wallet introduction describes a wallet as a tool for interacting with an account. We use that interface distinction only; its broad consumer descriptions should not replace inspection of a particular product’s control and recovery arrangements. The page was updated on 24 February 2026. Ethereum wallets
The application shown on a phone might access a user-controlled signer, send an instruction to a service, or collect approvals for a programmable account. Similar-looking buttons can therefore initiate very different authority paths.
An address identifies an account or destination within its network context. Knowing the address or viewing its history does not establish the ability to authorise its next action. Likewise, logging into a website is not automatically possession of the authority that the chain recognises.
Begin with an operational question: if this interface disappeared, what independently available capability would still let an authorised action satisfy the account’s rules? Do not assume the answer from the interface’s name.
Back to contents · Next section
2. Give the comparison one harmless task
Our fictional catalogue account may request an update to one public label. All three arrangements use a correctly specified application operation. The chain, application and required submission resources are available unless a case explicitly says otherwise.
We assume signatures, policy checks and request-context binding work correctly. No case depends on cryptographic forgery. We also assume the requested update meets the application’s ordinary validity conditions, so we can focus on who can authorise it.
“Can act” below means can satisfy the arrangement’s authorisation condition. It does not guarantee immediate inclusion, successful execution under every possible later state or finality. Those remain separate stages.
The fictional participants are user U, service S and recovery authority G. Letters identify roles, not real people or providers. When two roles must cooperate, their independent control is a stated assumption to inspect, not a fact created merely by giving them different names.
We will distinguish technical capability from organisational permission. A party may technically be able to authorise an action while a policy says it should not. The technical map alone cannot establish legal entitlement, contractual performance or a reader’s rights.
Back to contents · Next section
3. Ask five questions for each arrangement
First, who can satisfy the ordinary authorisation rule? Second, who can withhold a necessary contribution and block that route? Third, what recovery capability is already configured? Fourth, who can change the participants or policy? Fifth, what evidence demonstrates a completed instruction?
These questions should be answered for all enabled paths, not just the one used on a normal day. A recovery route is part of the control system. So is an administrative function that can replace an authorised party.
The answer may be a person, organisation, device, contract rule or combination. Be precise about which layer makes the decision. A customer-support representative might restore a service login without possessing any independent ability to reconstruct a user-held signing key.
Conversely, a service may control the recognised signing authority even though the interface describes the account as belonging to the user. The relationship may involve service obligations, but those obligations are separate from the chain’s authorisation check.
The comparison is not a ranking from best to worst. Different arrangements move responsibility and failure modes between participants. A useful evaluation identifies those changes rather than hiding them behind a single custody label.
Back to contents · Next section
4. Arrangement A: user-held ordinary authority
In arrangement A, U alone controls the signing authority required for the catalogue account’s ordinary action. The interface vendor and service S do not hold a signing copy or another authorisation route. There is no separately configured recovery or policy-replacement authority in this baseline card.
Under those assumptions, U can authorise the update without S’s approval. S cannot veto the account’s authorisation rule simply by refusing to approve, because its approval is not part of that rule.
However, the user may still depend on an interface or RPC provider to prepare and deliver a request. In the particular outage case below, a correctly functioning alternative interface and submission path are explicitly available to U. That availability is an additional fact, not something the words “user-held” automatically guarantee.
If U loses every usable copy of the required signing material and no alternate recovery rule exists, the card provides no remaining authorisation capability. A help desk that only restores a website login cannot manufacture the missing signing authority.
This does not prescribe a backup method or claim all user-controlled systems have the same recovery design. It identifies the consequence of this card’s deliberately limited arrangement. The next lesson examines different loss and recovery cases separately.
Back to contents · Next section
5. Arrangement B: service-controlled authority
In arrangement B, S controls the chain-recognised signing authority. U has a login to S’s service and can send it instructions, but U has no independent signing material or on-chain authorisation path for this account.
An ordinary workflow may require U to approve an instruction in the service interface. That can be an important organisational safeguard. In this card, however, the chain checks S’s authority; it does not separately verify U’s service login approval.
S can therefore technically authorise the catalogue update, and U cannot independently authorise it merely by knowing the account address or service password. S can also block the ordinary workflow by withholding its action.
If U loses the service login, S may restore that login under its stated account-recovery procedure. This changes access to the service; it does not change the basic fact that S controls the chain authority. The card does not promise how quickly or under what evidence a real provider would restore access.
A service receipt saying “instruction received” is evidence at the instruction boundary. It is not yet evidence that S signed, that a transaction was included or that the catalogue label changed. Preserve the stage even when the interface uses one simple status word.
Back to contents · Next section
6. Arrangement C: shared ordinary action with a recovery path
In arrangement C, ordinary action requires both U and S under a correctly enforced policy. Neither party alone can authorise an ordinary catalogue update. We do not specify whether the implementation uses separate signatures or another mechanism; the supplied access rule is what matters here.
The account also has a preconfigured recovery route. G and S together can approve replacement of U’s authorisation slot after a stated delay and the route’s other required conditions. Call its specified delay D; D is an invented policy parameter, not a universal duration. This route cannot replace S, change the ordinary two-party requirement or alter unrelated policy. No additional hidden route is supplied.
That recovery path can restore a user slot when U’s old authority is lost, provided G and S cooperate and all conditions are met. It does not reconstruct the old secret. It changes which authority occupies the user slot under the existing rules.
The same capability means that G and S together could replace the original U even if that original user objects, assuming they satisfy the supplied recovery conditions. After replacement, the new user-slot authority and S can satisfy the ordinary rule. That is a technical capability, not a statement that such use is organisationally permitted.
S is required for both ordinary action and recovery in this card. Its refusal or unavailability therefore blocks both routes. G alone cannot perform an ordinary update or replace U. These consequences are easy to miss if the account is described only as “the user must sign”.
Back to contents · Next section
7. Compare the same interruption across all three cards
Suppose S becomes unavailable while the chain and the explicitly supplied alternative tools remain available. In A, U can still satisfy the authorisation condition because S is not required. In B, U lacks the recognised signing authority and cannot bypass S. In C, S is required for both ordinary action and the recovery route, so those routes cannot complete.
Now suppose only the interface vendor’s website is unavailable. For A, the supplied alternative interface and submission path let U continue. For B, a replacement display alone does not give U S’s signing authority. For C, a replacement interface still needs the required participants and policy execution path.
Finally, suppose U loses the ordinary signing capability in the arrangements where U has one. In A’s baseline, no alternate authority is supplied. In C, the configured G-and-S recovery route may replace the user slot after its conditions are met. In B, U did not hold the chain key in the first place; loss of the service login is a different problem.
These are comparisons of capability, not guarantees of successful delivery. The alternative path, cooperation and policy conditions must be real and available. An architecture diagram cannot supply a capability that was never configured.
Back to contents · Next section
8. Check policy change and alternative execution routes
Shared control is incomplete as a description unless it includes how the sharing rule can change. If one administrator can silently reduce a required approval set, that administrator has authority beyond the ordinary signing path.
Our C card deliberately fixes the recovery route’s scope: it replaces U’s slot only and still needs G and S. A different card permitting G alone to change every rule would have a different control map. Do not merge the two merely because both use the word recovery.
Safe’s documentation provides a concrete example of why enabled paths matter. It describes owner-threshold execution as well as modules that can use alternative access patterns. Its module documentation warns that modules are security-critical and may execute transactions with extensive authority. Those facts require inspecting the actual configuration; they do not imply every Safe has the same module or recovery powers. Safe account overview, Safe modules
Likewise, a programmable account’s signature validation can be policy-dependent. ERC-1271 standardises a way for a contract to report whether a signature is valid on its behalf, with validation potentially depending on context or state. It does not mandate a particular custody or recovery arrangement. ERC-1271
Inspect ordinary approvals, recovery, administrators and any enabled alternative execution paths together. Counting only the normal-day signers can underestimate effective control.
Back to contents · Next section
9. Separate ability to block from ability to act
In C, S cannot authorise an ordinary update alone, but it can prevent one by withholding its required contribution. Those are different powers. A participant can lack unilateral spending or update authority while still being a critical availability dependency.
G’s role is different again. G is not required for ordinary action, so its ordinary absence does not block U and S from cooperating. G is required for the specific recovery route, so its absence matters when replacing U’s slot.
In B, S has both ordinary acting authority and blocking power. In A, the interface provider has neither under the account rule, although an unavailable exclusive interface could still be an operational obstacle if no alternative existed. Our particular A outage case supplies an alternative, so that obstacle is removed in that case only.
A good responsibility map records both positive and negative capabilities: can authorise, can refuse a required contribution, can change an authority, and can supply or withhold necessary information. None automatically implies all the others.
Do not turn a service promise into a technical impossibility claim. “The service promises to act only on my instruction” differs from “the protocol makes its action impossible without my independent authorisation.” Both statements require evidence, but of different kinds.
Back to contents · Next section
10. Require evidence at the actual completion boundary
For the catalogue task, define completion as the intended label update in an identified accepted history with the required assurance. A screen showing a prepared request, collected approval or service acknowledgement is an earlier stage.
In A, U’s signature is evidence of authorisation, not automatically execution. In B, S’s instruction receipt does not prove its on-chain action. In C, collecting the required approvals does not by itself prove that the policy execution occurred and the application accepted the update.
A verification record should connect the request identity, network, account, intended operation, inclusion context and application result. If finality is part of the required assurance, retain that evidence separately rather than infer it from the wallet’s interface.
This also helps explain what a provider can recover. Restoring a login, restoring the ability to authorise future actions and undoing a past accepted effect are different jobs. A capability to do one does not establish the others.
The broader digital-resilience lesson emphasises restoring trusted function rather than merely restoring a screen. Here the concrete test is whether the claimed authority and the completed catalogue effect can be established under the arrangement’s actual rules.
Back to contents · Next section
11. Build a short control record
For A, write: U alone can satisfy ordinary authorisation; S is not required; no alternate recovery is supplied; usable independent tooling is assumed only in the stated outage case. Do not add provider-held recovery power without evidence.
For B, write: S holds chain authority; U has service instruction access; S can act or withhold action; service-login recovery is separate from chain authority. A service statement requires the relevant completion evidence before being treated as an executed update.
For C, write: U and S are both required for ordinary action; G and S can replace U’s slot through the configured delayed route; S can block both routes; G alone cannot act. Recovery can change effective user control, so it belongs beside ordinary signing in the record.
For an actual system review, also identify the software and deployed policy version, verified participants, enabled routes and unknown configuration. Unknown does not mean absent. A feature advertised as optional still needs an answer about whether it is enabled in the account being assessed.
Keep the record descriptive. It is not a recommendation to select one arrangement, a judgment about legal ownership or a promise that a financial service is available to a reader.
Back to contents · Next section
12. Exercises and worked answers
Question 1. S is offline, but A’s user authority and explicit alternative tooling are available. Is S’s approval needed?
Answer. No. Under A’s rules, U can satisfy ordinary authorisation independently. Inclusion and application execution still need their separate conditions.
Question 2. In B, U knows the account address and service password. Does that provide independent chain authority?
Answer. No. The card assigns that authority to S.
Question 3. In C, can G alone replace U’s slot?
Answer. No. The configured route requires G and S, the delay and its other conditions.
Question 4. Can C’s original U always prevent G and S from replacing the user slot?
Answer. Not under the supplied rule. G and S can complete that route without original U’s approval if all its conditions hold. That is technical capability, not permission to misuse it.
Question 5. C has collected U and S approvals. Is the catalogue update proven complete?
Answer. No. Execution and the required application and chain evidence remain necessary.
Question 6. Why inspect enabled modules or administrative paths as well as ordinary signers?
Answer. They may provide another route to execute actions or change authority. Their actual scope can change the control map.
Back to contents · Next section
Sources and next reading
Sources checked on 12 October 2026:
- Ethereum wallets, page updated 24 February 2026, used only for the wallet-interface versus account distinction.
- Safe account overview, for owner and alternative-path concepts, without adopting security marketing or universal account claims.
- Safe modules, for enabled alternative execution authority and its risks.
- ERC-1271, Final, created 25 July 2018, for contract-based signature validation rather than a mandatory recovery design.
A, B and C are original control arrangements, not descriptions of particular products. Continue to the recovery lesson to distinguish device loss, lost authority, missing application state and compromise of authority that still works.