Security, Privacy and Risk Management

Introduction

Blockchain systems replace some trusted intermediaries with cryptographic protocols, distributed consensus, programmable transactions and user-controlled credentials. These properties can improve transparency and resistance to unilateral alteration, but they do not make a system automatically secure. A blockchain may preserve a fraudulent transaction permanently, expose sensitive information through an immutable ledger, or allow a coding error in a smart contract to transfer substantial value.

Security therefore has several layers: protecting keys and devices, validating transactions and software, controlling access to assets, preserving privacy, managing operational risk, and responding effectively when controls fail. This chapter develops a practical framework for identifying and controlling major blockchain risks, including key theft, phishing, double spending, Sybil attacks, 51% attacks, smart-contract vulnerabilities and cross-chain bridge failures.

Learning objectives

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

• distinguish blockchain security, privacy and operational risk;
• explain key theft, phishing, double spending, Sybil attacks and 51% attacks;
• identify common smart-contract and bridge vulnerabilities;
• select suitable custody, governance, auditing and monitoring controls;
• apply privacy-by-design principles to blockchain projects; and
• construct a basic incident-response plan.

1. A layered view of blockchain risk

A useful risk model separates the system into five layers:

1. Identity and access: private keys, seed phrases, passwords, hardware devices and signing permissions.
2. Application: wallets, exchanges, decentralised applications (dApps), smart contracts and user interfaces.
3. Protocol and consensus: transaction validation, block production, finality and network participation.
4. Infrastructure: nodes, cloud services, operating systems, networks, oracles and bridge relayers.
5. Governance and organisation: administrators, upgrade procedures, legal responsibilities, suppliers and incident decisions.

A weakness in one layer can defeat strengths in another. For example, a highly secure consensus protocol cannot protect funds if a user signs a malicious transaction, and a formally verified contract can still be compromised through an exposed administrator key.

Risk can be described qualitatively as the combination of likelihood and impact. In a simple risk register, each risk receives a likelihood rating, an impact rating, an owner, existing controls and a treatment decision. Multiplying ordinal scores can help rank risks, but the result is not a precise probability and should not be presented as one. More rigorous assessments estimate probability, exposure, recovery cost, regulatory consequences and affected stakeholders separately.

2. Cryptographic keys and custody

A blockchain address is generally derived from a public key or related identifier. The private key authorises transactions. Possession of the private key normally provides practical control over the associated assets; a blockchain generally cannot determine whether possession was obtained through theft, deception or coercion.

A seed phrase is a human-readable backup from which one or more private keys may be deterministically derived. It must be treated as a root credential. Photographing, emailing or entering it into a website creates significant exposure. Encryption protects stored data, but it does not make a seed phrase safe if the decryption password or the device is compromised.

Custody models

A multisignature arrangement requires several authorised keys before a transaction is valid. A 2-of-3 policy, for example, requires any two of three signers. It reduces dependence on one key but does not eliminate collusion, poor signer selection or faulty transaction review. Signers should be geographically and technologically separated, and recovery procedures must be tested before an emergency.

Good custody practice includes:

• use hardware-backed signing for material holdings;
• keep signing devices and backups in separate secure locations;
• use least privilege and separate operational, treasury and administration roles;
• require independent verification of destination addresses and transaction amounts;
• impose daily or per-transaction limits;
• maintain an approved address book with change delays;
• rotate personnel access and revoke it promptly; and
• perform controlled recovery drills.

3. Phishing, key theft and transaction deception

Phishing is the use of deceptive messages, websites or identities to induce disclosure of credentials or approval of an attacker-controlled transaction. Key theft includes malware, insecure backups, malicious browser extensions, compromised exchanges, insider misuse and social engineering.

Blockchain phishing is especially dangerous because a user may approve a valid transaction that transfers assets to the attacker. The blockchain then executes the instruction correctly. A familiar logo or correct-looking website does not prove that the destination contract or address is trustworthy.

A strong transaction-verification procedure checks the domain, wallet network, contract address, requested permissions, token allowance, destination address, amount and expected purpose. Users should avoid signing messages they do not understand. Organisations should use transaction simulation, allowlists, approval limits and dual review for high-value actions.

A common token risk is an excessive allowance: a user authorises a contract to spend an unlimited amount of a token. If the contract is compromised or malicious, the allowance may be abused later. Where supported, users should grant only the required amount and revoke obsolete approvals.

4. Double spending and finality

Double spending occurs when the same digital asset is attempted to be spent in two conflicting transactions. In a centralised database, a trusted operator can reject one transaction. In a distributed blockchain, nodes and consensus rules determine which history is accepted.

In a proof-of-work system, a conflicting transaction may be included in a competing chain. The attacker’s chance of replacing a transaction decreases as honest blocks extend the accepted chain, although it is not necessarily zero before strong finality. In proof-of-stake systems, validators and protocol rules may provide economic penalties and explicit or probabilistic finality.

Merchants should distinguish confirmation from finality. Confirmation means that a transaction has been included and followed by later blocks. Finality means that protocol rules make reversal impossible or economically and technically impractical under stated assumptions. The correct waiting policy depends on asset value, network conditions, consensus design and threat model.

Controls include waiting for an appropriate finality threshold, using reputable node infrastructure, monitoring reorganisation events, checking the correct chain and validating transaction status independently rather than trusting a wallet notification.

5. Sybil and 51% attacks

A Sybil attack occurs when an adversary creates many false identities or network participants to influence communication, reputation, peer selection or voting. Identity creation is cheap in an ordinary peer-to-peer network, so blockchains use a scarce resource such as computational work, staked value or permissioned membership.

A Sybil attack does not automatically give control of a blockchain. In proof-of-work, many identities without sufficient total hash power do not control block production. In proof-of-stake, many accounts without sufficient stake do not automatically control consensus. Nevertheless, Sybil identities can support eclipse attacks, spam, governance manipulation or misinformation.

A 51% attack is an informal term for an adversary controlling a majority of the relevant consensus power, such as hash power in proof-of-work or voting stake in some proof-of-stake designs. The attacker may censor or reorder transactions and, subject to protocol rules, reorganise recent history or double spend its own funds. It generally cannot create valid coins arbitrarily, spend another user’s funds without the required key, or violate cryptographic signature rules.

The phrase “51%” is a useful warning, not a universal mathematical threshold. Attack feasibility depends on the protocol, finality mechanism, concentration, rented resources, validator incentives and whether the attacker can sustain control. Mitigations include diversified validators or mining pools, economic penalties, checkpointing where appropriate, monitoring abnormal reorganisations, cautious confirmation policies and limiting dependence on a small number of infrastructure providers.

6. Smart-contract security

A smart contract is deployed program code whose state transitions are executed by blockchain nodes. Its immutability can preserve trustworthy rules, but it also preserves defects unless an upgrade or recovery mechanism exists.

Important vulnerabilities include:

• Reentrancy: external code is called before internal state is safely updated, allowing repeated entry. The checks-effects-interactions pattern and reentrancy guards reduce this risk.
• Access-control failure: privileged functions lack effective authorisation or use an incorrectly configured administrator.
• Integer and arithmetic errors: unsafe arithmetic may overflow or underflow in languages or compiler versions where checks are absent.
• Price-oracle manipulation: a contract relies on a price that an attacker can distort through thin liquidity, flash loans or faulty data sources.
• Flash-loan-assisted attacks: large temporary borrowing amplifies manipulation within one transaction; the loan is not itself the vulnerability, but it increases available capital.
• Front-running and transaction-order dependence: publicly visible pending transactions can be reordered or copied for advantage.
• Denial of service: loops, gas exhaustion, failing recipients or resource bottlenecks prevent required actions.
• Unsafe upgradeability: proxy administrators, implementation changes or unprotected initialisation create a powerful attack surface.
• Signature and replay errors: weak domain separation, incorrect nonce handling or cross-chain reuse permits an authorisation to be reused.

Security engineering should begin before deployment. Requirements must define invariants, such as “total balances equal recorded liabilities” or “only authorised roles may change parameters.” Code review, unit tests, property-based tests, fuzzing, static analysis, independent audits and, for high-value systems, formal verification provide complementary evidence. An audit is not a guarantee: it covers a stated scope and version, while dependencies, governance and economic assumptions may change.

A safe deployment process uses a test network, staged release, limited initial value, monitoring, bug bounty rules, emergency pause procedures and a documented upgrade policy. Pausing can limit losses but creates centralisation and availability trade-offs; its authority should therefore be narrowly defined and transparent.

7. Bridge and cross-chain risks

A bridge transfers or represents value across blockchains. Common designs include lock-and-mint systems, burn-and-mint systems, liquidity networks and systems using a multisignature committee, light client or external validators.

Bridges have a large attack surface because they connect different consensus systems. Typical failure modes include:

• compromise of a validator or signer threshold;
• forged or incorrectly verified messages;
• faulty light-client verification;
• replay of a valid cross-chain message;
• incorrect token accounting or minting limits;
• smart-contract bugs in custody or release logic;
• oracle and relayer manipulation; and
• governance takeover or rushed upgrades.

A bridge should be assessed as both a custody system and a message-verification system. Key controls include independent verification of source-chain finality, domain-separated message identifiers, replay protection, signer separation, rate limits, circuit breakers, supply reconciliation, validator monitoring, withdrawal delays and transparent reserves. Users should understand whether a bridged token is native, collateralised, or merely an issuer’s representation.

8. Privacy and data protection

Blockchains often provide pseudonymity rather than anonymity. An address may not contain a legal name, but transaction histories, timing, amounts, exchange records, IP information and behavioural patterns can enable identification. Public immutability also conflicts with data minimisation and deletion obligations in some legal contexts.

Privacy controls should be selected according to the threat model. Options include:

• avoiding personal data on-chain;
• storing sensitive information off-chain and recording only a commitment, hash or reference;
• using encryption with carefully managed keys;
• separating operational addresses and avoiding unnecessary address reuse;
• using zero-knowledge proofs where a fact must be demonstrated without revealing the underlying data; and
• applying permissioned access, selective disclosure and role-based visibility where appropriate.

A hash is not automatically private. If the original data comes from a small or predictable set, an attacker can guess candidates and compare hashes. Encryption also requires key management, rotation and a plan for future compromise. Privacy-enhancing technology may reduce transparency, complicate compliance or increase implementation risk, so privacy, auditability and lawful access must be balanced explicitly.

Privacy-by-design requires identifying data subjects, purposes, retention requirements, access rights and cross-border obligations before deployment. Organisations should conduct data-protection impact assessments where required and avoid treating a blockchain as an appropriate database merely because it is available.

9. Auditing, monitoring and governance

A professional assurance programme combines technical, operational and governance controls. A compact control framework is:

On-chain monitoring should detect unusual withdrawals, rapid parameter changes, new privileged addresses, abnormal minting, bridge message spikes, oracle divergence and failed transaction patterns. Alerts need severity levels and named responders; an alert without an owner is not an effective control.

Governance must define who can upgrade contracts, change risk limits, add signers, pause operations and communicate with users. Timelocks and public change notices provide review time, but they do not replace secure administration. Independent reconciliation should compare on-chain balances, liabilities, reserves and off-chain records.

10. Incident response

An incident-response plan should be rehearsed, not merely written. A practical sequence is:

1. Prepare: maintain contacts, authority matrices, backups, playbooks, monitoring and legal channels.
2. Detect and analyse: preserve logs, identify affected keys or contracts, determine whether the event is ongoing and estimate exposure.
3. Contain: pause vulnerable functions where justified, revoke permissions, isolate systems and prevent further signing. Avoid destroying evidence.
4. Eradicate and recover: patch or replace compromised components, rotate keys, validate balances, restore service gradually and monitor for recurrence.
5. Communicate and learn: provide accurate notices, meet reporting duties, support affected users and conduct a blameless post-incident review.

During a suspected key compromise, the priority is to move remaining assets to a pre-approved safe destination using an unaffected signing path. Teams must be careful not to trust an attacker-controlled interface or reuse compromised devices. Recovery decisions should consider legal authority, customer instructions, evidence preservation and the possibility that an apparent exploit is a false alarm.

Applied case: illustrative bridge compromise

Background

An illustrative digital-asset company uses a bridge whose five signing services authorise releases when three signatures approve a cross-chain message. The company stores the bridge’s reserve assets in a contract and advertises rapid settlement.

Problem

An attacker compromises two signing environments through a malicious software update and obtains valid signing authority. The attacker submits forged release messages and drains a substantial portion of the reserve. Monitoring detects an unusual sequence of withdrawals but does not automatically pause the bridge.

Analysis

The immediate cause is signer compromise, but the deeper causes are concentrated infrastructure, insufficient update verification, no withdrawal-rate limit, and unclear emergency authority. The bridge’s cryptography did not fail; the trust boundary around message approval failed. A secondary risk is that users continue depositing assets after the exploit because the public interface still reports normal operation.

Approach and solution

The response team freezes releases, disables the compromised signers, preserves logs and informs exchanges and infrastructure partners. It verifies the final state independently, publishes affected transaction identifiers and prevents further deposits. Before reopening, it replaces signing devices, separates signer operators and hosting providers, introduces hardware-backed approval, adds a daily release cap and requires a timelock for large transfers. The company also deploys independent reserve reconciliation and an automated circuit breaker for abnormal withdrawal patterns.

Outcome and learning points

Operations resume in stages after an external review and controlled testing. Some losses cannot be recovered, demonstrating that prevention and rapid containment are more reliable than post-event reversal. The case shows that security is socio-technical: code quality, key custody, supplier security, monitoring, governance and communication must be assessed together.

Challenges, ethics and regulation

Blockchain security controls may conflict with decentralisation, censorship resistance, usability and privacy. A pause key can protect users during an exploit but can also be abused to censor transactions. Identity checks may reduce financial crime while increasing surveillance and excluding legitimate users. Responsible governance therefore requires proportionality, transparency, accessible appeal mechanisms and separation of duties.

Organisations must consider applicable rules concerning custody, financial crime prevention, consumer protection, cybersecurity, privacy, market conduct, reporting and operational resilience. Requirements vary by jurisdiction and business model; technical teams should obtain qualified legal advice rather than assuming that decentralisation removes accountability. Ethical practice also includes honest disclosure of audit limitations, reserve conditions, centralised dependencies and known risks.

Best-practice checklist

Before launch, a project should be able to answer “yes” to the following questions:

• Are keys protected by an appropriate custody model and tested recovery process?
• Are privileged roles minimal, separated and monitored?
• Has the code been independently reviewed and tested against explicit security properties?
• Are oracle, bridge, upgrade and dependency risks documented?
• Are privacy and data-retention decisions made before data is written on-chain?
• Are finality, confirmation and reorganisation assumptions documented?
• Are rate limits, circuit breakers and emergency authorities defined?
• Is there a rehearsed incident-response plan with communication responsibilities?
• Are users given clear information about irreversible transactions and residual risk?

Chapter Summary

Blockchain security is a layered discipline involving keys, applications, consensus, infrastructure and governance. Key theft and phishing exploit users or signing systems; double spending exploits uncertainty about transaction history and finality; Sybil attacks create false identities; and 51% attacks seek majority consensus influence. Smart contracts introduce software, economic and governance vulnerabilities, while bridges enlarge the attack surface by connecting independent systems.

Effective risk management combines prevention, detection, response and governance. Hardware-backed custody, multisignature controls, least privilege, secure development, independent audits, monitoring, rate limits, privacy-by-design and rehearsed incident response are complementary rather than interchangeable. No audit, consensus mechanism or privacy tool eliminates all risk. Professional practice requires explicit assumptions, accountable decision-makers, transparent limitations and continuous review.

Key Terms

51% attack: Control of a majority of relevant consensus power, enabling possible censorship or history reorganisation.

Address: An identifier used to receive or reference blockchain assets.

Bridge: A system that transfers or represents assets or messages across blockchains.

Confirmation: Inclusion of a transaction in a block followed by subsequent accepted blocks.

Consensus: Rules by which network participants agree on valid state and transaction history.

Custody: Control, safeguarding and administration of private keys or assets.

Double spending: Attempting to use the same digital asset in conflicting transactions.

Finality: The condition in which a transaction is irreversible or extremely impractical to reverse under protocol assumptions.

Key theft: Unauthorised acquisition or use of a private key or signing credential.

Least privilege: Giving each user or process only the permissions required for its role.

Multisignature: A control requiring multiple authorised keys to approve an action.

Oracle: A service supplying external data to a blockchain application.

Phishing: Deception intended to obtain credentials or induce a harmful approval.

Private key: Cryptographic secret used to authorise transactions.

Reentrancy: Repeated entry into a contract before its prior state update is complete.

Sybil attack: Creation of many false identities to influence network activity.

Timelock: A delay imposed before an approved action becomes executable.

Zero-knowledge proof: A method of proving a statement without revealing the underlying secret.

Review Questions

Short Answer Questions

1. Why does possession of a private key generally provide control over blockchain assets?
2. Distinguish confirmation from finality.
3. What is a Sybil attack, and why does proof-of-stake make identity creation alone insufficient for consensus control?
4. Name two common smart-contract vulnerabilities and one mitigation for each.
5. Why is a hash of personal data not necessarily private?

Long Answer Questions

1. Compare self-custody, hosted custody and multisignature custody, including their principal risks and controls.
2. Explain how a 51% attack differs from a Sybil attack and identify appropriate mitigations for each.
3. Discuss why bridges have a larger security surface than many single-chain applications.
4. Develop a security assurance programme covering preventive, detective and corrective controls.
5. Explain how privacy-by-design can be applied to an application that needs both auditability and confidentiality.

Analytical / Application Questions

1. A treasury uses one administrator key to upgrade a high-value contract. Analyse the risks and design a safer governance and recovery arrangement.
2. A merchant receives a payment but accepts it immediately after one block. Evaluate the decision using confirmation, finality, transaction value and network conditions.
3. A bridge experiences rapid withdrawals after two validator machines install the same software update. Construct an incident-response plan and identify the underlying control failures.

Multiple Choice Questions with Answers

Question 1

Which control most directly reduces the risk that one compromised key can drain institutional funds?

A. Publishing more wallet addresses

B. Using a multisignature policy with separated signers

C. Increasing transaction display brightness

D. Removing transaction logs

Correct Answer: B. Using a multisignature policy with separated signers

Question 2

What does a 51% attack generally allow an attacker to do?

A. Create valid signatures for every user

B. Read encrypted private keys automatically

C. Potentially censor or reorganise recent transactions

D. Change any smart-contract code without an upgrade path

Correct Answer: C. Potentially censor or reorganise recent transactions

Question 3

Why is a blockchain transaction that is confirmed not always final?

A. A confirmed transaction may still be affected by a chain reorganisation

B. Confirmation means the private key is publicly revealed

C. Finality applies only to token transfers below a threshold

D. Confirmed transactions are stored only temporarily

Correct Answer: A. A confirmed transaction may still be affected by a chain reorganisation

Question 4

Which situation is an example of phishing?

A. A node rejects an invalid block

B. A user receives a deceptive website request to approve a malicious transfer

C. A validator is penalised for violating consensus rules

D. A contract checks a balance before a transfer

Correct Answer: B. A user receives a deceptive website request to approve a malicious transfer

Question 5

What is the main purpose of a circuit breaker in a bridge?

A. To increase the number of token types automatically

B. To accelerate every withdrawal regardless of risk

C. To pause or limit activity when abnormal behaviour is detected

D. To replace all cryptographic signatures with passwords

Correct Answer: C. To pause or limit activity when abnormal behaviour is detected

Question 6

Which practice best addresses reentrancy risk?

A. Update critical internal state before making external calls

B. Allow unlimited external calls before state updates

C. Disable all event logging

D. Store private keys in contract storage

Correct Answer: A. Update critical internal state before making external calls

Question 7

Why is a seed phrase treated as a root credential?

A. It is merely a public account label

B. It can derive or recover multiple private keys

C. It expires after one transaction

D. It proves that a contract has been audited

Correct Answer: B. It can derive or recover multiple private keys

Question 8

Which statement about a Sybil attack is most accurate?

A. Many identities automatically equal majority consensus power

B. It creates false identities to influence network activity or communication

C. It is identical to a smart-contract arithmetic error

D. It requires theft of every user’s private key

Correct Answer: B. It creates false identities to influence network activity or communication

Question 9

Which privacy measure avoids placing sensitive personal information directly on-chain?

A. Recording the full identity document in transaction data

B. Publishing a commitment or hash while retaining data off-chain

C. Reusing one address for every customer

D. Making all transaction amounts public twice

Correct Answer: B. Publishing a commitment or hash while retaining data off-chain

Question 10

What is the first priority when an active key compromise is suspected?

A. Continue normal signing until the next audit

B. Delete all logs immediately

C. Contain the compromise and prevent further unauthorised signing

D. Publish unverified accusations against suspected attackers

Correct Answer: C. Contain the compromise and prevent further unauthorised signing