SAYLOR The result you are building
A transfer preflight that resolves the exact chain/network/asset contract or mint, validates the address and destination support including memo/tag requirements, checks wallet/program type, runs a small test, and proves receipt before sending the remainder.
Use this guide when: sending crypto to a wallet, exchange, bridge, contract, or app — especially when validating an address that could syntactically exist on multiple networks.
Do not use it as a substitute for: inferring the network from address appearance alone (especially EVM 0x addresses, which look identical across many chains), or sending based on a copied ticker/symbol without the exact token contract/mint.
Before you change anything, collect: the source chain/network and chain ID/cluster; the asset symbol plus its exact contract/mint, decimals, and token program; the destination address, the platform's deposit-network page, memo/tag, and minimum/maximum; a small-test amount, fees, confirmation requirement, and recovery policy.
Stop before proceeding when sender and receiver network labels/chain IDs don't match exactly, the token contract/mint is unverified, the destination requires a memo/tag you don't have, or platform support can't be confirmed directly from the recipient.
Understand the system before fixing it
- A valid format does not mean a valid destination. An address can pass checksum validation yet belong to the wrong chain, the wrong account type, or an unsupported deposit network entirely.
- Symbols are not identities. USDT, USDC, and other names exist on many different contracts across many chains — only the exact mint/contract and network match.
- The recipient defines what's actually supported. A chain may technically transfer an asset that an exchange or app will never credit or be able to recover.
Evidence-to-decision map
| Evidence | Likely layer | First decisive check | What the result means |
|---|---|---|---|
EVM 0x address | Ambiguous network | Match sender/receiver chain ID and token contract | The same address format exists across many EVM chains — never guess |
| Solana base58 address | Account/program | getAccountInfo and token mint/account owner | Destination may be a wallet, a token account, a program, or nonexistent |
| Exchange shows memo/tag | Credit routing | Read the recipient's deposit instructions | A memo/tag is required for account credit despite a valid address |
| Token symbol matches but contract differs | Asset identity | Check the official contract/mint and decimals | Likely a wrong, wrapped, or fake asset — stop |
| Small test not credited | Support/confirmations/memo | Check tx status and recipient platform support | Do not send the remainder — open official support with the signature |
Step-by-step procedure
01. Read the recipient's deposit instructions. Only the recipient knows what it will actually credit. On the official wallet/exchange/app, select the asset and network and record the exact network name/chain ID, address, memo/tag, minimum, confirmations, contract/mint, and any unsupported-asset warnings. Never use instructions from a DM or a search ad — if they're unavailable, stop and ask the recipient directly.
02. Resolve the source asset identity. A ticker dropdown can silently select the wrong chain or a wrapped token. Verify the source wallet's network, the native asset or token contract/mint, decimals, token program, and balance, comparing against the official issuer/project source and what the recipient actually supports. Chain ID and contract/mint must agree — not just the symbol.
03. Validate destination structure and type. A checksum catches typos, not lack of support. Use a chain-native validator, RPC, or explorer; for Solana, inspect the account owner/type; for contract destinations, understand whether deposits are even supported there. A new/empty account may still be technically valid, but recipient support is what actually decides this.
04. Compare the network end to end. Bridges and exchanges can label networks differently from each other. Build a side-by-side comparison of sender network/chain ID, asset contract/mint, receiver network/chain ID, address, memo/tag, and route, requiring an exact approved mapping. Any mismatch here is a hard stop — don't rely on automatic recovery.
05. Send and verify a small test. A small loss is far cheaper than a full wrong-route loss. Send an amount above the platform's minimum but small enough to risk, review the wallet transaction, record the signature/hash, and wait for both the required confirmations and actual recipient credit. On-chain success without platform credit is not end-to-end success — don't send the remainder until it's credited.
06. Send the remainder with fresh checks. Clipboard malware or instructions can change between transactions. Reopen the official deposit page, compare the address/memo/network against your first send (or do a full verified copy), check fees/limits, and send the remaining amount, then verify receipt and reconcile totals. Save the record without any secret data.
Worked example
Starting problem: a user wants to withdraw USDT from an exchange to a Solflare wallet.
Evidence collected: the exchange offers several USDT networks; Solflare can display Solana token accounts, but selecting ERC-20 would send funds on Ethereum instead; the USDT symbol is identical across networks, though fees differ; recipient support requires the Solana USDT mint/account path specifically.
Decision: the correct choice depends on selecting the Solana/SPL network and the exact supported mint — not the wallet brand or the cheapest fee.
Actions taken: confirmed the exchange's Solana withdrawal support and official USDT mint/network instructions; validated the Solflare public address and memo requirement (none, per the platform); sent an above-minimum small test, waited for credit, then repeated fresh checks for the remainder.
Proof of completion: the test and remainder both confirm on the intended Solana network; the exact asset/mint and amounts appear in the recipient wallet; signatures and fees reconcile.
Why this matters: end-to-end credit proves the route actually worked — address appearance alone never does.
Verify, recover, and hand off
A transfer is complete only when: sender/receiver network and chain ID/cluster match exactly; the exact asset contract/mint/decimals/program match what the recipient supports; address type and any memo/tag requirements are satisfied; a small test confirms both on-chain and at the recipient; the remainder uses fresh official instructions and a re-verified address; and signatures, amounts, and fees reconcile without ever exposing secrets.
If a validator says the address format is valid but the platform still rejects it, follow the recipient platform's own instructions rather than a generic validator's opinion — format valid doesn't mean deposit type/network supported. If a test below the platform minimum doesn't show up, use the documented above-minimum test amount while still keeping the risk small. If a memo was omitted, don't resend — shared-address credit routing likely failed, and official support with the transaction hash may be required. If funds already went to the wrong network, that's usually irreversible and recipient-controlled recovery — preserve the hash, contact the recipient/owner through official channels, and ignore anyone offering unsolicited "recovery" help.
Reusable handoff record: sender and receiver network/chain identity; exact asset contract/mint/decimals/program; destination type, memo/tag, min/confirmations; the small-test hash and recipient credit proof; the remainder hash, totals, fees, and any support/incident record.
For agents
An agent drafting or executing a transfer on a user's behalf should treat this preflight as mandatory, not optional — specifically, it should never construct a transaction based on a ticker symbol alone, and should always insert the small-test-then-remainder pattern as two separate confirmed steps rather than one combined action.
Official references: https://solana.com/docs/rpc/http/getaccountinfo · https://ethereum.org/en/developers/docs/networks/ · https://consumer.ftc.gov/articles/what-know-about-cryptocurrency-and-scams
*This is educational technical and risk-analysis information, not financial, investment, legal, or tax advice. Blockchain transactions can be irreversible and no checklist can guarantee safety or profit.*