Skip to content
Wall 02 Sense

Ops Monitor

The organisation around the code, watched as closely as the code. Most large losses no longer begin with clever code. They begin with a signer added to a multisig at three in the morning, a proposal that does something other than its title says, or an endpoint that began returning answers somebody else wrote.

Wall02 of 05Watches5 surfacesBuilt for4 groupsLosses answered5Refuses a transactionThrough Live Detection

How it works.

None of this is a transaction, and where it is, it looks routine, which is why a transaction monitor never sees it. Three layers run in a fixed order. First, plain rules over events and calldata: a delegatecall from a multisig is never benign. These own every critical finding and consult no model. Second, a layer that learns what normal looks like for your signers, in maths simple enough to replay line by line. Third, a summary that orders the findings and never sets a severity. That third layer can run inside your own network, on your own model.

  • Signer and threshold changes
  • Governance read from calldata
  • Frontend and DNS
  • RPC integrity

What it actually looks at.

Five surfaces, named. Anything outside this list is not covered by this wall; the perimeter page says which one covers it.

Multisig and signer changes: who was added, who was removed, whether the threshold moved, whether the timelock was shortened
Governance, judged by what a proposal executes when it is run, rather than by what its description claims
The website your users type in, and whether it still points where it did yesterday
Whether the RPC endpoint your infrastructure trusts is returning answers somebody else wrote
How each signer normally signs, so a coerced or spoofed approval breaks a pattern even when the signature is valid

Who it is for.

Treasuries and signers

Anyone whose worst day starts with a valid signature nobody meant to give.

  • DAOs and protocol treasuries
  • Corporate treasuries
  • Foundations
  • Funds and asset managers
  • Custodians
  • Multisig and Safe operators

Governance

Anyone who votes on payloads they cannot read.

  • Governance councils
  • Security councils
  • Delegate committees
  • Timelock and executor operators
  • Grant and treasury committees

Front ends

Anyone whose users trust a page and a script to say what they are signing.

  • Protocol web applications
  • Wallet and signing interfaces
  • Exchange and custody interfaces
  • dApp aggregators and portals

Infrastructure

Anyone whose contracts act on data an endpoint handed them.

  • Node and RPC consumers
  • Bridge and message-layer operators
  • Oracle integrators
  • Indexers and keeper networks

Five losses this wall answers.

Public, dated and sourced. Open a row for what happened and for what would have caught or refused it.

$$292MM Kelp DAO April 2026 released against a cross-chain message that was forged, not sent
What happened

The bridge used a single verifier node to check cross-chain messages before releasing funds. Attackers compromised the RPC endpoints that verifier relied on, fed it a message with no matching burn behind it, and drew 116,500 rsETH out of escrow, roughly eighteen per cent of supply. No contract had a bug.

What answers it

RPC integrity is a named surface here. Independent providers are asked for the same block hash and the same key state reads, and divergence or staleness is itself a critical finding. A verifier reading from endpoints that disagree with the network is the alert, hours before a forged message clears.

It takes more than one wall. An Asset Ratings floor caps a one-of-one verifier outright, whatever else the asset scores, so this configuration is refused at integration rather than discovered at the loss.

OpenZeppelin on the rsETH bridge exploit
$$1.46BB Bybit February 2025 the largest theft on record, in one approved transaction
What happened

A Safe{Wallet} developer's workstation was compromised and tampered JavaScript was uploaded to the bucket serving the wallet interface. Seventeen days later the signers approved what that interface showed them, an ordinary transfer, while the payload sent to their hardware devices carried a delegatecall that replaced the cold wallet's implementation.

What answers it

Two independent checks, either enough. The served bundle changed and its hash no longer matches what was reviewed. And a delegatecall from a Safe is unconditionally critical here, with no model consulted and no threshold to tune, because it is never benign.

NCC Group's technical analysis of the Bybit hack
$$53MM Radiant Capital October 2024 signed off by three of eleven keyholders who were shown something else
What happened

macOS malware on contributor machines displayed legitimate transaction data in the Safe front end while sending different payloads to the hardware wallets for signature. The procedure was followed exactly, on hardware, by people doing their jobs correctly. Malicious contracts were staged on four chains; two executed.

What answers it

A per-signer baseline scores time of day, inter-signature latency, signing velocity, submitting address, gas habit and target novelty, so a coerced or spoofed approval breaks a pattern even when the signature is perfectly valid. The ownership transfer it authorised is separately an unconditional critical.

Halborn on the Radiant Capital hack
1.2M VOTESM VOTES Tornado Cash May 2023 minted out of nothing, against roughly 700,000 real ones
What happened

A proposal presented itself as identical to one the DAO had already approved, but carried an extra function. After the vote passed, the proposal contract was destroyed and redeployed at the same address with different code, granting the attacker 1.2 million votes and complete control of governance.

What answers it

A proposal is judged by what it executes on forked state before the vote closes, not by what its description claims. A payload whose deployed bytecode no longer matches what was reviewed is a critical finding on its own, and the simulated diff reaches voters while voting is still open.

Halborn on the Tornado Cash governance takeover
~$~$120MM BadgerDAO December 2021 taken from roughly 500 wallets that each approved it themselves
What happened

A compromised Cloudflare API key let an attacker inject a script into the application's own front end. The script quietly added an unlimited spend approval for the attacker's address to transactions users were already making. Around 500 wallets signed one.

What answers it

The served JavaScript changed and its hash stopped matching the reviewed bundle, which is a critical finding on the front end your users actually load, alongside DNS records and certificate transparency logs. The class is covered chain-agnostically, because a domain does not care which virtual machine you run.

It takes more than one wall. Live Detection's wallet lane closes the other half: an unlimited approval to a spender first seen minutes ago is blocked at the signing screen, even when the site is already compromised.

Halborn on the BadgerDAO hack

What it builds on.

Shared substrate, not features of this wall. Every layer below is already paid for by the first wall in your scope.

Ops Monitor This wall
Safe, AccessControl, proxy and timelock calldata decoding
fork simulation of every governance payload before the vote closes
grounded language models that explain and prioritise, never decide

How it is operated.

How this wall is run Stated before anything is provisioned

Three layers, always in the same order. Deterministic checks own every critical finding and consult no model. Statistical baselines catch what is unusual for you rather than in general. A language-assisted layer summarises and prioritises, and never sets a severity. That layer can run entirely inside your own network, on your own model.

What turns on when it is in scope.

Individually, or bundled with the walls beside it.

In scope

The full sensing stack

Multisig and signer changes, governance read from calldata rather than from the description, frontend and DNS, and RPC integrity, across every chain you run on

In scope

Routed the way you ask

Telegram, Discord, Slack or PagerDuty, at the severity floor you set, with a simulated diff on every governance payload before the vote closes

It closes the other half of the attack surface. Live Detection sees the chain; Ops Monitor sees the organisation. Together they cover both routes to the same money on one alert channel, and a signer added an hour ago changes how the ladder reads the anomaly that follows it.

Fuga Labs is read-and-attest, never custody-and-execute.
The cardinal ruleEnforced in code across every wall, Ops Monitor included

Put Ops Monitor on your perimeter.

A scoping call maps this wall against what you run and says where it reaches and where it stops. Nothing is provisioned until that is agreed in writing.