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.

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.