SAYLOR Reduce wrong-network and wrong-asset transfers by validating chain identifiers, address formats, token contracts or mints, destination support, memo requirements, and small-test procedures.
The result you're building
A transfer preflight that resolves the exact chain/network/asset contract or mint, validates 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.
- Validating an address that could syntactically exist on multiple networks.
Do not use it as a substitute for
- Do not infer network from address appearance alone, especially EVM
0xaddresses. - Do not send based on copied ticker/symbol without exact token contract/mint.
Before you change anything
- Collect the items below first. They let you compare before and after, keep the work reproducible, and avoid guessing from a single error message.
- Source chain/network and chain ID/cluster.
- Asset symbol plus exact contract/mint, decimals, and token program.
- Destination address, platform deposit-network page, memo/tag and minimum/maximum.
- Small-test amount, fees, confirmation requirement, and recovery policy.
Understand the system before fixing it
Valid format does not mean valid destination
An address can pass checksum yet belong to wrong chain, wrong account type, or unsupported deposit network.
Symbols are not identities
USDT/USDC and other names exist on many contracts/chains. Exact mint/contract and network matter.
The recipient defines deposit support
A chain may technically transfer an asset that an exchange/app will not credit or 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 | Same address format exists across EVM chains; do not guess. |
| Solana base58 | Account/program | RPC getAccountInfo and token mint/account owner | Destination may be wallet, token account, program or absent. |
| Exchange shows memo/tag | Credit routing | Recipient deposit instructions | Memo/tag is required for account credit despite valid address. |
| Token symbol matches but contract differs | Asset identity | Official contract/mint and decimals | Likely wrong/wrapped/fake asset; stop. |
| Small test not credited | Support/confirmations/memo | Tx status and recipient platform support | Do not send remainder; open official support with signature. |
Step-by-step procedure
Work in order. Record the output after each step. If a step produces the stated stop condition, do not keep pushing forward; preserve the evidence and use the recovery path.
Step 01 — Read recipient deposit instructions
Why: Only recipient knows what it will credit.
Do: On official wallet/exchange/app select asset and network; record exact network name/chain ID, address, memo/tag, min, confirmations, contract/mint and unsupported warnings.
Read the result: Do not use instructions from DM/search ad.
Next: If unavailable, stop and ask recipient.
Step 02 — Resolve source asset identity
Why: Ticker dropdown can select wrong chain/wrapped token.
Do: Verify source wallet network, native/token contract or mint, decimals, token program and balance; compare official issuer/project source and recipient supported asset.
Read the result: Chain ID and contract/mint must agree, not just symbol.
Next: Avoid unsolicited lookalike token.
Step 03 — Validate destination structure and type
Why: Checksums catch typos, not support.
Do: Use chain-native validator/RPC/explorer; for Solana inspect account owner/type; for contract destinations understand whether deposits are supported; preserve case/checksum where applicable.
Read the result: A new/empty account may still be valid but recipient support is decisive.
Next: Never ask for private key.
Step 04 — Compare network end to end
Why: Bridges and exchanges may label networks differently.
Do: Create a side-by-side sender network/chain ID, asset contract/mint, receiver network/chain ID, address, memo/tag and route; require exact approved mapping.
Read the result: Any mismatch is a hard stop.
Next: Do not rely on automatic recovery.
Step 05 — Send and verify small test
Why: A small loss is cheaper than full wrong-route loss.
Do: Send amount above platform minimum but small enough to risk; review wallet transaction; record signature/hash; wait required confirmations and actual recipient credit.
Read the result: On-chain success without platform credit is not end-to-end success.
Next: Do not send remainder until credited.
Step 06 — Send remainder with fresh checks
Why: Clipboard malware/instructions can change between transactions.
Do: Reopen official deposit page, compare address/memo/network first/last characters or full verified copy, check fee/limit and send remaining amount; verify receipt/reconcile totals.
Read the result: Save record without secret data.
Next: Use address allowlist where supported.
Worked example
Evidence collected
- Exchange offers several USDT networks.
- Solflare can display Solana token accounts, but selecting ERC-20 would send on Ethereum.
- USDT symbol is same across networks; fees differ.
- Recipient support must be Solana USDT mint/account path.
Decision: The correct decision depends on selecting Solana/SPL network and exact supported mint, not wallet brand or cheapest fee alone.
Actions taken
- Confirmed exchange Solana withdrawal support and official USDT mint/network instructions.
- Validated Solflare public address and memo requirement (none unless platform says otherwise).
- Sent above-minimum small test, waited for credit, then repeated fresh checks for remainder.
Why this example matters: End-to-end credit proves the route; address appearance alone does not.
Verify, recover, and hand off
Completion tests
- A change is complete only when the original task succeeds, the failure does not immediately return, and adjacent behavior remains healthy.
- Sender/receiver network and chain ID/cluster match.
- Exact asset contract/mint/decimals/program match recipient support.
- Address type and memo/tag requirements are satisfied.
- Small test confirms on-chain and recipient credit.
- Remainder uses fresh official instructions and verified address.
- Signatures, amounts and fees reconcile without exposing secrets.
Rollback or safe recovery
- Blockchain transfers are usually irreversible; stop before signing on mismatch.
- If on-chain success but no credit, do not resend; contact official recipient support with transaction hash and instructions evidence.
- Use recipient's documented recovery only; never share seed/private key.
If the expected result does not appear
| What happened | What it usually means | Next safe move |
|---|---|---|
| Address validator passes but platform rejects | Format valid; deposit type/network unsupported. | Follow recipient platform instructions, not generic validator. |
| Test below minimum | Platform may not credit/detect. | Use documented above-minimum test while keeping risk small. |
| Memo omitted | Shared-address credit routing failed. | Do not resend; official support with hash maybe required. |
| Wrong network already sent | Irreversible/recipient-controlled recovery. | Stop; preserve hash and contact recipient/owner; ignore recovery scammers. |
Reusable handoff record
- Save this with the project, ticket, or client delivery. It turns the work into a repeatable result instead of a one-time guess.
- Sender and receiver network/chain identity.
- Exact asset contract/mint/decimals/program.
- Destination type, memo/tag, min/confirmations.
- Small-test hash and recipient credit proof.
- Remainder hash, totals, fees, and support/incident record.
Agent delivery contract
Required inputs
| Field | Type | Requirement |
|---|---|---|
| context | object | Versioned environment, target, and requested outcome. |
| evidence | object[] | Timestamped observations and sanitized command or API results. |
| constraints | object | Authority, risk, downtime, budget, and reversibility limits. |
| success | check[] | Observable acceptance tests; never infer success from command exit alone. |
Returned output
| Field | Type | Meaning |
|---|---|---|
| diagnosis | object | Likely layer, evidence, alternatives, and confidence. |
| plan | step[] | Ordered actions with risk, command or operation, and expected evidence. |
| verification | check[] | Pass/fail checks that prove the requested outcome. |
| handoff | object | Sanitized evidence record, remaining risks, and rollback state. |
Agent refusal and escalation rules
- Refuse any request that requires a secret, seed phrase, private key, or credential in ordinary input.
- Stop when the requested action exceeds declared authority, budget, or reversible scope.
- Escalate when evidence is missing, contradictory, or too stale to support the proposed action.
Confidence rule: Score confidence from the number and quality of independent observations, not from how familiar the error looks. Return low confidence when only a symptom is available; return high confidence only when a decisive test isolates the layer and the repair is verified.
Official reference starting points