Blockchain forensics is most useful when it refuses to claim more than the evidence supports. A transaction hash can establish that a ledger recorded a transfer. It cannot, without additional evidence, identify the human being who controlled an address, explain why the transfer occurred or prove criminal intent. The craft lies in moving carefully from transaction to service, from service to account, and from account to person—while preserving every uncertainty in a form a Turkish court or investigator can test.

This English pillar explains how wallet tracing, attribution and digital-evidence reporting work in Turkey-connected matters. It is designed for criminal investigations, fraud recovery, P2P disputes, bank and exchange restrictions, corporate incidents, project conflicts and regulatory reviews. It also answers the substance behind searches such as “blockchain forensic expert Turkey”, “trace crypto wallet Istanbul”, “crypto expert report Turkish court”, “follow USDT across chains”, “prove wallet ownership”, “trace through a mixer” and “is blockchain analysis admissible evidence?”

The methodology has two promises. First, every material on-chain finding should be reproducible from identified data. Second, every conclusion about identity, ownership, knowledge or intent should expose the additional evidence on which it depends. Software accelerates that work; it does not replace it.

For legal advice on this matter, you may contact Av. Ahmet Karaca:

WhatsApp Email

What blockchain forensics can—and cannot—establish

Question	Public ledger may establish	Additional evidence normally required
Did a transfer occur?	Transaction, block, assets, addresses, events and status	Provider records where finality, token validity or internal credit is disputed
Who owns an address?	Usually no legal identity	KYC, device artefacts, signatures, communications, account or seizure records
Did an exchange customer receive funds?	Deposit to an exchange-associated address may be visible	Exchange deposit allocation and internal ledger
Were assets mixed or bridged?	Interaction with contracts or services and observable flows	Correlation method, service data and alternative-explanation testing
Was conduct criminal?	Sequence and movement pattern	Legal elements, source offence, knowledge, communications and control
What can be frozen?	Present location or service touchpoint	Correct legal entity, control mechanism and lawful authority

This boundary prevents two opposite errors. Investigators sometimes underuse the blockchain by treating cryptocurrency as untraceable. Defendants and victims sometimes overuse it by treating a path as identity. A reliable report turns the ledger into evidence without turning inference into fact.

Define the forensic question before collecting data

“Trace the money” is too broad. A defensible mandate asks a bounded question:

Which transfers moved the victim’s identified assets after a specified transaction?
Did a disputed exchange withdrawal correspond to a public transaction?
What part of a mixed pool can be linked analytically, and at what confidence?
Which service endpoints received the traced value?
Does the prosecution’s wallet attribution follow from the available evidence?
Can company treasury movements be reconciled to authorised decisions?
Were customer liabilities supported by controlled on-chain assets at a cut-off?

The mandate determines the collection universe. A loss trace may need several hops until an actionable endpoint. A source-of-funds review may need the entire economic history from bank income to current wallet. A defence review may focus on one incorrect cluster assumption. Unbounded tracing generates impressive diagrams and avoidable privacy, cost and relevance problems.

Preserving the source material

Blockchain data is often described as immutable, but forensic work still requires preservation. Websites change labels, explorers can disappear, chain reorganisations occur, APIs correct data, token metadata changes and provider accounts have retention periods. The investigator should preserve both the underlying ledger references and the off-chain materials used to interpret them.

Create an evidence register

For each item, record a unique identifier, description, source, acquisition date and time, collector, method, original path, working-copy path, hash value, access history and relevant time zone. Keep originals read-only. If data is collected through an API, record endpoint, parameters, response format, pagination and software version. If a node is queried, record chain, client and block reference.

The NIST guidance on digital-evidence preservation emphasises provenance and chain of custody. A cryptographic hash supports integrity after acquisition; it does not prove the truth of the source or the identity of its creator. That distinction should appear in the report.

Preserve off-chain records in native form

Collect exchange CSV exports, statements, order and withdrawal histories, P2P chats, email files with headers, bank statements, device records, API logs, smart-contract source and deployment data, and relevant web pages. Screenshots can capture a transient interface, but they are not a substitute for searchable exports or provider records.

Time normalisation is essential. A Turkish bank record may use local time; an exchange export may use UTC; a chat application may render the viewer’s device zone; a blockchain block timestamp is not always the exact human-action time. Preserve the original and state every conversion.

Start with chain and asset identity

A familiar ticker is not a unique asset. USDT exists on multiple networks; wrapped and bridged assets can share symbols; counterfeit tokens can imitate names and icons. The report should identify the network, native asset or contract address, token decimals and relevant implementation.

Before tracing, verify:

chain identifier and genesis or network context;
transaction hash and successful or failed status;
token contract, decimals and event semantics;
relevant block number and confirmation/finality state;
proxy and implementation contracts where used;
bridged representation and canonical asset relationship; and
whether an explorer is showing decoded convenience data or raw state.

An address copied from the wrong network can look syntactically valid. A token transfer displayed in an event log may not correspond to a change in ownership if the token is malicious or non-standard. High-value conclusions should be checked against primary chain data or more than one independent method.

UTXO analysis: follow outputs, not account balances

Bitcoin and other UTXO-based networks represent spendable outputs. A transaction consumes earlier outputs and creates new ones. There is no bank-style account balance stored at an address; balance is calculated from unspent outputs associated with the analytical scope.

Change and multi-input heuristics

A transaction may pay a recipient and return change to the sender, but identifying change requires inference. Novel address type, output value, wallet behaviour and address reuse can support a hypothesis. Multi-input clustering often assumes that inputs were controlled together because they were signed for the same transaction.

These heuristics can fail. CoinJoin and other collaborative transactions intentionally combine inputs from different users. Exchanges batch customer withdrawals. Wallet software chooses outputs in different ways. PayJoin can make a payee contribute an input. A report should state the heuristic, exceptions tested and confidence; it should not colour all clustered addresses as one person without corroboration.

Taint models are not legal ownership rules

FIFO, LIFO, proportional or haircut models allocate traced value differently when outputs combine sources. No universal blockchain fact selects one model. The choice depends on the analytical purpose and must be disclosed. “Ten per cent exposure” is a calculation under assumptions, not a finding that ten per cent of a person’s assets are criminal property.

Account-based analysis: state, calls and events

Ethereum and similar networks require examination of more than the “from”, “to” and native-value fields. A transaction can call a router that invokes several contracts, transfers tokens through events, creates internal value movements and changes allowances or positions.

A proper review may include:

transaction sender and nonce;
called contract and decoded input;
receipt status and gas usage;
event logs and token contract;
internal call trace;
state changes and balance effects;
proxy implementation at the relevant block;
allowance, permit or delegated-authority changes;
router, pool, vault and bridge interactions; and
same-transaction beneficiaries and fee recipients.

This is critical in wallet-drainer cases. The victim may have signed an approval earlier; the loss transfer is later initiated by the approved spender. Describing the victim as the transaction sender can be technically false and legally misleading.

Internal exchange ledgers: the missing layer

Centralised exchanges generally pool on-chain assets while maintaining customer entitlements internally. A customer deposit becomes a ledger credit. Trades and transfers between users may be recorded entirely off-chain. Withdrawals can be batched from a hot wallet funded by many customers.

Consequently:

a deposit address can identify a service endpoint without identifying its customer publicly;
the exchange’s next on-chain movement is not automatically the customer’s movement;
a customer can receive and send value without a public transaction;
one omnibus wallet may serve thousands of users; and
proof of a customer’s conduct often depends on provider records.

A targeted authority request should identify the specific chain, transaction, address, asset, amount and time, then request the credited account, KYC, login and device data, internal transfers, trades, withdrawals, beneficiaries and linked records within lawful scope. “Provide the owner of this hot wallet” asks the wrong question.

Address attribution: an evidence ladder

Attribution quality varies. Use a ladder rather than a binary label:

Self-authentication. A person publishes an address through a verified channel or signs a message under a controlled protocol.
Provider confirmation. The service confirms that a transaction was credited to a defined account.
Seized or imaged evidence. A device, wallet file, seed, key or authenticated account record links the person and address.
Transactional corroboration. Controlled test transfer, unique amount, timed withdrawal or matching internal record supports the link.
Open-source attribution. Official publications, verified project material or court records identify an address.
Behavioural clustering. Heuristics suggest common control but require caveats and confirmation.
Unverified label. A public explorer or user-generated tag supplies a lead only.

The report should identify the level and source. If a commercial tool says “Exchange X”, record the observation date and seek confirmation. Services migrate wallets; subsidiaries and white-label providers complicate legal-entity identification.

Following value through swaps and liquidity pools

A decentralised swap is not a disappearance. Identify the transaction initiator, router, pool, input and output tokens, minimum-output settings, fees and recipient. Multi-hop routes can be reconstructed from events and call traces. Aggregators may split a trade across pools or bridges.

The investigator should distinguish asset transformation from ownership change. Swapping USDT for ETH in the same controlled wallet changes the asset, not necessarily the controller. Sending the output to a different address adds an attribution question. Liquidity positions create receipt or position tokens whose redemption rights may represent the underlying assets.

Price and value should be calculated separately from flow. Use a stated market source, timestamp and convention; retain token quantities as primary facts. Illiquid or manipulated tokens may have a displayed price that cannot be realised.

Cross-chain bridges

Bridge analysis begins by identifying the mechanism. Lock-and-mint, burn-and-mint, liquidity-network and exchange-mediated bridges leave different records. The originating chain may show a deposit to a contract; the destination chain may show mint, release or liquidity transfer.

Correlate message identifiers, event data, amount after fees, token representation, sender or recipient parameters and timing. If the bridge uses relayers or an off-chain validator set, public data may not alone establish the destination. State which link is directly encoded and which is inferred.

Graph from our case files: bridge and swap hops between Ethereum, TRON, BNB Chain and Solana; a bridge order record establishes a control link — **From our case files: cross-chain bridge hops.** The suspect used bridge and swap services across four chains and opened a fresh wallet after each hop. We matched every hop through bridge and swap records; a bridge order naming the ETH wallet as recipient linked both wallets to the same person. Case data anonymised and amounts changed. Prepared by Av. Ahmet Karaca. Click the image to open it in full size.

Chain hopping through a centralised exchange is different. The user can deposit one asset, trade internally and withdraw another chain or asset. Only the exchange ledger can prove the customer-level continuity.

Mixers, CoinJoin and demixing

Mixing techniques deliberately weaken deterministic input-to-output linkage. A report should first classify the mechanism: custodial mixer, smart-contract pool, fixed-denomination pool, CoinJoin, cross-chain service or privacy-focused protocol. “Mixer” is not a single technical object.

Potential evidence includes:

deposit and withdrawal denominations;
timing windows and pool activity;
unique amount patterns and fees;
address reuse or downstream consolidation;
gas-funding sources;
relayer and withdrawal-recipient behaviour;
service or exchange touchpoints before and after mixing;
device, browser or account records; and
seized infrastructure or provider information.

These facts can rank hypotheses. They rarely justify saying that a particular withdrawal “is” a particular deposit without a method-specific basis. Our longer Turkish analysis, Demixing: Kripto Mikserlerindeki Para Nasıl Takip Edilir?, develops this methodology and its evidentiary limits.

Privacy coins and shielded transactions

Privacy-enhancing networks vary. Some conceal amounts, addresses or the transaction graph by default; others provide optional shielded pools or view keys. The analyst should not claim that ordinary tracing works where the protocol does not expose the relevant linkage.

Investigation can still use boundary evidence: exchange deposits and withdrawals, transparent segments, device artefacts, wallet software, view keys voluntarily or lawfully obtained, timing, amount information available to providers and fiat records. The conclusion may properly be that public-ledger data cannot resolve the question. Methodological restraint is a finding, not a failure.

Stablecoins and issuer controls

Stablecoins combine blockchain transfer records with issuer, reserve and contract governance. Identify the precise contract, issuer, upgradeability, freeze or blacklist functions, mint and burn events, and redemption pathway. Bridged representations may have a different controller from the canonical token.

An issuer’s technical ability to restrict tokens is not a private recovery entitlement. Action depends on applicable law, issuer policy and sufficient legal or authority process. The forensic report should give the correct chain, contract, address, amount and present state so that the legal request is operationally meaningful.

The FATF’s targeted report on stablecoins, unhosted wallets and P2P activity stresses risk-based controls, technical capability and cross-chain understanding. It does not support treating every self-hosted wallet or stablecoin transfer as illicit.

Wallet ownership and control

“Ownership” can mean beneficial entitlement, legal title, possession of credentials, unilateral signing ability or shared governance control. A multisignature wallet may require several signers. An MPC arrangement may distribute key material without ever constructing one complete key. A smart account may permit session keys, guardians or delegated execution.

Evidence of control may include:

a safely designed message signature;
a controlled low-value transaction;
wallet configuration and key-generation records;
device and application artefacts;
exchange withdrawal address books;
multisignature signer and threshold history;
administrator roles and contract events;
communications demonstrating instruction or access; and
provider KYC and session records.

Never request a seed phrase in ordinary correspondence to “prove” ownership. The proof method should not create a new theft risk. Where a device is examined, preservation, legal scope and handling of secrets require a controlled protocol.

Smart-contract and project forensics

A project incident may involve an external exploit, compromised administrator, governance capture, oracle failure, flawed upgrade, insider mint or economic attack. Transaction tracing alone may identify the beneficiary but not the vulnerability or authority path.

A project forensic record may require:

deployed bytecode and verified source;
compiler and build information;
proxy implementation and upgrade history;
administrator, pauser, minter and oracle roles;
multisignature composition and signer changes;
governance proposals, votes, timelocks and execution;
mempool or ordering evidence where relevant;
price and liquidity state at each block;
off-chain repositories, deployment pipelines and access logs; and
incident communications and remediation transactions.

Whether conduct is an “exploit” in technical language does not decide whether it is theft, fraud, breach of contract or an authorised use of code under Turkish law. The legal analysis must examine representations, rights, intent, control and loss.

Fiat-to-crypto reconciliation

Bank and blockchain systems describe different events. A bank transfer to an exchange funds an account; it does not itself identify the later wallet. A P2P payment may buy crypto released internally. A corporate purchase may be split into many execution fills and one withdrawal.

Build a reconciliation table with bank transaction, platform deposit, order, fills, fees, internal transfers, withdrawal request, destination address and on-chain transaction. Record unmatched items and timing tolerances. For source-of-funds work, continue backward to the economic source and forward to the asset’s current form.

This joined schedule is particularly important in Turkish crypto criminal investigations, where an IBAN holder may be visible but the platform buyer and final crypto controller are not.

Risk scores, sanctions exposure and false precision

Blockchain-analytics systems may calculate direct or indirect exposure to categories such as scams, mixers or sanctioned addresses. Scores depend on attribution databases, distance, tracing model, thresholds and risk taxonomy. Two systems can produce different percentages from the same public transactions.

A report should disclose:

tool and relevant version or observation date;
category definition and attribution source where available;
direct versus indirect exposure;
number of hops and flow model;
amount and percentage denominator;
material exclusions and false-positive risks; and
whether independent records corroborate the label.

OFAC’s virtual-currency industry guidance explains sanctions-compliance expectations in the US framework. Its address lists and designations can be relevant to globally operating institutions, but Turkish legal effect and a company’s contractual controls must be analysed separately. A foreign sanctions alert is not automatically a Turkish criminal finding.

From analytical chart to Turkish evidence

The Turkish Criminal Procedure Code governs collection, examination, seizure and evaluation of evidence. The role of a party-appointed technical opinion, court-appointed expert, law-enforcement report and provider record differs. A private forensic report can clarify the questions, identify evidence holders, challenge errors and support applications; it does not acquire compulsory power merely because it is technical.

To be useful in a Turkish file, the report should:

state the exact questions and legal context without deciding guilt;
identify all materials and their provenance;
explain networks, tokens and relevant technical terms in plain language;
describe methods and parameters sufficiently for reproduction;
separate fact, calculation, attribution and inference visually and verbally;
include searchable transaction schedules;
address alternative explanations and exculpatory data;
identify missing provider records and their probative purpose;
preserve confidentiality and avoid exposing private keys; and
state limitations, confidence and observation date.

Translation requires discipline. Keep hashes, addresses and code identifiers unchanged. Translate legal and technical terms consistently. If an English provider record uses “account”, specify whether this means a bank account, exchange user account, blockchain account or accounting entry.

A worked example: P2P payment, exchange release and bridge

Suppose a Turkish bank customer reports a fraudulent transfer to a foreign resident’s account. The recipient says the payment settled a legitimate USDT P2P order. The exchange export shows an order, but the buyer name differs from the bank payer. USDT was released internally, then withdrawn by the buyer to an address that bridged the asset and deposited it at another exchange.

A reliable analysis proceeds as follows:

authenticate the bank payment and exact credit time;
preserve the P2P listing, order, counterparties, chat and release time;
determine whether release occurred internally or on-chain;
request the exchange’s credited buyer, KYC, device and withdrawal records;
verify the withdrawal transaction and token contract;
decode the bridge interaction and identify the destination representation;
trace to the second exchange without following its omnibus wallet as personal property;
seek provider confirmation and linked-account evidence through proper process;
compare the recipient’s knowledge and controls with the organiser’s conduct; and
state which conclusions remain conditional on provider data.

This method serves both sides of justice. It can identify the fraud organiser and recoverable endpoint while preventing an unsupported attribution to the visible bank recipient.

A worked example: compromised DeFi wallet

A company reports that stablecoins left its treasury wallet after a team member connected to a website. Review shows an approval transaction two days earlier and a later transfer initiated by a spender contract. The assets were swapped, split and partly deposited into a centralised service.

The report should not say merely “the hacker transferred the stablecoins”. It should establish the signer of the approval if possible; the scope and amount of delegated authority; spender and implementation contracts; later caller; token events; swap route; fee and beneficiaries; destination service; and any remaining approval or compromised credential. Corporate evidence should show wallet policy, device access, multisignature design and incident response. Legal analysis can then address authorisation, deception, duty and provider requests on a correct technical foundation.

Tools: what matters more than the brand name

Investigations may use full nodes, archive nodes, explorers, indexed datasets, contract debuggers, graph tools, scripts, commercial attribution systems, packet or device forensics and document-analysis software. No single product covers every chain and evidentiary question.

Tool selection should follow six tests:

Does it access the required historical and chain-specific data?
Can key results be exported and reproduced independently?
Does it distinguish observed data from proprietary attribution?
Can versions, parameters and observation dates be recorded?
How does it handle bridges, internal traces, proxies and token events?
What data does the investigator disclose to the vendor?

A screenshot from an expensive platform is not stronger than a transparent method. Conversely, an open-source script is not reliable merely because its code is visible; input completeness, validation and operator judgment still matter.

Quality-control questions before signing a report

Can every material amount be traced to a row and source?
Are chain, token contract, decimals and time zone unambiguous?
Have failed and reverted transactions been distinguished?
Were exchange pooling, internal transfers and batching considered?
Are clustering rules and taint models disclosed?
Does every identity conclusion have evidence beyond a label?
Have alternative and innocent explanations been tested?
Are charts consistent with tables and accessible without colour?
Are private keys, seed phrases and unrelated personal data excluded?
Does the report identify the next record that could confirm or disprove the finding?

Repeated work across complex fraud, exchange, P2P and project files teaches a practical lesson: the most persuasive sentence in a technical report is sometimes “the present data does not establish that conclusion”. It narrows the dispute, shows independence and directs the authority to the evidence that actually matters.

Visualisation without distortion

A transaction diagram is an explanatory aid, not an independent source. Its layout can change perception: a graph that draws two addresses close together may suggest a relationship that exists only on the page; a thick line may represent value, number of transfers or nothing more than a design choice. Every visual convention should therefore be defined.

Use stable node identifiers tied to the transaction table, show direction, separate networks and services, and state whether line width represents asset quantity. Mark exchange or contract nodes differently from attributed individuals. Do not display fiat values without valuation date and method. Complex graphs should be divided into phases—acquisition, loss, layering, bridge and service endpoint—while preserving a master schedule from which the phases can be checked.

Accessibility is part of accuracy. Findings should not depend on colour alone; labels and shapes should remain intelligible in greyscale. A court should be able to move from a diagrammed transfer to the exact transaction hash and source. If a path is inferred across a mixer or exchange, a dashed convention and confidence note should make that limitation visible rather than hide it in a footnote.

International evidence and preservation

Crypto evidence frequently sits with foreign providers. A preservation request is not the same as compelled disclosure and neither is the same as seizure. The correct legal entity, jurisdiction, data category and retention window must be identified.

The Budapest Convention provides a framework for cooperation concerning cybercrime and electronic evidence. The Convention’s 24/7 Network can support expedited preservation among participating authorities, with later formal processes used to obtain evidence. A technically precise request reduces delay: it specifies transaction, chain, address, amount, time, account relationship and requested fields.

For foreign parties in a Turkish proceeding, preserve the original-language record and prepare a controlled translation. Note daylight-saving differences and provider timestamps. Provider affidavits or certifications may help explain record systems, but their use must fit Turkish procedural requirements.

What a client should provide for an initial forensic assessment

Provide a short chronology, known wallet addresses, transaction hashes as text, exchange names and legal entities if known, native exports, bank statements, communications, device and account-compromise facts, prior reports and the procedural question. State whether any authority or provider has been contacted and whether assets are moving.

Do not send seed phrases or private keys. Do not alter the affected device unnecessarily. Do not merge screenshots into a document that discards metadata unless originals are retained. If the assignment concerns a prosecution allegation, include the actual report, order or transaction schedule being challenged; a defence cannot test a conclusion it has not seen.

Blockchain forensics as legal infrastructure

The value of forensic analysis is not a picture of interconnected circles. It is the disciplined conversion of distributed, platform and device records into propositions that can be verified, contested and acted upon. In Turkey, that may mean a focused prosecutorial request, a defence against false wallet attribution, an application concerning a bank restriction, an expert opinion on a project exploit or a reserve reconciliation for a regulated provider.

The method remains the same: preserve first, identify the correct ledger and asset, reconstruct value, distinguish service infrastructure from user control, corroborate attribution, document every assumption and connect the technical finding to the legal question. That is how blockchain data becomes evidence rather than decoration.

Related Pega Hukuk analysis

Official sources

İlgili çalışma alanı: Blockchain ve Kripto Varlık Hukuku — Kripto varlık sahibi bireyler, yatırımcılar, kripto varlık hizmet sağlayıcıları ve blockchain girişimleri.

Related English guides on Turkish P2P law

Use these guides for the transaction-specific questions:

Blockchain Forensics in Turkey: Wallet Tracing and Digital Evidence