Transaction Hash: Data Point Intelligence Guide

A transaction hash is the one financial record that is permanent, publicly verifiable and impossible for the counterparty to alter after the fact. Investigators rarely get anything this clean.

Understanding the Transaction Hash as an intelligence artifact

A transaction hash, or txid, is the cryptographic digest identifying a single transaction on a blockchain, normally sixty-four hex characters. It is the atomic unit of movement: inputs, outputs, amounts, fees, block height, confirmation time and, on smart contract chains, the full call data and emitted event logs. Unlike an address, which aggregates activity over time, a transaction hash pins one specific transfer to one specific moment with a value and a set of counterparties that cannot subsequently be changed.

Chain model changes what a hash contains. A Bitcoin transaction may have many inputs and outputs, so identifying which output is a payment and which is change is an analytical step, not a given. An EVM transaction has one sender and one target but may trigger internal transactions and token transfers that never appear in the top-level record, so token movements must be read from event logs. Failed transactions still exist on chain and still carry evidential value.

Why it matters

A transaction hash is the evidential atom of financial tracing. It proves a specific value moved between specific control points at a specific time, verifiable independently by anyone. That makes it the backbone of ransom payment analysis, fraud reconstruction and asset recovery. Its timestamp anchors blockchain activity to real-world events such as a ransom deadline or a marketplace order, and its fee and structural characteristics fingerprint the wallet software used to create it.

What analysts actually look for

These are the concrete, observable signals that carry weight in this area of work:

• Block timestamp and confirmation depth, which fix the transfer in time and establish finality for evidential purposes.
• Input and output structure, which reveals consolidation, distribution, peeling chains and the likely change output.
• Fee level and fee rate strategy, which fingerprint wallet software, urgency and sometimes automated payment tooling.
• Counterparty addresses on both sides, which are the immediate pivot points for continuing the trace in either direction.
• Internal transactions and token transfer event logs on contract chains, which carry movements invisible in the top-level record.
• Contract call data on EVM chains, which shows exactly which function was invoked and with what parameters.
• Transaction status including failure and revert reasons, which can expose attempted actions that were blocked or misconfigured.
• Position and timing relative to other transactions, revealing batching, automation and scripted disbursement patterns.

Where the data comes from

Authoritative and openly available collection points. Always confirm licensing and terms before operational or commercial use:

• mempool.space — Bitcoin transaction detail with input and output breakdown, fee analysis and visual transaction graphs
• Blockchair — Multi-chain transaction lookup with structured data, advanced filtering and export capability
• Etherscan — Ethereum transaction view including internal transactions, token transfers, logs and decoded call data
• Blockscout — Open source explorer with decoded contract interactions and full transaction detail across many EVM chains
• Bitcoin Core RPC — Your own full node, giving authoritative and independently verifiable transaction data without third party trust
• OFAC SDN List — Designated addresses whose appearance on either side of a transaction triggers immediate compliance obligations
• Chainabuse — Victim reports that contextualise specific transactions as extortion, fraud or scam payments
• GraphSense — Open source framework for reproducible multi-hop flow analysis across transaction graphs

A working method

A repeatable sequence beats ad-hoc searching. This is a practical starting workflow:

1. Confirm the chain — Establish which network the hash belongs to before lookup, since identical length hex strings exist across many chains.
2. Capture the full record — Record inputs, outputs, amounts, fee, block height and timestamp verbatim, from a node where independence matters.
3. Read beyond the top level — On contract chains, extract internal transactions and token transfer logs, which frequently carry the value you are actually tracing.
4. Resolve change and payment — On UTXO chains, determine which output is change using established heuristics and state explicitly which heuristic you applied.
5. Trace forward and backward — Follow outputs onward and inputs back, recording each hop with its hash so the chain of movement is fully reconstructable.
6. Anchor to real-world events — Align the timestamp with ransom deadlines, order times, communications and other case evidence to build a combined timeline.
7. Preserve for evidence — Store the raw transaction, block header context and retrieval time so the record can be independently verified later.

How this connects across the intelligence taxonomy

Intelligence work does not respect neat boundaries. The mission domain you are working, the disciplines you practise, and the data points you pivot on are one connected system. These are the direct relationships for this entry — every link is also a tag, so you can follow any thread across the whole library.

Collected by these disciplines

• Financial Intelligence — Following Value Through the Financial System
• Cryptocurrency Intelligence — Tracing Value on Public Ledgers
• Accounting Intelligence — Financial Statements and Accounting Analysis
• Corporate Intelligence — Understanding Companies, Structure, and Control
• Sanctions Intelligence — Screening, Designations, and Evasion Detection
• Legal Intelligence — Law, Litigation, and Regulatory Intelligence

Investigated in these domains

• Financial Crime

Pivots to these data points

• Cryptocurrency Address — Blockchain wallet address for receiving or sending crypto assets.
• Stock Ticker / Security — An exchange-listed security symbol, pivoting to filings, ownership, and market data.
• Sanction / Watchlist Entry — An entry on a sanctions list, watchlist, or PEP database.
• Bank Account / IBAN — A bank account identifier (IBAN, SWIFT/BIC, routing + account) central to financial tracing.

Inside the platform: where Transaction Hash lives

The Quantus platform is 204 pages behind a 147-item sidebar organised into six working groups: Command (24 items), Dashboards (15), Threat Theaters (14), Intelligence Domains (15), Investigate (34), and Administration (45). This entry is not a page in isolation — it is a thread running through several of them.

The modules that matter most here:

• blockchain.php — Transaction Hash profile
• datapoint.php?dp=dp_crypto_tx — Data point hub
• search.php — Advanced search, filter and pivot
• correlate.php — Correlation graph
• cases.php — Case management

Each dashboard is local-first: it renders from the platform’s own database rather than depending on a live third-party call, so it still works when an upstream API is unreachable or rate-limited. Heavy aggregates are cached with a hard query time cap and degrade to the last good value instead of hanging the page.

Automation, playbooks and AI skills

Analysis that only happens when someone remembers to run it is not a capability. The platform ships a 30-step automation pipeline (cron.php) that collects, ingests, resolves, enriches, correlates and scores on a schedule — 25 seeders, 11 resolvers and 7 enrichment runners, all idempotent and cursor-based so a run can be interrupted and resumed without duplicating or losing work.

AI skills that apply

The 16 one-click operations in ai-skills.php are deterministic jobs, not free-text generation. The ones that matter here:

• Enrichment Runner
• Enrichment → Local
• Correlate Infrastructure
• Export STIX/MISP
• Summarise (Copilot)
• Generate Report

Alerting closes the loop: rules in alerts.php fire on new indicators matching a saved query, so a first sighting in this area raises a notification rather than waiting to be noticed at the next review.

Feeds, data sources and the API

The collection layer runs a feed registry of free, machine-readable sources — bulk blocklists and trackers (Maltrail, IPsum, FireHOL, the full abuse.ch corpora, phishing databases, Emerging Threats, Spamhaus, DigitalSide, ThreatView), authoritative government feeds (CISA KEV, OFAC, UN and EU sanctions lists), and reference datasets (RIR allocations, ip-to-ASN and geolocation tables, MITRE ATT&CK, EPSS). collect.php pulls them server-side on a schedule; feeds.php and source-catalog.php show what is registered, what it covers and when it last ran.

Anything the platform holds is reachable programmatically. The REST API in api.php exposes 11 endpoints — status, stats, search, lookup, recent, export, bulk_check, top_threats, by_category, categories, check — and export.php streams 18 formats in bounded chunks, so a million-row export neither exhausts memory nor times out:

STIX 2.1, MISP, OpenIOC 1.1, CEF (ArcSight), LEEF 2.0 (QRadar), Zeek/Bro intel, Snort/Suricata rules, Palo Alto EDL, BIND RPZ, hosts blackhole, iptables, CSV, JSON, NDJSON/JSONL, XML.

That covers the CTI standards (STIX 2.1, MISP, OpenIOC), SIEM ingestion (CEF, LEEF, Zeek), detection engines (Snort/Suricata), and direct enforcement (Palo Alto EDL, BIND RPZ, hosts, iptables) — so intelligence developed here can be actioned in the tools you already run, without a manual reformatting step. A TAXII 2.1 server and a MISP/RSS feed are also served for pull-based sharing.

Use cases

Three ways this entry earns its keep in day-to-day work:

1. Triage under time pressure. An artifact or report lands and you need a defensible read in minutes, not days. Confirm the chain is the first move; the platform pre-computes the enrichment so the analyst spends the time on judgement rather than lookups.
2. Building the picture. A single indicator is rarely the story. Read beyond the top level turns one artifact into a network — shared infrastructure, repeated selectors, the same operator behind different names — via the correlation graph and the cross-entity link engine.
3. Producing something actionable. Analysis that ends in a document nobody can use is wasted. Preserve for evidence feeds the case file, the detection rule, the block list or the referral — with sourcing attached so the recipient can verify it.

Case management (cases.php), watchlists, saved searches and scheduled reports mean the work persists between sessions and survives an analyst leaving the team.

How each sector uses Transaction Hash

The same entry is worked very differently depending on who you are, what authority you hold, and what you are ultimately producing. A military analyst is supporting a commander’s decision; a journalist is meeting a publication standard; an NGO caseworker is protecting a person. The underlying artifacts are shared — the constraints, outputs and thresholds are not.

🎖 Military and defence

Transaction hashes matter to defence primarily in counter-threat finance and in ransomware affecting mission-adjacent networks and suppliers. A txid proves that a specific value moved between specific control points at a specific moment, verifiable by anyone with a node, which makes it unusually robust evidence to pass across coalition and classification boundaries. It anchors a payment to a ransom deadline, a procurement action to a delivery, or a funding transfer to an operational event. Constraints are interpretive: the ledger shows value movement, not purpose or identity, so a transaction supports a financial finding and a referral to threat finance channels rather than any judgement about a person or a target.

🕵 National intelligence

For national intelligence the transaction hash is the atomic unit of financial tracing on public data, and it is permanent, which is rare in open source collection. Requirements-driven use includes reconstructing how a proliferation or sanctions evasion network moved value, establishing the funding chain behind an operation, and timing on-chain activity against real-world events observed through other disciplines. Fusion aligns transaction timestamps with communications, travel and infrastructure activity to build combined timelines. Assessments should record block height and retrieval time and, where the finding matters, verification against an independently operated node, so a recipient is not depending on a commercial explorer's indexing.

👮 Law enforcement

In law enforcement a transaction hash is close to ideal digital evidence: immutable, timestamped, independently verifiable and reproducible by any expert. It proves a specific transfer occurred, which supports fraud reconstruction, ransom payment analysis, asset tracing and restraint applications. Evidence handling is straightforward but must be done properly: capture the raw transaction, the block header context, the confirmation depth and the retrieval time, and verify against a node under your control rather than relying on a third-party explorer. Seizure, freezing and restraint require formal legal process directed at the service holding the assets, never an analytical conclusion, and identification still depends on records held by regulated intermediaries.

🔍 Private investigation and corporate security

Corporate investigators use transaction hashes in fraud recovery, ransomware response and dispute work. A txid substantiates that a payment was made, when, in what amount and to which address, which is frequently the disputed fact in a recovery action or an insurance claim. It also supports rapid engagement with exchanges, which can act on a well-evidenced tracing request through their own compliance processes far faster than a formal legal route. Private actors may analyse and present chain evidence but cannot compel disclosure or freeze assets; those steps run through counsel, the exchange's compliance function and law enforcement, and speed matters because funds move quickly.

📰 Journalism and OSINT media

A transaction hash is the most verifiable citation available in financial reporting: any reader can independently confirm the amount, timing and counterparties. That makes it excellent for stories on ransomware payments, sanctions evasion and illicit flows. The care required is in interpretation. On UTXO chains, identifying which output is a payment and which is change is an analytical step that should be stated, not assumed. On contract chains, the value being traced often sits in internal transactions and token logs invisible in the top-level view. Cite the hash and the chain, explain the heuristic used, and never present a traced flow as proof of who controlled either end.

🌍 NGO, humanitarian and human rights

Transaction-level evidence supports accountability work on conflict financing, trafficking proceeds, wildlife crime and corruption, and it is durable evidence that endangers no source. For organisations receiving cryptocurrency donations, the transaction record is also the basis of the screening and reporting obligations that come with accepting virtual assets. Where analysis touches victims, including people coerced into moving funds, keep the objective on recovery and disruption rather than exposure, since publishing a traced flow can identify individuals who were exploited rather than culpable. Preserve records with retrieval timestamps so documentation remains usable by a court or commission years later.

🎓 University and research

Transaction-level data supports research on illicit finance, market microstructure, fee dynamics, protocol behaviour and privacy technology, with reproducibility achievable to an unusual degree because the ledger is public and permanent. Pin block heights and dataset snapshots, publish extraction and heuristic code, and release the transaction identifier sets underlying any result. Report the change identification method and its error characteristics explicitly rather than treating heuristic output as ground truth. Ethics review applies where transactions can be linked to identifiable individuals, and published attribution of specific flows to named people generally requires the same scrutiny as any human subjects work.

Playbook: working Transaction Hash end to end

A repeatable sequence, from the moment the requirement lands to the moment a product is delivered and the case is closed out. Each phase states what you are trying to establish, not merely what to click — the point is a defensible chain of reasoning, not a checklist.

Phase 1 — Confirm the chain before lookup

Establish which network the hash belongs to, since sixty-four character hex strings are valid identifiers on many chains and the same hash format tells you nothing about the network. Where the source is a ransom note, an exchange record or a chat log, the chain is often implied rather than stated. A good output is a typed record with the chain identified and the source of that determination. Stop and clarify rather than guessing, because a hash that returns nothing may simply be on a different network.

Phase 2 — Capture the full record verbatim

Record inputs, outputs, amounts, fee, block height, block time, confirmation count and, on contract chains, the call data and status. Capture the raw transaction rather than a rendered summary, because rendered views omit fields and reformat values. A good output is a stored raw record plus a human-readable summary, both with the retrieval time. Note the confirmation depth at capture, since a transaction with few confirmations is not yet settled in the sense a court or a counterparty would expect.

Phase 3 — Verify independently where it matters

For any transaction that will support an evidential or high-consequence conclusion, verify against a node you control rather than accepting a third-party explorer's rendering. Explorers can be unavailable, can change indexing behaviour and introduce a dependency that opposing experts will probe. A good output is a verification record naming the node and its chain tip at the time. Where running a node is impractical, verify against at least two independent explorers and record both, stating the limitation explicitly.

Phase 4 — Read beyond the top level

On contract chains, extract internal transactions and token transfer event logs, because the value you are tracing frequently never appears in the top-level record. A transaction showing zero native value may have moved a very large token amount through a contract call. Decode call data where the contract is verified. A good output is a complete value movement record covering native, internal and token transfers. This is the single most common omission in EVM tracing and it produces traces that miss the money entirely.

Phase 5 — Resolve change and payment on UTXO chains

Determine which output is the payment and which is change using established heuristics such as address reuse, round-number amounts, script type consistency and output ordering behaviour of specific wallet software, then state explicitly which heuristic you applied and its confidence. Getting this wrong sends the trace down the wrong branch immediately. A good output records the decision, the reasoning and the alternative branch not taken, so a reviewer can test the choice rather than inherit it.

Phase 6 — Fingerprint the creating wallet

Examine fee rate strategy, input selection behaviour, output ordering, script types, nSequence and locktime usage, and RBF signalling, which together fingerprint the wallet software used to construct the transaction. That is a genuine and underused discriminator that can link transactions across otherwise unconnected addresses. A good output is a construction profile recorded alongside the transaction. State it as a software fingerprint rather than an operator identification, since many people use the same wallet software.

Phase 7 — Trace forward hop by hop

Follow outputs onward, recording each hop with its transaction hash, amount, timestamp and the branch decision made, until you reach a regulated service, a mixing boundary or the current chain tip. Discipline matters more than depth: an undocumented ten-hop trace is unusable, whereas a three-hop trace with every decision recorded is evidence. A good output is a hop table where each row cites a hash and states why that branch was followed and which alternatives were rejected.

Phase 8 — Trace backward to funding

Follow inputs back toward their origin, which frequently reveals the shared funding wallet, affiliate structure or service purchase connecting incidents that appeared unrelated. Backward tracing gets far less attention than forward tracing and produces a disproportionate share of the links that connect cases. A good output is a funding path with hop counts and dates. Note where inputs originate from an exchange withdrawal, since that is a lawful process opportunity at the start of the flow rather than the end.

Phase 9 — Anchor to real-world events

Align block timestamps with ransom deadlines, marketplace order times, communications, travel, corporate events and other case evidence to build a combined timeline. Because block times are independently verifiable and cannot be retrospectively altered, they are unusually strong timeline anchors. A good output is a merged timeline distinguishing chain-derived times, which are reliable, from claimed or reported times, which are not. Note that block time is approximate to within a tolerance and should not be treated as second-accurate.

Phase 10 — Screen counterparties for designation

Check every address involved, and the clusters they belong to, against sanctions designations, because exposure attaches to counterparties regardless of intent and can arise through an intermediary hop. This is a legal control with immediate consequences rather than an analytic refinement. A good output is a screening record with list version and date attached to the transaction record itself. Route hits to compliance and counsel before any further engagement, payment or public reporting.

Phase 11 — Assess what the transaction cannot show

State explicitly the limits: the chain does not show purpose, agreement, identity, off-chain settlement, or payments made in other assets or channels. A failed transaction still exists on chain and still carries evidential value about intent, which is easily overlooked. A good output includes a short limitations paragraph in every product. This is what prevents a reader from concluding that a traced flow proves a commercial relationship, which is the inference readers make unless it is expressly closed off.

Phase 12 — Preserve for evidence and reproducibility

Store the raw transaction, the block header context, confirmation depth, retrieval time and the node or explorer used, plus the full hop table and every heuristic decision. Where proceedings are likely, follow digital evidence handling practice with hashes over the stored records. A good output is a methodology annex allowing another analyst to reproduce the entire trail from public data, which is the standard the permanence of the ledger makes both achievable and expected of competent work.

The platform ships this as a step-checked workflow in playbooks.php, so progress is recorded against a case rather than held in someone’s head.

Source register: what to collect from, and how

Sources are listed with their access model so you can plan around cost and licensing before you build a dependency on them. Open means no account required; registration means a free account or API key; licensed means paid or institutional access. Always confirm current terms — licensing changes, and a source that was free for research may not be free for commercial or evidential use.

Source	Access	What it gives you	How it is used here
mempool.space	Open	Bitcoin explorer with full input and output breakdown, fee analysis, visual transaction graphs and mempool context.	Primary Bitcoin transaction examination including fee behaviour and change identification context.
Blockchair	Open	Multi-chain transaction lookup with structured data, advanced filtering and bulk export across major blockchains.	Cross-chain transaction retrieval and structured export for offline hop-by-hop analysis.
Etherscan	Registration	Ethereum transaction view including internal transactions, token transfer logs, decoded call data and contract source.	Reveals internal and token value movements that never appear in the top-level EVM transaction record.
Blockscout	Open	Open source explorer with decoded contract interactions and full transaction detail across many EVM networks.	Covers EVM chains where commercial explorers provide poor or no indexing.
Bitcoin Core	Open	Reference full node with RPC access, giving authoritative transaction and block data without third party trust.	Independent verification of transactions for evidential work, and authoritative raw transaction retrieval.
GraphSense	Open	Open source cryptoasset analytics implementing tracing and clustering with published, inspectable methodology.	Reproducible multi-hop tracing where the method must be examinable rather than proprietary.
OFAC Sanctions List Search	Open	US designations publishing specific cryptocurrency addresses associated with designated persons, entities and services.	Screening of every counterparty address encountered during a trace, at each hop.
Bitcoin Improvement Proposals	Open	Specifications defining transaction formats, script types, address encodings, RBF signalling and protocol behaviour.	Authoritative reference for interpreting transaction structure and wallet construction fingerprints.
Ethereum Improvement Proposals	Open	Specifications defining EVM transaction types, token standards and event log structures used in value tracing.	Explains how token transfers are recorded in logs rather than in the transaction value field.
Chainabuse	Open	Community reports linking addresses and transactions to scams, extortion and fraud with victim narrative context.	Provides off-chain corroboration and victim context for the endpoints of a traced flow.
FinCEN advisories	Open	US guidance on virtual asset red flags, ransomware payment reporting and suspicious activity reporting obligations.	Defines the typologies and reporting duties into which transaction analysis must feed.
FATF virtual asset guidance	Open	International standards for virtual asset service providers including travel rule data accompanying transfers.	Explains what originator and beneficiary information regulated services hold for a given transfer.
IC3	Open	US Internet Crime Complaint Center reporting channel and advisories covering cryptocurrency fraud and extortion.	Victim reporting route where a traced flow originates in fraud, and a source of typology context.
Ransomware.live	Open	Aggregated ransomware leak site data with group attribution and associated extortion infrastructure where published.	Connects a traced payment to a named ransomware operation and its wider victim and payment pattern.

Prefer sources that publish a methodology and a revision history. A dataset that changes silently is a liability in any product that has to survive challenge.

Tooling

Tools commonly used against Transaction Hash. None of these replace judgement, and each carries its own failure modes — know what a tool infers versus what it observes.

• Full node with RPC — Provides authoritative raw transaction and block data with no third party dependency. Limitation: substantial storage, bandwidth and synchronisation overhead.
• mempool.space and Blockchair — Fast transaction inspection with structured export across chains. Limitation: rendered views omit fields, so capture raw data for evidence.
• Etherscan decoders — Expose internal transactions, token logs and decoded call data on EVM chains. Limitation: unverified contracts cannot be decoded automatically.
• GraphSense — Open source multi-hop tracing with inspectable heuristics. Limitation: running it at full chain scale requires significant infrastructure.
• Commercial tracing platforms — Automate multi-hop tracing with entity labels and risk scoring. Limitation: proprietary heuristics cannot be independently reproduced or challenged.
• Transaction graph visualisation — Renders hop chains and flows for analysis and presentation. Limitation: visual clarity tends to overstate the confidence of the branch decisions beneath it.
• Hop table and case management — Records each hop with hash, amount, time and branch reasoning. Limitation: only useful if analysts record rejected branches as well as followed ones.
• Evidence preservation tooling — Stores raw records with hashes and retrieval metadata for later verification. Limitation: worthless unless applied at capture rather than reconstructed later.

AI skills and automation in detail

These are deterministic jobs with defined inputs and outputs, not open-ended prompting. Each is idempotent and cursor-based: interrupt one and it resumes where it stopped rather than duplicating work or losing progress.

• Enrichment Runner — Walks the indicator set through a chosen provider in time-boxed, cursor-based batches that resume rather than restart.
• Enrichment → Local — Materialises enrichment into the local store so dashboards render from your own database instead of a live third-party call.
• Correlate Infrastructure — Builds the cross-entity link graph: shared hosting, reused certificates, overlapping registrants, repeated selectors.
• Export STIX/MISP — Streams the selection in CTI standard formats for sharing with partners and ISACs.
• Summarise (Copilot) — Produces a narrative summary beside the underlying records. It explains; it never creates indicators or assigns attribution.
• Generate Report — Assembles a sourced product from the current case or query, with provenance attached to each element.

A note on the boundary: the only skill that involves a language model is Summarise (Copilot), and it writes prose about records that already exist. Nothing else on this list involves generation of any kind. No indicator, relationship or attribution in the platform originates from a model. See the full skill list.

Tradecraft notes

The distinctions that separate a competent analyst from a fast one:

• Change identification is the branch point of the entire trace. On UTXO chains, choosing the wrong output as the payment sends everything downstream in the wrong direction, so state the heuristic used and record the alternative branch you rejected.
• On contract chains the money is usually not in the value field. Token transfers and internal transactions live in event logs and traces, so a transaction showing zero native value can have moved an enormous token amount, and reading only the top level misses it entirely.
• Failed transactions are evidence. They exist permanently on chain, they cost a fee, and they record an attempt with a timestamp and a target, which frequently establishes intent or a relationship that succeeded transactions do not.
• Fee strategy, input selection, output ordering and locktime usage fingerprint the wallet software that built a transaction. That is a real and underused discriminator for linking activity, provided it is reported as a software fingerprint and not as an operator identification.
• Block timestamps are strong timeline anchors because they are independently verifiable and cannot be retrospectively altered, but they are approximate within a tolerance and are not second-accurate. Say which precision your timeline claim actually needs.
• Depth of trace is worth less than documentation of trace. A three-hop chain where every branch decision is recorded with its reasoning is usable evidence, while an undocumented ten-hop chain is an assertion that no reviewer can test or reproduce.
• Verify against your own node when the conclusion matters. The ledger is public and permanent, so independent verification is achievable in a way it never is for other financial records, and an opposing expert will ask whether you did it.
• Confirmation depth is a settlement statement. A transaction with a handful of confirmations has not settled in the sense a court or a counterparty means, and recording the depth at capture prevents an argument about finality later in the matter.

Measuring whether it is working

Capability claims should be falsifiable. These are the measures that show whether work on Transaction Hash is producing anything, and they are worth baselining before you change process or tooling.

• Proportion of traces where every hop is recorded with hash, amount, timestamp and the branch decision reasoning, which determines whether the work is reviewable.
• Share of evidential conclusions verified against an independently operated node rather than a third-party explorer alone.
• Median time from receipt of a payment hash to a completed trace reaching a named regulated service, since speed determines whether funds can still be frozen.
• Rate at which traces are later corrected because of a change identification error, tracked as a calibration measure on heuristic confidence.
• Proportion of EVM traces where internal transactions and token logs were extracted, rather than only the top-level record, which is the common omission.
• Recovery, freezing or restraint actions initiated from traced evidence, which is the outcome measure that matters more than hop counts or volume analysed.
• Percentage of products containing an explicit limitations statement covering what the chain cannot show, preventing over-reading by non-specialist recipients.

Beware of measuring volume alone. Indicator counts and report counts rise easily and say little; time-to-attribution, proportion of findings that survive review, and how often a product changed a decision say a great deal.

Common pitfalls

• Unconfirmed transactions can be replaced or dropped, so acting on a mempool observation before sufficient confirmations risks recording an event that never settled.
• Chain reorganisations can invalidate recently confirmed transactions, which matters for any conclusion drawn near the chain tip.
• Misreading the change output reverses the direction of a trace and can produce a confidently wrong attribution of ownership.
• Token transfers on contract chains do not appear in top-level transaction data, so naive reading of value transferred is often simply wrong.
• Peel chains and automated splitting generate enormous transaction counts designed to exhaust manual tracing effort.
• Cross-chain bridges break the trail entirely unless the corresponding transaction on the destination chain is separately identified.

Legal and ethical considerations

Transaction data is public, immutable and lawful to collect, which makes it unusually strong evidence when handled properly. Preserve records with retrieval timestamps, block heights and, where possible, verification against your own node, so authenticity does not rest on a third party explorer. Once transactions are linked to identified individuals the resulting analysis becomes personal data. Sanctions exposure attaches to counterparties regardless of intent, and asset recovery or seizure steps require formal legal process rather than analytical conclusion alone.

Data integrity: no fabrication, no drift, no hallucination

Intelligence that cannot be traced back to a source is not intelligence, it is assertion. Everything in this entry — and everything in the platform behind it — is built on a small number of non-negotiable rules.

Provenance on every record

Every indicator carries the source that supplied it, a first-seen and last-seen timestamp, and a sighting count. Where several feeds report the same artifact, each contribution is recorded separately rather than collapsed, so you can see whether a finding rests on one source or twelve. Source attribution travels with the data into every export, so a recipient can audit a claim without asking you for the working.

Nothing is invented to fill a gap

If the platform has no data for Transaction Hash, it says so. Empty is displayed as empty — never padded with plausible-looking placeholder values, sample records or illustrative examples that a reader might mistake for observations. A dashboard with no rows is a true statement about collection coverage, and it is treated as a gap to close, not a blemish to hide.

Scoring is deterministic and reproducible

Threat scores, reputation grades and risk tiers are computed from stated inputs with fixed weights, not estimated. The same inputs always produce the same output, and the formula is visible rather than a black box. Aggregates are cached with an explicit time-to-live so a figure on screen is never silently stale — and when a heavy query exceeds its time budget the platform serves the last known-good value and labels it, rather than inventing a fresh number or hanging.

Where AI is used, and where it is not

Language models summarise and explain. They do not create indicators, assign attribution or manufacture relationships. No IP address, wallet, hash or identity in the platform originates from a model — every one is ingested from a named feed, resolved from a reference dataset, or entered by an analyst with a source recorded. Copilot output is presented as narrative alongside the underlying records, never in place of them, so a reader can always check the summary against the evidence.

Guarding against drift

Enrichment is additive and timestamped rather than overwriting. Reference data — sanctions lists, allocations, taxonomies — is re-synchronised from the authority on a schedule instead of being edited in place, so local copies cannot quietly diverge from the source of truth. Attribution is recorded with a confidence level and the reporting it rests on, and inferred relationships are labelled as inferred. When a source retracts or corrects, the correction propagates rather than leaving a stale assertion behind.

What this means for you

You can put a finding from this platform in front of a regulator, a court, a board or a partner agency and show where each element came from. That is the standard the tooling is built to — because in this work, being confidently wrong is more damaging than being usefully uncertain.

By the numbers

The taxonomy this entry belongs to is not a marketing list — it is the actual structure of the platform: 52 mission domains, 52 intelligence disciplines and 65 data points, each with a live dashboard behind it. Supporting that: 18 indicator types, 14 playbooks, 16 AI skills, 18 export formats and a 30-step automated pipeline.

This particular entry connects directly to 6 intelligence disciplines, 1 mission domains, 4 closely related entries — every one of them a tag you can follow, and a dashboard you can open.

Questions analysts actually ask

How do I know which output is change?

By applying established heuristics and stating which one you used. The common signals are address reuse, since a change output frequently returns to a script type matching the inputs; round-number amounts, which usually indicate the payment rather than the change; script type consistency, since many wallets send change to the same type they spend from; and known output ordering behaviour of specific wallet software. None is conclusive. Record the decision, the reasoning and the branch you rejected, so a reviewer can test the choice. Getting this wrong sends the entire downstream trace in the wrong direction.

Why does the Ethereum transaction show zero value?

Because the value moved as a token transfer or through internal transactions rather than as native currency. On EVM chains the top-level value field records only native asset movement; ERC-20 and similar token transfers are recorded as event logs emitted by the token contract, and contract calls can trigger internal transactions that move value without appearing as separate top-level records. Read the logs and the internal transaction trace, and decode the call data where the contract is verified. Analysts trained on Bitcoin routinely miss the entire flow they are tracing because of exactly this.

Is a transaction hash sufficient evidence of payment?

It is strong evidence that a specific value moved between specific control points at a specific time, independently verifiable by anyone. What it does not establish is who controlled either end, what the payment was for, whether an off-chain agreement existed, or whether other payments were made in different assets or channels. For evidential use, capture the raw transaction, block header context, confirmation depth and retrieval time, and verify against your own node. Then state the limitations explicitly, because readers will otherwise infer a commercial relationship the chain does not show.

What does confirmation depth actually mean for evidence?

It measures how deeply the transaction is buried under subsequent proof of work or consensus, and therefore how economically infeasible reversal has become. A transaction with one or two confirmations is included but not settled in any meaningful sense, and reorganisations at shallow depth do occur. For evidential purposes record the depth at capture and again at a later date, which demonstrates settlement over time. Exchanges apply their own confirmation thresholds before crediting funds, and those thresholds are sometimes the relevant standard in a dispute about when a payment was complete.

How far should I trace?

Until you reach a regulated service where lawful process can obtain identity data, a mixing or privacy boundary you cannot reliably cross, or the point where each additional hop adds more uncertainty than information. Depth without documentation is worthless: every hop multiplies the branch decisions and therefore the accumulated uncertainty. A short, fully documented trace ending at a named exchange is far more useful than a long undocumented one. State where the trace ended and why, and report a mixing boundary as a boundary rather than silently continuing past it.

Can a transaction be reversed or altered?

No, once confirmed to reasonable depth, and that immutability is what makes the data unusually good evidence. Before confirmation, a transaction sitting in the mempool can be replaced where replace-by-fee is signalled, and shallow reorganisations can displace very recent transactions. Neither alters history at depth. What can change is your view of it: explorers reindex, chains fork, and services present data differently. Record block height and retrieval time, preserve the raw record, and verify independently, so your evidence does not depend on any third party's continued availability.

What can I do with a transaction hash after a fraud?

Move quickly and through the right channels. Preserve the hash, the raw transaction, any communications and the payment context with timestamps. Trace forward to identify whether funds reached a regulated exchange, and if so, notify that exchange's compliance function immediately, since they can act on a well-evidenced request faster than a formal legal route and funds move within hours. Report to the national fraud reporting body and to law enforcement, and engage counsel about restraint or freezing applications. Screen counterparties against sanctions designations before any negotiation is contemplated.

Standards, frameworks and further reading

Work that references a recognised framework is easier to defend, easier to hand over, and easier for a partner to consume:

• FATF Recommendation 15 and virtual asset guidance define the travel rule data that must accompany transfers between regulated service providers.
• EU Transfer of Funds Regulation implements travel rule obligations for crypto-asset transfers within and into the EU.
• OFAC sanctions regulations create strict liability for transactions involving designated addresses, including through intermediaries.
• ISO/IEC 27037 governs identification, collection and preservation of digital evidence, applicable to preserved transaction records.
• Bitcoin Improvement Proposals define transaction structure, script types, RBF signalling and address encodings underpinning transaction interpretation.
• Ethereum Improvement Proposals define transaction types and token standards, including the event log structures that carry token transfers.
• FinCEN reporting requirements define suspicious activity reporting obligations for US regulated entities handling virtual assets.
• EU Markets in Crypto-Assets Regulation establishes the supervisory framework determining which services hold customer identity records.

References

Primary sources and authoritative references for this entry. Publishers revise and retire material, so treat the retrieval date as part of the citation and re-check before relying on any of it in a formal product.

1. mempool.space — mempool.space. Bitcoin explorer with detailed input, output and fee analysis for individual transactions.
2. Blockchair — Blockchair. Multi-chain transaction lookup with structured data and export.
3. Etherscan — Etherscan. Ethereum explorer exposing internal transactions, token logs and decoded call data.
4. Bitcoin Core — Bitcoin Core project. Reference full node providing authoritative and independently verifiable transaction data.
5. GraphSense — GraphSense project. Open source tracing and clustering platform with published methodology.
6. Virtual assets guidance — Financial Action Task Force. International standards governing virtual asset transfers and originator information.
7. Sanctions List Search — US Department of the Treasury, Office of Foreign Assets Control. Designated cryptocurrency addresses screened at every hop of a trace.
8. Bitcoin Improvement Proposals — Bitcoin community. Specifications defining transaction structure and wallet behaviour used in construction fingerprinting.

Link integrity: every reference above was verified with a live request when this page was generated. Where a publisher had moved or withdrawn a document, the link was repointed at a preserved copy in the Internet Archive and marked as archived. Anything with no reachable copy anywhere had its link removed rather than left to rot — the source is still credited, it simply cannot be linked.

Put it into practice

The Quantus Intel threat intelligence platform operationalises this entry: transaction-level tracing with decoded contract activity, multi-hop flow reconstruction and evidence-grade preservation. Explore the platform, or browse the rest of the library by following any tag above.