Ilyria

Overview

Ilyria is a trading bot you operate entirely from Telegram. You paste a token address or a chart link, Ilyria works out which chain and which pool it belongs to, shows you exactly what a trade would do, and only acts when you arm it. Around that core sit chain-wide launch scans, a price-entry system called Dutch Guard, take-profit rules, per-user wallets and personal slippage and gas settings.

I lead the engineering: the execution engine, the chain integrations, the Telegram interface, the release process and the public site.

The problem

On-chain trading bots are fast and dangerous in equal measure. Most of them blur three things that should never be blurred: seeing a token, deciding to buy it, and spending money on it. One mis-paste, one stale quote, one route that silently changed, and real money is gone.

The brief was speed without that fragility: a bot that can catch a launch in seconds but never spends without a reviewed, explicit instruction, and never claims to support a route it hasn't actually proven.

The solution

Every action in Ilyria passes through the same sequence: resolve → review → arm → execute.

• Resolve. A pasted address or chart link is matched to a chain, a token and a pool. Ambiguous matches open a chain picker instead of guessing.
• Review. The user sees route, amount, slippage, fees and spending limits before anything happens. Pasting alone never spends.
• Arm. Watches run for a fixed 24 or 48 hours, or an explicitly reviewed until-stopped window. Budgets, wallets and permissions are frozen at the moment of arming.
• Execute. Sensors detect candidates; exact token, pool, wallet, price and spending checks still run immediately before any purchase.

Dutch Guard lets a trader wait for a price instead of chasing one: a maximum price, a range, or a percentage drop from a fixed reference. Take-profit attaches to an actual confirmed purchase (never a hypothetical one) and keeps the original slippage, fee and spending policy in force when it sells.

Architecture

1. Interfaces

   • Telegram bot (grammY)
   • Authenticated HTTPS wallet screen
   • Public site & live preview
2. Decision layer

   • Resolver
   • Review & arming
   • Automation authorization
   • Spending policy
3. Engines

   • Targeted watch
   • Chain launch scans
   • Dutch Guard
   • Take-profit
   • Paper trading ledger
4. Chain adapters

   • Base
   • Ethereum
   • BNB
   • Solana
   • Robinhood
   • GIWA · Arc testnets
5. Infrastructure

   • SQLite state
   • Verified RPC backups
   • Signed release packages
   • DigitalOcean

Engineering challenges

Proving a route before claiming it

"Supports Solana" is not a claim I'm willing to make. Ilyria supports 43 named trading profiles, and each one (a specific launchpad, pool type and lifecycle on a specific chain) is qualified on its own. When a profile isn't proven, the bot says so rather than guessing. The release desk publishes exactly which profiles are covered.

Releases as evidence

Every release ships with a manifest, hashed packages and a verification record. The 13 September release passed 1,195 of 1,195 regression tests across 115 files with no skips; the 22 September tester-fix release passed a clean 1,250-test suite with 2,070 packaged file hashes verified on the server. If the evidence and the documentation ever disagree, the evidence wins.

Paper trading that behaves like money

Paper mode isn't a toggle that skips the hard parts. It keeps persistent virtual balances, fills against fresh quotes, supports partial sells, and tracks cost basis and profit and loss, so testers exercise the same decisions they would make with real funds.

Wallet permissions on new standards

On the GIWA testnet, curve automation uses an EIP-7702 guard: a wallet explicitly enables a constrained permission, can revoke it at any time, and the permission survives restarts. It's the kind of capability that's easy to make convenient and hard to make safe.

Outcome

Ilyria runs on a production server with invited testers in paper mode, and its public site is live. Code qualification for the first two release batches is complete. Capped, real-money acceptance is the deliberate last gate, and it stays closed until the evidence says otherwise.

That restraint is the product. A trading bot earns trust by being precise about what it has proven.

Lessons learned

• Separate seeing, deciding and spending. Every serious bug class in trading bots lives where those three blur together.
• Write claims you can verify. "43 qualified profiles" is more useful, and more honest, than "multi-chain".
• Make the release record the source of truth. Documentation drifts. Hashes and test results don't.