Wallet send: review before you sign.

Know the account behind the wallet

A wallet is an interface for interacting with blockchain accounts. The account selected in the app determines which balance and authorization method you are using. Ethereum's account documentation explains the distinction between accounts controlled by private keys and accounts governed by contract logic.

Identify your setup before following transfer instructions. A self-custody wallet, a shared approval arrangement and a custodial exchange can have different authorization and recovery processes. Keep recovery phrases and private keys private. A recipient needs receiving information, and a support investigation needs transaction evidence; neither task requires giving someone the secrets that control your account.

Bind the destination to an asset and network

Obtain the address from the recipient's trusted receiving screen. Save the asset, network and account context with it. Compare the complete address after pasting and again before approval, including middle characters that a shortened display may hide. If the app resolves a human-readable name, inspect the resulting destination.

Address formatting cannot establish ownership or the receiving service's network support. A familiar address may be usable in several contexts, each with different requirements. The wallet address verification guide covers trusted sources, clipboard changes, QR codes and history entries. Stop whenever the original instruction and final preview disagree.

Include the receiving account's routing fields

Some deposits require more than an address. A memo or destination tag can identify the customer whose balance should receive the credit. XRPL's destination-tag documentation describes how tags help services assign payments to beneficiaries in their own systems.

Copy required fields from the current deposit instructions and enter them in the sending app's designated locations. Confirm a QR scan populated them correctly. A personal note or saved address nickname may have a different purpose. Read the exchange deposit and memo guide when the destination is a custodial account, and check minimum amounts before choosing a test payment.

Review the authorization as a complete action

Before signing, check the sending account, token, network, destination, routing fields, amount and fee currency. If you use a separate signing device, compare its display with the intended transaction. Make sure you understand any additional operation or permission included in the request.

A token balance and the balance available for fees can be different. Inspect what your app will charge and what the recipient is expected to receive. If you plan a test and a second payment, account for both transactions. The send altcoins workflow explains how to preserve the intended total while checking a new route.

Design wallet screens around verifiable decisions

For app teams, display the asset and network together throughout the flow. Keep a full-address view available, clearly distinguish required routing fields from personal notes, and show the fee currency beside its amount. Preserve what the user approved in the transaction record.

Keep important differences visible on small screens and reachable by keyboard. A network warning needs text that names the conflicting choices; color alone leaves the action unclear. Allow users to return to review without losing verified recipient details, and prompt them to recheck those details when the asset or network changes.

Use status labels that explain whether the app is awaiting a signature, submitting an instruction or observing a network result. A warning should describe the mismatch and the decision needed. A success screen should identify the completed event and offer the relevant receipt details. Users can then compare the final outcome with their original instruction and recognize where a receiving-side check is still needed.