An invoice says USDT, but the customer and treasury team are discussing different networks. Before reading a risk score, resolve that mismatch. A useful check needs a network and a subject, not only an asset name. For TRON and Ethereum, the business questions are similar, while the identifiers and request handling differ. This guide stays within the behaviour documented in A2 Route's public pages and current code.
What is the same
A2 Route's public FAQ supports address screening and USDT/USDC transaction screening on TRON and Ethereum. The API documentation names the networks tron-mainnet and ethereum-mainnet. It describes address checks and transaction checks, with transaction requests carrying a transaction reference and direction. Use the selected network consistently in the case file and screening request.
On either network, establish which customer, invoice and payment the result concerns. Before a payment exists, a proposed address check cannot examine that future transfer. After receipt, compare the actual sender, recipient, asset and amount with the trade record. The incoming USDT guide gives a receiving workflow that keeps those stages separate.
For a staff exercise, use FAKE_TRON_WALLET_NOT_AN_ADDRESS, FAKE_ETHEREUM_WALLET_NOT_AN_ADDRESS and FAKE_TRANSFER_NOT_A_HASH. These deliberately invalid synthetic labels are not examples of accepted address or hash formats. Do not submit them. Their purpose is to make the selected network explicit without publishing real identifiers.
What differs in identifier handling
The current address normalisation code validates TRON addresses and keeps their spelling unchanged. It validates Ethereum addresses with its EVM address validator and stores their lowercase form for the request subject. That is application handling, not a reason for staff to edit a customer's receiving instructions by hand. Preserve the original communication and verify the intended network.
Transaction references have separate rules. The current TRON normaliser accepts 64 hexadecimal characters and lowercases them. The Ethereum normaliser accepts 64 hexadecimal characters with an optional lowercase 0x prefix, then produces a lowercase reference with that prefix. The selected network determines which normalisation applies; a hash string alone is not a substitute for choosing the network.
Do not repair malformed references by guessing missing characters, changing their network or copying a similar entry from an old invoice. Ask for the correct reference through the agreed channel. A structurally accepted identifier still needs to belong to the payment you intend to review. Format validation and commercial relevance answer different questions.
Keep the report's scope separate from the asset name
The public report description includes verdict and score, source shares, top exposure, sanctions lists and a risk-categories appendix. Those are the published report contents, not a claim that every network has identical evidence or coverage. Read the actual result's sources, time and limitations before comparing two checks.
The committed synthetic PDF examples are TRON transaction reports. The ALLOW example is incoming; the REVIEW example is outgoing and concerns the destination. They illustrate the current sample layout. Do not present those fixtures as Ethereum sample evidence or assume that their amounts, scores and policy bands apply to every USDT check. The PDF walkthrough explains the sample-specific context.
Shares also need their stated denominator. In the outgoing REVIEW sample, address-mode shares concern the destination wallet's traced incoming funds, not the account holder's outgoing amount. Do not compare that percentage with another network's transaction result as if both measured the same thing. Write down the subject and mode before making any calculation.
Read risk and coverage the same careful way
The risk-score guide explains why the number is not a probability of guilt. The exposure guide separates direct transfers, intermediary paths and list results. Those reading habits matter whichever supported network appears in the case file. A change in network does not turn a category label into verified customer identity.
A2 Route's public FAQ describes a partial result as reduced coverage and recommends a re-check. Record that limitation for the result you received rather than declaring one network automatically safer or more complete. The repository sources used here do not support such a ranking, fee comparison or settlement-speed promise.
Keep separate records for separate subjects
If a customer supplies payment references on both networks, retain each with its own network, invoice context, result and reviewer note. Do not claim that two supported checks prove a continuous cross-network route or ownership of both wallets. The sample limitations say beneficial ownership, off-chain identity and purpose of payment are not verified.
For routine desk handling, use the OTC trade-ticket guide. For a separate supplier payment, consult the A2vanta business payment blog. Explore A2 Route screening or read the business API documentation. Reports are informational, not legal advice, guarantees of clean funds or promises of regulatory compliance.