Custodial vs Non-Custodial Records for Asset Reconstruction

Custody type changes what a record is allowed to say. A custodial statement reflects what a venue chose to write in its own database. A non-custodial entry reflects what a key actually signed on a public ledger. They are not the same evidence in different formatting. If the file merges them silently, the conclusion ends up overstated in one place and understated in another, and the reader is rarely shown the seam where the swap occurred.

A custodial record can support that a platform recorded a balance, a trade, a withdrawal request or an account event. A non-custodial record can support that an address signed or received a transaction at a given block. Neither, on its own, answers every question. The review states what each record proves, what it merely suggests, and what stays open until further materials arrive — the last column is the one most often skipped, and the one counterparties tend to read first.

Custodial records come from platforms that hold or administer positions on a user's behalf. They include account statements, CSV exports, withdrawal logs, deposit confirmations, KYC files, support tickets and venue correspondence. Their evidential weight depends on the completeness of the export, the venue's record-keeping standard, and the timezone and fee conventions baked into the format — none of which are guaranteed to match across two venues, or even two sub-accounts on the same one.

The central limitation is unglamorous: a custodial statement usually shows what the venue recorded internally, not what occurred on a public chain. A balance inside an exchange account is not a wallet transaction signed by a private key, and treating it as one will confuse ownership review, transfer mapping and any later dispute file. Each entry is classified as record-backed, supporting context, or unresolved before any narrative is drawn over it.

Non-custodial records describe activity bound to wallet addresses on a public ledger: transaction hashes, block confirmations, token contract interactions, gas fees, bridge events and signed messages. The chain is candid about what happened technically. It is silent about who held the keys, why the action was taken, or whether the address belongs to the person the file is about.

A transaction hash shows amount, time, destination and contract — useful, but not a confession of ownership. Authorship and human control require separate corroboration: signed challenges, device records, recovery artefacts, exchange withdrawal references that bridge into the address, or contemporaneous correspondence from the relevant period. The file records the on-chain event as verified and records the control question as open, in plain words rather than implication.

Many files contain hybrid movement: a withdrawal from a venue to self-custody, transfers between personal wallets, a bridge across networks, then a deposit into another platform. The evidence form changes at every transition, and that is where reconstructions usually break. An internal withdrawal note and an on-chain confirmation can describe the same event using different identifiers, different units, and clocks that disagree about which calendar day it was.

Reconstruction works by stitching the references together: platform withdrawal IDs, the broadcast transaction hash, the destination address, block confirmations and the receiving record on the other side. Where every link holds, the transfer is documented as a record-backed finding. Where a hash is missing, a timestamp drifts, or the destination address never appears in the chain history, the gap is flagged — not papered over, not quietly rounded down.

Reconstruction begins with indexing. Every record receives a source, a date, a record type, an asset reference and an evidential function. Platform statements are kept apart from wallet activity; screenshots are kept apart from source exports; client explanations are kept apart from record-backed findings. The discipline is unromantic and a little tedious — we would rather catalogue the boring details now than discover them missing during a counterparty review later.

Cross-checks then run across the indexed materials. Exchange withdrawals are matched to transaction hashes; wallet activity is reconciled against ledger entries; correspondence is treated as context rather than evidence. Inconsistencies are not forced into a conclusion that would make them disappear. They are listed as unresolved matters, with the specific record element that triggered the flag, so the reader sees exactly where the file is firm and where it is provisional.

A structured file can support specific findings: that an exchange recorded a balance on a date, that a withdrawal was initiated, that an address received funds at a block, that a signed message established control of a key at a moment in time. Each finding is linked back to the underlying record, so a reviewer can verify it without taking the conclusion on trust or asking us to repeat the working.

The same file usually leaves matters unresolved. It may not confirm legal ownership; it may not identify the human controller behind a key; it may not reconcile contradictory timestamps across venues. These limits are stated openly. The deliverable is a source-linked report — verified findings, record-backed findings, unresolved matters, and a documented action strategy framework for registration, control, ownership, disputes, security, transfer, mobility and rights.