仕組み
このページでは、Daiko Terminalがどのように条件を評価し、通知を配信するかを説明します。これらの概念を理解することで、より良い条件を作成し、現実的な期待を設定できます。
評価ループ
条件を保存すると、裏側では以下のことが起こります：
- DSLがバリデーションされる - システムが条件に有効なフィールドと演算子が使われているか確認
- SQLにコンパイルされる - 条件がパラメータ化されたデータベースクエリに変換（生のSQLインジェクションは不可能）
- クエリが実行される - マッチするトークンがライブデータベースから取得
- 結果がフィルタリングされる - クールダウンとリミットが適用
- 通知が送信される - Telegram経由でアラートを受信（接続されている場合）
このループは定期的（通常は数秒ごと）に実行されるため、条件は常に最新のデータに対して評価されます。
主要概念
条件（Condition）
トークンをフィルタリングするために定義するルールのセット。生のSQLではなく、DSL（JSON形式）で記述。
Example: holder_count > 100 のトークンを検索
評価（Evaluation）
条件をデータベースに対してチェックし、マッチを見つける定期的なプロセス。
クールダウン（Cooldown）
あるトークンについて通知した後、同じ条件で再度通知されない期間。
Example: クールダウンが1時間の場合、1トークンにつき1時間に1回だけ通知
リミット（Limit）
各評価サイクルで返されるトークンの最大数。
制限と制約
結果リミット: 500トークン
各評価で最大500トークンが返されます。条件が500以上のトークンにマッチする場合：
order_byまたはデフォルトの順序に基づいた最初の500件のみが返されます- 残りは上位に浮上するか条件が変更されるまで表示されません
ベストプラクティス: より具体的な条件を使うか、order_by句を追加して最も重要なものを優先しましょう。
クールダウン期間
特定の条件で特定のトークンについて通知を受けた後、そのトークンはその条件に対してクールダウン期間に入ります。クールダウン中：
- トークンは引き続き条件にマッチする可能性があります
- ただし重複通知は送信されません
- クールダウンは（条件、トークン）ペアごとに追跡されます
アクティブな条件のみ
アクティブなエージェントのアクティブな条件のみが評価されます。以下の場合：
- 条件を無効化：評価が停止
- エージェントを削除：すべての条件が削除
通知
Telegram（メインチャネル）
トークンが条件にマッチすると：
- システムがTelegramが接続されているか確認
- 接続されている場合、以下を含むメッセージを送信：
- エージェント名
- マッチしたトークンの詳細（シンボル、アドレス、メトリクス）
- 詳細を見るためのリンク
送信される内容
各通知に含まれる情報：
| フィールド | 説明 |
|---|---|
| シンボル | トークンシンボル（例：PEPE、WIF） |
| ミントアドレス | Solana上のユニークなトークン識別子 |
| 価格（SOL） | SOL建ての現在価格 |
| 時価総額（USD） | USD建ての時価総額 |
データの鮮度
条件はほぼリアルタイムのデータに対して実行されます：
- トークンメタデータ（シンボル、作成時刻）：新しいトークンの作成に伴い更新
- メトリクス（価格、時価総額、ホルダー数）：オンチェーンデータから継続的に更新
- 取引データ：最小限の遅延でブロックチェーンからストリーミング
セキュリティモデル
条件が安全な理由：
- 生のSQLなし: DSL（JSON）を書き、SQLではありません。システムがバリデーションしてコンパイル。
- フィールドホワイトリスト: 特定の許可されたフィールドのみクエリ可能
- パラメータ化されたクエリ: すべての値はパラメータとして渡され、文字列連結ではない
- パース時のバリデーション: 無効な条件は実行前に拒否
この設計によりSQLインジェクションを防ぎ、意図したデータのみをクエリできることを保証します。
まとめ
| 項目 | 動作 |
|---|---|
| 評価頻度 | 定期的（数秒ごと） |
| 1回あたり最大 | 500トークン |
| クールダウン | （条件、トークン）ペアごと、インメモリ |
| 通知 | Telegram（接続が必要） |
| データの鮮度 | ほぼリアルタイム（チェーンから数秒遅れ） |
| セキュリティ | バリデーション済みDSL → パラメータ化SQL |
クエリできる内容の詳細は、DSLリファレンスをご覧ください。