An LLM Wallet Is Easy. The Safety Engine Is the Hard Part.

You can build the demo in a weekend. Wire an LLM to a wallet, let someone type "send 50 USDC to alice.base.eth", parse the intent, sign the transaction. It feels like magic in the demo, and it is genuinely useful. It is also the easy 80%. The hard 20%, the part that decides whether this should ever touch real money, is teaching it when to refuse.

This is a project log for an LLM-native wallet I built on Base. The natural-language layer handles eleven intent types. The part I actually spent my time on is the safety engine that sits between the model and the chain.

What the wallet does

The wallet speaks intents, not button clicks. Eleven of them: send, swap, batch, chain (sequenced actions), streaming payments, bridging, and the rest of the operations you would otherwise click through a dapp to perform. Underneath there is a NEAR Intents integration (a Skills API, a policy layer, and a bridge adapter), so a single natural-language request resolves into a concrete, executable plan.

That part works. You can talk to it and it does the thing. Which is exactly why it is dangerous.

The interesting failure mode is obedience

A normal wallet does what you click. An LLM wallet does what you, or something pretending to be you, say. The threat is not that the model miscomputes a swap. The threat is that it is helpful to the wrong instruction: a poisoned address that looks almost right, a token approval with no spending limit, a message that reads like it came from you but did not.

So the design question stops being "can it execute" and becomes "what is the smallest set of checks that catches the dangerous request without blocking the legitimate one".

The four-check pipeline

Every intent passes through four checks before it can execute, plus one external check:

• Simulation: dry-run the transaction and inspect the actual state changes, not the stated intent. What balances move, what approvals get set.
• Approval scope: flag unlimited or unusually broad token approvals, the single most common way people get drained.
• Reputation: check the counterparty and contract against known-bad and known-good signals.
• Semantic review: a separate model pass asking whether the resolved plan actually matches what the user asked for. This is where prompt injection and intent drift get caught.

Each check writes a decision trace: per-check timing and an audit trail, so a refusal is explainable rather than a shrug. The policy engine logs every denial and applies a cooldown, so a rejected request cannot be hammered through by retrying.

The adversarial suite

The wallet ships with 170 evaluation cases: 112 for intent parsing, 10 for safety, 16 end-to-end, and 32 adversarial. The adversarial set is the one I care about, split across six attack categories:

Attack category	Cases
Prompt injection	8
Address poisoning	5
Approval exploit	5
Social engineering	5
Amount manipulation	5
Phishing	4

Each case encodes a concrete way these systems get drained in the wild. Address poisoning seeds the history with a lookalike address and waits for a copy-paste. Approval exploit asks for an innocent-sounding "approve" that is actually unlimited. Amount manipulation plays games with decimals and "send everything". Prompt injection hides an instruction inside data the agent reads.

What I cannot tell you yet

Here is the honest part. I have the harness, the categories, and the four-check pipeline. What I do not have yet is a tuned catch rate I would stake a claim on. Running the full adversarial suite against the live server and tuning the thresholds is the next task, and the thresholds are the whole game: too tight and the wallet refuses legitimate sends, too loose and the attacks get through. A catch rate is only meaningful next to an honest false-positive rate, and I have not finished that calibration. Per-session spending limits, address-book verification for new recipients, and real-time monitoring are also still on the list.

So this is not a "look how safe it is" post. It is a "here is the architecture, and here is what safety actually costs to build" post.

Why this matters

Everyone is racing to put agents in front of money, and the demo is trivial enough that the demos are everywhere. The unglamorous work, the simulation, the approval scoping, the denial cooldowns, the adversarial suite you run against yourself, is the entire difference between a neat toy and something you would let near a real balance. I would rather have a wallet that occasionally annoys me with a refusal than one that is confidently, helpfully wrong with my funds.

Ongoing. Next up: the full adversarial run against the live server, threshold tuning with false-positive accounting, and per-session limits.