Methodology

What we track

web3radar maintains two data streams in parallel, deliberately kept separate so chain-level totals stay clean:

Security incidents

Hacks, exploits, and protocol losses affecting a chain or a protocol on it. Sourced primarily from DefiLlama's hacks API and Rekt.news, normalized into a single editorial schema, and attributed to a specific chain.

Staking events

Validator-level occurrences that affect delegators: jailings, double-signs, tombstones, commission changes, and uptime warnings. Detected by polling each chain's native interfaces (Cosmos LCD; Ethereum beacon-chain API).

Sources

• DefiLlama Hacks API — incident base layer for losses, recovery, and attribution.
• Rekt.news — editorial post-mortems flagged for human review.
• Cosmos LCDs —/cosmos/slashing/v1beta1/signing_infos and /cosmos/staking/v1beta1/validators for slashing detection and commission tracking.
• Ethereum beacon-chain API — proposer + attester slashings via beaconcha.in.

Per-chain source endpoints are listed on each detector status row.

Cadence

Incident ingestion (DefiLlama, Rekt)

Every 15 minutes

Cosmos slashing detector

Every 15 minutes

Ethereum beacon slashing detector

Every 15 minutes

Cosmos validator performance

Once per UTC day

Portfolio refresh

Once per UTC day

Live freshness per detector: /status.

Editorial process

1. Detectors and ingestion adapters write rows as DRAFT — never directly published.
2. A named human editor reviews each DRAFT (typically via the editorial review channel) and either publishes, edits, or retracts.
3. On publish, alert dispatch fires to subscribers and the row becomes part of the public dataset.
4. Every status transition is recorded in an append-only audit log with actor, timestamp, and IP hash.

We do not auto-publish. The detector flags; a human decides.

Independence

web3radar is an editorially independent intelligence desk, founded and backed by Stakecito — a validator team operating on several of the chains web3radar covers. We are explicit about this because it would otherwise be a conflict of interest. Two structural controls:

• Stakecito's own validator footprint is published live on /stakecito-validator — operator addresses, commission, voting power, jail status. You can verify it on the chain itself.
• Editorial decisions about Stakecito-operated chains follow the same DRAFT → review → publish flow as every other chain, and the audit log captures who decided what.

Corrections

If a chain foundation, protocol team, or community member identifies an error in the public dataset, we want to know. Each chain report links to /contact for that purpose. Reasoned objections get a written response and, where warranted, a retraction or revision recorded in the audit log.

Limitations

Public LCD endpoints occasionally outage; when every endpoint we try fails, the relevant data point is held at its previous value rather than zeroed out. Counts are not weighted by stake — interpret as frequency of events, not dollars at risk. New chains have less historical depth than older ones; the monitoringStartedAt date on each report is the floor.