In February 2026, an autonomous trading agent only days old tried to send a stranger about $300 and instead sent its entire holding of one token, valued at about $250,000 at the time. Early observers suggested a decimal error. The developer’s own retrospective, as reported, pointed somewhere more worrying: the agent forgot what it owned.
A note on the legal and regulatory points here: they summarise public sources as of November 2026 and should not be relied on. Rules for AI agents are still being written, and some of what is described here is proposed or coming soon rather than settled. Check the current position, or ask a qualified professional, before acting on it. Incident details are as publicly reported at the time, and some are disputed.
What actually happened?
An agent with its own wallet answered a public request for money and transferred more than 52 million tokens, its whole balance of that token, in a single transaction. That was reported as roughly 5% of the token’s total supply.
The sequence, as reported in February 2026 coverage, ran like this:
- A developer launched an autonomous AI agent with a social media account, a crypto wallet funded with about $50,000, and access to trading tools.
- Soon after, strangers created a token linked to the agent and gave its wallet a large allocation, reported as about 5% of supply.
- In late February 2026, a user replied to one of the agent’s posts asking for a small amount of the network’s native coin, about $300 worth.
- The agent sent its full holding of the token instead. The agent later posted that it had meant to send a small donation and had sent everything.
- The recipient began selling within minutes. Reports say the tokens were sold within about fifteen minutes for roughly $40,000.
The transfer could not be reversed. On a public blockchain, a confirmed transaction is final unless the recipient chooses to send funds back.
Why does the number change depending on who you read?
The $250,000 figure is one valuation among several, because the token was thinly traded and its price moved sharply around the event. Some reports valued the tokens at about $250,000 at the time of the transfer. Others put the figure at about $441,000 or higher, using a different price point.
What the recipient could actually get out was far smaller. With limited buyers in the market, selling 52 million tokens quickly pushed the price down, and reports put his proceeds at roughly $40,000. That gap is worth remembering whenever an incident headline quotes a “paper” value for a small token.
The price then rose after the event. One report said the same quantity of tokens was later worth more than the original estimates. We treat these figures as illustrative of the scale of the mistake, not as precise losses.
Was it really a decimal error?
The cause is disputed and has not been independently confirmed. The early theory came from observers, who noted the token used six decimal places and suggested the agent had sent a raw number instead of a converted one. The developer’s own technical retrospective, as reported by crypto media, gave a different account.
The developer’s account, as reported, described a memory failure instead:
- An earlier session of the agent crashed on a software validation error.
- The crash stopped the step that normally saves important working information to disk.
- When the agent restarted, it kept its identity files and notes but lost its recent conversation, including what it knew about its wallet balance and where the large token allocation had come from.
- After buying a small amount of tokens, it checked its balance, saw about 52 million, assumed those were its new purchase, and sent the lot.
If that account is right, it is the more important lesson. A decimal error is a bug in one line of code. A memory failure is a design question that applies to any agent that relies on what it “remembers” rather than what the chain says. The developer was also reported as favouring autonomy and personality over guardrails in the agent’s design.
Which safeguards would have stopped it?
Several ordinary controls would each have prevented or capped this loss, and none of them depend on the AI being smarter.
| Safeguard | What it does | Would it have helped here? |
|---|---|---|
| Per-transaction cap | Blocks any single transfer above a fixed amount or share of the balance | Yes. A $300 request could never become a full-balance transfer. |
| Balance check against the chain | Reads holdings from the blockchain before acting, not from the agent’s memory | Yes. The agent would have seen the tokens were not a new purchase. |
| Human approval above a threshold | Requires a person to confirm large or unusual transfers | Yes. A person would have seen the size of the transfer. |
| Amount shown in plain units | Displays the transfer in dollars and tokens before signing | Likely. A $300 request against a six-figure transfer is hard to miss. |
| Small working wallet | Keeps most funds in a separate wallet the agent cannot spend from | Yes. The agent could only lose what it held day to day. |
| No payments to public requests | Stops the agent from sending money in reply to strangers | Yes. The trigger itself would have been ignored. |
None of these are exotic. They are the same controls a careful finance team puts on a junior employee with a company card. The difference is that an agent acts in seconds, at any hour, and does not hesitate.
What could go wrong with other agents?
The same failure can happen to any agent that holds money and keeps its picture of the world in short-term memory. Restarts, crashes, updates and long conversations can all wipe or truncate that memory. If the agent then trusts its own reconstruction instead of checking the source of truth, it can act confidently on a false picture.
Three features made this case worse than it needed to be. The agent held a large balance it had not earned or planned for. It was designed to respond to public messages, so any stranger could trigger a transfer. And it had no spending limit between “a small tip” and “everything”.
There is also a harder point. In this case nobody attacked the agent. There was no hack and no exploit, according to the developer’s account as reported. An agent can lose money entirely on its own. The next two guides look at what happens when someone is actively trying to make it do so, through prompt injection or by taking over the machine it runs on.
Finally, the money did not come back. Whether a user is made whole after an agent error depends entirely on who controls the funds and what they choose to do. In this case the recipient sold quickly and there was no platform in the middle to step in.
The trust takeaway
An agent that can send money needs limits that do not depend on the agent getting things right. Smarter models reduce the odds of a mistake; hard caps reduce the size of one. In our view, the second matters more for anyone deciding what to trust an agent with.
Before you give any agent a wallet, check:
- Is there a hard cap per transaction and per day? It should be set outside the agent, where the agent cannot change it.
- Does it check balances on-chain before acting? It should not rely on memory or a cached figure.
- Do large transfers need a human? Ask what the threshold is and who gets the approval request.
- How much can it actually reach? Keep the agent’s wallet small and the rest of your funds elsewhere.
- Who can trigger it? An agent that acts on public messages can be triggered by anyone.
- What happens after a crash or restart? Ask whether it saves state safely and re-checks before resuming.