The wallet address looks right. Are you screening the network you will actually use?
Charles Archibong, Co-founder
Treat a crypto destination as an address plus a network, with the asset identified separately. Screen the intended network and retain the evidence scope before using a result to inform a transfer decision.
Key takeaways
- An address string alone is not a complete transfer destination.
- Retain network, asset and screening scope with the result.
- An unsupported network is an evidence gap, not a low-risk result.
Keep the address, network and asset together from customer input to screening and transfer execution. Before relying on a result, confirm that it assessed the destination context your payment system is actually about to use.
A correctly formatted address does not establish the intended chain, the recipient's control or whether your screening source covers the relevant activity. These are separate questions.
Give the destination a complete identity
Store the chain identifier, address and asset identifier explicitly. Do not use an address string as the only key for a saved destination or screening cache.
Ethereum's account documentation (opens in a new tab) explains account addresses. EIP-155 (opens in a new tab) shows how chain identity enters transaction-signing protection. Neither turns an address format into evidence of the customer's intended network.
For an illustrative EVM-compatible transfer, the same-looking address may be supplied for two different chains. Your review record should make the selected chain unmistakable.
Check what the screening source covered
Confirm supported networks, the type of exposure returned, the observation time and any unavailable information. Preserve the distinction between an exact listed-address match and broader exposure analysis.
A result with no findings is not proof of ownership or legitimate purpose. A provider that cannot assess a requested network has supplied a coverage gap, not a clean assessment. Keep that difference visible to your decision process.
When the customer changes the network, reassess whether the old result still applies. Do not carry a previous approval across contexts without a documented reason.
Tie the decision to the actual transfer
Before execution, compare the reviewed destination with the address, network and asset in the proposed transfer. Any material change should return to the relevant checks.
Keep amount, fees and transfer status in your payment system's own authoritative records. A screening response does not prove that funds moved, and a failed transfer should not automatically create a new screening or payment attempt.
Test context changes before launch
Test a supported destination, an unsupported network, the same address on another chain and an asset change after review. Confirm that the interface names the destination clearly and that the backend does not reuse unrelated evidence.
Use Toden's crypto-operations guide to understand the records and observations available. Confirm current production network coverage and activation with Toden; simulated sandbox outputs establish test behaviour only. Bring your intended network and asset list to a crypto integration discussion.
Sources
Charles Archibong
Co-founder
Charles Archibong co-founded Toden. He writes about identity verification, financial technology, and the practical work of building trusted digital services.
