What is a confidence-gated subpoena target?

As the counterparty crawler traces value flows out from a target blockchain address, each counterparty it reaches is classified either as an attributed custodian - a KYC-holding exchange or service provider whose deposit/withdrawal wallet the counterparty address is - or as attribution-needed, meaning no custodian could be confidently identified. Only attributed-custodian counterparties above a value threshold generate auto-drafted subpoena language.

What does the system do for an unattributed address?

It explicitly declines to recommend legal process against that address and instead surfaces a documented next step - run cluster-attribution through a licensed graph provider, or continue tracing the funds forward until they reach a custodial off-ramp that can itself be subpoenaed.

What goes into an auto-drafted subpoena target?

The named custodian, the specific counterparty address, the exact date range of the transactions between the subject and that counterparty, the transaction count, the value moved, any ERC-20 token flows, and a rationale citing the custodian's role - assembled directly from the trace evidence rather than drafted from scratch by an investigator.

Does the crawler expand every counterparty indefinitely?

No - pooled or terminal nodes such as exchanges, mixers, sanctioned entities, and smart contracts are not expanded further, since traversing past a custodial or contract boundary does not add investigative value and would explode the graph's size.

Confidence-Gated Legal-Subpoena-Target Generator

Executive Summary

JIL Sovereign's counterparty crawler performs a breadth-first traversal outward from a target blockchain address, aggregating every native, internal, and token transfer to and from each counterparty it encounters. As each counterparty is resolved, it is attributed to a known owner where possible and classified into one of two outcomes: an attributed-custodian target, for which the system auto-drafts complete subpoena language embedding the counterparty address, custodian name, transaction count, exact date range, and value moved; or an attribution-needed target, for which the system explicitly declines to recommend legal process and instead documents what further investigative step is required before one would be appropriate.

This mirrors, and automates, the two-phase structure of blockchain-based asset recovery: mapping the entire flow of funds from public data requires no legal process at all, while piercing a specific custodian for an account holder's identity is the one step that does. The generator is designed to make that boundary explicit and machine-enforced rather than left to an investigator's judgment call on each address.

Core Innovation: The system's default behavior on an unattributed counterparty is an explicit refusal to recommend legal process, with a documented alternative investigative path - not a lower-confidence subpoena draft. The gate fails closed toward caution rather than over-generating legal-process language against every address the crawl touches.

Problem Statement

Asset-recovery and fraud-litigation teams tracing stolen or misappropriated funds on-chain face two distinct kinds of work: building the transaction-flow map itself, which is purely a matter of pulling and aggregating public blockchain data, and drafting legally sufficient subpoena or discovery language to compel a specific custodian to identify the human behind a wallet, which requires legal judgment and jurisdiction-appropriate phrasing. Manually drafting that language for every custodial counterparty a large trace touches is slow and repetitive, but automating it carries the opposite risk: a generator that drafts subpoena language indiscriminately for any address, including ones that are not actually attributable to a custodian, produces legally hollow or misdirected requests and can waste scarce legal-process capacity on unattributed addresses.

Why Naive Automation Falls Short

Manual drafting only: accurate but does not scale across a trace that may touch dozens of counterparties.
Indiscriminate auto-drafting: would generate subpoena language against unattributed EOAs with no custodian to actually serve, wasting legal-process effort and creating overbroad requests.
No documented fallback for unattributed addresses: without an explicit alternative path (cluster attribution, forward-tracing), an investigator has no clear next step once an address resists identification.

Technical Architecture

BFS Counterparty Trace

Starting from a target address, the crawler aggregates all native-value, internal, and ERC-20 counterparties within a configured block or date window, expanding breadth-first up to a configured hop depth and address budget. At each hop, a counterparty is expanded further only if it is not already a pooled or terminal node - custodians, sanctioned entities, and smart contracts are not traversed past, since expanding a custodial or contract boundary adds no further investigative value.

Confidence-Gated Target Classification

Classification	Trigger Condition	System Output
Attributed-custodian	Counterparty resolves to a known custodian and moved value exceeds the configured minimum	Auto-drafted subpoena language embedding custodian name, address, exact date range, transaction count, value moved (plus token flows), and a rationale
Attribution-needed	Direct (hop-1) counterparty is an unattributed EOA or unknown-category address, not a contract, not sanctioned, and moved value exceeds the minimum	Explicit refusal to recommend legal process, plus a documented next step: run licensed cluster-attribution, or trace forward to the first custodial off-ramp

Where a counterparty appears at multiple hops, the strongest edge - lowest hop, then highest value - is used for classification, since the most direct, highest-value relationship is the most defensible basis for legal process. Attributed-custodian targets are ranked ahead of attribution-needed targets in the output, and within each group by value moved.

Prior Art Differentiation

Approach	Auto-Drafts Legal Language?	Distinguishes Attributed vs. Unattributed?	Documented Fallback for Unattributed?
Manual investigator drafting	No - fully manual	Ad hoc, per investigator	Ad hoc
Generic blockchain-explorer tooling	No	No - just shows raw flows	No
JIL subpoena-target generator	Yes - only for confidently attributed custodians	Yes - hard classification boundary	Yes - explicit recommended next step

Patent Claim

Independent Claim 122: A computer-implemented method for generating legal-process recommendations from blockchain transaction data comprising: performing a breadth-first traversal of counterparties transacting with a target blockchain address, aggregating value moved, transaction count, and date range for each counterparty; classifying each counterparty above a configured value threshold into one of two states based on an attribution lookup, wherein a counterparty resolved to a known custodial entity is classified as attributed and a counterparty not so resolved is classified as attribution-needed; automatically generating, for each attributed counterparty, structured subpoena language that embeds the custodian's identity, the counterparty address, the transaction date range, the transaction count, and the value moved; and, for each attribution-needed counterparty, generating an output that withholds any legal-process recommendation and instead specifies an alternative investigative action required before legal process could be directed at that counterparty.