Skip to main content
Risk grades and simulations tell you where a position stands; detection tells you the moment something changes. Alterscope runs a standing detection engine that re-reads its data sources on a fixed cycle, evaluates a library of rules against the latest state, and emits findings — scored, scoped observations that something looks wrong — into the same alerts inbox you already use. The engine is deliberately boring: a short, repeated loop over real data, not a black box. This page describes what it actually does today.

​
The detection cycle

Each cycle the engine pulls a fresh snapshot from its wired sources, builds a feature view of the market, and runs every registered rule against it:
  1. Read. It fetches the latest state from each connected source — EVM lending markets (Aave v3, Compound v3, Euler v2, SparkLend, Morpho Blue), Stellar venues (Blend, SDEX, Aquarius, Sushi), and an Ethereum RPC for on-chain reads.
  2. Build features. It aggregates that data into a feature snapshot: oracle staleness, failed-transaction rate, utilization, liquidity imbalance, and holder concentration. Each feature carries a data-quality score that rises with how many real sources backed it, so a thin snapshot is visibly thin rather than silently confident.
  3. Evaluate. It runs protocol rule packs (lending, DEX, and governance) plus the core risk cycle, producing findings where a rule trips.
The cycle cadence is fixed (60 seconds by default). A finding is only as fresh as the last completed cycle, and the engine reports when that was — a wedged or frozen engine is detectable, not silently stale.

​
What a finding carries

Every finding is a structured record, not a free-text alert. It names the protocol and chain it concerns, the rule pack that produced it, a root cause, and a recommended action, alongside three scores:
  • Severity — how serious the condition is.
  • Confidence — how strongly the data supports it.
  • Blast radius — how much of the relevant exposure the condition touches.
Severity maps to the familiar alert bands — info, warning, critical — so a finding lands in your inbox at a priority you can triage at a glance.

​
From finding to your inbox

Findings flow into the alerts platform — the same inbox that carries your rule-based alerts. The engine registers detection as a platform-owned alert source, so detector findings appear in /alerts next to everything else, filterable by source. There is nothing extra to wire up: if you can see alerts, you can see findings. The engine also keeps a short rolling history of recent findings and persists it across restarts, so a pod restart does not blank your recent detection history.

​
Governance events

Beyond the polling cycle, the engine accepts governance events — a parameter change, an admin action, a proposal — and evaluates them immediately against the governance rule pack. Duplicate events inside a 24-hour window are de-duplicated, so the same on-chain action does not produce a wall of repeated findings.

​
Honest coverage

Detection quality tracks which sources are wired in your environment. A detector only fires on data it can see:
  • Detectors that depend on the knowledge-graph / topology export (contagion- and concentration-aware rules) stay dark wherever no graph-intelligence export is connected — they light up as that data lands, not before.
  • Per-protocol and per-chain coverage follows connector coverage. A protocol with no connected source produces no findings for that protocol, by design — the engine runs fail-open on the sources it has rather than fabricating a signal.
Treat detection as a capability whose breadth grows with source coverage, not as exhaustive surveillance of every protocol. See Coverage & gaps for what is connected where, and Graph Intelligence for the network analysis the topology-aware detectors build on.

​
What this is not

Detection surfaces conditions; it does not move funds. Findings are observations routed to your inbox — acting on them is yours to decide. The engine reads and scores; it does not place transactions.