Blockchain Strategy, Analytics and Decision-Making

Introduction

Blockchain initiatives are often presented as technology projects, but their success depends primarily on strategy, governance, economics, and adoption. A technically sound distributed ledger may create little value if participants do not share a business problem, if legal responsibilities are unclear, or if the cost of coordination exceeds the benefit of shared records. Conversely, a carefully designed blockchain network can reduce reconciliation, improve provenance, automate contractual processes, and create new forms of inter-organisational collaboration.

This chapter presents a managerial framework for deciding whether and how to pursue a blockchain initiative. It integrates stakeholder analysis, feasibility assessment, build–buy–join choices, total-cost analysis, return on investment, network effects, and adoption measurement. It also explains how on-chain data should be combined with operational, financial, and customer data to support evidence-based decisions.

The central principle is that blockchain should be selected because its organisational and economic characteristics fit the problem—not because it is technologically fashionable.

Learning Objectives

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

1. Identify and analyse stakeholders in a blockchain ecosystem.
2. Distinguish blockchain-suitable problems from problems better solved by conventional databases or process redesign.
3. Evaluate technical, economic, legal, organisational, and ecosystem feasibility.
4. Compare build, buy, join, and hybrid implementation choices.
5. Estimate total cost of ownership, benefits, ROI, and payback period.
6. Explain direct and indirect network effects and their implications for adoption.
7. Design useful on-chain and operational performance metrics.
8. Interpret analytics while accounting for data quality, privacy, causality, and governance.
9. Make and justify a strategic blockchain recommendation.

1. Blockchain as a Strategic Capability

A blockchain network is a shared information and transaction infrastructure. Its strategic value can arise from several capabilities:

• Shared state: authorised participants access a common transaction history rather than maintaining disconnected records.
• Tamper-evident history: cryptographic linking and consensus make unauthorised alteration detectable, although blockchain does not guarantee that the original data was truthful.
• Programmable coordination: smart contracts can enforce agreed rules automatically.
• Selective transparency: participants may obtain a common view while access to sensitive data is restricted.
• Tokenisation: rights, assets, claims, or incentives may be represented digitally.
• Reduced dependence on a central intermediary: this is valuable only where a trusted central operator is unavailable, costly, or strategically unacceptable.

Blockchain is not automatically superior to a conventional database. A conventional database is normally preferable when one organisation is trusted to control the data, high transaction throughput and low latency are essential, records do not need to be shared across organisational boundaries, or the process can be improved through ordinary integration.

A blockchain business case should therefore begin with the process and its governance problem. Typical indicators of potential suitability include:

1. Multiple independent organisations need to write to or verify a shared record.
2. Participants have limited trust in one another.
3. Reconciliation, duplicate records, disputes, or fraud create material cost.
4. A durable audit trail is valuable.
5. Rules can be expressed clearly enough for digital execution.
6. Participants are willing and legally able to share relevant data.

These indicators are necessary but not sufficient. A network may still fail because of poor incentives, weak adoption, data-entry errors, privacy restrictions, or an inadequate operating model.

2. From Problem Definition to Strategic Hypothesis

A strong business case states a testable strategic hypothesis. For example:

If manufacturers, logistics providers, and retailers share a permissioned product-event ledger, then reconciliation time and dispute costs will fall without unacceptable loss of confidentiality.

The hypothesis identifies the participants, intervention, expected outcomes, and constraints. It should be translated into measurable baseline and target values.

The case should separate outputs, outcomes, and strategic effects. A number of transactions recorded is an output. Faster settlement is an outcome. Greater partner dependence or improved market access may be a strategic effect. Confusing these categories leads to vanity metrics.

3. Stakeholder and Ecosystem Analysis

Blockchain projects are multi-party systems. Stakeholder analysis must therefore examine not only who uses the technology but also who supplies data, bears costs, receives benefits, controls governance, and may be harmed.

3.1 Stakeholder categories

Relevant stakeholders may include:

• customers and end users;
• suppliers, manufacturers, distributors, and retailers;
• banks, insurers, auditors, and logistics providers;
• regulators, standards bodies, and industry associations;
• technology vendors, node operators, and cloud providers;
• internal owners in operations, finance, legal, compliance, security, and information technology;
• affected communities, employees, and data subjects.

For each stakeholder, document the problem experienced, expected benefit, required contribution, decision authority, risks, and likely response. A participant that receives little benefit but must pay integration costs is a predictable source of resistance.

3.2 Power–interest analysis

A power–interest matrix is a useful first tool. High-power, high-interest stakeholders should be actively managed; high-power, low-interest stakeholders should receive appropriate assurance; low-power, high-interest stakeholders should be kept informed and enabled; and low-power, low-interest stakeholders should be monitored. This classification is not permanent. A regulator, major supplier, or platform operator may change category as the project develops.

Stakeholder analysis should be extended into an incentive analysis. Ask:

• Why would each participant join?
• What information must it disclose?
• What costs will it incur?
• Can it leave without losing critical business capability?
• Who benefits if adoption grows?
• Could one participant exploit information asymmetry or governance power?

A network that depends on voluntary participation requires a credible value proposition for every critical participant. Subsidies, shared savings, service-level commitments, voting rights, or access to new markets may be needed to balance contributions and benefits.

3.3 Governance design

Governance determines who can join, validate transactions, change software, resolve disputes, access data, and impose sanctions. A governance charter should define:

• admission and removal criteria;
• identity and credential management;
• node operation and security responsibilities;
• decision rights and voting thresholds;
• software-update procedures;
• dispute resolution and correction mechanisms;
• data retention, privacy, and deletion policies;
• liability, service levels, and exit arrangements.

Decentralisation is not binary. A network may distribute validation while retaining centralised administration, or it may distribute both technical and institutional control. The relevant question is whether the chosen governance arrangement is trusted, efficient, accountable, and legally defensible.

4. Feasibility Assessment

A feasibility assessment should be multidimensional. Passing a technical test does not establish commercial or legal feasibility.

4.1 Technical feasibility

Technical questions include:

• Can the ledger support required transaction volume, latency, availability, and finality?
• Are identities, permissions, and cryptographic keys manageable at scale?
• Can existing enterprise systems exchange reliable data with the ledger?
• Are smart-contract rules deterministic, testable, and upgradeable?
• Can confidential information be protected through channels, private data, encryption, or off-chain storage?
• What happens during outages, network partitions, key loss, or software defects?

Performance must be assessed using the actual workload. A high theoretical throughput may be irrelevant if the application requires complex validation, cross-network settlement, or strict privacy.

4.2 Economic feasibility

Economic feasibility asks whether measurable benefits exceed lifecycle costs and risks. Benefits may include lower reconciliation cost, reduced fraud, faster settlement, fewer disputes, lower inventory buffers, new revenue, or avoided regulatory penalties. Costs include design, integration, smart-contract development, audits, infrastructure, support, training, governance, compliance, and participant onboarding.

4.3 Legal and regulatory feasibility

Legal analysis should address data protection, financial regulation, consumer protection, electronic transactions, intellectual property, tax, competition law, sanctions, records management, and sector-specific rules. Immutability may conflict with correction or deletion rights. A practical architecture may store personal data off-chain and record only a reference, hash, or proof on-chain; however, a hash can still create privacy concerns if it permits identification or linkage.

Legal responsibility must also be allocated. If a smart contract executes an erroneous transfer, the parties need a process for suspension, reversal, compensation, and evidence preservation. Code does not eliminate contractual interpretation or institutional accountability.

4.4 Organisational feasibility

The organisation needs executive sponsorship, product ownership, technical capability, change-management capacity, and a realistic operating model. Existing performance incentives may discourage data sharing. Employees may also perceive automation as a threat. Training and role redesign are therefore part of feasibility, not optional communication activities.

4.5 Ecosystem feasibility

A blockchain project cannot create value in isolation when its benefits depend on other parties. Assess participant readiness, standards, interoperability, dominant platforms, switching costs, and the possibility of competing networks. Ecosystem feasibility is often the decisive factor.

A useful assessment method is a weighted score:

Here, F is the overall feasibility score, wᵢ is the weight assigned to criterion i, and sᵢ is the normalised score for that criterion. Scores must be based on an explicit scale, such as 0 to 5, and the result should not conceal a critical failure. A project with a high average but unacceptable legal risk should not be approved merely because other dimensions score well.

5. Build, Buy, Join, or Combine

Strategic sourcing is a decision about control, speed, cost, capability, and dependence.

A build decision should consider not only initial development but also protocol upgrades, security audits, key management, node operations, documentation, support, and talent retention. A buy decision should examine data portability, termination rights, service levels, pricing changes, subcontractors, incident obligations, and the vendor’s financial viability. A join decision should examine governance influence, admission rules, data rights, network fees, dispute processes, and the possibility that the network’s strategy will diverge from the organisation’s needs.

A proof of concept should not be treated as a production decision. It may demonstrate technical possibility while ignoring onboarding economics, legal constraints, operational controls, and failure recovery.

6. Total Cost, Benefits, and Investment Evaluation

6.1 Total cost of ownership

A lifecycle cost model should include both visible and hidden costs:

In this undiscounted expression, C₀ is initial cost, Cₜ is capital or implementation cost in period t, Oₜ is operating cost, Gₜ is governance and compliance cost, Rₜ is risk-related expected cost, and n is the planning horizon. All costs must be stated in the same currency and time basis. For investment comparison, discounted cash flow is more appropriate:

NPV is net present value, CFₜ is net cash flow in period t, and r is the discount rate per period. The rate should reflect the organisation’s capital assumptions and project risk. A positive NPV indicates value under the stated assumptions, not certainty of success.

6.2 ROI and payback

A simple project ROI may be calculated as:

This measure is easy to communicate but can be misleading if benefits and costs occur at different times. Payback period identifies when cumulative net cash flow becomes non-negative. Neither metric replaces NPV, sensitivity analysis, or strategic judgement.

Worked Example

An illustrative consortium estimates initial implementation cost of £240,000. Annual operating, governance, and support costs are £90,000. Annual measurable benefits are £180,000. Over three years, undiscounted total benefits are £540,000 and total costs are £510,000:

• Total costs = £240,000 + (3 × £90,000) = £510,000.
• Net benefit = £540,000 − £510,000 = £30,000.
• ROI = £30,000 ÷ £510,000 × 100% ≈ 5.9%.

The annual net benefit after implementation is £90,000, so the simple payback period is:

This is not a recommendation by itself. The calculation excludes discounting, taxes, residual value, uncertainty, and the cost of participant onboarding. If benefits depend on achieving adoption thresholds, the consortium should model low, central, and high scenarios rather than relying on one estimate.

6.3 Benefits realisation

Benefits should have owners, measurement methods, baselines, target dates, and dependencies. For example, “fewer disputes” requires a defined dispute category, a consistent counting method, and controls against merely changing the definition. Benefits should be reviewed after launch because predicted savings often fail when the old process is not retired.

7. Network Effects and Adoption Economics

Blockchain networks become more valuable as relevant participants join. A direct network effect occurs when a user benefits from more users of the same network, such as more counterparties available for exchange. An indirect network effect occurs when adoption attracts complementary services, such as wallets, data providers, auditors, or applications.

Network effects can be positive or negative. More participants may increase liquidity and verification, but may also increase governance complexity, privacy exposure, congestion, or malicious activity. The strategic task is to identify the conditions under which marginal participation creates net value.

A simplified adoption model can represent a participant’s perceived value as:

Vᵢ is perceived net value for participant i, Bᵢ(N) is benefit dependent on network size or quality N, Cᵢ is participation cost, and Rᵢ is perceived risk. Adoption is more likely when Vᵢ exceeds the participant’s alternative value or reservation threshold. This is a conceptual model, not a universal law; benefits may not increase linearly with network size.

Important adoption metrics include:

• invited, registered, activated, and retained participants;
• percentage of priority participants connected;
• active participants per period;
• transaction volume and value;
• percentage of transactions completed without manual intervention;
• time from invitation to first successful transaction;
• integration completion rate;
• participant satisfaction and support demand;
• concentration of activity among the largest participants.

A network with many registrations but few active users has poor adoption quality. Metrics should distinguish activity caused by genuine business use from testing, incentives, or automated noise.

8. On-Chain and Operational Analytics

On-chain analytics examines ledger events, transaction status, timestamps, smart-contract calls, asset movements, fees, validator activity, and address or identity relationships where legally and ethically permissible. Operational analytics combines these records with enterprise resource planning, customer relationship management, logistics, finance, support, and compliance data.

8.1 Useful metric families

A transaction count is not equivalent to value. A participant could generate many low-value events while another generates fewer but strategically important settlements. Metrics should therefore be segmented by participant, process, asset, geography, and use case.

8.2 Data quality and measurement validity

Blockchain provides a durable record of submitted events, not a guarantee of real-world truth. An incorrect sensor reading, fraudulent identity, or dishonest input can be immutably recorded. Data provenance, validation rules, trusted oracles, audits, and exception handling remain necessary.

Analytics must also address selection bias, survivorship bias, changing definitions, and confounding factors. If dispute rates fall after blockchain deployment, the cause might be improved data, lower transaction volume, a change in dispute policy, or the exit of difficult participants. Where feasible, use a baseline, comparison group, interrupted time series, or controlled pilot. Correlation should not be presented as proof of causation.

8.3 Privacy-preserving analytics

Managers should apply data minimisation and purpose limitation. Aggregate dashboards, pseudonymisation, role-based access, secure analytics environments, and off-chain storage may reduce exposure. Privacy-enhancing technologies such as zero-knowledge proofs can demonstrate that a condition is satisfied without revealing the underlying value, but they add complexity and require careful implementation and audit.

9. Decision Framework and Stage Gates

A disciplined decision process can be organised into six gates:

1. Problem gate: Is there a material coordination, trust, audit, or settlement problem?
2. Architecture gate: Does a shared ledger offer a clear advantage over a conventional database or integration layer?
3. Ecosystem gate: Are the necessary participants willing and able to join?
4. Feasibility gate: Are technical, economic, legal, organisational, and regulatory conditions acceptable?
5. Pilot gate: Can a bounded use case test assumptions with measurable outcomes?
6. Scale gate: Have benefits, controls, adoption, and operating costs been demonstrated?

Each gate should have explicit evidence and a stop or redesign option. A pilot should test the riskiest assumptions, not simply demonstrate a successful transaction. For example, if adoption is the main uncertainty, the pilot should focus on onboarding and repeated use; if privacy is the main uncertainty, it should test access controls and data architecture.

A decision record should state the chosen option, alternatives rejected, assumptions, confidence levels, residual risks, accountable owners, and review date. This makes strategic reasoning auditable.

10. Illustrative Case: TraceSure Food Provenance Network

Background

TraceSure is an illustrative case involving a food producer, three logistics providers, two distributors, and a supermarket group. Product recalls are currently managed through spreadsheets, emails, and separate enterprise systems. Participants spend considerable time reconciling lot numbers and shipment records.

Problem

A recall takes an average of 48 hours to identify affected shipments. Records are duplicated, some suppliers use inconsistent identifiers, and participants dispute responsibility for delays. The supermarket wants faster traceability, while smaller suppliers fear integration cost and loss of commercial confidentiality.

Analysis

The problem involves multiple organisations, inconsistent shared records, and a material safety outcome. A shared ledger may provide value, but it cannot verify whether a physical shipment actually contains the recorded product. Physical inspection, barcode controls, and supplier accountability remain necessary.

Stakeholder analysis identifies the supermarket and regulator as high-power stakeholders, logistics providers as operationally critical participants, and small suppliers as high-risk adoption participants because they bear disproportionate integration costs. The proposed governance model gives each organisation defined data rights, establishes a neutral operating committee, and requires common product and location identifiers.

The team compares three options:

• a central database controlled by the supermarket;
• a permissioned ledger operated by several major participants;
• joining an existing industry traceability platform.

The central database is cheaper initially but is viewed as unacceptable by suppliers concerned about unilateral control. Joining an existing platform is faster but offers limited influence over governance. The consortium selects a hybrid approach: join the industry platform while retaining internal systems and using standard interfaces.

Approach and solution

The pilot covers one product category and two distribution routes. Only shipment events, lot references, timestamps, and authorised organisational identifiers are recorded on the ledger. Personal data and detailed commercial documents remain off-chain. Smart-contract validation rejects incomplete lot or location information. A dashboard combines ledger events with warehouse and recall-management data.

Success criteria include:

• reduce traceability time from 48 hours to under 8 hours;
• achieve at least 80% monthly active participation among priority organisations;
• reduce manual reconciliation hours by 30%;
• maintain zero unauthorised disclosure of commercially sensitive data;
• identify and resolve data-quality exceptions within one business day.

Outcome

In the illustrative scenario, the pilot reduces traceability time to six hours and manual reconciliation by 35%. However, two small suppliers remain inactive because onboarding costs are high. The consortium therefore introduces an integration service and a graduated fee model. It also discovers that some incorrect lot identifiers originate upstream, demonstrating that ledger immutability does not solve source-data quality.

Learning points

1. The value came from common identifiers, governance, and process redesign as much as from distributed ledger technology.
2. Adoption and supplier economics were as important as technical performance.
3. Off-chain/on-chain separation reduced privacy exposure but required disciplined reference management.
4. Outcome metrics were more meaningful than transaction counts.
5. The pilot generated evidence for scale while revealing risks that a laboratory demonstration would not have exposed.

11. Challenges, Ethics, and Contemporary Developments

Blockchain strategy raises ethical questions about surveillance, unequal participation, exclusion, energy use, financial harm, and the distribution of value. Permissionless networks may create substantial energy demand depending on their consensus mechanism, while permissioned networks may concentrate power. Organisations should evaluate environmental impact using the actual infrastructure and workload rather than applying assumptions from unrelated networks.

Tokenised systems can create new opportunities for ownership and settlement but may also introduce speculation, consumer-protection concerns, unstable incentives, and regulatory obligations. Automated decision rules may reproduce discriminatory outcomes if input data or eligibility criteria are biased. Governance must include human escalation and correction processes for consequential decisions.

Contemporary developments include interoperability protocols, verifiable credentials, tokenised deposits and assets, zero-knowledge proofs, decentralised identity, and AI-assisted anomaly detection. AI can classify events, forecast adoption, and identify unusual transaction patterns, but it should not be treated as an unquestionable authority. Explainability, model validation, privacy, adversarial testing, and human accountability remain necessary. AI-generated recommendations should be linked to reliable data and reviewed against business and regulatory constraints.

12. Best Practices for Managers and Analysts

• Start with a measurable business problem rather than a preferred technology.
• Compare blockchain explicitly with databases, APIs, shared platforms, and process redesign.
• Identify who pays, who benefits, who supplies data, and who governs.
• Model lifecycle cost, uncertainty, adoption thresholds, and exit costs.
• Use standard identifiers and interfaces before designing sophisticated smart contracts.
• Keep sensitive or personal data off-chain unless there is a compelling and lawful reason not to.
• Treat key management, identity, incident response, and software upgrades as core operations.
• Design pilots around the riskiest assumptions and predefine success and stop criteria.
• Combine on-chain metrics with operational and financial outcomes.
• Separate recorded activity from realised value and correlation from causation.
• Reassess the business case after pilot evidence and changing regulation.

Chapter Summary

Blockchain strategy is concerned with creating sustainable value across an ecosystem, not merely deploying distributed ledger software. A sound business case begins with a clearly defined coordination, trust, audit, or settlement problem and compares blockchain with simpler alternatives. Stakeholder analysis must identify power, interest, incentives, costs, benefits, and governance responsibilities. Feasibility requires technical, economic, legal, organisational, and ecosystem assessment.

Build, buy, join, and hybrid choices involve trade-offs among control, speed, cost, interoperability, and dependence. Total-cost analysis should include implementation, operation, governance, compliance, risk, and onboarding. ROI and payback are useful communication measures, while NPV and scenario analysis provide stronger investment evaluation. Network effects can increase value as participation grows, but privacy, congestion, governance complexity, and exclusion may create negative effects.

On-chain analytics reveals activity and transaction behaviour, while operational analytics tests whether the initiative improves cost, quality, risk, service, and strategic outcomes. Durable records do not guarantee truthful source data, and analytics does not automatically establish causation. Effective decision-making therefore combines quantitative evidence, governance, ethical judgement, legal analysis, and staged experimentation.

Key Terms

Adoption metric: A measure of participant enrolment, activation, use, retention, or contribution.

Blockchain suitability: The degree to which a problem benefits from shared, tamper-evident, programmable records.

Build–buy–join decision: A choice among developing internally, procuring a solution, joining an existing network, or combining these approaches.

Consensus: The process by which network participants agree on the validity or ordering of transactions.

Direct network effect: Increased value arising from more users of the same network.

Ecosystem feasibility: The likelihood that required external participants can and will support the initiative.

Feasibility assessment: Structured evaluation of technical, economic, legal, organisational, and ecosystem conditions.

Governance: Rules defining decision rights, participation, data access, software changes, and accountability.

Indirect network effect: Increased value caused by growth in complementary services or applications.

Net present value: The present value of future net cash flows less initial investment.

On-chain analytics: Analysis of events and transactions recorded on a blockchain.

Operational analytics: Analysis combining blockchain data with business-process, financial, customer, or enterprise data.

Payback period: Time required for cumulative net cash flow to recover the initial investment.

Permissioned network: A network in which participation or transaction validation is restricted by identity and rules.

Return on investment: Net benefits divided by total investment cost, expressed as a percentage.

Smart contract: Program code that executes agreed rules when specified conditions occur.

Stakeholder analysis: Identification and evaluation of parties affected by or able to influence an initiative.

Total cost of ownership: All relevant lifecycle costs of acquiring, operating, governing, and retiring a solution.

Traceability: The ability to follow an asset, event, or record through a process or supply chain.

Zero-knowledge proof: A cryptographic method for demonstrating that a statement is true without revealing the underlying information.

Review Questions

Short Answer Questions

1. Why is a blockchain business case required to compare blockchain with conventional databases and process redesign?
2. What is the difference between a direct and an indirect network effect?
3. Identify four categories of cost that should be included in total cost of ownership.
4. Why does an immutable ledger not guarantee truthful data?
5. What is the purpose of a stage-gated blockchain pilot?

Long Answer Questions

1. Explain how stakeholder incentives and governance influence the success of a multi-organisational blockchain network.
2. Compare build, buy, join, and hybrid strategies, including the risks and circumstances associated with each.
3. Discuss how technical, economic, legal, organisational, and ecosystem feasibility should be assessed together.
4. Explain why ROI and payback period should not be used as the sole basis for approving a blockchain investment.
5. Describe how on-chain and operational analytics can be combined to evaluate performance and benefits realisation.

Analytical / Application Questions

1. A consortium has an initial cost of £300,000, annual operating costs of £100,000, and annual benefits of £220,000 over three years. Calculate undiscounted total cost, net benefit, simple ROI, and payback period. State two limitations of this analysis.
2. A proposed network has many registered organisations but only 15% are active monthly. Analyse three possible causes and recommend metrics or interventions for distinguishing and addressing them.
3. An organisation claims that a blockchain reduced fraud because fraud reports declined after launch. Design a more reliable evaluation approach that addresses baseline measurement, alternative explanations, data quality, and privacy.

Multiple Choice Questions with Answers

Question 1

Which condition most strongly supports considering blockchain rather than a conventional internal database?

A. A single trusted organisation controls all records and users.

B. Several independent organisations need a shared record despite limited mutual trust.

C. The application requires the lowest possible latency for one department.

D. The data never needs to be shared outside one application.

Correct Answer: B. Several independent organisations need a shared record despite limited mutual trust.

Question 2

Which item is primarily a governance responsibility?

A. Defining who may join the network and approve software changes.

B. Increasing processor clock speed.

C. Compressing an image file.

D. Selecting a monitor resolution.

Correct Answer: A. Defining who may join the network and approve software changes.

Question 3

An initiative has total benefits of £540,000 and total costs of £510,000. What is its simple ROI?

A. 5.9%

B. 16.7%

C. 30.0%

D. 94.4%

Correct Answer: A. 5.9%

Question 4

In the formula NPV = −C₀ + ∑ₜ₌₁ⁿ CFₜ ÷ (1 + r)ᵗ, what does r represent?

A. The number of network participants

B. The rejection rate

C. The discount rate per period

D. The residual asset value

Correct Answer: C. The discount rate per period

Question 5

Which is an example of a direct network effect?

A. More users attract more complementary software vendors.

B. More users provide more possible counterparties on the same network.

C. A vendor lowers its price after purchasing new servers.

D. A regulator publishes a new reporting standard.

Correct Answer: B. More users provide more possible counterparties on the same network.

Question 6

Why should sensitive personal data often be stored off-chain?

A. Blockchains cannot record any references.

B. Off-chain storage automatically removes all cybersecurity risk.

C. It can reduce conflict with privacy, correction, and deletion requirements.

D. Smart contracts cannot process non-personal data.

Correct Answer: C. It can reduce conflict with privacy, correction, and deletion requirements.

Question 7

Which metric best distinguishes adoption quality from simple registration?

A. Number of invitations sent

B. Number of logos displayed on a website

C. Monthly active participants completing valid business transactions

D. Number of pages in the technical specification

Correct Answer: C. Monthly active participants completing valid business transactions

Question 8

What is a major limitation of using transaction count as the only performance metric?

A. It always measures customer satisfaction directly.

B. It does not indicate transaction value, quality, or realised outcomes.

C. It cannot be calculated on a blockchain.

D. It automatically reveals legal liability.

Correct Answer: B. It does not indicate transaction value, quality, or realised outcomes.

Question 9

If annual net benefit after implementation is £90,000 and initial cost is £240,000, the simple payback period is approximately:

A. 0.38 years

B. 1.50 years

C. 2.67 years

D. 3.75 years

Correct Answer: C. 2.67 years

Question 10

What does a blockchain’s immutable record fail to guarantee?

A. That a submitted record remains detectable if altered.

B. That transactions can be ordered according to network rules.

C. That the original real-world data entered was truthful.

D. That authorised participants can apply validation rules.

Correct Answer: C. That the original real-world data entered was truthful.