13. Blockchain Analytics, Risk and Decision-Making

Introduction and Context

Blockchain systems generate a distinctive form of evidence. Unlike conventional databases, where records are usually controlled by a single organisation, public blockchains expose a chronologically ordered history of transactions, contract interactions, token movements, and account activity. This transparency creates opportunities for investigation, compliance, market intelligence, security monitoring, and project evaluation. It also creates analytical difficulties: identities are often pseudonymous, activity is distributed across several networks, smart contracts may obscure economic intent, and transaction data can be deliberately manipulated.

Blockchain analytics is therefore more than searching for an address on a block explorer. It is the disciplined collection, transformation, interpretation, and validation of on-chain and off-chain evidence. The objective may be to reconstruct the movement of stolen assets, identify suspicious transaction patterns, measure protocol exposure, evaluate a decentralised project, or support a governance decision. Each objective requires different data, assumptions, analytical models, and standards of proof.

For cybersecurity professionals, blockchain analytics lies at the intersection of digital forensics, graph theory, financial crime analysis, software assurance, economics, and governance. A sound analysis must distinguish observable facts from inference. An address can be associated with a service without revealing the legal identity of the person controlling it. A large transfer may be routine treasury activity rather than money laundering. A high token concentration may indicate governance risk, but concentration alone does not prove malicious intent.

This chapter develops a practical and critical framework for using blockchain data in decision-making. It examines data sources, graph analysis, anomaly detection, forensic workflows, risk indicators, due diligence, automation, ethical obligations, and the limitations of analytical conclusions.

Learning Objectives

After studying this chapter, students should be able to:

1. Explain the nature, scope, and evidential value of blockchain analytics.

2. Distinguish addresses, entities, transactions, smart-contract events, and off-chain identities.

3. Construct and interpret transaction graphs for investigative and risk-analysis purposes.

4. Apply methods for anomaly detection, tracing, attribution, and evidence preservation.

5. Evaluate blockchain projects across security, economic, operational, regulatory, and governance dimensions.

6. Interpret risk indicators without confusing correlation with proof of misconduct.

7. Design an analytics workflow suitable for compliance, incident response, or due diligence.

8. Assess the role and limitations of automation, machine learning, and artificial intelligence.

9. Make defensible decisions under uncertainty while respecting privacy, proportionality, and due process.

The Analytical Object: What Blockchain Data Represents

A blockchain ledger records state transitions. In a simple account-based system, a transaction may indicate that one account called a function on a contract, transferred an asset, or changed a stored value. In a UTXO-based system, transactions consume previous outputs and create new outputs. These models produce different analytical structures. Account-based ledgers naturally support account histories and contract-call analysis; UTXO systems require analysts to reason about input-output relationships and change addresses.

Several distinctions are essential:

• Address: A public identifier used to receive, hold, or send assets. It is not automatically a person, organisation, or legal entity.
• Entity: A person, organisation, exchange, protocol, wallet service, or other real-world or operational actor that may control one or more addresses.
• Transaction: A signed request recorded by the network, including transfers, contract calls, or state changes.
• Event or log: Data emitted by a smart contract during execution. Events are useful for identifying token transfers, approvals, swaps, and protocol actions, but they must be interpreted with transaction context.
• Internal or contract-mediated transfer: A value movement produced during contract execution rather than necessarily represented as a simple externally initiated transfer.
• Off-chain evidence: Exchange records, customer-identification data, server logs, communications, governance proposals, legal documents, and financial statements.

The distinction between address and entity is the foundation of responsible analysis. Analysts may cluster addresses using common-control indicators, deposit patterns, known service addresses, transaction timing, and public disclosures. Clustering is probabilistic. It should be expressed as an attribution hypothesis with a confidence level, not as an unquestionable fact.

Blockchain data also has temporal and economic dimensions. A transfer recorded at a particular block time does not necessarily establish when a person formed an intention. Token quantities may have little meaning without market price, liquidity, vesting conditions, or counterparty context. A protocol may report high transaction volume that is largely generated by automated bots or incentive programmes. Consequently, raw counts should be combined with qualitative interpretation.

From Ledger Records to Analytical Evidence

A reliable workflow begins with a clear question. “Investigate the wallet” is insufficient. A more precise question might be: “Did assets associated with the exploit move through identifiable services within seven days?” or “What proportion of the circulating supply can be influenced by the founding team and related wallets?” The question determines the relevant time period, chains, asset classes, and evidential threshold.

Data acquisition and preparation

Common data sources include full nodes, archival nodes, public explorers, indexers, RPC providers, decoded contract interfaces, token registries, exchange information, governance repositories, and open-source intelligence. Analysts should record the source, retrieval time, chain identifier, block range, query parameters, decoding assumptions, and any missing data.

Raw data normally requires normalization. Important tasks include converting timestamps, resolving token decimals, distinguishing native assets from token balances, decoding function calls, identifying failed transactions, removing duplicate records, and reconciling balances with transaction histories. Cross-chain analysis adds bridge deposits, bridge withdrawals, wrapped assets, and destination-chain identifiers. A token with similar names on multiple networks must not be treated as the same asset without contract-address verification.

A useful evidence record contains at least:

• transaction hash or equivalent immutable identifier;
• source and destination addresses;
• block number and timestamp;
• asset, quantity, and valuation method;
• transaction status and fee information;
• contract function and event data, where available;
• source provenance and collection method;
• analyst interpretation and confidence level.

The separation of observation and interpretation is particularly important. “Address A sent 50 units to Address B at block X” is an observation. “Address A attempted to conceal proceeds through layering” is an interpretation requiring additional evidence.

Transaction graphs

A transaction graph models blockchain activity as a network. Nodes may represent addresses, contracts, entities, transactions, or services. Directed edges represent transfers or interactions. Edges can be weighted by asset quantity, value, frequency, or time. A graph may be constructed as a one-mode address graph, a bipartite address-transaction graph, or a heterogeneous graph containing addresses, contracts, assets, bridges, and exchanges.

Graph analysis supports several investigative questions. Degree measures the number of connections; weighted degree measures the value or volume associated with those connections. In-degree and out-degree can distinguish accumulation from distribution. Betweenness centrality identifies nodes that lie on many shortest paths, although this metric can be misleading in networks where users naturally route through common infrastructure. Community detection may reveal clusters of addresses interacting more frequently with one another. Temporal motifs—such as rapid funding, conversion, and dispersal—can expose patterns that are invisible in a static graph.

Graph results must be interpreted cautiously. A central exchange address may appear highly connected because it aggregates customer deposits, not because it personally controls or directs all those funds. Similarly, a bridge or decentralised exchange may connect otherwise unrelated communities. Infrastructure nodes often create structural shortcuts that distort naive conclusions.

Tracing and attribution

Tracing follows assets through successive transactions. It becomes difficult when funds are split, merged, swapped, bridged, deposited into custodial services, or converted into privacy-enhancing assets. Analysts may use forward tracing from a known source, backward tracing from a destination, or bidirectional tracing from both ends.

Attribution associates an address or cluster with a known entity. Stronger indicators include a public disclosure signed by the address, a verified service deposit address, legal or exchange records, repeated operational patterns, or cryptographic proof of control. Weaker indicators include naming conventions, a single transfer from a known address, or superficial similarity in timing. Attribution should be graded—for example, confirmed, high confidence, probable, possible, or unknown—and the basis for each grade should be documented.

Risk Indicators and Decision Models

Risk indicators are signals that help prioritise analysis or support a decision. They are not automatic determinations of unlawful conduct. A mature risk model uses multiple indicators, applies context, and includes a review mechanism.

Security risk

Security assessment examines whether a protocol or organisation can prevent, detect, and recover from technical compromise. Relevant indicators include audit scope and quality, privileged roles, upgradeability, oracle dependencies, key-management arrangements, bug-bounty practices, incident history, pause mechanisms, and the concentration of administrative authority. An audit is evidence of review, not a guarantee of safety. Analysts should examine whether the deployed bytecode corresponds to the audited version and whether later upgrades changed critical logic.

Technical risk is often concentrated in dependencies. A lending protocol may depend on an oracle, a bridge, a stablecoin, a multisignature wallet, and several external libraries. The protocol’s effective risk is therefore a function of its own code and the failure modes of its surrounding ecosystem.

Economic and market risk

Economic analysis considers token supply, issuance, vesting, unlock schedules, liquidity, collateral assumptions, incentives, and concentration. Important indicators include the proportion of supply held by insiders, the depth of trading markets, dependence on a single liquidity venue, leverage, stablecoin redemption assumptions, and sensitivity to price shocks.

A token’s market capitalisation may be misleading when only a small quantity is freely tradable. Fully diluted valuation can reveal future dilution, but it is itself dependent on assumptions about future price and supply. Wash trading and incentive-driven volume can inflate apparent adoption. Analysts should compare volume across venues, examine unique active participants, and test whether activity persists after rewards decline.

Operational risk

Operational due diligence covers governance procedures, incident response, documentation, staffing, vendor dependence, monitoring, business continuity, and access control. Warning signs include unclear responsibility for emergency decisions, undocumented deployment processes, single-person control of critical keys, absent recovery procedures, and inconsistent public communication during incidents.

Governance risk

Governance analysis asks who can propose, vote on, and execute changes. Token-based voting may be highly concentrated, delegated voting may conceal effective control, and quorum rules may permit a small active minority to determine outcomes. The formal design of governance should be compared with actual participation and execution. A system that appears decentralised in its documentation may remain operationally dependent on a small development team or multisignature group.

Compliance and exposure risk

Compliance analytics may identify exposure to sanctioned entities, fraud typologies, ransomware proceeds, theft, mixer services, or high-risk jurisdictions, subject to applicable law. Exposure should be time-sensitive and contextual. Direct interaction with a flagged service is not equivalent to beneficial ownership or intentional participation. Organisations should define escalation thresholds, conduct enhanced review, and avoid treating third-party labels as conclusive evidence.

A practical scoring model can combine dimensions such as security, concentration, liquidity, operational resilience, governance, and compliance exposure. However, numerical scores can create false precision. Scores should therefore be accompanied by confidence, evidence quality, materiality, and recommended action. A decision matrix may classify an issue as acceptable, requiring monitoring, requiring mitigation, or requiring rejection or escalation.

Detecting Anomalies and Suspicious Behaviour

An anomaly is activity that deviates from an established baseline. It is not necessarily malicious. Baselines may be defined for an address, user population, protocol, asset, or time period. Useful features include transaction frequency, value, counterparties, time between transactions, gas behaviour, contract functions, asset diversity, and changes in balance.

Rule-based detection remains valuable. Examples include a large transfer immediately after a privileged role change, repeated failed calls followed by a successful exploit-like call, rapid movement through newly created addresses, or transfers that exceed established operational limits. Rules are transparent and easy to audit, but they can produce high false-positive rates.

Statistical methods can identify outliers using moving averages, percentile thresholds, clustering, or change-point detection. A sudden increase in token approvals, for example, may indicate a compromised wallet or a malicious front-end. Machine-learning models can classify transaction sequences or detect graph anomalies, but their results depend on training data, feature quality, and the stability of behaviour. Adversaries may adapt to known features, and models can reproduce bias from historical labels.

Detection should combine several layers:

1. Baseline layer: establish normal behaviour and relevant peer groups.

2. Signal layer: identify unusual value, timing, counterparties, functions, or topology.

3. Context layer: incorporate known incidents, market events, governance changes, and service relationships.

4. Investigation layer: trace funds, inspect code and permissions, and seek off-chain corroboration.

5. Decision layer: determine whether to monitor, freeze where legally authorised, notify, remediate, or close the alert.

The alert lifecycle should be documented. An unexplained alert is not a successful detection; the organisation must show how it was triaged, investigated, resolved, and used to improve controls.

A Forensic Workflow for Blockchain Investigations

A professional investigation normally proceeds through six connected phases.

Scoping. Define the allegation, assets, chains, period, relevant entities, legal authority, and desired outcome. Preserve the initial information before it changes or disappears from off-chain sources.

Collection. Acquire ledger records, contract code, event data, exchange information, logs, communications, and relevant public material. Use reproducible scripts and record hashes or identifiers for collected files.

Preservation. Maintain chain-of-custody records, access controls, time references, and original copies. A blockchain record is persistent, but an analyst’s query output, web page, API response, or downloaded file may not be.

Analysis. Normalize data, construct graphs, trace assets, examine contract calls, compare behaviour with baselines, and test alternative explanations. Use independent checks where the consequences of an error are significant.

Attribution and corroboration. Link addresses to entities only when supported by evidence. Seek off-chain confirmation, such as exchange records or signed statements, especially when the conclusion may affect a person’s liberty, reputation, or access to financial services.

Reporting. State the question, methods, data sources, findings, uncertainties, limitations, and recommended actions. Reports should allow another qualified analyst to reproduce the material conclusions.

Applied Case: Investigating a Suspected Protocol Treasury Diversion

The following is an illustrative case, not a report of a real organisation.

Background

Northstar Finance is a decentralised lending protocol governed by a token-based voting system. Its treasury holds stablecoins and the protocol’s native token. A monitoring system reports that a treasury multisignature wallet transferred a large stablecoin balance to a newly funded address, after which the assets were swapped and bridged to another network.

Situation and problem

Community members suspect that a signer colluded with an external attacker. The organisation must determine whether the transfer was an authorised treasury action, a compromised key event, or an internal diversion. It must also decide whether to pause contracts, notify users, contact exchanges, or commence legal proceedings.

Analysis

Investigators first establish the exact transaction, contract addresses, signer set, and relevant governance proposals. The transfer is confirmed on the source chain, but confirmation alone does not establish that it was unauthorised. The team reviews the multisignature threshold, signer transaction histories, and time sequence.

A graph is constructed covering the treasury, signers, funding addresses, decentralised exchanges, bridge contracts, and destination-chain addresses. The graph shows that the receiving address was funded shortly before the treasury transfer and split the assets across two routes. One route entered a known bridge; the other was swapped through a liquidity pool. The destination address later interacted with a centralised exchange deposit cluster.

The investigators then compare the action with governance records. No approved proposal authorised the transfer. Two signers report that they did not approve it, while a third signer’s key had recently been used from an unfamiliar infrastructure environment. Contract logs show a change in signer configuration two hours before the transfer. The change was technically valid under the existing threshold but was not announced through the normal governance channel.

Several hypotheses are tested: a legitimate emergency rebalancing, a compromised signer, and collusion. The absence of a proposal does not by itself prove theft, but the signer change, unusual access pattern, rapid dispersal, and exchange exposure collectively increase the probability of compromise or insider abuse. Investigators avoid claiming that the destination address belongs to a named individual because no reliable identity evidence is available.

Approach and solution

Northstar freezes discretionary treasury operations, preserves node and access logs, notifies relevant service providers through lawful channels, and publishes a factual incident notice. It requests that the exchange review the deposit, while recognising that freezing assets may require legal authority. A code review examines whether the signer-management contract can be upgraded or bypassed. Governance proposes a temporary change to signer thresholds, independent key generation, transaction simulation, address allow-listing for treasury operations, and mandatory public recording of emergency actions.

Outcome

The investigation establishes that the transfer was not supported by an approved treasury decision and that a signer credential was likely compromised. It does not establish the real-world identity of the beneficiary. Some assets are recovered after service-provider intervention; the remainder cannot be recovered. The protocol improves its signing procedures and introduces independent monitoring for role changes and unusually large transfers.

Learning points

The case demonstrates why transaction tracing must be combined with governance, key-management, contract, and off-chain evidence. Graph structure is useful for prioritising routes, but it cannot by itself determine intent or identity. Early preservation of logs and access records is as important as ledger analysis. Finally, incident response must balance speed with legal authority, privacy, and accuracy of public communication.

Practical and Organisational Applications

Blockchain analytics is used by exchanges for transaction monitoring, by financial institutions for counterparty assessment, by incident-response teams for stolen-asset tracing, by auditors for control testing, and by investors for protocol due diligence. Regulators and law-enforcement bodies may use it to develop leads and corroborate other evidence. Project teams can use internal analytics to monitor privileged actions, treasury flows, unusual approvals, liquidity changes, and governance participation.

A mature organisational capability normally includes defined ownership, data governance, analytical tools, legal and compliance review, escalation procedures, and periodic validation. Analysts should understand both the technical system and the organisation’s decision rights. A technically accurate alert may still be useless if nobody is authorised to act on it.

Automation is helpful for data ingestion, decoding, dashboarding, alert generation, and graph expansion. Artificial intelligence may assist with clustering, natural-language review of governance proposals, code-risk prioritisation, and summarising investigative material. Human review remains necessary for attribution, high-impact decisions, model validation, and explanations. AI-generated inferences should be traceable to source data, tested for false positives, and protected against prompt injection or contaminated data in automated workflows.

Limitations, Risks, and Common Mistakes

The principal limitation is the gap between ledger visibility and human identity. Public data may be complete at the protocol level but incomplete regarding ownership, purpose, and intent. Other limitations include chain reorganisations, indexing errors, missing historical data, contract-proxy complexity, privacy technologies, cross-chain fragmentation, exchange aggregation, and rapidly changing labels.

Common mistakes include:

• treating an address label as verified identity;
• assuming that all transfers represent economic payments;
• ignoring failed transactions and contract execution context;
• counting token volume without testing liquidity or bot activity;
• overlooking bridges, wrapped assets, and multiple chain environments;
• using a risk score without explaining its evidence and uncertainty;
• treating an audit as a security warranty;
• publishing allegations before corroboration and legal review;
• failing to preserve original data and query parameters;
• using machine-learning outputs without testing bias or drift.

Analysts should also guard against confirmation bias. Once an address is suspected, every subsequent transaction may appear incriminating. Investigations should record alternative hypotheses and specify what evidence would support or weaken each one.

Ethical, Governance, and Regulatory Considerations

Blockchain investigations can affect privacy, reputation, access to financial services, and legal rights. Analysts should apply necessity and proportionality: collect only what is relevant, restrict access, retain records appropriately, and distinguish public availability from unrestricted ethical use. Sensitive identity information obtained from exchanges or investigations must be handled under applicable privacy and financial-crime laws.

Governance requires clear accountability for risk decisions. Organisations should define who can place an alert on hold, escalate a case, contact a service provider, publish an incident statement, or suspend a product. Decisions should be reviewable and subject to challenge where appropriate.

Regulatory obligations vary by jurisdiction and activity. Analysts must not assume that a technical capability creates legal authority to freeze, seize, disclose, or block assets. Cross-border investigations may require formal cooperation. Professional reports should use careful language, identify limitations, and avoid presenting probabilistic attribution as established fact.

Emerging Directions and Best Practices

Blockchain analytics is moving toward multi-chain identity resolution, real-time graph streaming, privacy-preserving investigation, protocol-level risk observability, and integrated code-economic analysis. Zero-knowledge systems may allow compliance claims without exposing all transaction details, but they also create new verification challenges. Decentralised identity systems may improve attribution in some contexts while introducing governance and surveillance risks.

Best practice is to combine technical depth with disciplined uncertainty management. Organisations should maintain current asset and contract inventories, monitor administrative privileges, test alert rules, validate third-party labels, document analytical confidence, and conduct post-incident reviews. They should also separate investigative tooling from production signing infrastructure and protect analytical systems against unauthorised access.

The most defensible decision is rarely based on one metric. It emerges from converging evidence: ledger facts, graph patterns, code behaviour, governance records, operational controls, market conditions, and legally obtained off-chain information. Blockchain analytics is valuable not because it eliminates uncertainty, but because it makes important parts of that uncertainty visible and manageable.

Chapter Summary

Blockchain analytics transforms ledger records into evidence for investigation, compliance, security monitoring, and project evaluation. Its central concepts include the distinction between addresses and entities, the use of transaction and event data, graph-based tracing, probabilistic attribution, anomaly detection, and multidimensional risk assessment. Effective workflows begin with a precise question, preserve evidence, normalize data, test alternative hypotheses, corroborate on-chain findings, and report uncertainty.

Risk analysis should cover security, economic, operational, governance, and compliance dimensions. Numerical scores can support prioritisation but must not create false certainty. Automation and AI improve scale and speed, yet high-impact decisions require human review, explainability, and validation. Ethical practice demands proportionality, privacy protection, legal authority, and careful communication. The professional value of blockchain analytics lies in connecting transparent transaction histories with contextual evidence while recognising the limits of what the ledger can prove.

Key Terms

Blockchain analytics: The collection, processing, and interpretation of blockchain data for investigation, monitoring, assessment, or decision-making.

Address: A public blockchain identifier used to send, receive, or control assets or interact with contracts.

Entity: A real-world or operational actor associated with one or more blockchain addresses.

Attribution: The process of associating an address or cluster with an entity or service.

Transaction graph: A network representation of addresses, entities, contracts, and transfers.

Clustering: Grouping addresses that are believed, with some degree of confidence, to share control or operational association.

Centrality: A family of graph measures describing the structural importance or connectivity of a node.

Event log: Data emitted by a smart contract during execution and recorded with a transaction.

UTXO: An unspent transaction output used as a value unit in UTXO-based blockchain systems.

Anomaly detection: Identification of behaviour that differs materially from an established baseline.

Forward tracing: Following assets from a known source toward later destinations.

Backward tracing: Following asset history from a destination toward earlier sources.

Chain of custody: Documentation showing how evidence was collected, preserved, accessed, and transferred.

Risk indicator: A signal used to identify, prioritise, or evaluate a potential risk.

False positive: An alert incorrectly classified as suspicious or problematic.

Governance concentration: The degree to which decision-making power is controlled by a small group.

Liquidity: The ability to buy or sell an asset without causing substantial price movement.

Cross-chain analysis: Examination of activity spanning multiple blockchain networks.

Due diligence: Structured investigation of a project, counterparty, technology, or investment before a decision.

Confidence level: An explicit expression of how strongly available evidence supports an analytical conclusion.

Review Questions

Short Answer Questions

1. Why is an address not automatically equivalent to a real-world entity?

2. What is the difference between an observation and an interpretation in blockchain analysis?

3. Identify three features that may be used in transaction anomaly detection.

4. Why can a blockchain audit not be treated as a guarantee of protocol security?

5. What information should be included in a blockchain evidence record?

Long Answer Questions

1. Explain how a transaction graph can support asset tracing, and discuss two situations in which graph interpretation may be misleading.

2. Describe a complete forensic workflow for investigating a suspected blockchain incident.

3. Compare security, economic, operational, governance, and compliance risk in the evaluation of a blockchain project.

4. Discuss the role of attribution and corroboration in converting blockchain observations into defensible investigative findings.

5. Explain the benefits and limitations of automation and artificial intelligence in blockchain analytics.

Analytical / Application Questions

1. A treasury wallet transfers assets to a newly created address, which swaps half the assets and bridges the remainder. Design an investigation plan, including data sources, graph methods, alternative hypotheses, and preservation steps.

2. A protocol reports rapidly increasing transaction volume, but most transactions originate from a small group of addresses receiving token incentives. How would you evaluate whether the growth represents genuine adoption?

3. An exchange receives funds that can be traced through several intermediate addresses from a known exploit. Explain why exposure alone does not establish intentional participation and recommend an appropriate escalation process.

22. Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes an address from an entity in blockchain analytics?

A. An address is always controlled by a legally identified person.

B. An address is a public identifier, while an entity is a real-world or operational actor that may control one or more addresses.

C. An entity exists only on UTXO-based blockchains.

D. An address is an off-chain identity verified by a blockchain validator.

Correct Answer: B. An address is a public identifier, while an entity is a real-world or operational actor that may control one or more addresses.

Question 2

Why should a risk score be accompanied by evidence quality and confidence?

A. Because numerical scores are prohibited in compliance work.

B. Because scores can create false precision and may conceal uncertainty or weak evidence.

C. Because blockchains do not record numerical values.

D. Because confidence is relevant only to machine-learning systems.

Correct Answer: B. Because scores can create false precision and may conceal uncertainty or weak evidence.

Question 3

Which graph measure identifies nodes that lie on many shortest paths between other nodes?

A. Betweenness centrality

B. Token decimals

C. Transaction finality

D. Hash difficulty

Correct Answer: A. Betweenness centrality

Question 4

A large exchange address has thousands of counterparties. What is the most appropriate interpretation?

A. The address personally controls every counterparty.

B. The address may be an aggregation point for many customers, so connectivity alone does not prove common ownership.

C. Every connected address must be part of the same criminal organisation.

D. The address cannot be analysed because exchanges are off-chain.

Correct Answer: B. The address may be an aggregation point for many customers, so connectivity alone does not prove common ownership.

Question 5

Which finding most strongly supports treating an attribution as a hypothesis rather than an established fact?

A. A transaction has a confirmed block number.

B. An address has a publicly documented signed ownership proof.

C. An address resembles another address in naming and timing only.

D. An exchange has formally identified the customer through lawful records.

Correct Answer: C. An address resembles another address in naming and timing only.

Question 6

In the illustrative Northstar Finance case, why was the signer change important?

A. It proved the destination address belonged to a named individual.

B. It provided operational context suggesting possible compromise or insider abuse when combined with other evidence.

C. It showed that the blockchain had been rewritten.

D. It demonstrated that all multisignature wallets are insecure.

Correct Answer: B. It provided operational context suggesting possible compromise or insider abuse when combined with other evidence.

Question 7

Which is an example of a baseline feature for anomaly detection?

A. The analyst’s preferred conclusion

B. Transaction frequency and time between transactions

C. A legal judgment unrelated to the address

D. The colour scheme of a block explorer

Correct Answer: B. Transaction frequency and time between transactions

Question 8

Why can reported token volume overstate genuine adoption?

A. All token transfers are necessarily private.

B. Volume may be generated by bots, wash trading, or incentive programmes.

C. Token volume cannot be measured on public blockchains.

D. High volume always indicates malicious activity.

Correct Answer: B. Volume may be generated by bots, wash trading, or incentive programmes.

Question 9

What is a key ethical requirement when publishing an attribution finding?

A. Present probabilistic conclusions as certain to increase impact.

B. Disclose private information whenever it is technically obtainable.

C. Distinguish evidence from inference and respect privacy, proportionality, and legal requirements.

D. Avoid documenting limitations so the report appears decisive.

Correct Answer: C. Distinguish evidence from inference and respect privacy, proportionality, and legal requirements.

Question 10

Which sequence best represents a professional blockchain forensic workflow?

A. Publish, speculate, collect, and then preserve evidence

B. Scope, collect, preserve, analyse, corroborate, and report

C. Score, freeze, identify, and delete source data

D. Cluster, accuse, publicise, and request evidence later

Correct Answer: B. Scope, collect, preserve, analyse, corroborate, and report