NOTE - Some the provided use cases could be redundant with existing telemetry that's already leveraged by OP Stack chain operators
Context
Some system contract events that emit from OP Stack contracts occur on semi-deterministic time intervals. The same applies to some protocol transactions as well. For example, proposer submission to the L2OutputOracle typically occur around every hour on Base (see Etherscan). If this event were to not occur on its expected interval and be missed, it could be indicative of potential sequencer/protocol liveness failures. Furthermore the same could be said for an event that occurs too frequently/fast as well.
Example Use Cases
Some further examples of other potential liveness failures that could be caught via this heuristic:
Anomalous batch submission failure where the BatchInbox is not being posted to by the op-batcher
Proposer failure where OutputProposal events fail to post to the L2OutputOracle contract via the op-proposer
Anomalous (deposit,withdrawal) bridge transaction/event frequencies could be indicative of either protocol (e.g, paused withdrawals on L1) or integration failure (e.g, crashed entry-point UIs that most users use to bridge funds to layer2).
Technical Details
There should exist some calculation policies for how an event/transaction delta is computed that is configurable via the heurisitc_params; e.g:
static: Keep track of the last time a specific event (address,sig) or transaction (to,from) was emitted/executed. If the time delta from the last event goes above or below a user defined upper/lower threshold, then alert. This is useful for monitoring frequencies that are expected to be constant (e.g, sequencer/batcher l1 submission times).
dynamic: Compute the moving average (MA) of n prior time deltas for some (address,event) or (to,from) pair. After computing MA, calculate the percent_diff between MA and the most recent time delta. If percent_diff falls above/below some user defined upper/lower thresholds, then alert. This could be useful for monitoring repetitive events with differing frequencies based on entropic factors like user usage (e.g, bridging deposits, withdrawals).
Additionally a type enum should supported that assumes either transaction or contract_event.
Heuristic Description
NOTE - Some the provided use cases could be redundant with existing telemetry that's already leveraged by OP Stack chain operators
Context
Some system contract events that emit from OP Stack contracts occur on semi-deterministic time intervals. The same applies to some protocol transactions as well. For example, proposer submission to the
L2OutputOracletypically occur around every hour on Base (see Etherscan). If this event were to not occur on its expected interval and be missed, it could be indicative of potential sequencer/protocol liveness failures. Furthermore the same could be said for an event that occurs too frequently/fast as well.Example Use Cases
Some further examples of other potential liveness failures that could be caught via this heuristic:
BatchInboxis not being posted to by theop-batcherOutputProposalevents fail to post to theL2OutputOraclecontract via theop-proposerTechnical Details
There should exist some calculation policies for how an event/transaction delta is computed that is configurable via the
heurisitc_params; e.g:static: Keep track of the last time a specific event(address,sig)or transaction(to,from)was emitted/executed. If the time delta from the last event goes above or below a user defined upper/lower threshold, then alert. This is useful for monitoring frequencies that are expected to be constant (e.g, sequencer/batcher l1 submission times).dynamic: Compute the moving average (MA) ofnprior time deltas for some(address,event)or(to,from)pair. After computingMA, calculate thepercent_diffbetweenMAand the most recent time delta. Ifpercent_difffalls above/below some user defined upper/lower thresholds, then alert. This could be useful for monitoring repetitive events with differing frequencies based on entropic factors like user usage (e.g, bridging deposits, withdrawals).Additionally a
typeenum should supported that assumes eithertransactionorcontract_event.