The short answer
A visible transfer proves that a recorded event occurred. It does not, by itself, prove who controlled every address.
What a public record can establish
Ethereum's explorer documentation describes transaction hashes, sending and receiving addresses, value, fees and execution details. Token transfers may appear in event logs rather than as a simple native-currency value transfer.
Check the correct chain and the exact token. A transaction hash from one network is not a universal receipt, and a token's display name is not its issuer identity.
What requires additional evidence
| Statement | Evidence boundary |
|---|---|
| This address received a token transfer. | Can be checked in the relevant public ledger. |
| This named person controls the address. | Requires additional attribution evidence. |
| These two transfers belong to one customer. | An inference requiring a method and uncertainty assessment. |
| This transfer will be accepted by an exchange. | Depends on that exchange's policies and decisions. |
An intermediary does not erase earlier records
Changing an asset or a network creates a different sequence of events; it does not retroactively remove the original public record. An operator's own record-retention policy is a separate subject.
Avoid both absolute claims: “everything can always be identified” and “nothing can be traced”. The useful conclusion is narrower: identify the observed data, identify the inference, and state what is not known.
Traceability follows the actual chain and token
Use the explorer for the network that recorded the event and identify the exact asset contract or mint. An Ethereum hash cannot prove the state of a TRON, Solana, TON or Algorand transfer, and a ticker cannot replace the identifier.
A new address, a bridge hop or an intermediary creates another record. It may change what is immediately visible, but it does not prove that an observer cannot connect the events or that an operator has no offchain records.
Find the right USDT record on Etherscan or TRONSCAN
For Ethereum USDT, use the Etherscan token link in Tether's supported-protocols document. For TRON USDT, use its TRONSCAN token link. Start from the issuer document linked below rather than a sponsored result or a token with a familiar logo.
A token page identifies a contract and its activity; a transaction record identifies a particular transfer. To inspect a payment, use its transaction hash on the explorer for the stated network, then check the token, sending address, receiving address and amount. A hash from another network does not answer the same question.
- Match the network and contract first. A ticker or a balance beside an unrelated contract is not the same asset.
- For a particular payment, distinguish the recorded token transfer from a native-token value or network-fee field. Do not read a zero native-asset value as proof that no tokens moved.
- Record the observed transaction state and the recipient's required confirmation rule separately. An on-chain record is not a receipt for a credited exchange balance.
- An address page shows the history associated with that address on the inspected network. It does not identify the person controlling it or reveal an intermediary's internal records.
| Network | Explorer named by Tether | USDT token contract |
|---|---|---|
| Ethereum | Etherscan | 0xdAC17F958D2ee523a2206206994597C13D831ec7 |
| TRON | TRONSCAN | TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t |
Address reuse and wallet separation: what changes?
Reusing an address brings its activity into the same public address history. A fresh address starts a different history, but it does not remove earlier transactions. If the old address funds the new one on the same public chain, that transfer is itself a visible relationship.
Separating wallets for bookkeeping can make your own records clearer. It does not establish that an observer cannot associate the wallets, that a service has deleted its records or that the issuer's controls no longer apply. Distinguish organizational separation from a demonstrated privacy property.
| Situation | What can be observed | What cannot be concluded from that alone |
|---|---|---|
| The same address receives two transfers | Both transfers occur in that address's history. | The real-world identity or lawful source of either transfer. |
| A new address has no earlier activity | No earlier activity is visible in the inspected chain history. | That nobody knows who controls it. |
| One address funds another | The on-chain transfer connects the two addresses. | Whether they have the same controller or why the transfer happened. |
| A wallet label says business or personal | The label can organize the user's own records. | That other observers see the label or accept it as ownership evidence. |
What to keep when a recipient asks about a USDT transfer
A transaction hash shows an on-chain event; it does not by itself explain the economic source of the funds or prove who owns the addresses. Ask the recipient which documents it accepts, then assemble a factual timeline from records you already hold. Do not fabricate a source-of-funds explanation.
Keep the chain record separate from purchase, sale, payment or withdrawal records. Send sensitive documents only through the recipient's authenticated channel. StableMatrix does not collect these records or certify that a packet will satisfy a platform or legal requirement.
| Record | What it helps explain | Limit |
|---|---|---|
| Network and contract or mint | Which asset the transfer concerns. | A ticker alone does not identify the token. |
| Transaction hash, amount and time | Where to find the recorded transfer. | It does not establish the reason for payment. |
| Relevant receipt, invoice or account statement | The transaction or withdrawal recorded offchain. | It must be authentic and relate to the transfer in question. |
| A dated sequence of your own actions | How the available records fit together. | Unknown steps must remain unknown, not filled in by inference. |
| The recipient's stated request | Which missing fact it wants to verify. | Acceptance is the recipient's decision; this checklist is not a legal clearance. |
Amount correlation is a hypothesis, not a receipt
Suppose an observer sees a hypothetical 1,000 USDT input and a later 997 USDT output. A possible 3 USDT deduction is one explanation, but the numbers alone do not prove that the two transfers belong together. Other activity, a different fee rule or incomplete observations can fit the same amounts.
Keep observed facts separate from inferred relationships: record the chain, asset, amount and time first, then state the proposed link and what corroborating evidence is missing. Do not turn a matching amount into an identity finding, or a non-matching amount into proof that no link exists.
Source notes
Each reference has its own last-check date. That is not its publication date. Follow the live document for current terms and identifiers.
- Ethereum.orgBlock explorersPublic transaction, block and address data, rather than proof of a person's identity. Document date not recorded. Checked: 2026-09-20.
- CircleUSDC contract addressesIssuer-listed mainnet identifiers. A token listing is not a service endorsement. Document date not recorded. Checked: 2026-09-21.
- TetherSupported protocols and integration guidelinesExact issuer-listed asset/network combinations, including discontinued protocols. Document date not recorded. Checked: 2026-09-21.
- Solana documentationTokens on SolanaMint accounts and token accounts; why an EVM token-address model does not transfer unchanged. Document date not recorded. Checked: 2026-09-20.
- TON documentationJetton processing guidelinesJetton master contracts, wallet contracts and transfer processing; a token master is not a user's deposit wallet. Document date not recorded. Checked: 2026-09-21.
- Algorand documentationAlgorand assetsASA identifiers, opt-in and account requirements. Asset identity does not establish a third-party service route. Document date not recorded. Checked: 2026-09-21.
- TetherToken terms and risk disclosuresIssuer rights, redemption conditions, restrictions, and third-party wrapped-token risks. Document date: 2026-02-26. Checked: 2026-09-20.
- CircleUSDC TermsRedemption conditions, blocked addresses, third-party platform boundaries and transfer risks. Document date not recorded. Checked: 2026-09-20.