Skip to content
Quantix Security Labs

Continuous Security Monitoring

An audit describes a system at a point in time. Monitoring watches what happens once it is deployed. We design detection logic from the protocol’s threat model, tune it against historical activity to keep noise low, and route alerts to the people who can act on them. The console on this page runs recorded investigations from Quantix Protocol Research.

Detection rules for the events that matter after deployment.

Discuss monitoringSee the console
Illustration of a chain of blocks with sensors on watched contracts emitting event pulses along a rail into a rule engine; one block is marked with an alert.

Service overview

Most attacks are visible on-chain before they are finished.

Monitoring covers what the threat model says could go wrong: who can change the system, where value moves, and which patterns tend to precede an attack.

An upgrade that nobody approved, a role granted at three in the morning, a treasury transfer larger than any payment schedule: these are visible in the chain’s own record, often minutes before the damage is complete. Monitoring turns them into alerts that reach someone who can act.

Useful monitoring is specific to the protocol. Rules are derived from its privileged roles, its dependencies and its value flows, and each rule is tested against historical activity before it is deployed. Generic rule packs come second.

The output is a rule set, routing and runbooks your team understands and can maintain. We design and tune it with you; we do not ask you to trust a black box.

Starts from
Your threat model or latest audit report
Watches
Roles, upgrades, treasuries, oracles, transaction patterns
Hands over
Rules as code, routing matrix, runbooks

Applies to

  • Deployed protocol contracts
  • Multisig and governance executors
  • Treasury and fee-collection addresses
  • Proxy admin and upgrade paths
  • Oracle feeds and price dependencies
  • Bridge and cross-chain message flows
Privileged-operation rulesEvent and trace decodingAnomaly thresholdsIncident replay

Threats addressed

What monitoring is designed to catch.

Each rule traces back to an attack class with a known on-chain signature. The threat model decides which of them matter for your deployment.
  • Key compromise

    Privileged role used unexpectedly

    An admin, guardian or owner key acting outside its normal pattern, or transferring its role to a new address.

  • Upgrade risk

    Unapproved implementation

    A proxy pointed at bytecode that does not match any approved release, or an admin change on the proxy itself.

  • Governance manipulation

    Hostile or rushed proposals

    Proposals that move treasury funds, change roles or shorten delays, especially after a sudden accumulation of voting power.

  • Oracle manipulation

    Price feed out of bounds

    Deviation between sources, stale heartbeats, sequencer downtime, or a spot price moved within a single block.

  • Flash-loan exploit

    Attack-shaped transactions

    Borrow, manipulate, extract and repay within one transaction, often from a freshly deployed contract.

  • Treasury drain

    Outflows above any schedule

    Transfers from treasuries, fee collectors and multisigs that do not match approved proposals or payment schedules.

  • Bridge message validation

    Messages that should not exist

    Releases without a matching deposit, repeated nonces, or messages for a destination they were not signed for.

  • Signature phishing

    Mass approval drains

    Clusters of approvals or permits to one new spender, followed by transferFrom calls across many holders.

  • Liquidity risk

    Liquidity pulled or concentrated

    Sudden withdrawal of pool liquidity, collateral concentration, or utilisation drifting toward a threshold.

Technical capabilities

The events that matter after deployment.

Eight areas of coverage, each with rules designed for the protocol rather than copied from a template.

  • Privileged operations

    Every call that only an admin, guardian or governor can make, matched against what was expected to happen.

  • Contract events

    Event streams decoded into protocol terms, so an alert says what changed rather than which log fired.

  • Treasury movements

    Outflows from treasuries, fee collectors and multisigs, compared with approved proposals and payment schedules.

  • Contract upgrades

    Implementation changes, admin transfers and timelock queues, checked against the releases you approved.

  • Transaction patterns

    Sequences that precede known attack classes: flash-loan round trips, sudden approvals, unusual call ordering.

  • Security alerts

    Severity assigned by rule, deduplicated and routed with the runbook step that should follow.

  • Risk indicators

    Slower signals: utilisation, collateral concentration, oracle deviation and liquidity depth drifting toward thresholds.

  • Alert routing

    Who is told, through which channel, and what they are expected to do within the first minutes.

Rules, alerts and runbooks in one view.

The console below runs the recorded investigations of Quantix Security Monitoring. Filter the threat timeline, open the detection rule behind each alert, or step through an incident event by event. Watched contracts on live networks are followed in contract monitoring.

Open the monitoring console

Quantix Security Monitoring

Investigation archive · 83 recorded events through 24 Oct 2026, 09:00 UTC

Events in view
83
Alerts at current rules
50
Critical alerts
10
Open or acknowledged
13
CriticalHighMediumLowInformational
051015Nov 25Jan 26Mar 26May 26Jul 26Sept 26
Events per month by severity
CategoryCriticalHighMediumLowInformational
Nov 2500211
Dec 2500110
Jan 2600201
Feb 2600111
Mar 2602100
Apr 2600111
May 2604121
Jun 2612421
Jul 2623311
Aug 2632511
Sept 2612431
Oct 2635411

Select a month to filter the timeline.

83 events listed

Archive identifiers are internal and not linked to a block explorer. Status changes and rule edits stay in this view.Threat analysis

Assessment methodology

From threat model to rule.

A useful alert is specific, rare and actionable. Each rule is designed, tested against history and connected to a person and a next step before it is deployed.
The seven-stage Quantix workflow
  1. 01

    Start from the threat model

    Rules are derived from what could hurt this protocol: its privileged roles, its dependencies, its value flows.

  2. 02

    Write detection logic

    Each rule states what it watches, the condition that triggers it, its severity and the reasoning behind the threshold.

  3. 03

    Replay against history

    Rules are replayed against past activity to measure how often they would have fired. Noise is treated as a defect.

  4. 04

    Route alerts

    Alerts reach named people through agreed channels, each linked to a runbook step and an escalation path.

  5. 05

    Rehearse the response

    The first response is rehearsed before it is needed: who pauses, who signs, who communicates.

  6. 06

    Review and retune

    Rules are reviewed after every upgrade, new integration or incident, and on a regular cadence agreed with your team.

Anatomy of a rule.

Each rule states what it watches, the condition that triggers it, its severity, where it is routed, the first runbook steps and the reasoning behind the threshold. Rules are versioned and reviewed like code.

rules/proxy-implementation-changed (illustrative)text
rule:      proxy-implementation-changedwatch:     ProxyAdmin            # your deploymentevent:     Upgraded(address implementation)when:      implementation not in approved_releasesseverity:  criticalroute:     on-call -> incident channelrunbook:   1. verify bytecode hash           2. pause affected contracts           3. open the incident channelrationale: an unapproved implementation can change           any logic behind the proxy
Illustrative rule definition. The exact format depends on the monitoring platform you run.

What monitoring cannot do.

Detection is not prevention
An alert arrives after a transaction is observed. Monitoring shortens the time to respond; it does not stop a transaction that is already included.
Some activity is invisible until inclusion
Transactions sent through private order flow are not visible in the public mempool. Rules that depend on pending transactions say so.
Alerts need people
Value depends on someone being able to act: a guardian who can pause, signers who can be reached. We help design that, but cannot replace it.
The monitoring stack is a target too
Alert channels, API keys and automation that can pause contracts must be secured with the same care as the protocol itself.

Tools & techniques

Data sources and techniques behind each rule.

Detection quality depends on data quality. Every rule documents its source, its latency and what it cannot see.
Tools and techniques used for Continuous Security Monitoring
Tool or techniqueCategoryWhat it is used for
Event and log indexingData sourceDecoded contract events from archive or full nodes, reorganisation-aware, with block confirmations stated per rule.
Call traces (debug_traceTransaction)Data sourceInternal calls, delegatecalls and value transfers that never emit an event.
Pending transaction observationData sourcePublic mempool subscriptions for rules that can act before inclusion, with the private-order-flow blind spot stated.
Fork simulation (Foundry anvil)AnalysisSimulates a queued proposal or suspicious transaction against a fork to see its effect before execution.
Price feed health checksOracle monitoringHeartbeat, deviation between sources and L2 sequencer uptime feeds, per the oracle provider’s documentation.
Multisig queue monitoringGovernancePending Safe transactions and timelock queues decoded and compared with approved actions.
Rules as code with testsEngineeringVersioned rule definitions, each tested against recorded incidents and documented with its threshold.
Signed webhooks and pagingRoutingDelivery to paging, chat and incident tools with authenticated payloads and an escalation chain.

Ecosystem coverage

Technical depth per execution environment.

Monitoring depends on reliable data sources for each chain: finality, reorganisation depth, tracing support and oracle infrastructure all differ.

Ethereum

Layer 1, proof of stake EVM

Programming languages
SolidityVyperYul
Monitoring capabilities
  • Proxy admin and implementation changes
  • Governance proposals and timelock queues
  • Large transfers and treasury outflows
  • Oracle deviation against reference feeds
Typical vulnerabilities
  • Reentrancy, including read-only reentrancy
  • Oracle and spot-price manipulation
  • Access control on privileged functions
  • Proxy storage collisions and initializer misuse
  • Signature replay across chains and contracts
  • Front-running and MEV exposure
Assessment methodologies
  • Line-by-line manual review
  • Invariant fuzzing (Foundry, Echidna)
  • Symbolic execution and formal verification
  • Economic attack modelling
Supported standards
ERC-20ERC-721ERC-1155ERC-4626EIP-2612EIP-712ERC-1967ERC-4337

Ecosystems indicate technical specialisation only, not partnerships or endorsements.

Deliverables

A monitoring setup your team can read, run and change.

Engagements begin with the threat model, or with your latest audit report if you have one.

  • Threat-to-rule mapping

    Every rule traced to the threat it detects, and every material threat to a rule or a stated gap.

  • Rule set as code

    Versioned definitions with conditions, thresholds, severities and rationale.

  • Replay and tuning report

    How often each rule would have fired historically, and how thresholds were set.

  • Routing matrix

    Who is alerted for what, through which channel, with escalation paths.

  • Runbooks

    First-response steps per alert type, including who can pause and how to reach signers.

  • Review cadence

    An agreed schedule and triggers for revisiting rules after upgrades and incidents.

Key assessment areas

  • Privileged contract operations
  • Smart contract event streams
  • Treasury and large-value movements
  • Contract upgrades and admin changes
  • Suspicious transaction patterns
  • Protocol risk indicators

Typical deliverables

  • Monitoring design derived from the threat model
  • Detection rule set with thresholds and rationale
  • Alert routing and escalation runbook
  • Periodic tuning and coverage review

Relevant research

Read the work behind the service.

Research on the on-chain signatures of attacks, and the assessments and case studies where monitoring rules were derived.
Research hub

Publications

Case studies

All case studies

Research assessments

Security assessments library
Compare all services

FAQ

Questions teams ask before an engagement

No. This page shows recorded investigations from Quantix Protocol Research; their contracts and transactions are internal to the research and are not on any chain. Security Monitoring under Quantix Intelligence also has a contract monitoring mode, which follows watched contracts on real networks through the configured RPC endpoints and Alchemy webhooks. For a client deployment, the same rules run against your contracts and data sources.

It can be designed to, for narrowly defined conditions where a false positive is cheaper than a missed attack. Automated responses need their own threat model, because the automation key becomes a privileged role.

Every rule is replayed against historical activity before it is deployed, and thresholds are reviewed periodically. Rules that fire without leading to action are retuned or removed.

Monitoring depends on reliable data sources for the chain in question. We confirm coverage for your deployment during scoping rather than promising it in advance.

No. An audit looks for flaws before deployment; monitoring watches behaviour after it. Each informs the other: audit findings suggest rules, and alerts suggest where the next review should look.

Know when something changes.

Tell us which contracts are deployed, who holds privileged roles and how your team responds today. We will propose the rules worth running first.

Discuss monitoringIncident response