Security teams frequently discover, after the fact, that the evidence of an attack was visible for hours or days before funds were actually lost. A wallet approval was granted to an unfamiliar contract, a governance proposal with unusual permissions was submitted, a node began responding to RPC queries in a pattern that did not match normal usage. None of this is exotic or hard to detect in principle. The recurring failure is architectural: these signals live in blockchain-native data sources that most crypto logging and SIEM deployments were never built to ingest, so they sit unmonitored in a block explorer or a node's local log file while the organisation's actual security operations centre watches a dashboard that has no visibility into them.
This guide addresses the layer of Web3 security logging that general SIEM guidance does not cover: on-chain event monitoring, node and RPC log sources, hardware security module audit trails, and the practical mechanics of getting blockchain-native signals into a traditional SIEM with alert thresholds that produce action rather than noise.
The Web3 Logging Gap: What Traditional SIEMs Miss
A conventional SIEM deployment ingests logs from firewalls, endpoints, identity providers, cloud infrastructure and applications. For a crypto or DeFi organisation, this covers perhaps half of the attack surface that actually matters. The other half exists on-chain and in blockchain infrastructure that speaks a different protocol language entirely: JSON-RPC calls, smart contract event logs, mempool data and consensus-layer peer traffic. None of this arrives at a SIEM unless someone builds the pipeline to extract it.
The consequence is a structural blind spot. Security teams can tell you within seconds if an employee's laptop connects to a suspicious IP address, but many cannot tell you within minutes that a proxy admin contract just executed an upgrade, or that a treasury wallet just granted an unlimited token approval to an address created an hour earlier. Both events are equally detectable in principle. Only one of them is typically being watched.
Why this gap persists
Part of the reason is organisational: SIEM ownership usually sits with a security operations function built around traditional infrastructure, while on-chain monitoring, where it exists at all, is often owned by a separate blockchain or protocol engineering team using entirely different tools such as Dune dashboards or custom scripts. These two monitoring worlds rarely share an alerting pipeline, which means a genuine threat detected by one team's tooling may never reach the incident response process the other team actually follows.
Most crypto hacks leave forensic evidence on-chain before the funds ever move. The problem is rarely that the signal was absent, it is that no monitoring architecture existed to notice it in real time.
On-Chain Event Monitoring: What to Watch and How to Alert
On-chain monitoring should be organised around a small number of high-signal event categories rather than an attempt to log every transaction indiscriminately, which produces unmanageable volume without improving detection.
Large value transfers and whale alerts
Monitor transfers above a defined threshold from any address the organisation controls, and from any address known to hold significant protocol reserves if you operate a DeFi platform. Thresholds should be set relative to normal operational transaction sizes, not as a flat figure, since a threshold appropriate for a small treasury will be meaningless noise for a large one and vice versa.
Governance proposal submissions
Any new governance proposal, particularly one affecting protocol parameters, treasury allocation, or contract upgrade permissions, should generate an immediate alert to the security team, independent of whatever notice period the governance process itself provides. Malicious or coercive proposals have been used as an attack vector in their own right, and early visibility gives the team time to assess intent before a vote concludes.
Contract upgrade transactions
Proxy admin calls and other upgrade transactions represent one of the highest-impact event categories to monitor, since a malicious upgrade can silently redirect all future contract logic, exactly the mechanism exploited in the frontend and signing compromise that led to the Bybit loss. Every upgrade transaction from an admin address should trigger a real-time alert and, ideally, require out-of-band confirmation before being treated as legitimate.
Liquidity pool drain patterns
Rapid, sequential withdrawals from a liquidity pool, particularly when paired with unusual price impact, are a strong signal of an active exploit in progress. Detection logic here should focus on rate of change rather than absolute values, since a legitimate large withdrawal looks structurally different from an automated draining pattern executed across multiple transactions in a short window.
New contract deployments from admin addresses
Any new contract deployed from an address holding administrative privileges over existing protocol infrastructure warrants review, since this pattern frequently precedes the introduction of a malicious replacement contract or an unauthorised extension of system functionality.
Node and RPC Endpoint Log Sources for Web3 Infrastructure
Organisations running their own blockchain nodes, or relying heavily on third-party RPC providers, have an additional log layer that sits below the application and smart contract level and is frequently ignored entirely.
RPC rate limits and unusual query patterns
Capture logs of RPC request volume, source, and method type. A sudden spike in calls to methods associated with mempool inspection or transaction simulation can indicate reconnaissance ahead of a front-running or exploit attempt, and sustained rate-limit breaches from a single client may indicate automated scanning against your infrastructure specifically rather than general network traffic.
Peer connection anomalies
For self-hosted nodes, monitor peer connection churn, unexpected peer geography concentration, and repeated connection attempts from addresses associated with known malicious infrastructure. Anomalous peer behaviour has been used in eclipse-style attacks intended to isolate a node from the honest network and feed it manipulated chain data.
Memory pool manipulation indicators
Where visibility into mempool contents is available, log patterns consistent with sandwich attacks or transaction replacement targeting your own pending transactions. This is particularly relevant for organisations executing large trades or liquidity operations, where mempool-based front-running can represent a direct and repeated financial loss even without any breach of the organisation's own systems.
Third-party RPC provider logs
Firms that do not run their own nodes still need visibility into query logs, rate limit events, and response anomalies from their RPC provider, since a compromised or manipulated RPC response can feed incorrect data into monitoring dashboards, trading systems or transaction construction logic, effectively blinding downstream security controls without ever touching the organisation's own infrastructure.
HSM and Key Usage Audit Logs: The Forensic Foundation
Hardware security modules are frequently treated as a trusted black box once deployed, which means the most sensitive event category in the entire security stack, actual key usage, often receives the least monitoring attention of any log source in the organisation.
Key access events
Every signing operation, key export attempt, and key derivation event should be logged with full context: which key, which operator or service account, what was signed, and from what originating system. This log becomes the single most important forensic artefact in any incident involving a compromised transaction, since it is the definitive record of what the key material actually did, independent of what any application layer claimed was happening.
Failed authentication attempts
Repeated failed authentication against an HSM, particularly outside of normal operational hours or from an unexpected source, is a strong indicator of an active attempt to compromise key material and should be treated as a high-priority alert rather than a routine security log entry.
Administrative actions
Changes to key policies, quorum requirements, access control lists, or user permissions on the HSM should generate alerts to a distribution list wider than the individual making the change, following the same principle of independent verification that applies to multisig transaction approval. No single administrator should be able to silently weaken key protection controls.
Firmware updates
HSM firmware updates should be logged, scheduled, and verified against vendor-issued checksums before application, with the update event itself feeding into the SIEM as a change record. An unscheduled or unverified firmware update is a plausible vector for a sophisticated supply chain compromise and should never pass unnoticed through routine maintenance logs.
Integrating Smart Contract Events Into Your SIEM
Getting the on-chain and infrastructure log sources described above into a usable SIEM pipeline is primarily an engineering problem, and there are three practical approaches organisations commonly combine.
Custom log shippers for JSON-RPC data
A lightweight service can poll or subscribe to a node's JSON-RPC interface, filter for the event categories defined in your monitoring strategy, normalise the output into a structured format, and forward it to the SIEM using a standard log shipper. This approach gives the most control over exactly what is captured but requires ongoing engineering maintenance as contract addresses and event signatures change.
Indexing services for contract events
Services such as The Graph provide indexed, queryable access to historical and near-real-time smart contract events without requiring the organisation to run and maintain its own indexing infrastructure. Query results can be polled on a schedule and fed into the SIEM as structured events, which is often a faster path to coverage than building custom indexing from scratch, particularly for organisations monitoring contracts they do not control directly.
Forta Network alert integration
Forta operates a decentralised network of detection bots that continuously scan transactions for known exploit patterns, unusual approval activity, and governance anomalies across a wide range of protocols. Forta alerts can be consumed via webhook and piped directly into the SIEM as an additional structured log source, giving security teams the benefit of community-sourced detection logic alongside their own custom rules, without needing to replicate that detection capability internally.
Correlation with off-chain identity
The real value of integration comes from correlating on-chain events with off-chain identity and access data already in the SIEM. An alert that simply says "large transfer detected" is far less actionable than one that says "large transfer detected, initiated by a signing key accessed sixty seconds after an anomalous HSM authentication attempt from an unrecognised device." Building this correlation logic should be treated as a priority engineering task, not an optional enhancement.
Alert Thresholds and Tuning for Web3 Security Operations
The volume of raw on-chain and infrastructure data available is enormous, and a monitoring programme that alerts on everything will produce the same outcome as one that monitors nothing: real signals lost in noise. Deliberate tiering is essential.
Tier one: page a human immediately
Reserve immediate, out-of-hours paging for events with high financial or operational impact and low false-positive likelihood: contract upgrade transactions from admin addresses, large transfers from treasury-controlled wallets to unrecognised addresses, HSM administrative changes, and governance proposals affecting privileged roles or treasury control.
Tier two: alert during business hours, review within the shift
Events such as moderate-value transfers to known but infrequently used counterparties, RPC rate-limit breaches from recognised but unusual sources, and repeated failed authentication attempts that do not meet the tier-one threshold can be queued for review within the operating shift rather than triggering an immediate page.
Tier three: log for retrospective analysis
Routine transaction volume, expected governance activity, and normal peer connection churn should be logged in full for forensic and trend-analysis purposes but should not generate any active alert. This tier exists to preserve the evidence trail without contributing to alert fatigue.
Tune continuously against known-good baselines
Thresholds set at launch will drift out of relevance as transaction volume, treasury size and operational patterns change. Review and retune alert thresholds on a quarterly basis at minimum, using the previous period's confirmed false positives and any missed incidents as the primary input for adjustment.
From SIEM Alert to Incident Response: The Web3 Workflow
An alert that does not connect to a defined response workflow provides little practical value beyond documentation. Web3-specific alerts need response playbooks that reflect the irreversibility of on-chain action.
Immediate containment options
For tier-one alerts involving active fund movement, the response playbook should specify, in advance, what containment actions are actually available: pausing a contract if a pause function exists, revoking specific approvals, alerting exchange partners to flag incoming funds from a known malicious address, and notifying any multisig co-signers to withhold further approvals. These options should be pre-documented rather than improvised during an active incident, consistent with a broader incident response plan.
Escalation to the security operations centre
On-chain alerts should route into the same escalation structure as any other security event, reaching the security operations centre rather than a separate, informally staffed blockchain monitoring channel. Fragmented escalation paths are one of the most common reasons a detected signal fails to trigger a timely response.
Cross-referencing threat intelligence
When an alert fires, the response workflow should automatically check the involved addresses against current blockchain threat intelligence feeds to determine whether the counterparty is already flagged as associated with known exploit infrastructure or laundering activity, which materially changes both the urgency and the appropriate response.
Post-incident log preservation
Following any tier-one alert, whether it resolves as a genuine incident or a false positive, preserve the full log set, on-chain data, RPC logs, HSM audit trail and SIEM correlation output, in an immutable archive. This record is essential both for post-incident review and for demonstrating control effectiveness to auditors, insurers and institutional counterparties, and it depends on the underlying node infrastructure being properly secured in the first place, which is covered in our guide to blockchain node security.
Frequently Asked Questions
Can a traditional SIEM ingest on-chain blockchain events?
Yes, but not natively. Traditional SIEM platforms are built around syslog, JSON and API-based log sources, so on-chain events need to be extracted first, typically through a node's JSON-RPC interface, an indexing service such as The Graph, or a monitoring network such as Forta, then normalised and shipped into the SIEM as structured events.
What is the most commonly missed log source in Web3 security operations?
HSM and key management audit logs are the most commonly missed source. Many organisations log application and infrastructure activity thoroughly but treat the hardware security module as a trusted black box, which means the most sensitive events in the entire system, key access and administrative actions, often go unmonitored.
How do you avoid alert fatigue when monitoring on-chain activity?
Tier alerts by financial and operational impact rather than treating every on-chain event as equally urgent. Large transfers from known treasury addresses, contract upgrade transactions and governance proposals affecting privileged roles should page a human immediately, while routine transaction volume and known counterparties should be logged for retrospective analysis rather than triggering real-time alerts.
What is Forta Network and how does it fit into a Web3 SIEM strategy?
Forta is a decentralised network of bots that monitor blockchain transactions in real time for suspicious patterns such as exploit signatures, unusual approvals and governance anomalies. Its alerts can be piped into a SIEM as an additional structured log source, giving security teams community-sourced threat detection alongside their own custom on-chain monitoring rules.
Do RPC endpoint logs matter if a firm does not run its own blockchain node?
Yes. Firms relying on third-party RPC providers should still capture and review query logs, rate limit events and response anomalies from those providers, since manipulated or delayed RPC responses have been used to obscure malicious activity or feed incorrect data to monitoring systems and trading logic.