Solana RPC reads available but writes failing: why the two paths fail separately

Solana RPC reads and writes travel different paths with different failure domains. A read is served from the node's local copy of state and succeeds even if that node has lost every connection that matters; a write must leave the node, cross the network to the current leaders, and survive their ingress policy before it exists on chain at all. Under partial degradation the write path fails first, and a status page built on reads will show green throughout.

Common causes

• Leader ingress is shedding traffic under load, so sendTransaction calls are accepted by your RPC node and then dropped downstream, invisibly.
• The RPC node's transaction-forwarding path is broken or misconfigured while its query stack runs normally, a failure mode nothing on the read side will reveal.
• Congestion-level priority fees are pricing your transactions out of blocks, which presents as writes failing while every read confirms the cluster is alive.
• The node is lagging the tip: reads work but return stale state, and the blockhashes it hands out produce transactions that expire.

System-level mechanism

The asymmetry is architectural. Reads scale by adding replicas and never touch consensus, so the network's entire degradation response, shedding at ingress, fee-based prioritisation, stake-weighted admission, is concentrated on the write path by design. That is the correct engineering trade, but it means "is the RPC up" and "can I get a transaction included" are separate questions with separate answers, and they diverge precisely during the load events when the difference matters most. Distinguishing the two is how operators avoid debugging their own stack while the actual constraint is admission at the leaders.

What this indicates

Reads succeeding while writes fail indicates the degradation sits in the forwarding and ingress path, beyond the node you are talking to. The practical consequence is that availability monitoring built on read probes measures the wrong thing for any system that needs to land transactions; the write path has to be probed end to end, by landing real transactions and timing them.

Related issues

Transactions dropped before the leader under stake-weighted throttling; expiry errors from stale blockhashes; endpoints disagreeing about chain state while all of them remain readable.

Deep references

• Expensive work before authentication covers the cost and admission asymmetries that shape the write path under load.
• We're securing validators at the wrong layer argues that this transport and RPC layer is where availability is really decided.
• NR-2026-001, Agave RPC architectural findings documents RPC-layer saturation behaviour, including modes where nodes keep answering while degraded.