Hybrid Records: Exchange Withdrawals into Self-Custody

Custodial and non-custodial records answer different questions, and a withdrawal is the precise event at which the question changes mid-sentence. The venue is closing an internal entry; the chain is opening a public one. A file that records only one side describes only half of what happened, and the half it omits is usually the half the counterparty cares about.

DC-Services treats the hybrid case as a reconstruction problem rather than a presentation problem. Each side is preserved with its own metadata — venue reference, withdrawal status, internal timestamp on one side; transaction hash, block height, confirmation count on the other — and the link between them is documented explicitly, not implied by adjacency on the page.

Platform-side records include the withdrawal log entry, the venue's withdrawal confirmation email, the user's account statement for the period, and any KYC-bound information that ties the originating account to a verified identity. Each carries its own evidential weight, and the file does not flatten the differences for convenience.

Chain-side records include the broadcast transaction hash, the block timestamp, the destination address, the credited amount net of network fees, and the confirmation count at the time of review. The chain is candid about what happened technically and silent about why; the file records that silence as part of the record rather than filling it in.

Every element receives a classification: verified where the source evidence supports it, record-backed where a venue or chain entry exists but corroborating material is partial, supporting where the item is contextual, unresolved where a link is missing. The classification appears beside each element rather than buried in a summary line.

The discipline matters because a hybrid transfer is only as strong as its weakest link. A perfectly clean platform-side record paired with a chain entry whose destination address does not match the venue's stated destination is not a verified transfer; it is two records that happen to be filed next to each other, which is a different and weaker claim.

Verification works where the venue's withdrawal reference, the broadcast hash, the destination address, the amount net of fees, and the block timestamp align within the network's confirmation window. Where all five align, the transfer is documented as a record-backed finding end to end and the file says so explicitly.

Where four out of five align and the fifth drifts — a timestamp outside the confirmation window, an amount short of the expected delta after fees, an address that received the credit but cannot be tied to the venue's stated destination — the entry is held as partially verified, with the specific element that failed identified by name.

Some hybrid transfers do not close cleanly even with the best available records. A venue may have purged its older withdrawal logs; a chain may have re-organised the relevant block; a destination address may have received many similar transactions in the period, making attribution probabilistic rather than definitive.

Each unresolved matter is named on its own row: missing venue reference, missing hash, address reuse on destination, timestamp drift beyond confirmation window, failed broadcast, re-broadcast on a new contract after a venue change. The reader sees what would need to arrive to close each gap, rather than a blanket admission that something is unclear.

A hybrid transfer documented end to end supports control of the destination address from the moment of credit forward, subject to corroborating evidence on the destination side. It does not, on its own, establish legal ownership of the asset before the withdrawal, or after it; it supports the transfer event itself, which is the question hybrid reconstruction is built to answer.

The deliverable separates the transfer-continuity finding from the ownership and control questions that depend on it. Counterparties who need ownership confirmation are told what additional materials would actually support it, instead of being invited to read more into the transfer record than the records themselves contain.

Reconstruction begins with indexing: every record receives a source, a date, a side (platform or chain), and a candidate counterpart on the other side. Cross-checks then run pair by pair, with matches recorded as record-backed and mismatches preserved with the specific point of divergence noted in plain words.

The output is structured for the reader the file is for. A counterparty reviewer sees the transfer summary, the underlying records, the classification of each, and the unresolved matters list, in that order, on adjacent pages. Nothing in the file requires the reviewer to trust a confident sentence; everything is traceable to a record.

Where the hybrid transfer is record-backed end to end, the framework identifies follow-on steps that depend on it: registration of the destination wallet, refreshed control evidence, security records for the receiving device, transfer corroboration for any onward movement. The framework describes moves the client may make rather than recommending that they make them.

Where the transfer is partially verified or unresolved, the framework identifies the specific records that would upgrade the position: a re-issued venue confirmation, a refreshed control signature on the destination, a corroborating receipt from a downstream counterparty. The action is structured around closing named gaps, not around generic next steps.