Wallets and keys
A wallet helps a person or system manage accounts and authorize actions, while cryptographic keys provide the signing authority behind those actions.
Category: GovernanceHexagon category cue
System record
Start with the economic purpose, participants, resources, and entitlements before studying implementation detail.
Why it exists
Users need a controlled way to prove authorization, construct transactions, inspect state, and interact with programmable assets without revealing a private key.
Traditional-finance analogy
Signing authority plus account-access software is the closest comparison recorded for this concept.
Where the analogy stops
- Possession of a private key can directly authorize irreversible on-chain actions without a bank's identity recovery or transaction-reversal process.
- Smart-account, multisignature, hardware, and custody designs can distribute authority across code and people rather than one credential holder.
Main actors
- ActorAccount controller
- ActorWallet software or hardware provider
- ActorSigner, guardian, or custodian
- ActorApplication requesting authorization
Assets and claims
Assets — controlled or transformed resources
Assets are resources the mechanism moves, holds, values, or transforms.
- AssetAssets controlled by the authorized account
- AssetNative asset used for transaction fees
Claims — entitlements and corresponding dependencies
Claims are rights to value, repayment, redemption, control, or another party's performance; each depends on an obligation or system that must honor it.
- ClaimSigning authority over account actions
- ClaimRecovery, threshold, or policy rights in managed-account designs
A wallet is the interface and policy layer around blockchain accounts; a private key or another authorization mechanism is what grants signing power.
Why it exists
Section titled “Why it exists”People and applications need to construct transactions, inspect balances, review requested permissions, and authorize actions without exposing secret key material. Wallet designs also determine how authority is stored, divided, recovered, automated, or delegated.
Traditional-finance analogy
Section titled “Traditional-finance analogy”The closest analogy combines account-access software with signing authority. It is incomplete because a valid blockchain signature can directly authorize an irreversible action without a bank checking identity or offering a reversal. Hardware wallets, custodians, smart accounts, guardians, and multisignatures also split control in ways that one password analogy hides.
Actors, assets, and claims
Section titled “Actors, assets, and claims”| Role or object | Economic or control position | Main question |
|---|---|---|
| Account controller | Decides which actions to authorize | Is control individual, shared, delegated, or custodial? |
| Wallet software or hardware | Builds, displays, and signs requests | Does it show the real destination, amount, and permissions? |
| Signer, guardian, or custodian | Holds part or all of the authority | Can it act alone, recover access, freeze, or censor? |
| Application | Requests a transaction or off-chain signature | What exact capability does the request grant? |
| Controlled assets | Can move under valid authorization | Which contracts or approvals can move them later? |
| Recovery or policy right | Can restore or override access | Who holds it and under which delay or quorum? |
The wallet does not “hold coins” like a physical container. The blockchain records state; the wallet helps exercise authority over accounts that can change that state.
Mechanism and flows
Section titled “Mechanism and flows”- Wallet software obtains account and network state from a node or provider.
- An application or user constructs a transaction or typed message.
- The wallet presents the request and applies its signing policy.
- A key, threshold group, hardware device, custodian, or smart account authorizes the request.
- A transaction is broadcast, or an off-chain signature is returned to the requesting application.
Capital flow begins only after authorization is exercised by a state-changing transaction. Claim flow changes when the signed action mints, transfers, borrows, deposits, or redeems. Information flow includes the displayed request and chain data. Control flow follows every signer, guardian, administrator, and allowance. Return flow does not originate in a wallet; it only displays or authorizes returns paid by another protocol or economic actor. Risk flow reaches assets if any of those authorities is compromised or the user approves a different effect than intended.
State and loss allocation
Section titled “State and loss allocation”| Before | Action | After |
|---|---|---|
| Key or policy controls an account | Sign a transfer | The account nonce advances and assets may move |
| Token allowance is absent | Approve a spender | The spender gains a future transfer capability |
| One signer is unavailable | Invoke recovery | Guardians or another policy may replace authority |
| Custodian controls keys | Request withdrawal | Settlement depends on the custodian’s policy and solvency |
Wallet use does not create return. A wallet may display staking, lending, or incentive income, but the payer and risk live in those protocols. If a secret, approval, guardian set, or custodian fails, the account holder usually bears the immediate loss unless an explicit recovery, insurance, or legal remedy applies.
Beginner lens
Section titled “Beginner lens”Never treat a request as “just connecting.” Read what is being authorized: login proof, token approval, asset transfer, contract call, or policy change. The seed phrase or private key is authority, not a customer-support identifier.
Practitioner lens
Section titled “Practitioner lens”Inventory key custody, device isolation, backups, recovery tests, spending limits, approval exposure, chain selection, transaction simulation, signer quorums, operational delays, and emergency authority. Distinguish self-custody from delegated or custodial control in every user-facing claim.
Engineer or auditor lens
Section titled “Engineer or auditor lens”Ethereum distinguishes externally owned accounts controlled by private keys from contract accounts controlled by code. Wallets are applications that let users interact with accounts; that vocabulary is Ethereum-specific in detail, although the separation between interface and authorization is broadly useful. Smart-account systems can add validation logic, batching, guardians, or sponsored fees and therefore need their own trust and lifecycle review.
Security review notes
Section titled “Security review notes”Verify that secrets never leave their trusted boundary, signatures bind the intended chain and payload, replay protection works, displayed effects match encoded effects, and recovery cannot bypass its quorum or delay. A secure cryptographic primitive does not make compromised wallet software safe.
Common misunderstandings
Section titled “Common misunderstandings”- “The wallet contains my assets.” The chain records positions; the wallet controls how an account can act on them.
- “A signature cannot move funds.” Some signatures grant approvals, orders, permits, or account authority that another party can exercise.
- “Multisig means decentralized.” Security depends on who controls the signers, thresholds, devices, and recovery process.
Prerequisites and learn next
Section titled “Prerequisites and learn next”Start with blockchain. Continue to transactions and gas to see how an authorization becomes an executable state-change request.
Sources
Section titled “Sources”- Ethereum.org, Ethereum accounts — Ethereum’s account, key, signature, and wallet distinctions (accessed 2026-08-09).
- The supplied DeFi seed, sections 2, 12, and 14 — control analysis and the blockchain learning stage.
Machine-readable model
Key equations
Canonical expressions come from the structured concept record. KaTeX renders the notation, while the plain-text expression and variable table keep its meaning and units inspectable without JavaScript. Read the narrative above for the model's domain, assumptions, and rounding rules.
This concept does not require one canonical equation. Its mechanism and state transitions remain the authoritative explanation; do not invent a formula merely to make the topic look quantitative.
Assurance contract
Security properties
These structured statements define desired behavior. Their stable IDs can bind tests, invariants, specifications, audit findings, or proof results without turning descriptive review advice into an assurance claim.
Desired · not evaluated: No test, audit, or proof result is implied until scoped evidence is linked to this property.
Secret signing material is never disclosed to an untrusted requester
Every authorization binds the intended account, chain, action, parameters, and replay domain
Recovery and threshold policies cannot bypass their documented quorum or lifecycle rules
The user can inspect the material effect of an action before approving it
Knowledge check
Quiz
Answer in your own words, then open the model answer.
What is the first question to ask about a wallet prompt?
Model answer
Ask what capability the exact payload grants, to whom, on which chain, and whether that capability can be reused later.