Discovery for wallets, exchanges, and devices: beyond the CSV

A party may produce a CSV labeled "transaction history" that lacks a timezone, field definitions, reconcilable identifiers, or documented fiat-conversion rates. Such an export may be inadequate for reconstruction. This article is about drafting discovery so that does not happen: requests to parties, exchanges, and devices that deliver native data, schemas, identifiers, timestamps, and authentication history. The working assumption is federal practice; state rules vary, so check the forum's counterpart.

Why a Transaction CSV Is Not Enough

A recurring discovery failure is accepting a summary export as the production. A CSV from an exchange's reporting tab may be a curated customer view rather than a record set built for reconstruction: it may omit internal transfers or failed orders, convert amounts to fiat at undocumented rates, truncate identifiers, or log times in a local timezone.

Rule 34(b)(1)(C) permits the request to specify the form or forms in which ESI will be produced (Federal Rules of Civil Procedure, amended through December 1, 2025). If no form is specified, Rule 34(b)(2)(E) requires production in a form in which the information is ordinarily maintained or in a reasonably usable form. A party need not produce the same ESI in more than one form. If the request omits a form, or the responding party objects to the requested form, Rule 34(b)(2)(D) requires the responding party to state the form or forms it intends to use. Specify the form up front so the issue is addressed in the response, not after the expert receives an unusable production.

Start with the Disputed Propositions, Then Map Each to a Record Source

Draft backward from what the case must prove, then name the record source for each proposition:

• "X held the account" maps to registration records, KYC verification steps with dates, linked payment methods, and assigned deposit addresses.
• "X controlled the withdrawal destination" maps to withdrawal records with destination addresses, address book and whitelist entries with add dates, and withdrawal approvals.
• "The transfers were authorized by X" maps to authentication history: logins, sessions, device identifiers, two-factor changes, API key usage.
• "The amounts and values on the relevant dates" maps to order and trade records with native timestamps; "X knew about or directed the activity" maps to support tickets, chat logs, and the party's own communications.

That source list should come from an expert who knows which fields an export must contain and which records exist only internally; that expertise defines the categories a discovery and evidence review engagement can verify before the RFP goes out, cheaper than a motion to compel after an unusable production.

What to Request: Native Data, Schemas, and Field Definitions

Name actual record categories rather than asking for "all documents relating to cryptocurrency." For each category, specify:

• Structured export format (CSV or JSON with full precision) with a schema or data dictionary defining every field, not PDFs or screenshots.
• Field definitions for identifiers: account identifier, wallet address, transaction hash, order identifier, internal transfer identifier.
• All timestamps in UTC with the source timezone documented, plus block height where relevant.
• Amounts in the asset's base units or with the exchange's recorded rate, and chain and network identifiers so exports from different sources can be joined.

This is not a demand for the exchange's internal database; it is a demand for exports plus the documentation that makes them legible. Where a party operates its own Ethereum node, name the block, transaction, and receipt objects and fields needed rather than accepting any flat export.

Form specifications that survive objections

Three habits keep these requests defensible. Tie each form specification to usability: the specified form is needed to reconcile the production against blockchain data and other productions, and Rule 34(b)(1)(C) lets the request name that form. Ask for one form per category, since a party need not produce the same ESI in more than one form. Anticipate an objection that a source is not reasonably accessible because of undue burden or cost under Rule 26(b)(2)(B): scope requests to the disputed period and be ready to show good cause if the source is an encrypted legacy backup.

Beyond Transactions: Account, Authentication, and Device Records

Transaction exports capture value movement, not the account-level facts that tie movement to a person.

Account lifecycle records

Request registration data, KYC steps with dates and outcomes, linked payment methods, every deposit address assigned, and address book and whitelist entries with add dates, often correlating with the disputed transfers. Also request hold, freeze, and flag records with the reasons recorded; a compliance flag is itself a relevant fact about the account.

Authentication and access history

Login events with IP addresses and device fingerprints, session records, password and two-factor changes, recovery code issuance, and new-device notifications. This separates "the account was used" from "the party used the account," and the fingerprints later reconcile against the device production.

API keys and automated activity

Request API key creation, scopes, last-use timestamps, and, if retained, the hosts from which keys were used. These records can help test a claim that a bot initiated transfers the party denies authorizing.

Support and communications records

Support tickets, chat logs, and emails, including KYC appeals and fraud reports, often contain the party's own admissions about the account and activity.

The mechanics of enforcing these categories against nonparties are covered in how to subpoena cryptocurrency exchange records; the point here is that party discovery and nonparty subpoenas should be one system. Serve the party first for identifiers and device records, then feed those identifiers into the exchange subpoena so the exchange searches by email, phone, and wallet address. If the party cooperates, consider a signed authorization to the exchange as an additional avenue for requesting account records.

Device and App Records: The Self-Custody Evidence Layer

For self-custody wallets there is no institution holding records; the evidence lives on devices and in the party's files. Device production is a Rule 34 request too: phones, computers, and hardware wallets are tangible things within the scope of Rule 34(a)(1), and the ESI on them is within the same rule.

Wallet software and browser extensions

Request installed wallet applications, app data directories, local databases, configuration files, and logs, plus browser extension storage. App data may persist after uninstall, though a qualified examiner must determine whether any artifact is recoverable. Seed material in notes apps, password managers, photos, and cloud documents belongs in the same category, requested explicitly.

Hardware wallets

The device itself can be produced for examination, and its companion application may leave address and transaction artifacts on the host computer. The most productive target is often that computer: request connection artifacts, app install history, and records of which addresses the party managed through the device.

Backups, seed material, and signed messages

Request cloud backups of wallet data, password manager exports, encrypted containers, and any written or photographed seed phrase material. Where control of an address is disputed, request a signed message from it: a valid signature demonstrates that the signer controlled the relevant private key at the time of signing without disclosing the key. A refusal may become a factual issue, but it is not proof by itself.

Collection integrity is the expert's prerequisite. The four-phase forensic process in NIST SP 800-86 (published by NIST in August 2006) runs collection, examination, analysis, and reporting, with data integrity preserved through collection and examination. Devices should be imaged under a defensible protocol with hashing and documented chain of custody, and the request should permit that methodology rather than demanding raw devices with no safeguards. See understanding wallet ownership evidence for the evidence types that establish control, and self-custody vs. custodial wallets for how custody changes what records exist.

Interrogatories and Rule 30(b)(6) Depositions: Explain the System

Interrogatories describe; native ESI proves. Use interrogatories (Rule 33) to ask the party to identify every exchange account, wallet address, device, application, and key-storage location, and to state whether any data was deleted or migrated during the relevant period. The answers become the roadmap for the RFP. They do not substitute for production: responsive records still must come out in usable form under Rule 34, and describing records is not producing them.

Rule 30(b)(6) depositions fill the explanatory gap for organizational parties. The notice must describe the matters for examination with reasonable particularity, and the named organization must designate one or more people to testify about information known or reasonably available to it. Useful topics for an exchange include schema, export methodology, retention periods, KYC process, key custody, and API logging. For an individual party, use an ordinary Rule 30(b)(1) deposition to cover which devices and applications were used, how keys were stored, and what happened to the account during the dispute window. Depose after production so the deponent can be walked through the actual exports. For nonparties, the same explanation can be compelled with a deposition subpoena under Rule 45, which also permits designating the form of production.

Model Request Categories and Proportionality Limits

A defensible RFP structure for a digital asset matter:

1. Native exports with schemas and field definitions for account, trade, order, deposit, withdrawal, and transfer records, in the specified form.
2. Account, authentication, API key, and support records as specified in the sections above.
3. Device records: wallet applications, app data, extension storage, backups, seed and key material in any form, and device production for imaging where self-custody control is disputed.
4. Explanatory records: written procedures, export documentation, and any tool used to generate the production.

Handle proportionality in the drafting. Rule 26(b)(1) limits discovery to nonprivileged matter that is relevant to any party's claim or defense and proportional to the needs of the case. Scope time periods to the dispute, limit imaging to the custodians that matter, and stagger requests so account records come first and device production follows only if the dispute turns on self-custody control. The proposed discovery plan under Rule 26(f) must state the parties' views and proposals on ESI issues, including the form or forms in which ESI should be produced, and the scheduling order may include ESI preservation terms under Rule 16(b). Issue a litigation hold early: Rule 37(e) applies when ESI that should have been preserved in the anticipation or conduct of litigation is lost because a party failed to take reasonable steps to preserve it, and it cannot be restored or replaced through additional discovery, so the preservation letter should name these categories rather than "all records."

Practitioner checklist

1. Build the proposition-to-source map with the expert before any RFP.
2. Serve a preservation notice covering the categories above.
3. Serve RFPs with explicit form specifications, schema demands, and date ranges.
4. Serve interrogatories requiring identification of accounts, addresses, devices, applications, and deletions.
5. Designate Rule 30(b)(6) topics against an organizational party and any custodial exchange.
6. Coordinate nonparty subpoenas using produced identifiers, with party authorizations.
7. Have the expert reconcile exchange exports against the blockchain and both against device evidence.
8. If productions arrive without schemas or in unusable form, move to compel on the form specification.

Reconciling Productions: A Worked Hypothetical

Hypothetical example: In a business divorce, the company's exchange account shows a withdrawal of 40 ETH to a wallet address, and the other side claims the address belongs to an unrelated third party repaying a loan. The native export shows the withdrawal with a transaction hash, a UTC timestamp, and an address book entry the account holder added for that destination 11 days earlier. The exchange's Rule 30(b)(6) deponent confirms address book entries are added only through authenticated sessions. Blockchain data confirms the hash and the recipient's later activity. Device production from the company laptop shows a browser extension vault and a photo of a seed phrase, and the expert verifies the derived addresses match the recipient. Each layer checks against the others: exchange records tie the company to the withdrawal, the address book ties the destination to the holder's action, and the device evidence ties it to the party personally.

Now the same case with a badly drafted production: a PDF statement with local times, dollar-converted amounts, and no hashes. The expert cannot match the withdrawal to the blockchain, the address connects to no one, and the gap becomes a factual fight. That outcome was decided when the RFP was drafted.

Limitations: what discovery cannot fix

Requests cannot manufacture records that never existed. Foreign and non-KYC platforms may sit beyond domestic process, decentralized protocols leave no record-holder to subpoena, retention windows may already have closed for login logs, and an encrypted device can block examination until the court addresses it. Shared keys and multisig arrangements complicate attribution even with perfect records. Where these limits bind, the case narrows to what the blockchain shows and what disclosure obligations require, which is one more reason to run blockchain tracing in parallel with discovery rather than waiting for productions.

Frequently Asked Questions

Q: Can I compel production of a phone, computer, or hardware wallet for forensic examination in civil discovery?

A: Devices are tangible things within the scope of Rule 34(a)(1), and the ESI on them is discoverable like any other electronically stored information, subject to relevance and proportionality under Rule 26(b)(1). Courts manage privacy and burden through protective orders, search protocols, special masters, or limits on custodians and timeframes. Because devices get replaced or wiped, request device production early and pair it with a preservation notice.

Q: What if the exchange produces a CSV with no field definitions or timezone information?

A: If you specified a structured form, it may be the wrong form. Rule 34(b)(1)(C) lets the request name the form, for example a structured CSV or JSON rather than a PDF statement. If you requested schemas, documented timezones, and full identifiers as their own categories, assess any response or objection to those categories against the rules and the case-specific order. Have the expert document which fields are missing and why they cannot be joined to the blockchain or to other productions; that turns a format dispute into a concrete showing.

Q: Are interrogatory answers enough to establish who controlled a wallet?

A: No. Answers are useful evidence and can be used to impeach if contradicted, but they describe facts; they do not substitute for responsive records that must be produced in native, usable form under Rule 34. That form lets the expert verify addresses, hashes, and timestamps against the blockchain. Treat interrogatories as the map and the production as the territory. For how control is proven once records exist, see the difference between a blockchain analyst and an expert witness.

Q: When should I bring a forensic expert into the discovery process?

A: At the drafting stage, not after the first production. The expert determines which fields an exchange export must contain, which records exist only internally, and what form the data needs to reconcile against the chain and device evidence. Early engagement converts vague requests into specific ones, shortens the meet-and-confer, and strengthens a motion to compel if the production still comes back unusable. For custody disputes over self-custody assets, an early expert witness consultation also shapes the Rule 30(b)(6) topics before depositions are noticed.

Rules differ by court and by state: Missouri's general provision governing discovery, for example, is in Rule 56.01, and federal districts impose their own ESI protocols. The right request set depends on the disputes and the exchanges and devices involved. If you are drafting discovery in a matter that touches wallets, exchanges, or devices, I am available to discuss the request categories and the ConsensusIntel methodology for this kind of reconstruction. Contact me with the facts of your matter.