Six Questions to Ask Before Your RPC Fails You

Target audience: Intermediate · 5 min read

TL;DR

• Most DeFi systems take whatever their RPC endpoints return and act on it.
• That's how an audited bridge lost about $292M in April 2026, and no contract bug has been identified.
• We turned the questions we keep asking teams into a two-page checklist. You can answer every one of them without touching code.
• If it turns out you're trusting your providers, the fix is proofs anchored to independently verified headers, plus a quorum, not just more providers.

1. The Part Nobody Audits

Hardly anyone ships a DeFi protocol without an audit anymore. Good. But ask a team where their prices, balances or cross-chain messages actually come from, and you usually get a provider name and a shrug. The data comes in through an RPC endpoint, and the contract believes it.

KelpDAO is the example everyone knows by now: two poisoned RPC nodes, a DDoS against the rest, one forged message, roughly $292M gone. I won't retell it here, we did that in the post-mortem. What bothers me more is that none of this was new. In November 2020, Infura ended up on a minority chain after a consensus bug, and its mainnet API was down for about six and a half hours. In March 2022, Infura applied sanctions settings more broadly than intended, and MetaMask users in Venezuela lost access for several hours. Later that year, Consensys disclosed that Infura, MetaMask's default RPC provider, collects IP and wallet addresses when users send transactions. Different failures, same root cause: one provider, taken on faith.

So for my talk in Mumbai we wrote down the questions we end up asking in almost every architecture review. Here's what made the list, and why.

Audited code acting on unverified data is an unaudited system.

2. Four Questions for Protocol Architects

How many independent sources stand behind each critical read?

"We have three endpoints" sounds like redundancy. If all three belong to the same provider, or sit in the same cloud region, it's one source with three URLs. Write down every read that can move value (prices, balances, cross-chain messages, finality), and next to each one the operator, cloud and region behind it. Anything that shares an operator or a cloud counts as one. Most teams I've done this exercise with didn't like the result.

Is any response verified, or only trusted?

In most stacks, eth_call and eth_getLogs come back and get used as they are. You can do better: check each response against Merkle proofs anchored to a block header your system verified against consensus. For state, that means account and storage proofs from eth_getProof; for logs, receipt proofs. There are two traps, though. If the header comes from the same RPC endpoint as the data, you've proven nothing. And if a failed proof just writes a warning to a log file, you haven't really verified anything either. It has to stop the action.

What happens when sources disagree or disappear?

This is the one teams skip, and it's the one that mattered at KelpDAO. If the first answer wins, or the system quietly falls back to whatever is still reachable, an attacker doesn't have to compromise every source. Knocking the honest ones offline is enough. What you want instead: disagreement pauses the action and pages someone, and failover never drops below a quorum you've actually written down. Then go and test it. Take endpoints offline one at a time in staging and watch what the system does. And alert on every failover, not only on full outages.

How concentrated is your provider and jurisdiction exposure?

If one company, one cloud or one jurisdiction serves most of your reads, its outages, its compliance decisions and its logs are effectively yours. Don't forget the wallet defaults your users bring along. Map all of it, read each provider's logging and retention policy (yes, actually read it), and make switching providers a config change. If it takes a deploy, you'll be shipping a release in the middle of an incident.

If switching providers needs a deploy, your incident response starts with a release cycle.

3. Two Gaps for Monitoring and Tooling Providers

The second page is for the people building security monitoring. You're watching the right chain, just one layer too high.

Response integrity

Anomaly detection looks at transactions. Nobody looks at what each component was told by its RPC provider, and from the transaction side KelpDAO looked like ordinary bridge traffic. To catch that kind of attack, you'd have to compare what a component acted on with independently verified state, seen from somewhere an attacker can't reach or poison. Cross-chain invariants like burns against releases are still worth having. Just keep in mind they fire after the money has left.

Concentration

Ask a protocol team what share of their reads goes through a single provider and most can't tell you. There's no dashboard for it, and failover usually happens without anyone noticing. Good tooling would track RPC dependencies per component, alert on failover and lost quorum, and treat an attack on one provider as an alarm for everyone who relies on it.

4. Verify Instead of Trust

Once you know where the trust sits, there are basically three things you can do about it.

1. Use state proofs. eth_getProof (EIP-1186) gives you Merkle proofs for account and storage values; receipt proofs cover events, and transaction proofs cover transaction inclusion.
2. Anchor to consensus on your own. Check block headers against the beacon chain sync committee with a light client, not against the endpoint that sent you the data.
3. Run a real quorum. Independent operators, a defined threshold, no silent failover. That handles outages and most censorship. It doesn't make any single source trustworthy, though.

A light client gets you the first two in one place, as long as it verifies every response it passes on. We build one at Corpus.Core, colibri.stateless, which checks RPC responses against proofs (repository). It's not the only option, and the checklist works whatever you end up using.

Your contracts verify signatures. Who verifies the data?

5. Get the Checklist

Everything above fits on two pages, together with a table of the four RPC failures I mentioned and the sources behind them. It's CC BY 4.0, so take it into your next architecture review, cut it down to what fits your stack, or forward it to your monitoring vendor.

Download the checklist (PDF)

I'll go through it on stage at the DeFi Security Summit in Mumbai on 2 November. And if you find a gap we missed, I'd honestly like to hear about it: @CorpusCoreHQ.