Close RPC security gaps
before attackers find them.
Set flexible security policies based on the value and risk of each operation, and enforce cross-validation and cryptographic proofs to protect against malicious RPC attacks.
RPC is a critical attack surface
RPC is your app's source of truth. If it's compromised, everything downstream is at risk: transactions, balances, contract state. That's why attackers target it.
RPC isn't reliable by default
RPC providers can be compromised and you won't even know. Treat every RPC response as untrusted input.
Simple quorum is not enough
Multiple RPCs can be manipulated simultaneously, and a simple quorum can agree on the wrong answer.
Security vs. flexibility
Overly rigid security creates unnecessary complexity, hurting the end user experience.
Built-in protection at the RPC layer
Cross-provider validation
RPC responses are validated across independent providers before anything goes downstream.
Mixed-source quorum
Quorum isn't just about count. Define independent provider groups that must agree before a response is approved.
Policy-based protection
Define security policy per operation, matched to its value and risk. High-stakes calls get stricter validation than low-risk ones.
The $292M KelpDAO exploit was an RPC data-poisoning attack: the failure mode that becomes possible when infrastructure trusts a single validator or RPC. Cross-provider consensus catches a lying or compromised provider before its data reaches you.
Freshness checks catch out-of-sync providers before the request; consensus catches wrong answers after they return. Run both.
Talk to us.
Take 2 minutes to get a view of where you stand against RPC attacks.