12. Governance, Law, Ethics and Sustainability

Introduction and Context

Blockchain systems are often described as trust infrastructures that reduce dependence on central intermediaries. That description is technically useful but institutionally incomplete. A blockchain does not eliminate governance; it redistributes governance across software developers, validators, token holders, businesses, regulators, courts, and affected communities. Nor does cryptography determine whether an activity is lawful, ethical, taxable, environmentally responsible, or socially legitimate.

For cybersecurity professionals, governance and law are not peripheral concerns. A technically secure system may still expose personal data, facilitate sanctions evasion, create unclear liability, or operate in breach of financial regulation. Conversely, a legally compliant project may remain vulnerable to smart-contract exploits, opaque decision-making, or concentrated control. Effective blockchain strategy therefore requires simultaneous attention to protocol design, organizational accountability, jurisdictional rules, ethical duties, and sustainability.

This chapter examines the relationship between on-chain and off-chain governance; accountability and legal enforceability; anti-money-laundering and know-your-customer obligations; sanctions, taxation, and data protection; ethical challenges; and the environmental consequences of different blockchain architectures. Because regulation differs across jurisdictions and changes frequently, the chapter emphasizes analytical frameworks rather than jurisdiction-specific legal advice.

Learning Objectives

After completing this chapter, students should be able to:

1. Distinguish on-chain governance from off-chain governance and evaluate their interaction.

2. Analyse accountability, liability, legal personality, and enforceability in blockchain arrangements.

3. Explain the relevance of AML, KYC, sanctions screening, taxation, and data-protection principles.

4. Evaluate ethical concerns involving privacy, exclusion, manipulation, surveillance, and concentration of power.

5. Compare the sustainability implications of proof-of-work, proof-of-stake, and other consensus approaches.

6. Apply a governance and compliance framework to a blockchain project or incident.

7. Recommend controls that balance decentralisation, security, legal compliance, and social legitimacy.

Governance Beyond the Protocol

Governance refers to the processes through which rules are created, interpreted, enforced, and changed. In a blockchain ecosystem, rules may be embedded in consensus software, expressed through token-holder voting, imposed by an operating company, or supplied by courts and regulators. Governance is therefore broader than voting on protocol upgrades.

On-chain governance

On-chain governance uses blockchain transactions and smart contracts to propose, vote on, and implement changes. A proposal may alter fees, inflation, validator requirements, treasury expenditure, or application parameters. The process can be transparent, auditable, and automated. It may also reduce ambiguity about voting outcomes and execution.

Its weaknesses are equally important. Token-based voting can convert financial wealth into political power. Large holders, exchanges, custodians, or coordinated insiders may dominate decisions. Voters may be rationally apathetic, lacking technical expertise or incentives to examine complex proposals. Automated execution can make an erroneous or malicious decision difficult to reverse. A formally valid vote may therefore possess limited democratic legitimacy.

Off-chain governance

Off-chain governance includes developer discussions, foundation or company decisions, validator coordination, social norms, informal signalling, legal agreements, emergency interventions, and judicial or regulatory processes. Many supposedly decentralised systems depend heavily on maintainers who control repositories, release software, publish standards, or coordinate responses to crises.

Off-chain governance can provide expertise, deliberation, and flexibility. It also creates accountability questions: Who has authority to act? Are decisions documented? Can affected users appeal? What prevents a foundation, developer group, or infrastructure provider from exercising unacknowledged control?

A layered governance model

A useful analytical model treats blockchain governance as four interacting layers:

• Protocol layer: consensus rules, validation, cryptographic permissions, and upgrade mechanisms.
• Application layer: smart-contract logic, interfaces, oracles, custodial arrangements, and business rules.
• Organisational layer: developers, foundations, companies, token communities, service providers, and boards.
• Public-law layer: legislation, regulation, courts, taxation authorities, and enforcement agencies.

A governance failure at one layer can defeat controls at another. For example, an immutable smart contract cannot resolve a mistaken transfer unless the application includes a recovery mechanism or an off-chain legal process can identify a responsible party. Governance design should therefore specify decision rights, emergency powers, transparency duties, conflicts-of-interest controls, and procedures for upgrades and disputes.

Accountability, Liability and Legal Enforceability

Blockchain records can establish what an address submitted and when, but an address is not necessarily a legal person. Attribution requires evidence linking keys, devices, accounts, organisations, or agents to real-world actors. This distinction is central to liability. A person who deploys a contract, a person who controls an upgrade key, an operator who markets a service, and a validator who confirms transactions may bear different responsibilities.

Legal enforceability depends on the applicable law, the parties’ intentions, formation requirements, evidence, consumer-protection rules, and the nature of the transaction. A smart contract is code that executes conditions; a legally enforceable contract is a legal relationship. The two may coincide, but neither automatically guarantees the other. Contractual terms, governing-law clauses, dispute-resolution provisions, identity requirements, and records of consent can strengthen enforceability.

Organisations should avoid the assumption that decentralisation eliminates liability. A company may remain responsible for marketing, custody, customer assets, data processing, or the operation of an identifiable platform. A decentralised autonomous organisation may face uncertainty concerning legal personality, fiduciary responsibilities, taxation, and the status of participants. Legal wrappers, such as companies, trusts, foundations, or partnerships, can clarify responsibility but do not immunise participants from law.

Accountability can be strengthened through:

• documented roles and responsibility matrices;
• multi-signature administration and separation of duties;
• independent smart-contract audits and controlled deployment procedures;
• incident-response and rollback policies where technically possible;
• transparent treasury, voting, and conflict-of-interest disclosures;
• records linking decisions to authorised individuals or committees; and
• insurance, reserves, indemnities, and carefully drafted user agreements.

These controls introduce centralisation, but centralisation is not inherently a defect. The appropriate question is whether concentrated authority is visible, constrained, reviewable, and proportionate to the risks it creates.

Financial Crime, Sanctions and Taxation

Blockchain’s pseudonymous design, global reach, rapid settlement, and use of mixers, bridges, privacy-enhancing tools, and unhosted wallets create challenges for financial-crime compliance. The same features can support legitimate privacy and financial inclusion. Compliance should therefore be risk-based rather than based on the assumption that every digital-asset transaction is suspicious.

AML and KYC

Anti-money-laundering controls generally seek to identify customers, understand beneficial ownership, assess risk, monitor transactions, retain records, and report suspicious activity where required. Know-your-customer procedures are one component of this wider framework. A service that exchanges assets, holds customer funds, transfers value, or provides certain financial services may fall within a regulated perimeter, depending on the jurisdiction.

A blockchain business should map its activities before selecting controls. Relevant questions include: Does it have custody? Can it freeze or redirect assets? Does it intermediate transactions? Does it serve customers in regulated jurisdictions? Are agents or distributors involved? Are privacy tools or cross-chain transfers used? A compliance programme may include identity verification, sanctions screening, wallet-risk assessment, transaction monitoring, travel-rule processes where applicable, suspicious-activity escalation, employee training, and independent testing.

Analytics tools can cluster addresses, identify exposure to illicit services, detect unusual transaction patterns, and support investigations. They do not provide certainty. Heuristics produce false positives, attribution can be wrong, and privacy-preserving technologies can limit visibility. Human review, documented reasoning, and appeal processes are essential.

Sanctions

Sanctions compliance requires screening relevant persons, entities, wallets, jurisdictions, and transactions against applicable lists and restrictions. A blockchain transfer may be irreversible, cross-border, and executed without an intermediary, but that does not remove legal exposure for an organisation facilitating or benefiting from the transaction. Controls should address both direct customers and indirect exposure through counterparties, liquidity pools, custodians, bridges, and service providers.

A difficult issue arises when a protocol is technically accessible to everyone but a front-end company, developer, validator, or infrastructure provider has a regulated presence. The legal analysis depends on facts and jurisdiction. Organisations should document their sanctions-risk assumptions, escalation procedures, blocking or rejection controls, and evidence-retention practices.

Taxation

Tax treatment may depend on whether an asset is classified as property, currency, a security, a commodity, a financial instrument, or another category. Tax consequences can arise from trading, mining or validation rewards, staking, lending, airdrops, token issuance, employment compensation, and decentralised-finance activity. Valuation is difficult where assets are illiquid, volatile, or received through complex protocols.

A robust tax-control environment records transaction histories, acquisition and disposal values, fees, wallet ownership, dates, counterparties, and the purpose of transactions. Businesses should distinguish accounting records from raw blockchain data and preserve an auditable reconciliation. Tax advice must be obtained for the relevant jurisdiction; a public ledger does not by itself establish the correct tax treatment.

Data Protection and Privacy

Immutability conflicts with legal and ethical expectations that personal information should be minimised, corrected, deleted, or processed only for legitimate purposes. A blockchain address may not be directly identifying at first, but transaction histories can become personal data when combined with exchange records, IP information, device identifiers, or behavioural analysis.

A privacy-preserving architecture begins by asking whether personal data belongs on-chain at all. Common approaches include storing only hashes or commitments on-chain, keeping the underlying data in controlled off-chain repositories, using decentralised identifiers, applying selective disclosure, encrypting sensitive fields, and using zero-knowledge proofs to demonstrate a fact without revealing the underlying information.

Hashing is not a universal solution. If the original data can be obtained or guessed, a hash may remain linkable to an individual. Encryption also requires key-management, access control, rotation, and procedures for compromise. Off-chain storage reduces immutability conflicts but creates conventional risks involving administrators, databases, availability, and unauthorised alteration.

Data-protection governance should identify the controller and processors, establish a lawful purpose, minimise collection, conduct privacy-impact assessments, define retention periods, address international transfers, protect data subjects’ rights, and provide breach-response procedures. Organisations should also assess whether automated profiling or blockchain analytics produces discriminatory or unjust outcomes.

Ethical Questions in Blockchain Systems

Ethics extends beyond legal compliance. A system may be lawful yet unfair, manipulative, exclusionary, or harmful. Four recurring ethical tensions deserve attention.

First, transparency can conflict with privacy. Public ledgers support auditability but may expose financial behaviour permanently. Second, decentralisation can conflict with responsibility: when control is dispersed, victims may struggle to obtain remedies. Third, financial innovation can conflict with consumer protection when complex products are marketed to users who cannot assess volatility or smart-contract risk. Fourth, permissionless access can conflict with the prevention of fraud, exploitation, and criminal finance.

Additional concerns include governance capture, insider allocation of tokens, misleading claims of decentralisation, predatory token design, front-running and maximal extractable value, exclusion caused by transaction fees, and the social effects of automated liquidation. Ethical assessment should consider affected stakeholders rather than only token holders. Vulnerable users, workers, communities near energy infrastructure, and individuals whose data is analysed may bear costs without possessing governance power.

A practical ethical review asks:

1. Who benefits and who bears the risks?

2. Can users understand the system and meaningfully consent?

3. Are there remedies when code behaves unexpectedly?

4. Does the system create avoidable surveillance or discrimination?

5. Are governance rights distributed fairly relative to exposure to harm?

6. What happens to users who lack sophisticated devices, identity documents, or technical knowledge?

Sustainability and Environmental Impact

Environmental assessment must distinguish energy consumption from environmental impact. Energy use depends on hardware, utilisation, electricity sources, geography, and time. Impact also includes emissions, water use, electronic waste, land use, and the opportunity cost of electricity. Claims about sustainability should therefore be based on transparent methodology rather than simplistic labels.

Proof-of-work secures networks by requiring miners to perform computational work. This can provide strong resistance to certain attacks but may consume substantial electricity and encourage specialised hardware. The environmental burden varies with the energy mix and equipment lifecycle. Proof-of-stake replaces intensive computation with economic collateral and penalties for dishonest or unavailable validators. It generally reduces operational energy demand, although it introduces different concerns involving wealth concentration, validator infrastructure, governance power, and correlated failures.

Other approaches include permissioned consensus, federated validation, proof-of-authority, and layer-two systems that batch transactions. These can improve throughput and reduce per-transaction resource use but may increase reliance on selected operators or introduce bridge and settlement risks. A lower energy profile does not automatically make a system socially sustainable.

Sustainability decisions should evaluate functional need, transaction volume, hardware lifecycle, renewable-energy claims, accessibility, resilience, and governance concentration. Organisations can use carbon accounting, supplier disclosures, lifecycle assessment, energy monitoring, efficient software, transaction batching, and appropriate data-retention policies. They should avoid presenting offsets as a substitute for reducing direct impacts.

A Governance and Compliance Decision Framework

A blockchain project can be assessed through a sequence of questions rather than through a single compliance checklist.

Define the activity. Identify the asset, users, functions, custody model, jurisdictions, and role of each participant.

Map authority and dependencies. Document who writes code, controls keys, operates interfaces, validates transactions, supplies data, and can alter or suspend the system.

Classify legal exposure. Consider financial regulation, consumer law, AML obligations, sanctions, taxation, privacy, intellectual property, employment law, and civil liability.

Assess threats and harms. Combine cybersecurity threat modelling with privacy, financial-crime, market-abuse, environmental, and human-rights assessments.

Select proportionate controls. Use identity and monitoring controls where required, privacy-enhancing technologies where appropriate, secure development practices, governance disclosures, and escalation procedures.

Test and review. Conduct audits, red-team exercises, legal reviews, tabletop incidents, and stakeholder consultations. Reassess after upgrades, new jurisdictions, or significant changes in use.

This framework avoids two common extremes: treating regulation as a late-stage obstacle or treating decentralisation as a substitute for institutional responsibility.

Applied Case: Meridian Supply Network

The following is an illustrative case.

Background

Meridian, a consortium of manufacturers and logistics firms, proposes a blockchain platform for recording the origin of high-value components. Suppliers upload certificates, transport providers record custody events, and buyers verify provenance. A public blockchain is used to timestamp proofs, while detailed documents remain in an off-chain repository.

Situation and problem

The consortium discovers that some suppliers operate through high-risk jurisdictions. Several certificates contain personal information about individual workers. A validator proposes an upgrade controlled by a small committee, while buyers assume that every ledger entry is independently verified. The project team must determine whether the design is legally defensible, ethically acceptable, and operationally sustainable.

Analysis

The ledger proves that a record was submitted, not that the underlying certificate was true. Responsibility for verification must therefore be allocated to named organisations. The consortium also needs to determine whether it is acting as a data controller and whether worker information is necessary for the provenance purpose. Supplier onboarding creates AML, sanctions, and beneficial-ownership questions, particularly where payments or trade financing are integrated.

The committee’s upgrade power creates a governance dependency that should be disclosed. Concentrated control may be justified for emergency response, but it requires multi-party approval, audit logs, conflict-of-interest rules, and a published change process. Finally, the environmental profile should be compared with a permissioned or layer-two design rather than assumed from the use of the word blockchain.

Strategy and solution

Meridian adopts a permissioned validation model with independent consortium members and separates the roles of document issuer, verifier, validator, and platform operator. Personal information is stored off-chain with access controls; on-chain records contain a commitment, document type, issuer, timestamp, and revocation status. Suppliers undergo risk-based due diligence and sanctions screening. Smart contracts prevent unauthorised changes but permit a documented revocation process for fraudulent certificates.

The consortium publishes a governance charter, service-level responsibilities, incident procedures, voting thresholds, and an emergency committee subject to retrospective review. Annual privacy and security assessments are combined with sustainability reporting based on measured infrastructure use.

Outcome

The revised design is less rhetorically decentralised but more accountable. Buyers receive clearer evidence about what the ledger verifies and what remains a supplier assertion. Personal-data exposure is reduced, and the consortium can investigate suspicious participants without treating automated analytics as conclusive proof.

Learning points

The case demonstrates that trustworthy blockchain deployment depends on evidence quality, role clarity, privacy engineering, risk-based compliance, and transparent governance. A ledger can improve integrity of records without guaranteeing the truth of real-world events. The most suitable architecture is the one that matches the trust, legal, and operational requirements of the use case.

Challenges, Limitations and Common Mistakes

A frequent mistake is assuming that code is law. Code determines execution within a technical environment, whereas law determines rights, duties, remedies, and consequences beyond that environment. Another mistake is treating a public ledger as inherently transparent when users may not understand the data, the governance process, or the limitations of analytics.

Projects also fail when compliance is bolted on after launch, when wallet addresses are treated as verified identities, when sanctions screening ignores indirect exposure, or when privacy teams are excluded from architecture decisions. Governance can become symbolic if token voting is dominated by insiders or if emergency powers have no sunset or review mechanism. Sustainability claims become unreliable when they report only operational electricity and omit hardware, infrastructure, or energy-source assumptions.

Regulatory fragmentation is a persistent limitation. The same activity may be classified differently across jurisdictions, and cross-border enforcement may involve conflicting requirements. Professional teams should maintain a legal-risk register, obtain local advice, record assumptions, and design controls that can adapt without compromising core security properties.

Current Developments and Strategic Implications

Several developments are reshaping blockchain governance. Regulators are increasingly focusing on identifiable service providers, custody, stable-value arrangements, consumer protection, market integrity, and financial-crime controls. Privacy-enhancing computation, zero-knowledge proofs, decentralised identity, and verifiable credentials may allow stronger compliance with less disclosure. At the same time, artificial intelligence is being used for fraud detection, code review, sanctions analytics, and governance analysis, but automated outputs require validation because biased data and false attribution can produce unjust decisions.

Interoperability increases utility but expands the attack surface and complicates jurisdictional analysis. Tokenisation of conventional assets may bring blockchain systems closer to established financial rules rather than outside them. Institutional adoption is therefore likely to favour controlled access, auditable governance, privacy-preserving compliance, and clearly assigned responsibility over claims of absolute permissionlessness.

Best Practices for Professionals

Professionals designing or assessing blockchain systems should:

• conduct legal, privacy, ethical, security, and sustainability assessments at the design stage;
• identify every party with technical or practical control;
• separate identity data from public transaction data whenever possible;
• use risk-based AML and sanctions controls with human review and documented appeals;
• define upgrade, emergency, dispute, and remediation processes before deployment;
• maintain accurate records for taxation, accounting, investigations, and audits;
• test smart contracts, bridges, oracles, key-management systems, and governance mechanisms;
• disclose limitations, conflicts of interest, concentration of power, and environmental assumptions; and
• review controls whenever the protocol, business model, user population, or regulatory environment changes.

Chapter Summary

Blockchain governance combines protocol rules, application logic, organisational authority, and public law. On-chain voting can improve transparency and execution but may suffer from token concentration, apathy, and technical complexity. Off-chain governance supplies expertise and flexibility while creating accountability and legitimacy challenges. Smart contracts execute code but do not automatically create legally enforceable relationships or eliminate liability.

AML, KYC, sanctions, and taxation require activity-based legal analysis, reliable records, risk-based controls, and careful treatment of pseudonymous transactions. Data protection favours minimisation, off-chain storage, selective disclosure, and privacy-enhancing technologies, while recognising that hashes and encryption are not complete solutions. Ethical evaluation must consider power, consent, fairness, remedy, and impacts on vulnerable stakeholders. Sustainability depends on consensus design, energy sources, hardware, infrastructure, and governance—not merely on transaction speed or a label such as decentralised. Strategic blockchain deployment therefore aligns technical architecture with accountable governance, lawful conduct, ethical responsibility, and measurable environmental performance.

Key Terms

On-chain governance: Governance conducted through blockchain transactions, smart contracts, and protocol voting.

Off-chain governance: Decision-making occurring through organisations, developers, social processes, agreements, or public institutions outside the ledger.

Accountability: The obligation to explain decisions, accept responsibility, and provide remedies for harm.

Legal enforceability: The capacity of a legal arrangement to create rights and duties recognised and remedied by a competent authority.

Smart contract: Program code that automatically executes specified conditions on a blockchain.

AML: Anti-money-laundering measures designed to prevent and detect illicit movement of funds.

KYC: Know-your-customer procedures for identifying and assessing customers.

Beneficial owner: The natural person who ultimately owns or controls an entity or arrangement.

Sanctions screening: Checking persons, entities, jurisdictions, or transactions against applicable restrictive-measure lists.

Pseudonymity: Identification through an address or identifier that may be linked to a real person through additional evidence.

Data minimisation: Collecting and retaining only information necessary for a defined purpose.

Zero-knowledge proof: A cryptographic method for proving a statement without revealing the underlying information.

Privacy impact assessment: A structured evaluation of privacy risks and safeguards associated with processing activities.

Proof-of-work: Consensus based on computational work used to secure transaction agreement.

Proof-of-stake: Consensus in which validators commit economic value and may be penalised for dishonest conduct.

Governance capture: Control of decision-making by a powerful insider, coalition, or concentrated group.

Decentralised autonomous organisation: An organisation coordinated substantially through blockchain rules, tokens, and smart contracts.

Sustainability: The capacity of a system to operate responsibly over time while managing environmental, social, and economic impacts.

Review Questions

Short Answer Questions

1. What is the principal difference between on-chain and off-chain governance?

2. Why does a blockchain address not automatically identify a legally liable person?

3. Why is hashing personal data not always sufficient for privacy protection?

4. What functions do AML and KYC controls perform?

5. How does proof-of-stake differ from proof-of-work in its security mechanism?

Long Answer Questions

1. Explain the four-layer governance model and show how failures at one layer can affect the others.

2. Discuss the relationship between smart-contract execution and legal enforceability.

3. Analyse the major privacy, ethical, and accountability challenges of public blockchains.

4. Compare the sustainability trade-offs of proof-of-work, proof-of-stake, and permissioned consensus.

5. Develop a governance and compliance framework for a blockchain-based financial service.

Analytical / Application Questions

1. A token-governed protocol approves a proposal supported by 60 percent of votes, but 80 percent of voting power belongs to three connected wallets. Evaluate the legitimacy and risk of the decision, and recommend safeguards.

2. A company stores employee identity documents on-chain and argues that encrypted data is safe because it cannot be altered. Identify the legal, privacy, and security problems and propose a redesign.

3. A cross-border exchange detects that a customer’s wallet has indirect exposure to a sanctioned service through a bridge. Design an investigation and escalation process that balances sanctions compliance, false-positive risk, and customer fairness.

22. Multiple Choice Questions with Answers

Question 1

Which statement best describes the relationship between on-chain and off-chain governance?

A. On-chain governance eliminates the need for organisations and legal institutions.

B. Off-chain governance is relevant only when a blockchain has failed technically.

C. They are interacting layers in which code-based rules and human or institutional decisions influence one another.

D. On-chain governance applies only to private blockchains.

Correct Answer: C. They are interacting layers in which code-based rules and human or institutional decisions influence one another.

Question 2

Why does a smart contract not automatically guarantee legal enforceability?

A. Smart contracts cannot execute transactions.

B. Legal enforceability depends on applicable law, consent, evidence, rights, duties, and available remedies.

C. Blockchain records are never admissible as evidence.

D. Only governments can deploy smart contracts.

Correct Answer: B. Legal enforceability depends on applicable law, consent, evidence, rights, duties, and available remedies.

Question 3

Which control is most directly associated with identifying the person who ultimately controls a customer entity?

A. Beneficial-ownership assessment

B. Transaction batching

C. Proof-of-work mining

D. Hash collision testing

Correct Answer: A. Beneficial-ownership assessment

Question 4

A company wants to reduce privacy risks while retaining public proof that a document existed at a particular time. Which design is most appropriate?

A. Store the complete document publicly forever.

B. Store a commitment or hash on-chain and retain the document in a controlled off-chain repository.

C. Publish the document encryption key on-chain.

D. Remove all timestamps from the system.

Correct Answer: B. Store a commitment or hash on-chain and retain the document in a controlled off-chain repository.

Question 5

Why can blockchain analytics not be treated as conclusive proof that an address belongs to a criminal actor?

A. Blockchain transactions cannot be analysed.

B. Analytics are always prohibited by data-protection law.

C. Address attribution uses probabilistic methods and may generate false positives.

D. Criminal actors never use blockchain addresses.

Correct Answer: C. Address attribution uses probabilistic methods and may generate false positives.

Question 6

Which governance safeguard most directly limits abuse of emergency upgrade authority?

A. Allowing one anonymous developer to change the code immediately

B. Removing all records of emergency actions

C. Using multi-party approval, defined scope, time limits, and retrospective review

D. Preventing users from seeing governance proposals

Correct Answer: C. Using multi-party approval, defined scope, time limits, and retrospective review

Question 7

Which statement most accurately captures a sustainability comparison between proof-of-work and proof-of-stake?

A. Proof-of-stake necessarily has no environmental impact.

B. Proof-of-work relies on computational work, while proof-of-stake relies primarily on economic collateral and validation.

C. Both mechanisms always consume identical energy.

D. Proof-of-work cannot provide security against attacks.

Correct Answer: B. Proof-of-work relies on computational work, while proof-of-stake relies primarily on economic collateral and validation.

Question 8

A public ledger proves that a supplier submitted a certificate. What additional issue must be addressed before treating the certificate as reliable evidence?

A. Whether the underlying real-world information was independently verified

B. Whether the ledger contains any timestamps

C. Whether all users own mining hardware

D. Whether the certificate was stored without any cryptography

Correct Answer: A. Whether the underlying real-world information was independently verified

Question 9

Which practice best reflects a risk-based AML approach?

A. Treat every transaction as criminal.

B. Ignore transactions involving unhosted wallets.

C. Assess customer, jurisdictional, product, and transaction risks and apply proportionate monitoring.

D. Rely solely on the customer’s choice of wallet name.

Correct Answer: C. Assess customer, jurisdictional, product, and transaction risks and apply proportionate monitoring.

Question 10

Why is decentralisation not by itself a defence against organisational liability?

A. Decentralised systems cannot use cryptography.

B. Identifiable operators may still control marketing, custody, interfaces, data processing, or service delivery.

C. All decentralised projects are legally corporations.

D. Validators are always government employees.

Correct Answer: B. Identifiable operators may still control marketing, custody, interfaces, data processing, or service delivery.