A blockchain wallet is an interface for working with accounts and signing authority. Custody asks who can exercise that authority, restrict it and recover access. Understanding both begins with a control map, rather than with buying an asset.
Continue from How Blockchain Works | Simplest Explanation, or begin here if this is your current question. The guide develops the idea through 18 chapters, concrete situations and a paper activity. Its scenarios are fictional teaching models; a real service follows its specified network and application rules.
The Master Blockchain technical companion provides the deeper route after the everyday explanation here.
Choose your reading route
- Separate the objects · Chapters 1–3
- Follow an approval · Chapters 4–7
- Map custody and recovery · Chapters 8–11
- Check interfaces and remaining powers · Chapters 12–15
- Practise and explain · Chapters 16–18
Full chapter index · Worked situations · Answer check · Master Blockchain hub
Full chapter index
Separate the objects · Chapters 1–3
Follow an approval · Chapters 4–7
Map custody and recovery · Chapters 8–11
Check interfaces and remaining powers · Chapters 12–15
Practise and explain · Chapters 16–18
CHAPTER 1 OF 18 · Separate the objects
1. The word wallet can suggest the wrong picture
A physical wallet holds cards and banknotes. A blockchain wallet usually helps a person interact with accounts, inspect information and authorise instructions.
The assets or rights shown by the interface are represented through the relevant ledger and application state, rather than being ordinary objects tucked inside a screen.
This guide explains that relationship without asking readers to buy anything or create an account.
Our teaching scenario is a fictional community art club with a digital membership record and a shared programme for approving equipment bookings.
Some examples use familiar account terminology, but the activity uses paper cards and invented identifiers.
The first question is what the wallet actually helps the user do.
The second is who holds the power to do it.
Those questions make the difference between interface and custody visible.
A neat app icon tells us little about the control and recovery arrangement behind it.
CHAPTER 2 OF 18 · Separate the objects
2. Wallet, account, address and key are different concepts
A wallet application is a tool or interface. An account is part of the relevant system’s state and authority model. An address identifies an account or other relevant destination according to that system’s rules.
Keys can support signing authority, but different account designs use different control arrangements.
These terms should not be collapsed into a single object.
Our fictional club calls its approval account CLUB-A. The interface displays that account’s permissions. A separate signing arrangement determines how an instruction is approved.
Changing the interface does not automatically change the ledger record or its authority.
Nor does knowing an address automatically permit a person to act for the account.
For learners, use four separate cards: interface, account, identifier and approval capability.
Connect them with labelled relationships.
This simple separation prevents several later misunderstandings about losing an app, changing a device or sharing an identifier.
The actual network’s account specification supplies the technical details; the cards teach the roles.
CHAPTER 3 OF 18 · Separate the objects
3. The balance or status display comes from a source
The wallet shows that the club has an active membership and permission to request a studio booking.
Where did that information come from?
The interface may query a remote service, read a local participant’s view or use another specified route.
Its answer can depend on the network, account identifier and history position being queried.
A display is not automatically an independent validation of the whole ledger.
Nodes and Shared Copies explains that boundary.
For our club, an outdated service might still show last week’s membership status. A display mistake does not necessarily mean the underlying record changed.
The reader should be able to obtain relevant context when a consequential decision depends on the answer.
For the classroom, give the interface desk an older membership sheet and the record desk a newer one.
Ask which source the interface is reading.
The exercise locates the problem instead of treating the wallet as a container whose contents mysteriously vanished or appeared.
CHAPTER 4 OF 18 · Follow an approval
4. A signing request needs an understandable meaning
Alicia uses the club interface to approve one equipment booking.
The displayed message should explain the actual proposed authority: which equipment, which booking, which account and which operation.
A vague button saying Approve can hide a broader instruction.
The prepared message might grant continuing permission to another programme rather than approve one isolated booking.
The distinction matters because the signature applies to the message the system constructs, not simply to Alicia’s general hope that the request is harmless.
Our toy interface therefore presents a clear statement before the approval.
Keys and Digital Signatures explains the relationship between a message and its signing authority.
For learners, compare two paper screens. One says Approve. The other names the single booking and explicitly describes the scope of the action.
Ask which information the person needs to understand the decision.
A reliable wallet experience includes intelligible authorisation, not only correct cryptographic calculation.
The relevant authority approves a prepared instruction. The instruction still needs to enter the network’s processing path.
A signed request can fail to arrive, wait or be refused by other rules.
An interface should not describe the signature alone as proof that the booking was completed.
The user needs the outcome for the identified request.
A Record’s Journey follows this wider path. Confirmations and Finality explains the settlement stages.
For our club, the approval receipt says the instruction was signed. A later result tells Alicia whether the booking state changed.
The distinction is familiar from paper administration: signing a form and receiving a completed reservation are different events.
For the classroom, place the signed card in a submission tray and withhold the result. Ask what the learner can conclude.
They should state the completed authorisation step and the unresolved processing step.
That answer keeps the interface from becoming a source of overconfidence about an action that has not yet taken effect.
The custody question is who can use the relevant authority, not merely whose name appears on the screen.
A service may hold signing authority for a user. Another arrangement may let the user control it directly. Shared or programmable arrangements can divide powers differently.
The labels need their actual mechanisms explained.
For our club, one proposal lets a service operator approve bookings on the club’s behalf. Another requires authorised club officers to approve through their designated capabilities.
The two proposals create different dependencies.
Ask who can initiate an action, who can refuse it, who can change the controlling arrangement and who can restore access.
The answer may involve several parties.
This guide does not recommend a custody product.
It teaches how to read the control structure.
A person’s ability to log in and inspect an account does not necessarily establish that they alone control every consequential instruction.
The control map is the evidence we need.
CHAPTER 7 OF 18 · Follow an approval
7. A service-held arrangement includes an operator
The club uses a provider that manages its approval capability. Club members sign in through an ordinary account interface.
That can create a familiar user experience, including a service-managed recovery process.
The provider’s relevant powers remain part of the arrangement.
Can it approve actions without a particular member? Can it freeze access? Which organisational policy governs those powers?
Those questions should be answered by the actual service, rather than inferred from the word Wallet.
Our fictional model does not specify a real provider.
It shows why operator responsibility belongs in the custody explanation.
For learners, give the interface card to a member and the signing card to the service desk.
Let the member request an action, then ask which desk must perform it.
The arrangement may serve particular needs. It also creates a dependency.
A useful description makes both the convenience and the authority boundary visible.
The interface alone cannot establish where the controlling capability sits.
CHAPTER 8 OF 18 · Map custody and recovery
8. Direct control does not remove every dependency
In another proposal, designated club officers directly control the relevant signing capability.
This changes who can authorise the action, but the service still depends on devices, software, network information and the programme’s rules.
Direct control also creates operational responsibilities.
The officers need to understand what they approve, how access is protected and what recovery is possible under the design.
There is no reason to turn that explanation into an investment recommendation.
Our paper model gives an officer the signing card while another desk supplies the interface and network answer.
Now make the interface desk unavailable.
The officer still holds the toy authority, yet may need another appropriate route to use it.
This distinguishes possession of control from availability of a particular application.
Real systems vary in which alternative routes and recovery mechanisms exist.
Ask for the actual design.
A slogan about complete independence would conceal dependencies that users may need to understand during a failure.
The art club decides that changing equipment-booking rules requires approval from two designated officers.
An appropriate technical arrangement can express shared authority.
The mechanisms differ. Multiple signatures, threshold schemes and programmable account policies should not be treated as interchangeable merely because they involve several people.
For our learner, begin with the human requirement: which action needs which approvals?
Then map the technical arrangement intended to enforce it.
The club also needs procedures for officer replacement, absence and disagreement.
Shared control can constrain unilateral action while creating coordination work.
For the classroom, require two matching approvals on one exact rule-change card. Present approvals describing different changes and ask whether they satisfy the requirement.
They should not simply be counted as two unrelated votes.
This reinforces message scope as well as shared authority.
The useful design states the necessary support, the permitted effect and what happens when that support cannot be obtained.
CHAPTER 10 OF 18 · Map custody and recovery
10. Recovery depends on what was actually lost
Alicia cannot open the wallet application on her phone.
Several different losses could explain the situation: the app stopped working, the device failed, the service login became unavailable or the signing capability was lost.
Their recovery paths can differ.
An app reinstall does not automatically restore missing authority. A password reset may recover a service login without recovering a separately controlled key.
The actual account design must explain which capability is needed for each task.
For our club, distinguish the interface card, login card and signing card.
Remove one at a time and ask which operation is still possible.
The activity shows why “I lost my wallet” is an incomplete technical description.
A useful support conversation identifies the lost capability and the relevant control arrangement.
No learner should experiment with real credentials to practise this.
The paper model supplies enough structure to understand recovery while avoiding assumptions that all wallets use the same reset procedure.
CHAPTER 11 OF 18 · Map custody and recovery
11. A recovery secret is a capability, not ordinary profile data
Some wallet arrangements use recovery material that can restore important signing capabilities.
Its role is different from a public account identifier or a harmless helpdesk reference.
If someone obtains sufficient recovery authority, they may be able to act under the account’s control arrangement.
The exact result depends on the design.
Our educational exercise never generates or shares real recovery phrases. It uses a card labelled Recovery authority.
Give that card to another player and ask which powers the toy rules now permit.
The lesson is about consequences of capability transfer, not about creating a real backup.
When reading a service’s recovery process, ask what information or approval is required, who may use it and which actions it enables.
Do not assume every wallet uses a phrase or that one phrase is the universal recovery mechanism.
A precise explanation distinguishes account identification from the material or procedure that restores control.
That distinction makes custody much easier to understand.
CHAPTER 12 OF 18 · Check interfaces and remaining powers
12. A hardware device addresses particular parts of the path
A dedicated signing device can play a role in protecting or isolating signing operations.
It does not automatically make every prepared instruction sensible or every displayed external fact correct.
The complete path still includes the application, message interpretation, device operation and network result.
For our club, imagine a protected approval desk that faithfully signs the exact card it receives.
If the card requests the wrong booking, faithful signing preserves the mistake.
The signer still needs enough intelligible information to assess the action.
The device’s actual guarantees and limitations depend on its design and use.
This guide does not recommend hardware or compare brands.
It introduces the principle that a protective component has a scope.
For learners, place a strong guard around the signing card while allowing the request card to be misleading.
Ask what the guard prevented and what it did not.
A useful security explanation names both.
Protection improves particular risks; it does not eliminate the need to understand the authorised operation.
CHAPTER 13 OF 18 · Check interfaces and remaining powers
13. Disconnecting an interface may not revoke an earlier permission
The club disconnects a website from its wallet interface.
Does that cancel every authority previously granted through the website?
Not necessarily.
A local connection setting and a recorded programme permission can be different objects.
If an earlier instruction granted continuing authority, the applicable programme may require a separate authorised action to change or revoke it.
The exact behaviour depends on the service and network.
For our toy example, the club grants another programme permission to submit certain booking changes. Removing the visible shortcut does not alter that permission card.
Learners should inspect the permission’s current state and the rule for changing it.
This is not an instruction to manage real financial approvals.
It is an explanation of why an interface action should be matched to its actual effect.
Ask what changed: the screen’s connection, the account’s recorded authority or both?
The answer should come from the specific implementation rather than the reassuring disappearance of an icon.
CHAPTER 14 OF 18 · Check interfaces and remaining powers
14. Changing people requires changing the authority arrangement
A club officer leaves. The membership record and controlling permissions need an appropriate update.
The old officer’s earlier valid actions remain part of the history, while their authority over future actions may change.
Those are separate questions.
Our club’s toy procedure replaces the officer through a defined approval process and records the effective change.
A real service needs to specify which capability is retired, what happens to devices and recovery arrangements, and who checks the transition.
This work belongs to custody because controlling authority changes over time.
For learners, remove the officer’s role card but leave their signing card in place.
Ask whether the procedure has actually removed their technical power.
The exercise exposes a gap between an organisational decision and its implemented effect.
A dependable arrangement connects both.
The control map should therefore include ordinary operation, departures and recovery.
It is a living account of who can do what, rather than a diagram drawn only when the account was created.
CHAPTER 15 OF 18 · Check interfaces and remaining powers
15. Control and entitlement are different questions
A person can possess a technical signing capability without necessarily being entitled to use it for every purpose.
An account’s interface can display a membership or token while the real-world rights associated with it depend on separate arrangements.
Our club’s toy account controls booking instructions under its programme rules. It does not automatically establish ownership of the physical studio or every piece of equipment.
Keeping these distinctions visible helps avoid exaggerated claims about digital ownership.
This guide does not determine legal rights in a real situation.
It separates technical capability, authorised permission and the underlying entitlement the service is meant to represent.
For learners, give one player the signing card and another the club’s equipment ownership record.
Ask which question each card answers.
The two may be connected by a well-designed arrangement, but the connection needs explanation.
The wallet screen alone is not a complete account of every right.
A useful custody guide identifies both the digital power and the real responsibility it is supposed to serve.
Make columns for view, propose, sign, restrict, change permissions and recover access.
List the member, club officer, service operator, recovery authority and programme administrator as relevant to the fictional design.
Fill each cell with its actual power and conditions.
Then ask which powers depend on another party.
This map gives a more useful account of custody than a single label.
For one arrangement, the service operator may sign and recover. For another, officers may sign while an agreed shared procedure changes authority.
Neither map should be assumed from the appearance of the interface.
The classroom can compare the designs against the club’s actual needs.
What happens when an officer is unavailable? What happens when the provider stops responding? Which party can intervene during an incident?
The map exposes the answers and gaps.
A reliable explanation makes those dependencies reviewable before people rely on the service for a consequential action.
Use cards for interface, account, public identifier, signing authority, recovery authority and recorded permissions.
Give a fictional club member access to the interface. Ask them to view the membership status and prepare one booking request.
Follow the approval and submission steps. Compare the signed instruction with the resulting programme effect.
Now run variations: lose the interface, lose the signing capability, change an officer and disconnect a shortcut while leaving an earlier permission active.
Use only the written toy rules to resolve each case.
No real wallet, funds, key or recovery phrase is needed.
The learner should identify what was lost or changed and which authority can restore the necessary function.
The exercise succeeds when the child or adult can explain the difference between a screen, an account identifier and a controlling capability.
That understanding makes real documentation easier to read later without turning education into account setup or speculative trading.
A wallet helps users interact with the relevant account and authorisation arrangement. Custody describes who controls the capabilities and intervention paths behind that interaction.
The beginner’s question is who can act, who can stop an action and who can recover access.
The adult explanation adds precise message scope, programme permissions, service dependencies and changing authority.
Return to Keys and Digital Signatures for approval. A Record’s Journey follows the request after approval. Confirmations and Finality explains the resulting status.
The technical Master Blockchain custody lesson examines control maps more closely.
The Ethereum wallet guide supplies one ecosystem’s terminology; individual products and account designs need their own descriptions.
Our fictional club keeps the focus on mechanism rather than investment.
A clear control map helps readers understand the useful service and its responsibilities.
Once those powers are visible, the wallet becomes an understandable interface to a system, rather than a mysterious container for everything the screen displays.
Worked situations: locate the next check
| Situation | What it establishes | Next check |
|---|---|---|
| Interface stops working | Loss of one app differs from loss of authority. | Identify which capability is unavailable. |
| Service login works but provider controls signing | Viewing an account does not establish sole control. | Map the provider’s actual powers. |
| Website disconnected after continuing permission granted | Connection settings may not change programme authority. | Inspect the permission’s current recorded state. |
| Officer removed from club but technical authority remains | Organisational change needs an implemented transition. | Update and verify the relevant control arrangement. |
Check your understanding
Five questions: Is a wallet screen the ledger itself? Does knowing an address grant signing authority? Does signing prove the request completed? Is every recovery design the same? Can an earlier permission survive a local disconnect?
Answer check: No; no; no; no; yes. Identify the interface, capability and recorded state in each case.
Continue through the beginner collection
- Simplest Explanation
- A Record’s Journey
- Digital Fingerprints
- Keys and Digital Signatures
- Nodes and Shared Copies
- Consensus and Agreement
- Smart Contracts and Rules
Technical companion · Structured technical learning guide
Primary references and scope
Reference pages checked 13 October 2026. The classroom models explain roles and evidence; they do not implement a secure network, define a universal waiting period or prescribe a production custody or measurement system.
- Ethereum: Wallets — a primary, platform-specific reference. The actual system’s documentation defines its guarantees, roles and implementation.
- NIST IR 8202: Blockchain Technology Overview — published October 2018; broader shared-ledger terminology and mechanisms.
How Blockchain Works · beginner reading sequence: 1. Simplest Explanation · 2. A Record’s Journey · 3. Digital Fingerprints · 4. Keys and Digital Signatures · 5. Nodes and Shared Copies · 6. Consensus and Agreement · 7. Smart Contracts and Rules · 8. Oracles and the Outside World · 9. Public, Private and Consortium Networks · 10. Confirmations and Finality · 11. Wallets and Custody · 12. Tokens and What They Represent · 13. Supply Chains and Handovers · 14. Certificates and Credentials · 15. Databases and When Blockchain Helps · 16. Scaling and Layers · 17. Bridges Between Networks · 18. Fees and Computing Resources · 19. Governance and Upgrades · 20. Privacy and What Records Reveal · 21. Zero-Knowledge Proofs · 22. Block Explorers and Reading a Record · 23. Testing Rules and Finding Mistakes · 24. Merkle Trees and Small Proofs · 25. Data Availability and Missing Pieces · 26. Forks and Changing Histories · 27. Digital Identity and Proving Who You Are · 28. Light Clients and Checkpoints · 29. Multisignature and Shared Control · 30. Network Delays and Partitions · 31. Incident Response and Recovery · 32. Transaction Order and Fairness · 33. Token Approvals and Remaining Permission · 34. NFTs, Metadata and Linked Files · 35. Logs, Events and Application Memory · 36. UTXOs and Change Outputs · 37. Proof of Work and Targets · 38. Proof of Stake and Validator Duties · 39. Post-Quantum Cryptography and Migration · 40. Virtual Machines and Replaying Rules · 41. All-or-Nothing Execution and Its Boundaries · 42. Client Diversity and Software Independence · 43. Benchmarks, Throughput and Finality · 44. Encoding and Serialisation · 45. RPC Requests and Access Points · 46. State Snapshots, Pruning and Archives · 47. Timestamps and Clock Limits · 48. Commit–Reveal and Hidden Choices · 49. Proxies and State-Preserving Upgrades · 50. Formal Verification and Model Limits · 51. Content Addressing and File Retrieval