Part 2 of a 2-part series on how Fireblocks uses Smart Router to survive extreme network events. Part 1 covered the $TRUMP Solana launch.
A routine Ethereum upgrade took roughly half of Fireblocks' RPC providers offline and left others serving stale data. Smart Router held uptime at 100%. Here's how.
TL;DR
On December 3, 2025, the Ethereum Fusaka hard fork required every node operator to upgrade and resync, and roughly 50% of Fireblocks' Ethereum RPC providers unexpectedly went offline. Others fell behind the chain head and risked serving stale data. Smart Router by Magma Devs routed around the failures automatically and rejected outdated responses, keeping Fireblocks at 100% uptime with accurate, up-to-date on-chain data throughout the upgrade.
The event: a coordinated upgrade with staggered risk
Where the $TRUMP launch was a sudden demand spike, Fusaka was the opposite kind of stress: a planned protocol upgrade that put supply-side reliability at risk.
On December 3, 2025, Ethereum underwent the Fusaka hard fork, a critical upgrade focused on scalability and network efficiency. Fusaka introduced 11 infrastructure improvements, including PeerDAS for scalable data availability, and required every node operator to deploy new client software and resync with the upgraded network. Because providers upgraded across staggered windows rather than all at once, the network passed through a stretch where reliability was uneven from one provider to the next.
What went wrong across the provider layer
During the upgrade, roughly 50% of Fireblocks' Ethereum RPC providers unexpectedly went offline, putting Ethereum services at immediate risk. Losing half your providers to a single event is exactly the kind of correlated failure that overwhelms basic redundancy.
The subtler problem was the providers that stayed up. Several fell behind the chain head: still responding to requests, but at risk of returning stale or inaccurate data. For an institution, that is arguably worse than an outage, because a wrong answer looks like a right one. A client could see an outdated balance or a delayed confirmation and act on it.
How Smart Router held
Smart Router treats "up" and "correct" as two different tests, and Fusaka needed both.
It detected the failing and lagging nodes in real time and routed traffic to healthy providers with up-to-date data and low latency, keeping Fireblocks online even while half its Ethereum providers were unavailable. And because Smart Router tracks the latest known Ethereum block and rejects responses that fall behind it, the lagging providers were quietly screened out. No stale balances, no misleading transaction states reached Fireblocks' systems.
As with the $TRUMP launch, none of this required hands-on intervention from Fireblocks' engineers.
Before and after Smart Router
| During the Fusaka hard fork | Without Smart Router | With Smart Router |
|---|---|---|
| ~50% of Ethereum providers offline | Ethereum services at immediate risk | 100% uptime maintained |
| Failover to healthy providers | Manual, too slow for a live upgrade | Automatic, real-time rerouting |
| Lagging or out-of-sync nodes | Stale balances and delayed confirmations reach clients | Stale responses rejected via latest-block tracking |
| Data accuracy during the upgrade | Uncertain, provider by provider | Accurate, up-to-date for every client |
| Engineer intervention | Hands-on monitoring and manual switching | None required |
Why "up" is not enough
Fusaka is a useful reminder that reliability at institutional scale is about correctness, not just availability. A provider can be online and still be wrong, and single-provider or hand-balanced setups have no way to tell the difference.
"Financial institutions are moving into digital assets today. It's not a future mission. When they're that deeply involved, they can't afford mistakes or downtime. If your access to the blockchain is down, that's not a dev-team problem. It's a business problem."
Routine network upgrades will keep happening, and each one is a scheduled opportunity for provider reliability to fragment. Smart Router is built so those events pass without customers ever noticing: resilient by default, adaptive under stress, and reliable when it matters most.
Start of the series: how the same layer handled a sudden 1,000% traffic spike. Read Part 1: the $TRUMP Solana launch →
How exposed is your RPC stack?
Take the 2-minute Secure RPC Assessment and get a personalized risk report.
Run the assessment