A payment can pass the signing process and reach the wrong recipient because the destination was copied from a contaminated transaction history. Address poisoning targets that selection step. For an institution, the practical defence is a controlled beneficiary record that cannot be silently replaced by an address appearing in a wallet feed.
The attack does not need to change the institution's private key. It needs an operator or connected system to accept the wrong destination as a familiar one. That distinction changes the control design. More signatures will not necessarily help if every approver reviews the same shortened address and the same unverified label.
History is evidence of activity, not a beneficiary register
MetaMask's address poisoning guidance describes attackers introducing small transactions involving addresses resembling those previously used, hoping the user copies the wrong address later. The institutional implication is to deny transaction history the authority to create or update a payment destination.
An incoming transfer should enter the reconciliation process as an observed event. It should not automatically establish a business relationship, approved recipient or account-owner identity. The sender can cause data to appear on a public ledger without the institution asking for it. Importing that data into a treasury address book gives an external party influence over an internal control.
Apply the same rule to browser history, recent-recipient menus and spreadsheet extracts built from explorer data. These may help an investigation, but they should not become the source of truth for the next transfer. If a workflow offers a recently used address, compare it with the approved record before allowing submission.
Compare the entire destination
A shortened display showing the beginning and end of an address can conceal differences in the middle. Approval interfaces should make the complete destination available and support comparison with an independently obtained approved value. A reviewer should not be asked to recognise forty hexadecimal characters from memory.
ERC-55 specifies a mixed-case checksum encoding for Ethereum addresses. A checksum can help detect certain typing errors. It does not identify the beneficiary: an attacker can supply a validly checksummed address of their own. Treat syntax validation and beneficiary verification as different tests.
The network is part of the approved destination record. A familiar address string does not establish that the recipient supports the proposed asset on the proposed chain. The asset identifier, address and network should travel together through the payment instruction and signing review. A correct address on the wrong network remains a distinct operating problem.
This is one reason to connect the beneficiary process to token reference data. Address accuracy does not repair an ambiguous token contract, and a correct asset identifier does not establish who controls the destination.
Beneficiary onboarding needs an independent source
The destination should come through an agreed channel that can be tied to the intended counterparty. Record how the organisation obtained it, who verified it and when it became effective. A message attached to an unsolicited transfer is not a substitute for that onboarding evidence.
For a counterparty changing its wallet, use an established contact path to confirm the change. A reply to the message requesting the update may return to the same compromised channel. The institution should define what counts as independent confirmation for its counterparties, using a method that its operations staff can execute under time pressure.
Approval of a new beneficiary should be separate from approval of the payment. Combining both in a single urgent transfer ticket creates an opportunity for a changed destination to inherit the credibility of a legitimate invoice or settlement obligation. The second reviewer needs to see that the beneficiary is new or amended.
A practical record can contain the counterparty identifier, complete destination, network, supported asset or deposit route, verification source, approvers and change history. Keep the source evidence accessible to the person reviewing a later exception. A green status without retrievable evidence encourages trust in a label whose basis has been forgotten.
Make the signing review compare two independent values
Ethereum's transaction documentation distinguishes the transaction recipient from input data used in contract interactions. When transferring a token, the outer destination may be the token contract, while the economic recipient is encoded in the call. Reviewers should verify the relevant beneficiary rather than assuming the transaction's outer address is the payment destination.
The approval system should decode the proposed operation and compare its economic destination with the authorised instruction. That comparison should use the controlled beneficiary record, not another rendering of the same unverified clipboard value. A second screen showing the same wrong data is an additional view, not an independent control.
For batch payments, provide an exception report listing new or changed destinations and mismatches. An approver may not be able to inspect hundreds of addresses meaningfully. Automated exact comparison can narrow the human review to relevant changes, provided the approved input list itself has been authenticated.
The wider wallet transaction policy should specify who resolves a mismatch. Operators should not rename the destination in the approved registry to make the payment pass. A failed comparison is a reason to investigate the instruction and its source.
Small test payments have a defined, limited role
A test payment can demonstrate that a particular transfer path works. It does not independently establish identity if the destination was already substituted. An attacker-controlled address can receive a small payment just as readily as an intended address.
When a test is useful, send it using the approved destination and ask the counterparty to confirm receipt through the established verification channel. Record what the test established: network support, correct deposit handling or successful receipt. Do not treat a transaction confirmation alone as confirmation of the beneficiary.
Some counterparties require deposit instructions, account references or other conditions beyond a raw address. The beneficiary process should include those requirements. A test that succeeds for one asset or network does not establish universal support for every subsequent instruction.
Handle unsolicited activity without promoting it
The reconciliation team should be able to identify unsolicited transfers and separate them from authorised business activity. That does not mean deleting them from the chain record. Preserve the evidence, classify the exception and keep it out of auto-complete destinations and routine payment templates.
Filters should consider the actual token contract and event source, not just a displayed symbol. A symbol is an unverified label unless the institution has mapped it to an approved instrument. An unexpected record that looks like a known asset should be checked against the authoritative contract identity before it enters a ledger workflow.
The institution should also decide how suspicious history appears to operators. Hiding it entirely may remove useful incident evidence; displaying it beside approved recipients without distinction may increase confusion. The useful design keeps the raw activity available for investigation while giving payment preparation a separate, controlled source of destination data.
Track beneficiary changes as a source of operational risk in their own right. Useful measures include payments prepared from history, mismatches between the instruction and registry, unverified emergency updates and overrides of destination checks. These measures identify where the process still invites unauthenticated values into the payment workflow. Counting only attempted poisoned transfers misses whether the institution's own preparation steps remain vulnerable.
Review any override with its original source evidence, not just the operator's explanation after execution.
Respond according to what actually happened
An unsolicited lookalike transaction is not, by itself, evidence that the institution's key has been compromised. If nobody used its address, the response can focus on quarantine, source review and the beneficiary controls. If a payment was sent to it, preserve the instruction, approval trail, signed transaction and chain evidence immediately.
The incident team should determine whether the wrong value came through history, an amended file, a compromised communication channel or another interface. Calling every wrong-destination event address poisoning can obscure a different failure. The corrective action should address the actual point where unauthenticated data became authoritative.
A drill can place a lookalike address in the test history, alter a batch destination and include a legitimate new beneficiary. The team should reject the unapproved values while routing the legitimate change through onboarding. That tests the control's ability to distinguish evidence and authority, rather than rewarding a blanket refusal to process new destinations.
The result to aim for is simple: a stranger can place activity in a public wallet history, but that activity cannot rewrite the institution's beneficiary record. Exact address comparison, independent source verification and separate change approval make that boundary concrete.