Status
Every rule carries one status badge.| Badge | Status | Meaning |
|---|---|---|
| 🟢 | Active | Live in production today. You can enable it now. |
| 🟡 | Building | Implemented but not yet emitting alerts — typically waiting on a data source. Close to ready. |
| 🔵 | Planned | On the roadmap. Not available yet. |
| 🟣 | Internal | Used internally or for a single workspace; not generally available. |
| ⚪ | Deprecated | Retired from a previous runner. Listed for migration context. |
Account types
What you point a rule at when you configure it:- Wallet (EOA): an externally-owned account / individual wallet.
- Multisig: a Squads or Safe / Gnosis multisig.
- DAO / Governance: a Realms (SPL Governance) realm or governance account.
- Contract: a smart contract (proxy, Ownable, Pausable, etc.).
- Program: an onchain program.
- Token / Mint: an SPL mint or ERC-20 token, including stablecoins.
- Network: chain-wide signals not tied to a specific account.
Trigger model
- Per-block: evaluated on every block; alerts fire as the triggering transaction lands.
- Scheduled (tick): evaluated on a timer. Used for polling external state, time-window comparisons, and timelock countdowns.
Chains
Rules describe a capability, not a chain. Coverage spans Solana and EVM, and we extend rules to new networks on request. Where a rule uses a chain-specific mechanism (for example Squads on Solana or Safe on EVM), that’s clear from the rule itself.Severity and destinations aren’t rule properties, you set them per instance. See
How alerting works and
Supported destinations.