Abstract
Cryptoasset disputes often use the word “wallet” as though it described one technical object. In reality, a wallet may be self-custodial software, a hardware wallet, a custodial exchange account, a multisig, MPC arrangement, smart-contract wallet or institutional custody system. Each architecture distributes control, authentication and operational authority differently. This article identifies the evidence needed to reconstruct a transfer, distinguishes credential possession, operational control and legal custody, and explains why a proper analysis integrates on-chain data with authentication logs, key policies and internal platform records.
Keywords: wallet; exchange; custody; MPC; multisig; cryptoassets; digital evidence.
1. First question: what kind of “wallet” is involved?
A wallet does not literally store coins; it manages or enables credentials capable of authorizing state changes involving blockchain assets.
Architectures include self-custody software, hardware wallets, custodial exchange accounts, multisig, MPC, smart-contract wallets and institutional custody with HSMs and approval workflows.
The term alone says little about who could move the asset.
2. Cryptographic control, operational control and legal entitlement are different
It is useful to distinguish:
cryptographic control:
who could produce the authorization accepted by the blockchain?
operational control:
who could initiate, approve, recover or instruct the transaction process?
legal/economic entitlement:
who had rights to the asset under contracts and surrounding facts?
A custodial exchange may cryptographically control a hot wallet holding assets for many customers while each customer controls only an internal account. Directly equating the on-chain address with the customer can therefore be wrong.
3. In exchanges, the critical event may occur before the blockchain
An exchange withdrawal often involves login, MFA, withdrawal request, risk checks, internal approval, ledger update, batching and eventual on-chain signing/broadcast.
The public transaction hash captures only the final public step.
Relevant evidence may include account ID, login history, network data, devices, MFA, password/2FA resets, whitelist changes, withdrawal addresses, risk alerts, manual approvals, internal withdrawal IDs, mapping to the txid, ledger entries, user notifications and support tickets.
4. Seed phrases and private keys: critical but highly sensitive evidence
Possession of a seed phrase or key may establish capability to control derived addresses, but collection must be carefully designed. A seed generally should not be reproduced in a public report.
Control can often be demonstrated through safer verification procedures that document derivation paths, addresses and cryptographic proofs where appropriate.
A seed may also have been copied, so possession does not always establish exclusivity.
5. Hardware wallets do not eliminate compromise hypotheses
Hardware wallets reduce private-key exposure, but transaction security also depends on firmware, supply chain, PIN/passphrase, confirmation interface, host computer, backups and recovery.
A legitimate signature can still be produced over a transaction the user misunderstood or was tricked into approving. “Signed by a hardware wallet” is therefore meaningful, but not a complete answer about informed consent.
6. Multisig: who signed, and which policy was active?
A multisig analysis should identify M-of-N policy, authorized signers, key changes, script/contract, coordination process, devices, institutional approvals and the signatures actually present.
A 2-of-3 transaction shows that two required authorizations were produced; attribution of each key and compliance with organizational policy are separate questions.
7. MPC: do not necessarily look for one complete private key
In some MPC architectures, cryptographic shares remain separated and cooperate to produce a signature without reconstructing one full private key.
Forensic questions therefore shift toward threshold policy, participants/shares, protection mechanisms, recovery/re-sharing events, devices/services involved, signature logs and human approval workflows.
8. Proof of reserves is not complete proof of solvency or customer ownership
International AML/CFT frameworks increasingly require virtual-asset service providers to maintain records that can link customer accounts, custody arrangements, transfers and risk controls. FATF's 2026 implementation update highlights licensing or registration, Travel Rule implementation and effective supervision as important cross-jurisdiction reference points.[1]
Technically, demonstrating control of certain addresses does not by itself prove all liabilities, customer segregation, absence of off-chain debt or complete beneficial ownership.
Custody analysis should relate assets, liabilities, accounting and internal controls.
9. Hot, warm and cold architectures affect the risk model
Hot wallets prioritize availability; cold storage reduces online exposure; intermediate tiers combine controls.
Incident analysis should establish the tier affected, authorized actors, transaction limits, rebalancing policy, alerts, HSM/MPC/multisig controls and segregation of duties.
A loss may originate in the blockchain layer, application layer, operational process or key governance.
10. Smart-contract wallets and account abstraction
Programmable wallets may implement social recovery, guardians, spending limits, session keys and other policies.
The examiner may need to inspect account contract, implementation version, installed modules, guardian set, recovery events, session keys and infrastructure such as bundlers/paymasters where relevant.
In these architectures, code itself is evidence.
11. Digital chain of custody still applies
Blockchain data may be persistent, but internal logs, configurations, database exports, wallet files and physical devices still require forensic preservation.
ISO/IEC 27037 and NIST SP 800-86 provide appropriate principles.[2][3]
Documentation should include source, time, operator, tools and versions, file hashes, export method, redaction of secrets and the link between off-chain record and on-chain txid.
12. Regulation increases the importance of control architecture
Across jurisdictions, regulated VASPs can create valuable off-chain evidence through customer due diligence, transfer records, custody logs and governance controls. These records strengthen attribution when correlated with on-chain data, but they do not eliminate the need to verify the platform's actual technical architecture.[1][4][5]
FATF has also focused on custody, unhosted wallets, stablecoins and DeFi.[6][7]
For disputes, governance documents, key policies, custody ledgers and internal controls are therefore increasingly important sources of evidence.
13. Useful expert questions
Was the architecture custodial, self-custodial, multisig, MPC or smart-contract based?
Who controlled cryptographic authorization?
Who could initiate a withdrawal?
Which authentication factors were required?
Was there credential recovery or reset?
Which internal record maps to the on-chain transaction?
Was batching used across customers?
Which approval policies and limits existed?
Did the transaction follow those policies?
What evidence supports attribution of a key or account to a specific person?
14. Conclusion
In cryptoasset disputes, “who had the wallet?” is rarely sufficient. The technical analysis must map custody architecture, cryptographic control, operational workflow and on-chain/off-chain evidence.
A valid transaction may demonstrate that the blockchain’s cryptographic conditions were satisfied. Responsibility depends on how credentials were governed, who could activate the workflow and which controls failed or were bypassed.
The more sophisticated the custody architecture, the less useful it is to search for one magic artifact. Evidence lies in the correlation among keys, policies, logs, devices, approvals and blockchain records.
14A. Custody records and analytical traceability
Internal ledger events, withdrawal identifiers, and on-chain transactions may belong to the same operational flow, but that relationship should be demonstrated through correlation keys, timestamps, architecture documentation, and extraction procedures. Regulatory reporting can provide additional correlation points, but it does not, by itself, prove title, authorization of a specific transaction, or full solvency.
References
FATF. Seventh Targeted Update on Implementation of the FATF Standards on Virtual Assets/VASPs. 2026. https://www.fatf-gafi.org/en/publications/Fatfrecommendations/targeted-updated-virtualassets-vasps-2026.html
ISO/IEC.
ISO/IEC 27037:2012
. https://www.iso.org/standard/44381.html
NIST.
SP 800-86
. https://doi.org/10.6028/NIST.SP.800-86
FATF. Updated Guidance for a Risk-Based Approach to Virtual Assets and Virtual Asset Service Providers. https://www.fatf-gafi.org/content/dam/fatf-gafi/guidance/Updated-Guidance-VA-VASP.pdf
FATF. Targeted Report on Stablecoins and Unhosted Wallets — Peer-to-Peer Transactions. 2026. https://www.fatf-gafi.org/en/publications/Virtualassets/targeted-report-stablecoins-unhosted-wallets.html
FATF.
Targeted Report on Stablecoins and Unhosted Wallets
. 2026. https://www.fatf-gafi.org/en/publications/Virtualassets/targeted-report-stablecoins-unhosted-wallets.html
FATF.
Targeted Report on Regulatory Challenges from Decentralised Finance
. 2026. https://www.fatf-gafi.org/en/publications/Virtualassets/targeted-report-decentralised-finance-2026.html
NIST.
Blockchain Technology Overview — NISTIR 8202
. https://doi.org/10.6028/NIST.IR.8202
ISO/IEC.
ISO/IEC 27042:2015 — Guidelines for the analysis and interpretation of digital evidence
. https://www.iso.org/standard/44406.html
Editorial note: custody is an architecture and credential-governance problem; the public blockchain records only part of the operational process.