The failure is a broken trust model. Transaction history becomes an attacker-controlled display layer when poisoned addresses can be inserted through dusting or UI abuse. Users then treat convenience data as proof of legitimacy, which creates a transfer path to the wrong destination. The fix is to move recipient verification to a separate, trusted source rather than the wallet history itself.
Why Wallet History Fails as a Trust Signal
Wallet transaction history is a convenience view, not an authority source. If a wallet allows poisoned entries, address substitution, or misleading labelling, the history can stop reflecting a trustworthy recipient record and instead show whatever an attacker managed to introduce. The practical failure is not just visual confusion, it is misplaced trust in a display that can be manipulated.
That matters because users often treat a familiar history entry as confirmation of legitimacy. Once that assumption breaks, the wallet is no longer helping the user verify where funds are going, it is helping the attacker normalise a bad destination.
Recipient verification has to be based on an independent source of truth, such as a trusted address book, out-of-band confirmation, or a separately authenticated recipient record. A wallet history can support recall, but it should not be the mechanism that proves who should receive the transfer.
How Poisoned History Turns Convenience Into an Attack Path
Dusting, UI abuse, and address poisoning work because they exploit the gap between what is shown and what is true. The attacker does not need to break the wallet cryptography if they can alter the user’s interpretation of the recipient list, history, or recent contacts.
For the user, the danger is false familiarity. A plausible-looking prior transaction or a near-match address can bias the next payment decision, especially when the recipient is selected from memory or recent activity instead of re-entered and independently checked.
The same pattern can affect high-volume or routine transfers, where speed becomes the enemy of verification. The more users rely on the history pane as a shortcut, the more attractive it becomes as a target for manipulation.
What a Reliable Recipient Check Should Look Like
A reliable recipient check compares the destination against a trusted reference outside the wallet’s mutable display layer. That can mean verifying the full address from a separate channel, confirming a signed payment request, or using an approved recipient registry that the wallet history cannot rewrite.
NIST SP 800-207 Zero Trust Architecture reinforces the underlying rule: do not trust a convenience view just because it is local or familiar; verify the transaction target from an independent control point.
NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because the failure is really about access decision quality, auditability, and control over the information users rely on before authorising a transfer.
NIST SP 800-63 Digital Identity Guidelines is relevant where recipient verification depends on a separately authenticated identity proof, rather than on whatever the wallet interface most recently displayed.
Risk and Threat Considerations
The risk is recipient substitution, which can turn a legitimate payment flow into an irreversible transfer to an attacker-controlled destination. When users rely on wallet history as the verification source, the attacker only needs to contaminate the display layer once to influence later decisions.
Failure mechanism: The wallet history becomes an untrusted evidence source because poisoned entries, lookalike addresses, or manipulated labels create false confidence in the recipient.
Impact: Funds can be sent to the wrong address, and the error is often hard to reverse because the user authorised the transfer on the basis of misleading convenience data.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Recipient verification depends on trustworthy identity and verification material. |
| AC-6 — Least Privilege | Limits the impact of a poisoned recipient reference or mistaken transfer. | |
| AU-6 — Audit Review, Analysis, and Reporting | Helps detect manipulated recipient records and suspicious transfer patterns. | |
| Recommendation — Manage recipient verification material separately from mutable wallet history. Restrict payment approval paths to the minimum necessary authority. Review transaction records for address poisoning and anomalous recipient changes. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | The issue is a trust failure in how the recipient is verified before action. |
| DE.CM-01 — Networks and Systems Are Monitored | Monitoring can reveal poisoned entries or unusual wallet interaction patterns. | |
| Recommendation — Use independent recipient verification before approving any transfer. Monitor for anomalous recipient changes and suspicious transaction workflows. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Wallet actions need correct authorization so a manipulated display cannot drive the wrong function. |
| Recommendation — Enforce authorization on payment actions independently of the UI state. | ||
| MITRE ATT&CK | T1110 — Brute Force | Supports the broader pattern of attacking trust and access paths through repeated manipulation attempts. |
| Recommendation — Hunt for repeated attempts to manipulate recipient-selection workflows. | ||
Practitioner Guidance
What to verify: Treat the wallet history as a memory aid, not as proof of legitimacy. The verification step should compare the recipient against a separate trusted record or a second channel that the wallet interface itself cannot influence.
Decision rule: If the user is about to rely on a remembered or recently seen address, force a fresh check of the full destination string or a cryptographically or operationally trusted recipient reference before approving the transfer.
What practitioners underestimate: The problem is often framed as user carelessness, but the real issue is control design. If the interface can be poisoned, then convenience features must be treated as potentially adversarial until proven otherwise.
Practitioner takeaway: The safest rule is simple: verify recipients from a trusted source outside the wallet history, because any display that can be manipulated should never be the final authority for a transfer.
Related resources from NHI Mgmt Group
- What fails when organisations rely on brand trust alone to verify payment requests?
- Who is accountable when a crypto platform fails to detect illicit wallet risk before a transaction goes on-chain?
- How should security teams test and govern SAP transaction codes before users rely on them in production?
- What happens when gig platforms rely on anonymity without a way to verify users?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org