You manage a DeFi protocol deployed on Ethereum, Arbitrum, and Base. Funds move across bridges, and events in one network affect another. A delay in anomaly detection can cost millions — recall the Wormhole attack ($326M) or Ronin ($610M). There are no off-the-shelf solutions for cross-chain correlation — each protocol requires a custom architecture. Over 5 years, we have set up monitoring for 15+ DeFi protocols, processing up to 10,000 events per second with less than 1 second latency and guaranteed 99.9% uptime. Source: ERC-20 Token Standard Our certified team delivers a solution within 4–6 weeks, with setup costs typically ranging from $15,000 to $30,000 depending on complexity. Clients typically see a 50% reduction in critical incident response time, saving up to 40% on incident-related costs. Contact us to discuss your architecture.
How to Organize Smart Contract Monitoring Across Multiple Networks?
Data Sources — Monitoring System Development
RPC nodes — direct calls to EVM nodes via WebSocket for real-time events. Each network needs a reliable RPC with support for eth_subscribe:
const provider = new ethers.WebSocketProvider(RPC_WS_URL);
const contract = new ethers.Contract(address, abi, provider);
contract.on('Transfer', (from, to, value, event) => {
emitEvent({
network: 'arbitrum',
block: event.log.blockNumber,
txHash: event.log.transactionHash,
type: 'Transfer',
data: { from, to, value }
});
});
Problem with a single RPC: public nodes are unreliable, they miss events under high load. Solution: at least 2 independent providers per network (Alchemy + QuickNode, or your own node). Deduplication of events by (chainId, txHash, logIndex).
The Graph / Subgraph — for historical data and complex queries. A mediation layer on top of raw RPC. Latency is 1–3 blocks, but ideal for analytical queries and cross-network balance reconciliation.
| Network | Block time | Recommended RPC | Finality |
|---|---|---|---|
| Ethereum | ~12 sec | Alchemy/Infura | ~64 blocks (~13 min) |
| Arbitrum One | ~0.25 sec | Arbitrum RPC / Alchemy | L1 finality |
| Polygon PoS | ~2 sec | Polygon RPC / QuickNode | ~256 blocks |
| Base | ~2 sec | Base RPC / Alchemy | L1 finality |
| Optimism | ~2 sec | Optimism RPC / Alchemy | L1 finality |
| BNB Chain | ~3 sec | BSC RPC / NodeReal | ~75 blocks |
Event Processing Pipeline
Raw events cannot be analyzed directly — they need normalization and enrichment:
RPC Listener → Message Queue (Kafka/Redis Streams) → Event Processor → Alert Engine → Notification
↓
Time-series DB (InfluxDB/TimescaleDB)
↓
Analytics Dashboard
Event Processing Pipeline is the key element. Message Queue buffers spikes. During sudden spikes in on-chain activity (e.g., large liquidation cascades), events can arrive faster than they can be processed. Kafka with 24h retention allows replay if the processor crashes.
Event Processor — normalizes events from different networks into a unified format, decodes ABI, enriches (token prices, account metadata), and detects anomalies.
Alert Engine — rules applied to normalized events. Stateful rules require a state store (Redis). Example rules:
class LargeTransferAlert(AlertRule):
def evaluate(self, event: NormalizedEvent) -> Optional[Alert]:
if event.type != 'Transfer':
return None
usd_value = event.data['value'] * get_token_price(event.data['token'])
threshold = self.get_dynamic_threshold(
token=event.data['token'],
window='24h',
multiplier=10.0
)
if usd_value > threshold:
return Alert(
severity='HIGH',
message=f'Large transfer: ${usd_value:,.0f} on {event.network}',
context=event
)
Cross-Chain Correlation
Cross-Chain Correlation is the most valuable feature for multi-network protocols. It links events between networks. Typical scenarios:
Bridge monitoring — a token is locked on Ethereum, should appear on Arbitrum. If it does not appear within N minutes, an alert is triggered. This requires a correlation engine:
class BridgeCorrelator:
def __init__(self, redis_client):
self.pending = {}
def on_bridge_initiated(self, event):
key = f"bridge:{event.src_chain}:{event.tx_hash}"
self.redis.setex(key, 3600, json.dumps(event.to_dict()))
def on_bridge_completed(self, event):
key = f"bridge:{event.src_chain}:{event.bridge_nonce}"
pending = self.redis.get(key)
if not pending:
alert(f"Bridge completion without initiation: {event}")
return
initiation = json.loads(pending)
latency = event.timestamp - initiation['timestamp']
if latency > EXPECTED_BRIDGE_LATENCY[event.bridge_protocol]:
alert(f"Bridge latency anomaly: {latency}s")
TVL consistency check — total TVL on L2s should not exceed the locked amount on L1. Periodic check via subgraph queries with an alert if discrepancy > 5%.
Example of cross-chain correlation implementation
For bridge monitoring, we use a correlator on Redis: on initiation, we store the event for one hour; on completion, we check the timeout. If the time exceeds the expected (e.g., 30 minutes for Arbitrum bridge), we generate an alert. This approach allows detecting stuck transactions before the user panics.Which Smart Contract Events to Monitor First?
Security-critical events — those that must not be missed:
- Ownership transfers — on any protocol contract
- Upgrade proposals — events from Timelock (new proposals, execution)
- Large withdrawals — withdrawal > 5% of TVL over a short period
- Flash loan usage — obtaining a flash loan + interacting with the protocol contract in the same tx
- Oracle price deviations — protocol price deviating from market by > 3%
- Pause events — someone pauses the contract
Operational Metrics
- Gas usage anomalies (sharp increase may indicate inefficient execution or an attack)
- Failed transactions share (increase in failed tx for a router may indicate a UI/API bug)
- Block inclusion latency for own transactions (keeper bots, liquidation bots)
Business Metrics
- TVL dynamics per network
- Volume per network
- Unique active addresses
- Protocol revenue (fees collected)
How to Choose Between OpenZeppelin Defender, Tenderly, and Custom Development?
Ready-made services provide a quick start, but cross-chain correlation is weak. Comparison:
| Approach | Advantages | Limitations |
|---|---|---|
| OpenZeppelin Defender | Quick start, built-in networks | Weak cross-chain correlation |
| Tenderly | Excellent dev environment, visualization | Not suitable for production under high load |
| Custom system | Full control, flexibility | Development time 4-6 weeks |
We recommend a combination: use Tenderly for operational monitoring of dev environment, Defender for basic production monitoring, and a custom layer for cross-chain correlation and specific rules.
Stack for a custom system:
- Event ingestion: Node.js + ethers.js WebSocket listeners
- Message queue: Redis Streams (for smaller projects) or Kafka (for high load)
- Storage: TimescaleDB for time-series, PostgreSQL for event metadata
- Alert rules: Python with rule engine
- Notifications: PagerDuty/OpsGenie for critical, Telegram/Discord for operational
- Dashboard: Grafana on TimescaleDB
Monitoring Development Process: From Audit to Deployment
- Audit of current infrastructure and requirements gathering — 1-2 days.
- Architecture design considering networks and load — 2-4 days.
- Setup of RPC, subgraph, and message queue.
- Development of custom alert rules and cross-chain correlation.
- Integration with notification systems (PagerDuty, Telegram, Discord).
- Documentation and team training.
- Post-launch support (optional).
What Is Included in the Work
- Complete documentation of architecture and alert rules.
- Source code for handlers and correlators.
- Integration with your infrastructure (RPC, bridges, contracts).
- Team training on dashboards and alert response.
- Technical support for up to 3 months after launch.
- Priority access to our support team via dedicated Slack channel.
Automatic Response to Alerts
Monitoring without automatic response is only half the system. We configure OpenZeppelin Defender Autotask or a custom keeper bot:
- Anomalously large withdrawal > 5% of TVL → automatic contract pause (if pauser is set to keeper).
- Oracle deviation > 3% → switch to fallback oracle.
- Bridge stuck > 2 hours → notify bridge operator + create ticket.
Automatic response requires thorough auditing of the keeper bot itself. We ensure reliability and provide security certificates for our solutions. Get a consultation on monitoring your protocol — we will assess complexity and timeline within 1 day. Contact us to discuss your project.
Frequently Asked Questions
Which networks are supported in the monitoring system?
We connect any EVM-compatible networks: Ethereum, Arbitrum, Polygon, Optimism, Base, BNB Chain, Avalanche, and others. For each network, we configure reliable RPC and block finality settings.
How does the system handle high event load?
We use a message queue (Kafka or Redis Streams) to buffer peak loads. During sudden spikes in on-chain activity, such as large liquidations, all events are stored and processed asynchronously.
Can we integrate existing solutions like OpenZeppelin Defender?
Yes, we use ready-made services (Tenderly, Defender) for basic monitoring and layer custom logic for cross-chain correlation and specific business rules.
Which alerts are considered critical?
Critical alerts include: unauthorized transfer of ownership, execution of upgrade proposals, large TVL discrepancy between L1 and L2, anomalous oracle prices, and stuck bridge transactions.
Does the system include automatic response to alerts?
Yes, we configure automatic actions: contract pausing on anomalies, oracle switching, ticket creation. All keeper bots undergo security audits.