Wallets, Keys and Decentralized Identity

Introduction

Blockchain applications do not identify users through usernames and passwords alone. They rely on cryptographic keys, addresses, signatures and increasingly sophisticated identity frameworks. A wallet is therefore more than a software interface for holding cryptocurrency: it is a system for managing authority over blockchain accounts and authorising actions.

This distinction is fundamental. Digital assets are generally recorded on a distributed ledger rather than stored inside a wallet. The wallet stores, protects or accesses the credentials—especially private keys—that allow a user to control those assets. Loss, theft or misuse of the credential can therefore have direct financial and operational consequences.

This chapter examines custodial and non-custodial wallets, seed phrases, key-management architectures, account abstraction, multisignature controls and decentralised identity. It also considers verifiable credentials, transaction-signing risks, governance and professional security practice.

Learning Objectives

By the end of this chapter, the reader should be able to:

1. Distinguish custodial, non-custodial, hardware, software and smart-contract wallets.
2. Explain private keys, public keys, addresses, seed phrases and hierarchical deterministic derivation.
3. Evaluate key-management risks and design appropriate operational controls.
4. Describe multisignature wallets and account abstraction.
5. Explain decentralised identifiers and verifiable credentials.
6. Apply safe transaction-signing procedures in personal and organisational settings.
7. Assess the legal, ethical and governance implications of blockchain identity systems.

1. Wallets as Control Systems

A blockchain wallet is an interface and credential-management system. In a conventional account, a bank maintains a ledger and authenticates a customer. In a blockchain account, the ledger is maintained by a network, while control is demonstrated by producing a valid cryptographic signature.

A simplified transaction-authorisation model is:

Here, sk is a private key, m is the transaction message, and σ is the signature. A verifier uses the corresponding public key to test whether the signature is valid. The private key must remain secret; the public key may be shared.

The blockchain normally records an address, account state and transaction history—not the private key itself. Ownership in practical terms means control of the credential accepted by the relevant protocol.

Custodial wallets

A custodial wallet is operated by a third party, such as an exchange, fintech provider or institutional custodian. The provider usually controls the private keys and gives the customer an account interface. Advantages include password recovery, customer support, transaction screening and integration with conventional payment systems. Disadvantages include counterparty risk, withdrawal restrictions, insolvency exposure, surveillance and dependence on the provider’s security.

Custody does not eliminate risk; it changes its location. The user’s principal risk may shift from seed-phrase loss to account compromise, provider failure, fraud or regulatory intervention.

Non-custodial wallets

In a non-custodial wallet, the user or organisation controls the signing keys. This provides direct control and reduces dependence on an intermediary, but it also transfers responsibility for backup, access control, software integrity and incident response to the owner. A non-custodial wallet may be a browser extension, mobile application, hardware device or smart-contract account.

Wallet classifications

A wallet may also be “hot” or “cold.” A hot wallet is connected to an internet-enabled environment and is suitable for frequent, smaller transactions. Cold storage keeps signing capability offline or strongly isolated and is generally more suitable for reserves and treasury assets.

2. Cryptographic Keys, Addresses and Seed Phrases

Private and public keys

A private key is a secret value used to generate signatures. A public key is mathematically related to the private key and is used for verification. In well-designed public-key cryptography, deriving the private key from the public key is computationally infeasible under accepted assumptions.

An address is usually an encoded identifier derived from a public key or from a smart-contract account. The exact process differs between blockchain systems. Consequently, an address is not itself a universal identity and may not reveal the person or organisation controlling it.

Seed phrases

Many wallets use a human-readable recovery phrase, commonly called a seed phrase. The phrase is not a password and should not be entered into websites, emailed, photographed or stored in ordinary cloud notes. It is a backup representation from which wallet keys can be deterministically derived.

A simplified hierarchy is:

Figure: A recovery phrase can deterministically support multiple accounts and derived keys.

Hierarchical deterministic wallets derive many keys from one root using a defined derivation scheme. This improves backup and account organisation, but it concentrates risk: compromise of the recovery phrase can expose all derived accounts within the relevant scope.

A passphrase sometimes called a “25th word” may create a different wallet from the same recovery phrase. It can improve plausible deniability but introduces an additional secret that must be backed up correctly. A forgotten passphrase can make funds permanently inaccessible.

Key-management principles

Effective key management includes:

• Generation: create keys using trusted, auditable randomness and uncompromised devices.
• Storage: separate high-value keys from internet-connected systems where practical.
• Backup: maintain tested, geographically separated backups using durable media.
• Access control: apply least privilege and role separation.
• Rotation and revocation: replace compromised credentials and remove departing personnel.
• Recovery testing: prove that backups work without exposing the secrets during testing.
• Destruction: securely retire obsolete devices, copies and credentials.

A backup that has never been restored is an assumption, not evidence of recoverability.

3. Custody Models and Operational Design

The appropriate wallet model depends on transaction frequency, value, organisational structure, compliance obligations and recovery capability. A business may use a custodian for payroll liquidity, a hardware wallet for reserves and a multisignature smart-contract wallet for treasury approvals.

A useful risk separation is to divide assets into:

1. Operational funds: small balances for routine activity.
2. Working capital: moderate balances requiring controlled access.
3. Strategic reserves: large balances protected by cold storage and multiple approvals.

Organisations should document who may initiate, review and approve transactions. The person entering a destination address should not necessarily be the person providing final approval. This separation reduces the likelihood that one compromised account can cause irreversible loss.

Custodians should be assessed for financial soundness, asset segregation, insurance claims, withdrawal procedures, incident history, proof-of-reserves limitations and applicable regulation. A cryptographic proof of reserves may demonstrate control of certain on-chain assets, but it does not by itself prove solvency, absence of liabilities or quality of governance.

4. Multisignature Control

A multisignature, or multisig, arrangement requires multiple authorised keys before an action is accepted. In an m-of-n design, at least m signatures from n authorised signers are required.

For example, a 2-of-3 wallet may have three signers, while any two must approve a transaction. It provides resilience against one lost key and reduces the effect of one compromised key. However, it does not protect against colluding signers, fraudulent transaction details or a malicious smart contract.

Multisig governance requires a documented signer list, secure devices, clear quorum rules, succession plans, address-change procedures and emergency recovery. Signers should independently verify transaction destination, amount, network, token contract and calldata—not merely approve a message displayed by an untrusted computer.

Multisig is not identical to decentralisation. If all signers are controlled by one person or stored in one location, the arrangement may provide little meaningful independence.

5. Account Abstraction and Smart-Contract Wallets

Traditional externally owned accounts generally rely directly on a private key for authorisation. A smart-contract wallet represents account logic in code. Its rules may support multisignature approval, spending limits, social recovery, session keys, transaction batching and alternative authentication mechanisms.

Account abstraction refers broadly to designs that make account behaviour programmable and reduce dependence on a single fixed transaction-signing model. Depending on the implementation, a user operation may be submitted through a relayer or bundler, and a paymaster may sponsor network fees. These features can improve usability, but they introduce additional components and trust assumptions.

A smart-contract wallet should be evaluated for:

• contract audit quality and upgrade authority;
• recovery and guardian procedures;
• fee sponsorship and denial-of-service risks;
• replay protection and chain identification;
• limits on session keys and delegated permissions;
• emergency pause or escape mechanisms;
• compatibility with the target blockchain and applications.

Account abstraction does not remove keys. It changes how authority is represented, validated and recovered. Poorly designed recovery logic can become an attack route, while excessive complexity can make failures difficult to diagnose.

6. Safe Transaction Signing

A transaction signature is an authorisation, not a harmless login. Before signing, users should establish exactly what is being authorised.

A disciplined signing procedure

1. Verify the origin. Use a bookmarked or independently verified application address. Do not rely only on a sponsored advertisement or social-media link.
2. Inspect the network. Confirm chain, account and fee currency.
3. Read the action. Identify recipient, amount, token, contract and permissions.
4. Review approvals. Unlimited token approvals can allow a contract to transfer future balances.
5. Check calldata where possible. A human-readable label is helpful but not proof of safety.
6. Use a simulation or small test transaction. Treat simulations as evidence, not guarantees.
7. Confirm on the trusted display. Hardware-wallet screens should be checked directly.
8. Revoke unnecessary permissions. Monitor and remove stale allowances using reputable tools.
9. Record the transaction purpose. Organisations should retain an approval trail.

Common malicious requests include signing a disguised approval, authorising a permit, granting operator rights to a token collection, or signing an apparently random message that is later replayed. A signature may be valid cryptographically while the transaction is economically harmful.

Users should never disclose seed phrases or private keys to support staff, websites, “verification” forms or recovery services. No legitimate transaction requires a seed phrase to be entered into a dApp.

7. Decentralised Identity

Decentralised identity seeks to give individuals and organisations greater control over identifiers, credentials and disclosure. It does not necessarily mean that all personal information is placed on a blockchain. In fact, storing personal data publicly and immutably can create serious privacy and compliance problems.

Decentralised identifiers

A decentralised identifier, or DID, is an identifier designed to be controlled through cryptographic methods rather than issued solely by a central identity provider. A DID commonly resolves to a DID document containing verification methods, service endpoints and metadata. The exact syntax and resolution method depend on the DID method.

A DID may represent a person, organisation, device or software agent. Control can be updated by authorised keys, but key rotation and recovery are essential. A DID does not automatically prove that a real-world person exists or that a particular legal identity controls it. That connection requires an issuance, verification or governance process.

Verifiable credentials

A verifiable credential is a digitally signed statement issued by one party about a subject and presented to a verifier. Examples include a professional qualification, membership, age threshold or training completion.

The principal roles are:

• Issuer: creates and signs the credential.
• Holder: stores and presents the credential.
• Verifier: checks authenticity, integrity, validity and policy compliance.
• Subject: the person, organisation or entity described; often the holder, but not always.

A credential generally requires verification of issuer authority, signature validity, status or revocation, expiry and suitability for the specific context. A valid signature alone does not prove that the issuer’s claim is truthful or that the credential has not been revoked.

Privacy and selective disclosure

Identity systems should follow data minimisation: disclose only what is necessary. For example, a verifier may need evidence that a customer is over a certain age, not the customer’s full birth date. Selective-disclosure and zero-knowledge techniques can support this goal, although implementations vary in maturity and interoperability.

Blockchain anchoring can support integrity or status registries, but it should normally avoid publishing raw personal data. Public addresses can become personally identifying when linked with exchange records, social profiles, device information or transaction patterns.

8. Applied Case: Illustrative University Research Treasury

Background

A university blockchain laboratory receives grants in digital assets and pays researchers through a treasury wallet. Initially, one administrator uses a browser wallet and stores the recovery phrase in an office safe.

Problem

The arrangement creates concentration risk. One person can approve payments, the phrase may be copied, and there is no formal process for staff turnover or emergency recovery. A phishing attack could drain the treasury.

Analysis

The laboratory separates funds into a small operational wallet and a reserve wallet. It identifies four authorised signers: the finance director, laboratory director, compliance officer and external trustee. The reserve uses a 3-of-4 multisignature wallet. The operational wallet is funded only with a defined monthly limit.

Approach

Each signer uses a hardware device generated and initialised independently. Recovery materials are stored in separate secure locations. A transaction policy requires the initiator to provide an invoice, destination verification and purpose statement. Two reviewers independently check the address and amount before the third approval. Quarterly recovery exercises test whether the institution can operate after loss of one signer.

The laboratory also adopts a decentralised credential system for researchers. A university issuer provides credentials for approved researchers. The credentials prove research affiliation without placing personal records on-chain. Revocation is checked before access is granted to restricted laboratory resources.

Outcome

The new design reduces single-person failure and improves auditability. It does not eliminate risk: three colluding signers could still approve a harmful transaction, a compromised smart-contract wallet could affect all signers, and poor address verification could defeat the approval process.

Learning points

The case demonstrates that wallet security is an organisational-control problem as well as a cryptographic problem. Strong devices cannot compensate for weak governance, and decentralised identity is useful only when issuer authority, privacy and revocation are addressed.

9. Limitations, Ethics and Regulation

Blockchain identity can increase user control, but it may also create new forms of surveillance. Persistent identifiers can enable profiling, discrimination and unwanted correlation. Designers should consider consent, purpose limitation, accessibility and the rights of people who cannot safely manage cryptographic keys.

Regulatory obligations may include anti-money-laundering controls, sanctions screening, consumer protection, data-protection law, electronic-signature rules, financial-services licensing and custody requirements. Requirements vary by jurisdiction and change over time; technical teams must obtain qualified legal advice rather than assuming that decentralisation removes regulatory responsibility.

Important governance questions include: Who may issue a credential? Who can revoke it? What happens if the issuer disappears? How can a person recover access without surrendering control? How are minors, vulnerable users and disputed identities treated? These are institutional questions that code alone cannot answer.

Artificial intelligence can assist with transaction classification, anomaly detection and support triage. It must not be treated as an authority for approving irreversible transactions. AI-generated summaries may omit malicious calldata or misidentify an address. Human review, deterministic policy controls and trusted display verification remain necessary.

10. Best-Practice Framework

A professional wallet and identity programme should:

• classify assets, identities and transaction risk;
• use least privilege and separation of duties;
• keep recovery secrets offline and test restoration;
• use hardware-backed signing for significant value;
• require independent transaction verification;
• limit approvals, session keys and spending allowances;
• document multisig membership and succession;
• monitor addresses, permissions and unusual activity;
• minimise personal data and avoid placing raw identity data on-chain;
• verify credential issuer, status, expiry and intended use;
• maintain incident-response and key-compromise procedures;
• train users through realistic phishing and signing exercises.

Security should be usable. Procedures that are so complex that staff bypass them may be less secure than a simpler, well-enforced design.

Chapter Summary

Wallets provide access to blockchain authority rather than storing assets in the conventional sense. Custodial models offer convenience and recovery but introduce intermediary risk; non-custodial models provide direct control but require disciplined key management. Private keys create signatures, public keys support verification, and seed phrases can deterministically recover multiple derived accounts.

Multisignature wallets distribute approval authority, while smart-contract wallets and account abstraction make account rules programmable. These mechanisms improve recovery and governance but add code, configuration and operational risks. Safe signing requires verifying applications, networks, recipients, amounts, permissions and calldata through trusted channels.

Decentralised identifiers and verifiable credentials can support portable, privacy-aware identity, but they depend on issuer trust, revocation, recovery, governance and legal context. Effective blockchain security is therefore a combination of cryptography, technology, organisational controls, human judgement and ethical design.

Key Terms

Private key: Secret cryptographic value used to create signatures.

Public key: Cryptographic value used to verify signatures.

Address: Encoded identifier associated with an account or public key.

Wallet: Interface and system for managing blockchain credentials and transactions.

Custodial wallet: Wallet service in which a third party controls signing keys.

Non-custodial wallet: Wallet in which the user or organisation controls signing keys.

Seed phrase: Human-readable recovery representation for deterministic wallet keys.

Hierarchical deterministic wallet: Wallet deriving multiple keys from a common root.

Hot wallet: Wallet connected to an internet-enabled environment.

Cold storage: Strongly isolated storage for signing credentials.

Multisignature: Authorisation requiring signatures from multiple keys.

Account abstraction: Design approach that makes account validation and execution programmable.

Smart-contract wallet: Account whose control logic is implemented by blockchain code.

Decentralised identifier: Cryptographically controlled identifier for an entity.

DID document: Data describing verification methods and services associated with a DID.

Verifiable credential: Digitally signed claim issued about a subject.

Issuer: Entity that creates and signs a credential.

Holder: Entity that stores and presents a credential.

Verifier: Entity that checks a credential and applies an access decision.

Selective disclosure: Revealing only the minimum required identity information.

Review Questions

Short Answer Questions

1. What is the principal difference between custodial and non-custodial wallets?
2. Why must a seed phrase be protected more carefully than an ordinary application password?
3. What does a 2-of-3 multisignature arrangement mean?
4. Identify the issuer, holder and verifier in a verifiable-credential system.
5. Why should raw personal data generally not be placed directly on a public blockchain?

Long Answer Questions

1. Explain the relationship between private keys, public keys, addresses and digital signatures.
2. Compare the security, recovery and governance implications of hot wallets, hardware wallets and custodial wallets.
3. Describe how account abstraction can improve usability while introducing new technical risks.
4. Explain a complete organisational key-management policy for a blockchain treasury.
5. Discuss the privacy, governance and regulatory challenges of decentralised identity.

Analytical / Application Questions

1. A startup has one founder controlling its entire treasury through a browser wallet. Design a phased control architecture using operational funds, cold storage and multisignature approval.
2. A dApp requests unlimited token approval and a signature described only as “confirm access.” Analyse the risks and specify the checks a user should perform before proceeding.
3. A university wants to issue digital credentials proving that researchers are authorised to enter a laboratory without revealing their full identity publicly. Propose a DID and verifiable-credential workflow, including issuance, verification, revocation and recovery.

Multiple Choice Questions with Answers

Question 1

Which statement best describes a non-custodial wallet?

A. A wallet in which a bank always controls the keys

B. A wallet in which the user or organisation controls the signing keys

C. A wallet that cannot interact with smart contracts

D. A wallet that stores assets outside the blockchain ledger

Correct Answer: B. A wallet in which the user or organisation controls the signing keys

Question 2

What is the primary function of a private key?

A. To create digital signatures

B. To display a token balance

C. To identify a blockchain network by name

D. To encrypt every public blockchain transaction permanently

Correct Answer: A. To create digital signatures

Question 3

In a 2-of-3 multisignature wallet, how many authorised signatures are normally required?

A. One

B. Two

C. Three

D. Four

Correct Answer: B. Two

Question 4

Why is a seed phrase especially sensitive?

A. It is only used to calculate transaction fees

B. It can recover multiple derived wallet keys

C. It is publicly recorded in every transaction

D. It cannot be backed up

Correct Answer: B. It can recover multiple derived wallet keys

Question 5

Which action is safest before signing a significant blockchain transaction?

A. Trusting a pop-up because it uses familiar branding

B. Entering the seed phrase to unlock the dApp

C. Independently checking the network, recipient, amount and permissions

D. Approving every requested token allowance

Correct Answer: C. Independently checking the network, recipient, amount and permissions

Question 6

What is a central feature of account abstraction?

A. It makes all blockchains permissionless banks

B. It allows account validation and execution rules to be programmable

C. It eliminates the need for any authentication

D. It guarantees that smart contracts contain no bugs

Correct Answer: B. It allows account validation and execution rules to be programmable

Question 7

Who normally creates and signs a verifiable credential?

A. The issuer

B. The verifier

C. The network miner only

D. An anonymous browser extension

Correct Answer: A. The issuer

Question 8

What is selective disclosure intended to achieve?

A. Revealing all available personal data

B. Disclosing only the information necessary for a purpose

C. Preventing credential revocation

D. Making private keys public

Correct Answer: B. Disclosing only the information necessary for a purpose

Question 9

Which statement about a blockchain address is most accurate?

A. It automatically proves a person’s legal identity

B. It is generally an identifier associated with an account or public key

C. It is the same thing as a seed phrase

D. It can always be changed after every transaction without consequence

Correct Answer: B. It is generally an identifier associated with an account or public key

Question 10

Which practice best supports organisational treasury security?

A. Allowing one administrator to initiate and approve all payments

B. Keeping all recovery copies in one office drawer

C. Using separation of duties and independently verified approvals

D. Treating simulations as absolute proof of transaction safety

Correct Answer: C. Using separation of duties and independently verified approvals