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 on-chain 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.