Visualizing flows and visual evidence for courts

Most readers of a tracing report look at the pictures first, and some never read the text at all. Judges and juries remember the flow chart long after they have forgotten the transaction table. That makes figures the most persuasive part of a crypto case, and the part most likely to be attacked: a chart that shows more certainty than the report, or that cannot be traced back to the data, can damage the credibility of everything else the expert says. This lesson covers choosing and building the right visual, keeping it honest and readable, and turning it into an exhibit a court can follow, check and rely on. The report around the figures is covered in Lesson 9.2.

Choose the visual by the question

Start from the question the reader needs answered, not from the tool you have open.

Every visual simplifies, and each hides something. A court figure should make one claim: if the report has four findings, it may need four figures, or one overview with detail figures, each tied to a finding number.

Sankey diagrams

A Sankey diagram draws flows as bands whose width is proportional to the value moved. It is named after Matthew Sankey, who used one in 1898 to show the energy efficiency of a steam engine, and it is the clearest way to show how a sum was split. Worked example: an exploiter address holds 941.2 ETH after swapping its loot, and three bands leave it: 600 ETH to a cross-chain swap service, 300 ETH to a bridge, and 41.2 ETH that stayed put. The widths are in the ratio 600 : 300 : 41.2, so the reader sees at once that almost two thirds went one way.

Rules that keep a Sankey honest:

• Conserve value. What enters a node equals what leaves plus what stays. Show fees, unspent balances and untraced amounts as explicit bands ("fees 0.002 BTC", "unmoved 41.2 ETH", "not traced"); never let them silently disappear.
• One unit per diagram. Draw one Sankey per asset, or convert to one currency at the time of each transfer and state the price source.
• Order columns by hop or by time, left to right, and say which.
• Avoid cycles. Round-tripping belongs in a flow graph.

The data behind a Sankey is an edge list (source, target, value), produced directly from a case table of traced ETH transfers with the same columns as transactions (Lesson 2.7):

-- Edge list for a Sankey: value moved between labeled entities
SELECT
  COALESCE(ls.entity, t.from_address) AS source,
  COALESCE(lt.entity, t.to_address)   AS target,
  SUM(t.value) / 1e18                 AS eth_moved,   -- value in wei, as in transactions
  COUNT(*)                            AS transfers
FROM traced_transfers t
LEFT JOIN labels ls ON ls.address = t.from_address
LEFT JOIN labels lt ON lt.address = t.to_address
GROUP BY 1, 2
ORDER BY eth_moved DESC;

The left joins use entity names where a label exists and keep the raw address otherwise. A single "Unlabeled" bucket instead would merge unrelated addresses and draw flows that never happened. The joins assume one label per address (otherwise sums fan out; see Lesson 2.8), and dividing by 1e18 gives a floating-point number in many engines, so cast to a high-precision decimal when exact figures matter.

Flow graphs, timelines and cluster maps

A flow graph draws addresses or entities as boxes and transfers as arrows, the native picture of tracing work (Lesson 3.1).

• Use a layered, left-to-right layout, each column a hop or time step, so readers follow the money like text. Force-directed layouts are for exploration only: position there is an artifact of the algorithm, and two nodes drawn close together look related even when they are not.
• Distinguish observed from inferred. Solid arrows for transfers recorded on chain; dashed arrows for inferences (an amount-time bridge match, a change-output call), with the grade or likelihood term next to them.
• Label edges with amount, date and a short transaction reference; keep the full hash in the appendix.
• Show where tracing stopped, and why: "custodial service, records requested" or "not traced further". The boundary is a choice, not the end of the money.
• Keep it small. Above about 30 to 50 nodes a graph stops being readable. Collapse peel chains ("peel chain, 9 hops") and clusters into single boxes, with detail in the appendix.

Whatever tool you use (open ones include Graphviz for layered layouts and Gephi or Cytoscape for exploration), export the edge list with the figure.

A timeline answers "when" and "in what order", which often matters more in court than the path, because it connects on-chain events to witness testimony and shows whether there was time to freeze. Show block times in UTC with block heights and, where events must be compared with witness accounts, also the local time the witnesses lived through, with the offset stated. Use one swimlane per chain in cross-chain cases, so a bridge deposit and its release sit side by side. Distinguish on-chain events (a transaction confirmed) from off-chain events (the victim's report, a freeze request, an arrest) by shape or lane, not only by color. Keep gaps visible: a three-week pause before a deposit is evidence; mark any axis break.

A cluster map shows entity resolution: each cluster as a container with its addresses or address count, and each reason for a link (common inputs, shared deposit address) as a distinct line style. If bubble area shows size, say whether it encodes address count or balance, and warn the reader when a cluster is suspiciously large (Lesson 4.4).

Maps of places carry a special risk. IP geolocation from provider records is approximate, and addresses may belong to VPNs, hosting providers or mobile networks. Show such locations as a region or radius with source and date, never as a pin on a street. A provider's registered office, its servers and its customers may be in three different countries; a map of "where the money went" must say which it shows.

A figure is an exhibit

In court a figure is part of the evidence, or at least a summary the court relies on. Whether a chart counts as evidence in its own right or only as an aid varies between systems; either way, treat it as an exhibit. It needs a unique identifier and version matching the report, the data cut-off and source data, the appendix rows supporting every edge, amount and date, and the author and tool. Generate figures from data rather than drawing them, and keep the input file under hash so the opposing expert can regenerate the same picture:

{
  "figure_id": "FIG-04",
  "version": 2,
  "title": "Movement of the stolen 41.6 BTC, 14 to 16 March 2026",
  "source_file": "fig04_edges_v2.csv",
  "source_sha256": "9c1e…a07b",
  "appendix_rows": "A14-A31, B3-B9",
  "data_cutoff": {"bitcoin_block": 941350, "ethereum_block": 24812000},
  "generated_with": {"tool": "open-source graph layout library", "version": "12.1"},
  "supersedes": "FIG-04 v1, report v1.0",
  "author": "Examiner 2"
}

If a figure changes between report and hearing, the manifest records why, and the version shown in court must be the one disclosed. A figure that appears for the first time at the hearing, or differs from the disclosed version, is an easy target and may be excluded (Lesson 8.4).

Designing for the courtroom

A court figure serves the judge or panel, lay decision-makers where a system uses them, and the opposing expert, who will check every number. They may meet it in printed bundles, often photocopied in grayscale and reduced; projected in a courtroom from several meters away; on shared screens in video hearings; or in electronic files on any device. Design for the worst: print it in grayscale at bundle size, view it projected from the back of a room, and check every label is readable without zooming.

• Put the legend first, at the top: "solid line: transfer recorded on the blockchain; dashed line: expert's inference, with its grade".
• Use plain names: "deposit address at Exchange K", not "cluster 88412".
• Account for all the value: if 41.6 BTC entered, show where all 41.6 BTC went, including fees, unmoved balances and untraced amounts.

Showing uncertainty

Uncertainty that is clear in the report often disappears in the figure. Grade every inferred edge with the report's own terms, such as "strong support" or "very likely", and nothing stronger. Show ranges where methods disagree: if FIFO allocates 2.0 BTC to Exchange K and haircut allocates 0.7 BTC (Lesson 3.3), show both or the range, not the more helpful number. Show candidates: a bridge release chosen from three is drawn with its alternatives or annotated "1 of 3 candidates in the window". Round in the figure, exact in the appendix: "about 2.95 BTC" in the picture, eight decimals in the table; "1,912,400.000000 USDC" in a figure suggests certainty about attribution that the amount does not carry. Date every fiat value, with the price source and whether it is at the time of each transfer, the theft or the report; in a volatile market these can differ by multiples.

Avoiding misleading visuals

Visuals mislead more often through layout than through wrong data:

• Truncated or inconsistent axes: a bar chart starting at 900 ETH makes 950 look double 925. Use one scale across charts meant to be compared.
• Area versus length: if bubble radius encodes value, doubling the radius quadruples the area. Scale area, not radius.
• Unlabeled log scales read as linear.
• Loaded color: red for an entity only suspected implies a verdict; reserve warning colors for established facts, such as a confirmed exploit contract.
• Selective omission: showing only paths that reach the suspect and dropping larger flows elsewhere.

Before a figure goes into the bundle, a reviewer who did not make it runs a pre-hearing check:

Animation that makes funds "race" through addresses implies speed and certainty the data may not support, and cannot go into a printed bundle. Prepare a static version of every animated sequence, disclose both, and make the final frame identical to the static figure.

Accessibility

Reports are read on phones, printed in grayscale and read by people with color-vision deficiency, which affects roughly 1 in 12 men and 1 in 200 women. The Web Content Accessibility Guidelines (WCAG 2.1 and 2.2) give useful targets even for documents: text contrast of at least 4.5:1 (3:1 for large text), at least 3:1 for meaningful graphical elements such as lines and bands, and never color alone to carry meaning. Solid for observed and dashed for inferred works in grayscale too. Give every figure alt text or a caption that states the takeaway ("two thirds of the funds went to the cross-chain swap"), not just a description ("a Sankey diagram"), and include the underlying table in the appendix so screen-reader users and reviewers get the same information.

Exam focus: matching the visual to the question (Sankey for amounts, flow graph for paths, timeline for order, cluster map for entity resolution) and one claim per figure; Sankey rules (conservation, explicit fees and untraced amounts, one unit, no cycles); building an edge list without merging unlabeled addresses; layered versus force-directed layouts; solid arrows for recorded transfers, dashed and graded for inferences, and showing where tracing stopped; UTC plus stated local time and separate on-chain and off-chain events on timelines; IP geolocation as a region with source, never a street pin; a figure as an exhibit with identifier, version, cut-off, source hash and appendix rows, and matching the disclosed version; designing for grayscale print and projection; showing method ranges, match candidates and dated fiat values; misleading layouts and the pre-hearing check; static versions of animations; WCAG targets of 4.5:1 for text and 3:1 for graphics.