Pasting should never spend
How Ilyria separates seeing a token, deciding to buy it and spending money on it, and why every trading-bot bug I've studied lives where those three blur.
The most dangerous moment in a trading bot is the moment you paste something into it.
You've found a token. You copy the address, drop it into the chat, and in a lot of bots, that's it. The paste is the order. It's fast, it feels powerful, and it's how people lose money to a mis-copied address, a stale quote or a pool that changed while they weren't looking.
When I started building Ilyria, the first rule I wrote down was the one in the title: pasting should never spend.
Three things that look like one
Every trade is really three separate events:
- Seeing: a token exists, on some chain, in some pool.
- Deciding: this person wants to buy it, with this wallet, at this size, under these limits.
- Spending: a transaction is signed and broadcast.
Most of the bugs I've studied in trading tools come from collapsing those three into one. So Ilyria keeps them apart, explicitly, in code.
A paste only ever resolves: which chain, which token, which pool. If that's ambiguous, the bot opens a chain picker instead of guessing. Then the user reviews the route, amount, slippage, fees and spending limit, and only then arms the trade. Even after arming, the exact token, pool, wallet, price and spending checks run again immediately before execution.
Freezing the decision
Arming does something subtle: it freezes the decision. The wallet, the source, the execution settings and the spending permission are captured at that moment. A watch that runs for 48 hours can't quietly pick up a different wallet or a bigger budget halfway through. If you want different terms, you make a different decision.
Claims you can check
The same principle shaped how we talk about coverage. "Supports Solana" is a marketing sentence. "Supports these 43 named profiles, each qualified individually" is an engineering one. And when a profile isn't proven, the bot says so instead of trying.
It makes the product feel slower to describe. It makes it much faster to trust.
What I'd tell anyone building one
- Treat input, intent and execution as different types, not different moments.
- Freeze permissions when a user commits, not when the code happens to need them.
- Never let a claim in the interface run ahead of the evidence in the release record.