From Finding to Evidence: Making an On-Chain Trace Defensible

A trace is not yet evidence. A finding becomes evidence when someone else can check it — repeat the analysis, examine what it rested on, and weigh how much it proves. This chapter is the field guide’s closing discipline: how to turn a reading of a walletSoftware or hardware that stores private keys and uses them to sign transactions. A wallet holds keys, not coins — balances live on the ledger itself — so the same funds can be reached from any wallet loaded with the same keys, and losing the wallet loses nothing if the keys are backed up elsewhere. into something defensible, using the machinery a serious tool should provide and the standards that govern digital evidence. The uncertainty mechanics it draws on live in How Confident Is That Answer?; what follows carries that honesty into a report.

Capture and preserve

A blockchainA shared ledger maintained by many independent computers, in which transactions are grouped into blocks and each block cryptographically references the one before it. Because rewriting any past entry would break every link after it, the record is effectively append-only — new entries can be added, but history cannot be quietly altered. is, in NIST’s words, “tamper evident and tamper resistant,” such that “no transactionA signed instruction ("tx" for short) that changes on-chain state — transferring value, calling a contract, or updating an account's settings. Once it is included in a block and that block reaches finality the record is permanent: later transactions can supersede its effects, but the entry itself can never be edited or deleted. Before finality, a freshly included transaction can still be reversed if its block is reorganized out. can be changed once published.” So preservation for an on-chain investigator is not about protecting the ledger — it is about recording which records you read and when you read them. The long-standing digital-evidence principles apply in their plainest form: do not alter the original data, and be competent to explain what you did with it.

A defensible tool anchors its findings to things you can preserve. An activation finding should carry the activating transaction hashA fixed-length fingerprint computed from data of any size by a one-way function: the same input always produces the same output, but the output reveals nothing about the input and no practical method finds a second input that matches it. Transaction IDs and block IDs are hashes, and each block embeds the previous block's hash — which is what makes tampering with history detectable. as a first-class field. A control finding is a point-in-time permission snapshot fetched live from the chain; because it reflects current on-chain state, it is the most reliable kind of reading you can take — good for the moment it was taken. Historical permission state is reconstructible after the fact, because every AccountPermissionUpdateContract is a full permission snapshot dated to its block. And every result should be stamped with the version of the analysis method that produced it — a stamp that tracks the method’s identity, not the app’s package version, so an investigator can cite which generation of the method made a finding.

A gap worth naming: an on-chain analysis does not, on its own, stamp its wall-clock capture time. So record it yourself. A minimal preserved finding is the target addressA public identifier, derived from a key pair, at which an account receives funds and is looked up on-chain. Anyone can view an address's history, but only the matching private key can spend from it. TRON addresses are 34-character Base58Check strings beginning with "T"., the transaction hashes and block timestamps behind it, the permission snapshot, the analysis version, and the date and time you captured the result.

Make it reproducible

In digital-evidence practice, the bar for process is that an independent third party can repeat the steps and reach the same result. Three properties get an analysis there.

A full-history read at request time is the foundation. If the analysis saw the wallet’s complete on-chain record, a thin result means the record really is thin, and a re-run reads that same record plus whatever has happened since. The ordering of candidates must be deterministic: when a fixed, stated tie-break rule governs otherwise-equal candidates, the same inputs always produce the same ranking — so an independent re-run reaches the same order rather than a re-shuffled one. The last piece is server-side — a cache keyed to the analysis version, so a re-query within the window returns an identical result and a method change cannot quietly pass itself off as the old one.

Completeness is the other thing a tool must not over-claim. A history can be treated as complete only when the full-history pull provably was not truncated, and a provably complete history is one you can describe plainly in a report: the entire on-chain record was examined, and the ordering is final. The source behind that read is archival — every canonical block from genesis, at the cost of a modest freshness lag. A reproduction reads a record that has already settled.

Finality: when a record is settled

Reproducibility assumes the records underneath have stopped moving, and TRON defines that point precisely. Per the developer documentation, “a block is confirmed when, after it is produced, 18 different Super RepresentativesOne of the 27 elected block producers on the TRON network, chosen every six hours from a wider candidate pool by TRON Power voting (one vote per staked TRX); candidates ranked 28th–127th, called SR partners, earn voting rewards without producing blocks. SRs collect block and vote rewards and pass a share to their voters after deducting a self-set commission. TRON's protocol code also calls these producers "witnesses" — a term other DPoS chains such as Steem and Hive use for the same role. generate subsequent blocks building on top of it” — 19 acknowledgements in all, including the producer. A confirmed block is solidified, and the network’s solidity endpoints return only transactions that “have been on the chain and solidified.” An analysis built for evidence respects the boundary and requests confirmed transactions only.

The practical point for evidence: cite records that are solidified. A transaction that has not yet been confirmed can, in principle, still be orphaned; a solidified one is the settled history everyone else will read too.

Writing confidence honestly

Confidence language is where reports most often overreach, so set the register deliberately and hedge by design. Even a High reading should say only that strong signals support the attributionThe process of identifying the entity most likely to control a blockchain address by combining on-chain signals — who created and funded it, how it transacts, which keys can act for it — with known service patterns and labels. Attribution conclusions are evidence-weighted judgments, not certainties, and are strongest when several independent signals converge. with high certainty, and the word “proves” should appear nowhere. The most alarming finding a tool can surface should read “the data suggests control changed hands.” A High confidence result means the data strongly supports the identified candidate. It does not mean the case is closed.

The honesty is built into the structure. Honest confidence moves in only one direction: each new caution lowers it, and nothing an analyst turns up later should inflate it back up. Any non-definitive judgment should be understood as a probability with an explicit range of uncertainty, not a single hard number. And you should refuse to be confident outside the conditions your method has actually been tested against — a thin transaction history caps how confident any reading can honestly be, because there is simply too little record to stand on. And “unknown” is a first-class answer. With no permission evidence, a disciplined tool names no controller, because the alternative is a false-confidence guess.

There is legal weight behind this posture. In United States v. Sterlingov (2024), a federal court held blockchain-analytics heuristicsA behavior-based rule used to infer facts a blockchain does not state directly — for example, that addresses spending together, or all draining into one collector, share a controller. Heuristics can be highly reliable when the pattern is strong, but they produce inferences with known failure modes, never proof, so their conclusions should carry confidence levels and survive cross-checking. admissible under the Daubert standard, finding the software “highly reliable—and, if anything, conservative,” while preserving the defense’s right to “challenge the accuracy and reliability” before the jury. A report should adopt the same posture: a calibrated reading that expects to be weighed.

Entity versus individual — the attribution ceiling

On-chain evidence can establish only so much, and an honest tool says so up front: it does not attempt to link blockchain addresses to real-world identities. The limit is structural. As the deposit-address chapter puts it, “from chain data you can say ‘this is a Binance deposit address.’ You cannot say whose” — the mapping from address to customer lives in off-chain books the chain never records.

The Sterlingov court drew the same line inside blockchain analytics itself: stepping from a cluster to a named entity relies on what it called an “intelligence-based heuristic,” which “is not actually a heuristic at all” — it is information from sources outside the blockchain. Chain analysis attributes to an entity; naming the human behind it is off-chain intelligence work, and a report should keep the two separate.

Honest limits, and reading it as an investigator

An accuracy claim comes with conditions: sparse, mixer-touched, or deliberately obfuscated histories will show lower confidence and may not produce actionable attribution. Known blind spots should be disclosed as such. An undetected mixerA service (also called a tumbler) that pools deposits from many users and pays recipients out of the common pool, deliberately breaking the on-chain link between sender and recipient. The severed trail can sometimes be re-joined by matching amounts and timing around the mixer, and U.S. guidance has treated custodial mixing itself as money transmission since 2019. can leave a result unattributable in fact while the analysis shows only a low band with no mixer flag — which makes an unexplained low reading itself a signal. The final attribution call is reserved to the human. A tool reports its confidence level and explains the on-chain signals behind each result; the call belongs to the investigator.

Translate the bands into claims you can defend, in vocabulary you can stand behind. High — the evidence strongly supports the candidate; the finding alone does not close the case. Medium — the most probable candidate given the data, stated with that qualifier attached. A Low band is honest abstention, and an abstention is a finding you can report. Then write the finding the way the analysis computed it. Show your working — list, verbatim, the specific on-chain signals that put each candidate where it is, so a reader can retrace exactly how you reached the finding. Inherit the uncertainty without dressing it up. Keep entity separate from individual, and record what you cannot see alongside what you can. A trace becomes evidence when someone else can stand where you stood and see the same thing.

Sources

• NIST IR 8202 — Blockchain Technology Overview (2018) — blockchains as tamper-evident and tamper-resistant, the basis for treating on-chain records as fixed once solidified.
• ACPO Good Practice Guide for Digital Evidence, v5 (March 2012) — the digital-evidence principles: do not alter the original data, be competent to access it, and keep an audit trail an independent party can repeat. Hosted by the College of Policing library, the official professional body for policing in England and Wales that holds the ACPO legacy guidance. (The 2012 formulation is still the standard reference; ACPO’s functions passed to the NPCC in 2015.)
• TRON Developer Hub — Transactions — block confirmation by 19 Super Representatives and the solidified/confirmed distinction that defines settled history.
• United States v. Sterlingov, No. 21-cr-399 (RDM) (D.D.C., Feb. 29, 2024) — a federal court admitting blockchain-analytics heuristics under Daubert (“highly reliable—and, if anything, conservative”), and its treatment of named-entity attribution as off-chain “intelligence,” not a heuristic. (A Bitcoin case, cited here for its evidentiary posture.)
• Bitquery — Archive dataset documentation — the full-history-from-genesis, trunk-blocks-only property behind reproducible reads, with its documented freshness lag.
• account_contract.proto — tronprotocol/protocol — the protocol definition of AccountPermissionUpdateContract (owner_address, owner, witness, actives) — the message type this chapter names. Protocol-authoritative: a contract type is either declared in core/contract/ or it does not exist.