eRPC vs. Magma Devs Smart Router: A Proxy You Operate vs. Infrastructure You Can Defend in a Security Review

eRPC is a well-built EVM proxy your team operates. Smart Router is chain-agnostic infrastructure with validation on the transaction path, and the audit evidence to clear an institutional security review.

Here's the short version: eRPC is an EVM proxy your team runs and tunes. Smart Router is the layer an institution can put in production and defend in front of its security team, its auditors, and its customers.

Let's start by being fair, because eRPC deserves it: it's a genuinely good piece of software. An open-source (Apache 2.0) fault-tolerant EVM RPC proxy maintained by the team at Goldsky, with retries, hedging, circuit breakers, consensus checks across upstreams, reorg-aware permanent caching, and Grafana-ready observability. Teams like Polymarket, Dune, and Moonwell run it in front of their providers, and for read-heavy, indexing-style workloads it's one of the best DIY answers available.

So if both products do failover, hedging, caching, and even cross-upstream consensus, is this comparison just taste? No. The differences are in three places a feature checklist doesn't show: what chains it covers, what workloads the validation is designed for, and who stands behind it when it's in your critical path. For a hobby indexer those barely matter. For a custodian or exchange, they're the entire decision.

Same feature names, different design centers

eRPC's design center is the EVM read path. It's built to make high-volume reads cheap, fast, and consistent: dedupe in-flight requests, serve from a reorg-aware cache, hedge slow upstreams, use consensus to catch a provider that's lagging or misbehaving, and prefer cheap nodes until they degrade. That's exactly what an indexing or data workload wants, and it shows in who uses it.

Smart Router's design center is the institutional transaction path. The question it's built around is: what does it take for an exchange or custodian to act on chain data, and broadcast transactions, without any single provider's answer becoming a point of failure or attack? That produces a different shape of product:

Chain-agnostic, not EVM-only. eRPC covers every EVM chain, and only EVM. Smart Router orchestrates EVM and non-EVM alike: Solana, Cosmos, Bitcoin-family, and more, across JSON-RPC, REST, gRPC, Tendermint, and WebSocket. Institutional platforms are multi-chain by definition; Fireblocks runs Smart Router across 100+ chains, Kraken across 130+ networks. An EVM proxy solves one slice of that surface, and the remaining slices are where you'd be back to glue code.

Validation where the money moves. Both products can compare responses across upstreams. Smart Router's cross-validation is policy-based and built for the calls where a wrong answer costs real money: quorum requirements per method, validation against your own on-prem nodes as an independent source of truth, and real-time isolation of upstreams that return stale or malicious data, the class of attack behind the $292M KelpDAO exploit. Writes get fanned out across eligible upstreams in parallel to maximize transaction success, with the same scrutiny on what comes back.

Self-hosted doesn't have to mean self-supported. Both products deploy the same way institutions want: inside your own infrastructure, on your own nodes and providers, with nothing routing through anyone else's cloud. Smart Router is open source and built for exactly that: most of its institutional deployments run self-hosted, in the customer's own trust domain. The difference is what stands behind the deployment. eRPC is Apache 2.0 software: you operate it, tune it, and own the 3 a.m. page, with community support. (Goldsky's managed offering, Cloud Edge, wraps eRPC, but that's an endpoint product, a different architecture conversation.) A self-hosted Smart Router comes with a company behind it: enterprise SLAs, onboarding, custom integrations, and dedicated support. You keep full control of the infrastructure without becoming the vendor of it. When the RPC layer sits in the critical path of a platform holding customer assets, "who do we call, and what did they commit to" is not a soft requirement.

The security-review test

Here's the practical filter for this comparison. At some point, your RPC layer will be an item in a vendor risk review, yours or your customers'. The review asks questions software licenses don't answer: Who attests to the security of this component? What's the SLA? Where's the DPA? Who's accountable for patching, incident response, and support?

For a self-operated OSS proxy, the honest answer to all of those is "we are." That can be acceptable, if your team has budgeted the headcount to be the vendor, permanently. It's the same trade-off as any build-vs-buy decision on RPC infrastructure, shifted one notch: you didn't write the proxy, but you own everything around it.

Smart Router ships the answers, including when you self-host it: SOC 2 Type II, audited by PwC with zero exceptions noted, ISO 27001 certification, a DPA available today, a full security package, and an enterprise support SLA. Your security review becomes a document exchange instead of a project, and the software still runs entirely in your own infrastructure.

Side-by-side

Which one do you actually need?

If you're an engineering team with an EVM-only, read-heavy workload (indexing, analytics, a data pipeline) and you're comfortable operating your own infrastructure, eRPC is a strong choice. We mean that without hedging; it's well-built software solving the problem it set out to solve.

If you're an institution whose application acts on chain data across many networks (custody, trading, settlement, threat detection), the calculus changes. You need non-EVM coverage without a second stack, validation designed for the calls that move money, and a vendor whose certifications and SLAs your risk team can file rather than replicate, while the software itself runs self-hosted in your own infrastructure, exactly where you'd have put eRPC. Kraken, Fireblocks, Galaxy, and Hypernative made that calculation; Smart Router is what it points to.

The two aren't enemies so much as different answers to differently-sized problems. One is a proxy. The other is the infrastructure an institution runs its chain access through.

The bottom line

eRPC keeps EVM reads fast, cheap, and consistent for teams willing to operate it themselves. Smart Router keeps an institution online and its data provably correct across every chain it touches, self-hosted in your own infrastructure if that's your model, with a company, an SLA, and a PwC-audited SOC 2 Type II report behind it either way. Pick based on which of those sentences describes your risk.