Monitor targets

A monitor target is a single measurable signal on a contract. Targets are what alert rules compare thresholds against. Each contract can have many targets — typical setups mix one or two event-based targets with a revert rate or latency target for general health.

Target types

  • event_frequency — count of a specific event emitted by the contract within the rule's window. Filtered by topic0, the keccak256 hash of the event signature, which is set when you pick the event during contract onboarding.
  • tx_rate — count of unique transactions that touched the contract in the window. Useful for spotting volume spikes or sudden silence.
  • function_call_rate — in the current implementation this resolves to the same counter as tx_rate. It is exposed as its own type so we can split the two when per-function decoding lands; treat it as a synonym for now.
  • revert_rate — fraction of transactions that reverted, expressed as a float between 0.0 and 1.0. This requires fetching transaction receipts, so it costs more RPC calls than the count-based targets.
  • latency_proxy — seconds since the most recent on-chain activity (any tx or event). Good for "dead contract" alerts: if nothing has touched the contract in N hours, something is probably wrong upstream.
  • value_transfer — the largest single transfer observed in the poll window (the maximum over native-ETH transaction values and individual ERC-20 Transfer amounts), expressed in ETH-equivalent units. Use it for big-transaction threshold alerts: “alert me when a single transfer exceeds 1,000 ETH”. Note it is a max, not a running total, so it tracks the biggest move, not aggregate volume. Native (pure-ETH) transfers are included via a per-block window scan, and ERC-20 amounts are scaled by each token's actual decimals (resolved on-chain, with 18 used only as a fallback for unknown tokens).

Oracle targets (Chainlink price feeds)

  • oracle_price_deviation — the absolute percentage change between the two most recently polled feed rounds (e.g. 2.5 means the price moved 2.5%). Threshold it to catch sudden repricings.
  • oracle_staleness — seconds since the feed's updatedAt timestamp. Set the threshold just above the feed's expected heartbeat interval to catch a missed update.

Anomaly detection

anomaly_detection is a meta-target: instead of a raw metric, its value is a z-score of a base signal against a rolling baseline (mean + standard deviation) that IMAA learns online. Set the base signal in the target's config under base_target_type (defaults to tx_rate), and threshold the z-score (2–3 is a typical "this is unusual" band). Two things to know:

  • It needs a 50-sample warm-up. Until 50 observations have accumulated, the target returns no signal and cannot fire — expect a quiet period after you create it.
  • The baseline adapts continuously, so a slow, sustained drift eventually becomes the new normal; anomaly detection catches sudden departures, not gradual creep.

Bridge targets

  • bridge_dvn_change — fires when the LayerZero V2 DVN configuration for a route changes on-chain (a DVN added or removed, the required threshold decreased, or an unknown operator appears). This is the only DVN alerting target; the static DVN risk score is a read-only signal shown on the contract's Bridge tab, not a firing target. See DVN Detection.

Agent targets

Five agent-specific dimensions apply to monitored AI agents, not contracts: agent_response_drift, agent_latency_spike, agent_signature_invalid, agent_endpoint_down, and agent_model_swap_suspected. See AI Agent Monitoring for what each one measures.

Solana targets

Contracts on Solana (programs) use their own set of target types, ingested from Helius enhanced-transaction webhooks rather than the EVM poller:

  • sol_tx_rate — number of transactions touching the program in the window.
  • sol_instruction_count — total number of instructions invoking the program.
  • sol_latency_proxy — seconds since the program's most recent activity.
  • sol_instruction — count of transactions carrying a specific instruction, set via discriminator in the target config.
  • sol_event — count of transactions emitting a named program event, set via event_name in the target config.

Event filtering

For event_frequency targets, IMAA matches on the indexed topic0 of each log. You select the event from the decoded ABI during contract onboarding, and IMAA stores its signature hash on the target. Only logs whose first topic equals that hash are counted — everything else on the contract is ignored for that target.

Indexed parameter filters (e.g. "Transfer where from is the treasury address") are not yet supported. If you need that level of granularity today, route the alert into a webhook channel and post-filter in your handler.