A familiar history entry is not a verified recipient
Copying an address from recent activity can turn a routine stablecoin payment into a misdirected transfer. MetaMask describes address poisoning as the use of a similar-looking address and tiny or zero-value transactions to encourage a later copying mistake; the appearance of the entry alone does not mean assets have been stolen.[1] A merchant should therefore distinguish a destination seen before from one authenticated for this payment. Familiar ends, an incoming transfer and an absence of warnings are not recipient verification. This guide covers instructions issued to customers and checks before subsequent treasury payments, rather than confirmation counts or refund rules. Its operational workflow is an editorial recommendation, not a report of tests performed on real wallets.
Read the transaction, not just its label
CertiK documents fake USDT records, zero-value entries that appear to be outgoing from a targeted address, and poisoning attempts involving small USDC transfers.[2] An outgoing label, familiar ticker or nonzero amount therefore does not establish that your team previously authorized the apparent payment. Compare transaction details and the actual token contract with internal payment records instead of treating an explorer list as a contact directory. CertiK also describes a May 3, 2024 incident in which copying the wrong address led to the loss of 1155 WBTC.[2] That was not a stablecoin loss, but it illustrates the consequences of the same copying error. It does not establish the probability that a particular merchant will suffer an attack.
Establish a trusted reference and compare the entire value
MetaMask advises against copying destinations from transaction history and emphasizes checking the middle characters, not merely the beginning and end.[1] Our recommendation is to obtain current instructions through an authenticated merchant order page or an established business channel. Independently confirm an unexpected address change through contact details already on file, not a new number supplied in the change request. Compare the complete pasted destination against that reference, expanding any shortened display. A QR code is an input method, not evidence of identity: inspect the decoded value too. Two employees comparing against the same suspicious history entry are not performing independent verification. Record which authenticated instruction served as the reference so a reviewer can understand the decision.
Separate destination, network and asset checks
Full-address comparison asks whether the destination matches the authenticated instruction. Network and asset checks ask whether the transfer uses what the recipient accepts. We recommend separate fields for the recipient, order identifier, complete address, network, asset and relevant token contract identifier. Do not let a USDT or USDC ticker substitute for that record. CertiK’s fake-USDT example demonstrates why a familiar name alone does not establish token identity.[2] A correct address comparison does not replace the network check, and choosing the right network does not rule out a lookalike destination. If any field differs from the approved instruction, stop and resolve the discrepancy rather than choosing the closest-looking option. This is a pre-send verification boundary, not a settlement-finality policy.
Maintain verified contacts rather than a history cache
MetaMask recommends saving verified, frequently used addresses in its address book and using a hardware wallet to add a destination check on the device.[1] We recommend recording the verification channel, owner, effective date and applicable network for each business contact. Importing a history entry and immediately labelling it trusted simply preserves the original uncertainty. Reapprove changes and document whether older instructions remain valid, so staff do not reuse an obsolete ticket. Before submission, compare the actual signing destination with the trusted reference. A hardware wallet adds a checkpoint only if someone reads its display; it does not authenticate the business instruction that supplied the address. Apply the same change controls to contacts used for repeat payments as to newly submitted destinations.
A small transfer supports a check; it cannot replace identity
Where appropriate, consider a small verification payment only after authenticating the full address, network and asset. Have the real recipient confirm the corresponding receipt through an established channel. Explorer success alone is not that confirmation. Do not subsequently copy the destination again from the newest history entry: MetaMask’s warning about copying from history still applies.[1] Our proposed process binds the small transfer and the main payment to the same approved instructions, with fresh checks after any change. A successful small payment does not guarantee that a later transaction uses the same destination. This article did not initiate any transfers, and this optional procedural step should not be presented as an automatic protection supplied by a payment product.
Stop, preserve evidence and state what remains unresolved
Before sending, pause and preserve the order, authenticated instruction, pasted destination and suspicious transaction hash with restricted access. Rebuild the payment details through the trusted channel. An unsolicited poisoning entry alone does not establish private-key compromise; MetaMask explicitly distinguishes the entry itself from the later copying mistake.[1] After a mistaken payment, promptly contact official wallet or custody support and report as appropriate. Never give recovery phrases to unsolicited recovery agents or pay supposed unlocking fees. CertiK reports that the WBTC incident’s funds were later returned, but that outcome is not a recovery promise for another case.[2] Close the incident with documented checks, affected payments and unresolved questions, not a claim that deleting or hiding an entry fixed the problem.
Sources and dates
Verified on 2026-09-20. Source dates distinguish explicitly stated publication and update dates; an unspecified date does not mean the source was published today. This is public-document research, not a live payment test, security audit or accessibility certification. Vendor facts apply to the cited vendor; proposed workflows are editorial synthesis.
More new articles
A payment API key leaked: how do you rotate every consumer? →
Payment troubleshooting logs: redact sensitive data without losing investigation clues →
Payment review and errors that keyboard and screen-reader users can check →
Integer or decimal payment amounts? Precision and rounding boundaries →
Payment lookups returning 429 or 503: backoff, retry budgets and recovery →
All field guides →