Pre-Signature Risk Packet for AI-Enabled Wallet Scams
Disclosure: AI tools were used for source collection and editorial review. The article was written by a human author, who checked the facts, code, and conclusions.
Crypto risk disclosure: This article is a technical explanation, not investment advice. It is not a recommendation to buy, sell or hold any cryptoasset.
A boring failure starts the design: a user reaches a wallet prompt before the product has connected the request path, the spender, the chain, and the approval scope. Research on LLM spear phishing, lateral phishing with LLMs, and phishing content generation supports only a narrow claim: language models can make lures cheaper and more plausible. The wallet-safety packet keeps that model signal in the evidence lane; the model does not get to release the signature.
This is a response to proximity, not panic. A risky off-wallet path can sit near a typed-data signature, token approval, Permit2 allowance, or WalletConnect session request in the same user journey. Google Cloud's Cybersecurity Forecast 2026 treats AI-enabled social engineering as threat context, and Chainalysis' 2026 scams report treats impersonation and AI-enabled scams as material context in its own methodology. The engineering object sits between that context and the wallet action.
Failed Prompt
One failed prompt should be easy to debug. The bad prompt is not "the user saw a scary message." The bad prompt is "the wallet could not say which origin, chain, spender, allowance, deadline, and warning reason were present before confirmation." Web3 blind-message attack research supports the concern that users may not be able to inspect what a message authorizes. The packet turns that concern into fields a product can inspect.
The model gets a limited job. A model may mark a suspicious origin, lookalike domain, copied brand pattern, or unusual urgency. A model score may explain why a wallet slowed the flow. The model score should not approve a recipient, suppress a warning, or weaken a spending cap; deterministic wallet rules decide whether the signature flow continues.
Fields To Read
Start with fields wallets already expose or can decode. EIP-712 gives typed structured data and domain separation fields, while also saying that replay protection is not provided by EIP-712 alone. Sign-In with Ethereum shows why domain, URI, chain-id, nonce, issued-at, and origin checks matter. These fields are product safety inputs, not decoration around a generic confirmation.
Allowance fields deserve their own read. ERC-20 defines approve, allowance, spender, and transferFrom; ERC-2612 adds signed permits with owner, spender, value, nonce, and deadline; Permit2 separates one-time signature transfers from allowance transfers, and the AllowanceTransfer reference documents maximum allowance behavior. Before the user signs, the product should classify requested authority as one-time, bounded, time-limited, or effectively unlimited.
Packet Log
This is a product-layer log, not a universal cross-wallet standard. MetaMask Snaps transaction insights and signature insights show that wallet tooling can inspect origin and transaction/signature data before confirmation. CAIP-2 gives machine-readable chain labels, and WalletConnect namespaces keep session scope explicit. The record assembles those signals without pretending that every wallet already implements the same hold behavior.
{
"event_type": "pre_signature_risk_packet.v1",
"message_risk": {
"origin": "signatureOrigin | transactionOrigin",
"risk_class": "impersonation | lookalike_domain | unknown",
"model_score": 0.86,
"model_authority": "evidence_only"
},
"wallet_action": {
"chain_label": "eip155:1",
"signing_method": "eth_signTypedData_v4",
"recipient_or_spender": "decoded_from_calldata_or_typed_data",
"counterparty_status": "new_for_user",
"approval_scope": "unlimited | bounded | one_time",
"deadline_or_expiration": "timestamp | none"
},
"hold_review": {
"rule_id": "new_spender_unlimited_scope_unverified_origin",
"decision": "hold_before_signature_release",
"user_visible_reason": "New spender requests broad token access from an unverified request path.",
"lower_risk_next_step": "Reopen from a user-verified entry point or reduce the approval limit."
}
}
The record stays narrow. It says the wallet captured origin, counterparty, approval scope, chain label, and rule before signature release. It does not prove the user's real-world intent, the legal identity behind an address, or the future safety of the spender.
Misuse Diff
A misuse diff is more useful than a slogan. TRM Labs' 2026 crypto crime report is useful context for evolving illicit-flow behavior, but a chain label remains a data-pipeline claim. External labels should sit next to deterministic wallet facts such as new spender, approval scope, chain label, method, and origin.
- model_score: 0.86 means refuse the transaction
+ model_score: 0.86 explains why review was raised
- chain_label: reported_cluster means the user is a criminal
+ chain_label: reported_cluster is context with source and confidence
- approval_scope: unlimited is always fraud
+ approval_scope: unlimited is a concrete authority class to display
- warning: "be careful"
+ warning: "new spender, broad token access, unverified request path"
Bad product copy should become harder to ship. "This looks risky" gives the user nothing to verify. A stronger warning says: "This approval lets a new spender move this token without another confirmation; the request path is unverified; reopen from a user-verified entry point or reduce the approval limit." The warning names the action, the reason, and a user-verifiable next step.
Review Ticket
After the user action, the same fields can feed a small review ticket. The ticket should capture origin, wallet event, approval scope, deterministic rule, model score, user-visible reason, user action, support outcome, and final fraud label when known. The ticket does not need the user's full chat history, private keys, seed phrases, or unnecessary message contents.
Reviewers need something concrete when a normal flow is interrupted. If the spender is new and the approval is unlimited, a lower-risk retry might use a bounded allowance or a user-verified entry point. A model score without the deterministic rule cannot explain that review path.
Release Check
Before the wallet lets a risky flow continue, run one release check: one source-path fact, one decoded wallet-action fact, one authority-scope fact, and one user-visible hold reason. Without those fields, the product cannot explain this pre-signature hold. The product has a polished guess.
Top comments (0)