On July 31, 2026, Moonbeam — once one of Polkadot's flagship EVM parachains — officially ceased operations. GLMR migrated 1:1 to an ERC-20 on Base, the team pivoted to a new project, and the chain wound down. We watched it happen from the infrastructure side: block production stopped, the chain's tip froze, and one by one, public RPC endpoints started returning nothing at all. Yesterday we removed Moonbeam and Moonriver from our own chain list.
Chain deaths used to be hypothetical. In 2026 alone we've now handled three, and they turn out to follow three distinct patterns — each of which breaks running code in a different way. If you build on smaller chains (and everything outside the top ten is a "smaller chain" for this purpose), it's worth knowing all three.
Pattern 1: Full shutdown (Moonbeam)
The chain simply stops. Moonbeam's pattern: an announcement with a deadline, a migration bridge for the native token (GLMR → ERC-20 on Base, open until the cutoff), an urgent window for users to withdraw from on-chain protocols, and then — nothing. Block production halts. When we probed it, the latest block was two weeks old and frozen; a chain that answers RPC calls but never advances. Assets left behind in contracts became permanently inaccessible, which is why Wormhole and Axelar spent July urging withdrawals.
What breaks: everything, eventually — but not all at once, which is the trap. For days or weeks, some RPC endpoints keep serving the frozen chain state, so a naive app keeps "working" against a corpse: balances read fine, transactions never confirm. A liveness check is not a freshness check — a stalled chain is the ultimate stale endpoint, and only block-timestamp monitoring catches it.
The under-appreciated loss: history. A blockchain's data exists only while someone runs nodes. Once operators shut down, the "immutable ledger" becomes an unreadable artifact. If your accounting, tax records, or analytics need historical Moonbeam data, the time to export it was before the shutdown — historical queries require a live archive node, and those are exactly what disappears first.
Pattern 2: Successor migration (Fantom → Sonic)
The project lives on, but on a new chain. Fantom's Opera chain was succeeded by Sonic: new chain ID (146, not 250), new native token (S, converted 1:1 from FTM), new endpoints, new explorer — a fresh network that inherits the community rather than the state.
What breaks: everything that pinned the old chain's identity. Chain ID is baked into EIP-155 transaction signatures, so wallet configs, signing code, and hard-coded chainId: 250 checks all fail closed on the successor. Contracts don't carry over — deployments are fresh, addresses differ. Treat a successor chain as a new integration that happens to share a brand, not an upgrade.
Pattern 3: Rebrand in place (Story → DATA Network)
The chain survives untouched; everything around it changes. When Story became the DATA Network in June, the chain ID stayed 1514, contracts kept running, signatures stayed valid — but the docs domain died, the official RPC hostname changed, the explorers moved, and the token ticker swapped ($IP → $DATA).
What breaks: the off-chain periphery. Hard-coded official RPC URLs rot on a deprecation timer, doc links 404, and UI labels go stale. Annoying rather than fatal — provided you notice it happened.
The defensive checklist
Three patterns, one set of habits:
- Monitor freshness, not liveness. Alert when a chain's latest block timestamp falls minutes behind wall-clock. This catches full shutdowns, stalls, and your own stale endpoints with one check. (It's the same logic we now run inside our routing layer — endpoints that lag the chain tip get benched automatically.)
- Never hard-code chain identity assumptions. Chain ID, RPC URL, explorer URL, token symbol — all config, none constants. Every pattern above rotates at least one of them.
- Export history you'll need, early. If a chain you depend on announces anything about migrations or "new directions," pull your historical data that week. Archive access has a shelf life.
- Watch the token, separately from the chain. Migrations (GLMR→Base, FTM→S 1:1) have deadlines; missing them has real cost. Your app's chain integration and your treasury's token position die on different schedules.
- Expect the long goodbye. Chains don't disappear cleanly — they serve frozen state from half-dead endpoints for weeks. Plan an explicit removal, not a fade-out.
The provider side of a chain death
There's an infrastructure version of this checklist too. When Moonbeam died, the failure mode we wanted to avoid was silently serving a frozen chain to customers as if it were live. So deprecation was explicit: verify the stall against multiple sources, deactivate the chain, and return a clear Unknown chain error instead of two-week-old state. The same happened to Evmos and Dymension earlier this year when their public infrastructure rotted away — quiet deaths, no headlines, same playbook.
That's part of what you're outsourcing when you use a provider: not just uptime on chains that work, but an honest answer about the ones that stop. We currently serve 75 chains — and the number goes down as well as up, on purpose.
Building multi-chain? Our chain list shows what's live right now, every chain with HTTP and WebSocket under one key, on a free tier with no KYC.
Originally published on the SwiftNodes blog. SwiftNodes provides flat-rate multi-chain RPC endpoints — HTTP + WebSocket, 75+ chains, no per-request metering. Grab a free key.
