Skip to main content
Get API Key

Signal Triggers

Signal is the condition category for real-time social and event-driven triggers:

  • X/Twitter Post maps to EQL source: "tweet" semantic matching.
  • Telegram Channel maps to EQL source: "telegram" semantic matching.
  • Event maps to EQL source: "news" semantic matching.

Use Signal when you care about what was said (semantic meaning), not only market price movement.

Why Agents Use Signal​

  • React when a specific monitored account posts, instead of polling sentiment indirectly.
  • Capture breaking events by meaning (for example ETF approval, exploit, sanctions), not brittle keyword exact-match.
  • Pair Signal triggers with webhook, notify, telegram_bot, or llm actions for immediate handoff.

Selection Policy​

Choose the Signal source by intent:

  • Use tweet (X/Twitter Post) when the trigger is anchored to a specific account/handle.
  • Use telegram (Telegram Channel) when the trigger is anchored to a monitored public Telegram channel.
  • Use news (Event) when the trigger is a world event and is not pinned to a specific account.
  • Use sec, not news, when the trigger is an official SEC filing for an issuer CIK.
  • Prefer tweet/telegram/news over llm when the trigger is plausibly expressed in X/Twitter, Telegram, or news content.
  • Use llm as a last resort for world-state questions that are not naturally represented as post/event matching.

Examples:

  • Alert me if @cz_binance posts that Binance Alpha is listing a new token -> tweet
  • Alert me if a monitored public Telegram channel posts about a new Binance listing rumor -> telegram
  • Alert me if spot ETH ETF approval happens -> news
  • Alert me when Alphabet files a new 8-K -> sec

Event Semantics​

Signal conditions are event-driven:

  • tweet, telegram, and news evaluate when relevant mention events arrive.
  • They are not driven by recurring schedule polling intervals.
  • You can still combine Signal conditions with other condition types using AND/OR.

Condition Contracts​

X/Twitter Post (tweet.semantic)​

Arguments:

  • username: string (required)
  • text: string (required)
  • minConfidence: integer in [0,100] (required)

Important behavior:

  • username should be provided without @.
  • At create-time, Auto resolves username to an active monitored account; if unresolved, validation/create fails.
  • Semantic verification passes only when confidence is >= minConfidence.

Default condition form:

{
  "source": "tweet",
  "args": {
    "username": "cz_binance",
    "text": "Binance Alpha is listing a new token",
    "minConfidence": 80
  }
}

Telegram Channel (telegram.semantic)​

Arguments:

  • chatUsername: string and/or chatId: string (at least one required)
  • text: string (required)
  • minConfidence: integer in [0,100] (required)

Important behavior:

  • Telegram Signal triggers support monitored public Telegram channels.
  • Shorthand authoring requires exactly one identifier. Full telegram.semantic conditions may carry both; if both are present, they must resolve to the same monitored channel.
  • Prefer chatUsername without @ or t.me/ when you know the public channel username.
  • Use chatId only when it came from tooling or an existing plan.
  • At create-time, Auto resolves the Telegram channel; if unresolved or unmonitored, validation/create fails.
  • Semantic verification passes only when confidence is >= minConfidence.

Default condition form:

{
  "source": "telegram",
  "args": {
    "chatUsername": "<monitored_public_channel_username>",
    "text": "new Binance listing rumor",
    "minConfidence": 80
  }
}

Event (news.semantic)​

Arguments:

  • text: string (required)
  • minConfidence: integer in [0,100] (required)

Important behavior:

  • Event matches are evaluated against mentions from news-tagged sources.
  • Semantic verification passes only when confidence is >= minConfidence.

Default condition form:

{
  "source": "news",
  "args": {
    "text": "SEC approves a spot ETH ETF",
    "minConfidence": 80
  }
}

Text Authoring Constraints (High Impact)​

For tweet, telegram, and news, args.text quality is the biggest determinant of match quality.

  • Keep text atomic: one event/theme per condition.
  • Phrase text as what the post should say/report, not as a monitoring command.
  • Avoid broad umbrella wording in a single condition.
  • For tweet, do not restate account identity in text; username already scopes publisher identity.
  • For telegram, do not restate channel identity in text; chatUsername or chatId already scopes the source.
  • If intent has alternatives (A or B), split into multiple Signal conditions and combine with OR.
  • If intent requires co-occurrence (A and B), split into multiple Signal conditions and combine with AND.

Design recommendation:

  • Prefer splitting event-driven Signal intents and schedule-driven (cron.every) intents into separate queries for clearer semantics and easier debugging.

Match Description Quality (Good vs Bad)​

For X/Twitter Post, Telegram Channel, and Event, keep text as a short factual claim.

X/Twitter Post examples:

  • bad: Bearish vibes -> good: Opens a short position on oil
  • bad: Something bullish -> good: Announces a new stake in TSLA
  • bad: Bullish on a coin -> good: Posts that they're bullish on $HYPE and $SOL

Telegram Channel examples:

  • bad: Alpha group update -> good: new Binance listing rumor
  • bad: Team news -> good: team confirms mainnet launch
  • bad: Whale chatter -> good: large OTC buyer interest

Event examples:

  • bad: Market crash -> good: Major DeFi protocol suffers a $200M exploit
  • bad: War conflict -> good: US imposes new sanctions on Russia
  • bad: Big news -> good: SEC approves a spot ETH ETF

Confidence Tuning​

  • Start with minConfidence: 80.
  • Raise to 85-90 to reduce false positives.
  • Lower to 70-75 if you are missing relevant matches and can tolerate more noise.

Validation Notes​

Common errors:

  • minConfidence must be an integer from 0 to 100.
  • tweet username must be non-empty and resolvable to a monitored active account.
  • telegram must include chatUsername or chatId, and the channel must resolve to a monitored public Telegram channel. Shorthand requires exactly one identifier; full conditions may carry both if they agree.