How It Works
This page explains how Daiko Terminal evaluates your conditions and delivers notifications. Understanding these concepts helps you create better conditions and set realistic expectations.
The Evaluation Loop
When you save a condition, here's what happens behind the scenes:
- Your DSL is validated - The system checks that your condition uses valid fields and operators
- It's compiled to SQL - Your condition becomes a parameterized database query (no raw SQL injection possible)
- The query runs - Matching tokens are fetched from the live database
- Results are filtered - Cooldown and limits are applied
- Notifications are sent - You receive alerts via Telegram (if connected)
This loop runs periodically (typically every few seconds), so your conditions are always being evaluated against fresh data.
Key Concepts
Limits and Constraints
Result Limit: 500 Tokens
Each evaluation returns at most 500 tokens. If your condition matches more than 500 tokens:
- Only the first 500 (based on your
order_byor default ordering) are returned - You won't see the rest until they rise to the top or your condition changes
Best Practice: Use more specific conditions or add an order_by clause to prioritize what matters most.
Cooldown Period
After you receive a notification about a specific token for a specific condition, that token enters a cooldown period for that condition. During cooldown:
- The token may still match your condition
- But you won't receive duplicate notifications
- Cooldown is tracked per (condition, token) pair
Active Conditions Only
Only active conditions for active agents are evaluated. If you:
- Deactivate a condition: It stops being evaluated
- Delete an agent: All its conditions are removed
Notifications
Telegram (Primary Channel)
When tokens match your condition:
- The system checks if you have Telegram connected
- If yes, it sends a message with:
- Agent name
- Matching token details (symbol, address, metrics)
- A link to view more
What Gets Sent
Each notification includes:
| Field | Description |
|---|---|
| Symbol | Token symbol (e.g., PEPE, WIF) |
| Mint Address | Unique token identifier on Solana |
| Price (SOL) | Current price in SOL |
| Market Cap (USD) | Market capitalization in USD |
Data Freshness
Your conditions run against near-real-time data:
- Token metadata (symbol, creation time): Updated as new tokens are created
- Metrics (price, market cap, holder count): Updated continuously from on-chain data
- Trade data: Streamed from the blockchain with minimal delay
Security Model
Your conditions are safe because:
- No raw SQL: You write DSL (JSON), not SQL. The system validates and compiles it.
- Field whitelist: Only specific, allowed fields can be queried
- Parameterized queries: All values are passed as parameters, not string-concatenated
- Validation at parse time: Invalid conditions are rejected before execution
This design prevents SQL injection and ensures you can only query intended data.
Summary
| Aspect | Behavior |
|---|---|
| Evaluation frequency | Periodic (every few seconds) |
| Max results per run | 500 tokens |
| Cooldown | Per (condition, token) pair, in-memory |
| Notifications | Telegram (requires connection) |
| Data freshness | Near real-time (seconds behind chain) |
| Security | Validated DSL → Parameterized SQL |
For details on what you can query, see the DSL Reference.
