Vetting a counterparty with our tools, click by click

A rule I repeat in every consultation: the cheapest freeze is the one that never happened. Checking a counterparty before the trade takes thirty seconds. Cleaning up the aftermath takes weeks and costs money. This lesson is a hands-on walkthrough of that check on our own tools: what to open, what to click, and what each result actually means. The behavioral signs you watch in chat are a separate catalogue in the red flags lesson. Here we work with the address.

Step 1: the checker

Open the USDT checker, paste the counterparty address into the input field and press the check button. The tool accepts TRON, Ethereum and Solana addresses and recognizes the network automatically. Within a couple of seconds you get a verdict block with four independent answers.

• Tether blacklist. This is a binary fact read directly from the smart contract through the isBlackListed function, not from someone's database. If the address is blacklisted, the funds on it are frozen by the issuer, and no trade with it makes any sense. Our checker also shows the freeze date where we have it, because we collect these events straight from the contracts into our own corpus, which now holds more than 2,312 freeze events, roughly 61 percent on TRON and 39 percent on Ethereum.
• Sanctions. For 0x addresses the engine queries an on-chain sanctions oracle across six EVM networks in parallel; for TRON and Solana it checks the OFAC list. A match means legal risk, not inconvenience. The answer is simple: do not enter the trade.
• Scam databases. A lookup against external threat-intelligence bases of known scam and phishing addresses.
• Community reports. Complaints filed by other users through our bot and site. We label them honestly as unverified crowd signal, not as a verdict.

One number to calibrate your expectations: of the addresses users actually brought to the checker, 57 percent turned out to be blacklisted, 74 out of 128 at the time of counting. People check exactly the addresses that already worry them. Your job is to check before you have a reason to worry.

Step 2: the address passport

Below the verdict, the checker loads the address passport: public facts about the address gathered without any private databases. Read it top to bottom.

• Age. How long the address has existed. Under thirty days raises the fresh_address flag. A fresh address is not guilt, but for a counterparty offering large volume it is a question that needs an answer.
• USDT balance and the transfer window. Recent inflows and outflows, total sums, the number of unique senders, last activity.
• Flags. fresh_address, high_fan_in when many different senders converge on the address, and transit_like when almost everything that comes in leaves immediately. Each is a stated fact, not a score. A fresh address with high fan-in and a transit profile is the classic picture of a drop or a collection wallet, and I would not sell to it whatever the chat says.
• The zone chip. A compact red, amber or green rating we cover in detail in the zones lesson of the AML track.

Step 3: the tracer, when you need to see where money goes

The checker answers "what is this address". The tracer answers "where do funds from this address flow". Paste the same address there and it builds the outbound picture: top destinations by volume, up to two hops deep, with exchange attribution where a public label exists, and a peel-chain trace when the funds move through a chain of fresh intermediate wallets. Two situations where I reach for it before a trade: the counterparty is about to send me a large inbound transfer and I want to see whether his address behaves like a transit node feeding a known service, and the reverse case, when someone I already suspect has my money and I want to know whether it reached an exchange where a complaint can still matter.

Step 4: fix the result

Whatever you saw, capture it. Take a screenshot of the verdict and the passport with the date visible, and file it with the trade record. The checker also has a certificate button that issues a one-page dated verification document you can forward to a counterparty or keep for yourself. A dated check is what later turns "I was careful" from a claim into a document. How to store it, and the rest of the trade routine, is the workflow lesson.

The decision table

How to read green honestly

This is where we differ from cheap checkers that paint you a "cleanliness percentage". A green result means exactly one thing: no risk markers were found by our sources at the moment of the check. It is not a guarantee that the address is clean. Fresh scams have not yet reached the databases, and part of dirty flows carry no public labels. Green lowers the risk. It does not relieve you of caution, and treating it as an indulgence is the mark of an amateur.

Mistakes I see repeatedly

• Checking after the problem. The check costs nothing before the trade and explains nothing after it.
• Checking the username instead of the address. Reputation on the platform and the state of the wallet are different things. Fraudsters buy aged accounts precisely because people trust the profile.
• Checking a repeat counterparty once. Addresses change hands and change behavior. For a regular counterparty, recheck when the address changes or the amounts jump.

Check yourself

• Task. Open the Freeze Radar, pick any address from the recently frozen table, and run it through the checker.
• How to know you got it right. The checker shows a blacklist hit, and where the corpus has it, the freeze date matches the radar entry. You have just verified an issuer-level fact from the contract yourself.
• Task. Run your own working address through the checker and read the passport: age, flags, zone. Write one sentence on how a cautious counterparty would read you.
• How to know you got it right. You can name each flag on your address and say what fact it states, without the words "good" or "bad". If your address carries high fan-in from years of P2P, you now understand what question that raises and how you would answer it.