Iruka
For Agent Builders

Stop making agents maintain data plumbing

Build on top of a signal layer that only speaks when the pattern is real.

Autonomous agents should decide and act, not maintain watcher code. Iruka gives them one compact schema for the condition, the wake-up paths, and where the notification goes.

Read The Docs
Agent handoff

One saved rule becomes a reliable trigger surface.

API
EnvelopeBuilt in

version, name, triggers, definition, delivery, metadata

TriggersBuilt in

Use one schedule, a cron, or combine trigger entries when a workflow needs more than one wake-up path

DeliveryBuilt in

Route matched signals to Telegram without changing the condition definition

Signal definition
{
  "version": "1",
  "name": "Vault holder exits",
  "triggers": [
    {
      "type": "schedule",
      "schedule": { "kind": "interval", "interval_seconds": 300 }
    },
    {
      "type": "iruka_signal",
      "id": "sig_upstream_abc123"
    }
  ],
  "definition": {
    "window": { "duration": "7d" },
    "logic": "AND",
    "conditions": [
      {
        "type": "change",
        "metric": "ERC4626.Position.shares",
        "direction": "decrease",
        "by": { "percent": 20 },
        "chain_id": 1,
        "token": "0xvault",
        "account": "0xholder"
      }
    ]
  },
  "delivery": [{ "type": "telegram" }],
  "metadata": {
    "description": "Alert when 2 of 3 tracked holders reduce shares by >=20%.",
    "repeat_policy": { "mode": "until_resolved" }
  }
}
First Principles

Define the trigger contract instead of wiring another watcher.

The advantage is not backend plumbing. It is that users can describe monitoring intent directly.

Problem

Without Iruka, every alert becomes bespoke watcher code.

You have to decide when to check, what to evaluate, how to avoid noisy repeats, and where the alert should land.

Contract

With Iruka, triggers are explicit fields, not hidden glue code.

Start with a schedule, switch to cron, or add another Iruka signal as a wake-up path. The condition and delivery stay separate.

Result

Users get a cleaner rule they can read, edit, and reuse.

The important parts are visible in one JSON object: when it wakes, what it checks, and where the notification goes.

Public Schema

Changing trigger style should feel like editing one field.

Start with one trigger, swap the schedule style, add another wake-up path, or tune cooldown without rewriting the signal.

Field boundary

Triggers wake it

Use interval, cron, or signal-to-signal triggers in one array.

Field boundary

Definition checks it

The monitored condition stays stable while trigger style changes.

Field boundary

Delivery routes it

Telegram delivery is configured separately from wake-up logic.

Schema edit

Start with an interval

A recurring check is just one trigger entry.

1/5
signal.patch.json
What Agents Get

The boring reliability layer your agent should not rewrite.

These are the hard pieces of onchain automation that look simple until they have to run every hour.

One numeric-block model

State reads, indexed events, raw logs, and expressions all become sources your agent can compare.

Window and repeat state

Iruka keeps rolling windows, cooldowns, post-first-alert snoozes, and until-resolved incidents out of agent code.

Sources stay behind the signal

Users define the condition they care about instead of wiring separate RPC, indexer, and event-reader paths.

Explainable delivery

Delivery payloads include condition context so an agent can act on clear trigger reasons.

Multiple wake-up paths

Define interval schedules, UTC cron schedules, or signal-to-signal wake-ups in the same triggers array.

Readable signal intent

A saved signal shows when it wakes, what it checks, and where it notifies without spreading that logic across scripts.

Start Building

A durable signal layer for autonomous workflows.

Define when a signal should wake, what it should check, and where the notification should go. Keep the rule readable instead of spreading that intent across watcher scripts.

Open ConsoleDocs