Solana网络在周三早上因一次路由配置错误，险些完全失去交易最终性。根据托管提供商Teraswitch发布的事后分析，一个单一配置错误的默认路由导致28.83%的质押SOL离线，使网络距离停止最终性仅差4.51个百分点——即达到33.34%阈值的约86%。
故障源于Teraswitch内部的路由传播机制。该公司使用默认路由来指示边缘路由器能够访问互联网，通常每个站点会优先使用自己路由器发出的路由。然而，来自迈阿密站点的默认路由在传播过程中被剥离了度量值和社区标签，阿姆斯特丹的一个路由反射器将其推入欧洲和亚太地区。边缘路由器误将该路由视为本地路由，并优先使用它，而非真实路由，随后将数据转发至数据中心核心，核心拒绝该路由为无效。结果，伦敦、阿姆斯特丹、都柏林、法兰克福、新加坡和东京的12个站点没有任何有效路由可转发流量。北美地区未受影响。工程师在10分钟内发现故障，服务于UTC时间04:16:15恢复。
质押协议Marinade Finance事后提取数据发现，此次故障集中发生在单一自治系统AS20326上。该系统持有118,890,767 SOL，占网络总质押量的四分之一以上，其中94%在同一分钟内离线。这一比例已超过Solana基金会为防止此类事件设定的上限——任何单一自治系统不得超过网络质押的25%，而AS20326实际占比达到27.34%。
Marinade发现，在阿姆斯特丹、法兰克福和东京，有59个验证者（持有80.2百万SOL）在窄窗口内恢复，它们等待路由重新收敛，而没有切换至其他路由。Solana上第二大验证者Helius在整个33分钟故障期间一直处于离线状态。在Marinade可测量的74个运营商中，只有三个“干净恢复”：Laine、Cogent Crypto（均由Sol Strategies运营）以及Lion3d。
风险暴露范围远不止一个提供商。在同一分钟内，还有14.1百万SOL在latitude.sh、Limestone、Butterfly Research和Allnodes等处离线，Marinade表示无法从数据中解释这一现象，并指出按托管提供商统计质押份额会低估同时故障的风险。Marinade也对自己进行了分析，报告称其分配模型下，四个自治系统持有三分之二的质押份额，其中AS395201占36.94%。该公司在推特上表示：“任何人都不应该对此感到安心，包括我们。”并称将审查每个网络和数据中心的集中度限制，同时开始发布验证者是否具备热切换和自动故障转移能力（目前无法从外部确定）。
本次故障导致的333 SOL奖励损失将在周期结束时由验证者债券覆盖。但如果故障率超过三分之一，那么任何SOL持有者都无法完成最终交易，且没有债券能够覆盖这种损失。Solana上一次完全停止运行是在2024年2月，当时花了近五个小时才重启。