Say it in plain language; the wallet does it safely.
Axon Wallet separates proposing from deciding. A language model turns a plain-language request into a typed intent, and that is all it does. The intent then passes the same schema validation, policy limits and two-factor gate as any other API call before a transaction reaches Solana, EVM or Sui.
Because model output is untrusted input. A wallet that lets a language model call a transfer directly inherits every failure mode the model has: a hallucinated address, a decimal in the wrong place, or an instruction smuggled in through text it was asked to read.
The safe framing is older than agents and comes from ordinary API design. The client proposes, the server decides. Axon Wallet applies that literally, so the planner sits on the client side of the trust boundary and everything it produces is treated as a request from a stranger.
Not a transaction. It produces a typed intent, a small JSON object describing what the user appears to want: an action, a pair, an amount, a chain. That object is validated against a strict schema before anything else looks at it.
If it is malformed, it is rejected. If it describes something outside policy, it is rejected. A rejected intent never reaches an executor, so the worst case for a bad generation is a failed request rather than a lost balance.
Validated intents still have to clear policy: slippage caps, a token allowlist, and per-action limits. Anything that moves value then meets a two-factor gate before signing, so a compromised session cannot quietly drain an account.
Requests are HMAC-signed end to end, which means the model is not the only thing being checked. The call itself has to prove it came from where it claims to.
Each chain sits behind its own adapter, and a shared nonce and gas manager sequences transactions per chain so two concurrent actions on the same account cannot collide. The intent format stays identical across all three; only the adapter changes.
Swaps route through DEX aggregation to find a price, with 1inch limit orders for maker flow and Permit2 for gasless approvals, so a user is not signing a fresh allowance for every token they touch.
Two things, mostly. Moving execution onto high-concurrency workers raised transaction throughput by around 60 percent, and caching the read paths that were being hit repeatedly cut API latency by roughly 45 percent.
Neither is exotic, and that is rather the point: the safety layers above are cheap. Validation and policy checks cost microseconds, while the network calls they guard cost hundreds of milliseconds. Being careful here is close to free.
An agentic wallet backend where high-concurrency workers raised transaction throughput 60% and caching cut API latency 45%.
| Chains | Solana, EVM, Sui |
|---|---|
| Model role | Proposes typed intents only, never executes |
| Validation | JSON schema, the same path as any API request |
| Policy | Slippage caps, token allowlist, per-action limits |
| Authentication | HMAC-signed requests, 2FA before value moves |
| Swaps | DEX aggregation with 1inch limit orders |
| Approvals | Permit2 gasless allowances |
| Throughput | Around 60% higher via high-concurrency workers |
| Latency | Around 45% lower via caching |
Only if it is not the thing making the decision. A safe design lets the model propose a structured action and puts schema validation, policy limits and a two-factor gate between that proposal and any signing. The model's output is treated as untrusted input, exactly like a request arriving from a browser.
One where the user describes an outcome and the system works out the transaction, instead of the user assembling the transaction themselves. In Axon Wallet the intent is an explicit typed object validated against a schema, which is what makes it safe to generate from natural language.
By making sure the model cannot move funds at all. An injection can only ever produce an intent, and that intent still has to survive schema validation, a token allowlist, slippage caps and a two-factor prompt before anything is signed. A successful injection produces a rejected request.
No. The planner has no access to signing. Keys sit behind the validation and approval layers, and the only thing the model contributes is a proposal those layers are free to reject.
Best-route swaps across six aggregators, at production scale.