Solana 预言机 Switchboard 今日终止支持，还有谁在用它的价格？

Switchboard 的 9 月 25 日支持截止日期将六天的迁移警告变成了对 Solana 价格源的考验。当前的公开文档显示了其数据在应用程序设计中仍占有一席之地，但这些页面无法证明一个活跃市场仍在使用该数据源。Jito 和 marginfi 提供了两种截然不同的风险敞口视角。

Switchboard 已到达其声明的 9 月 25 日技术支持终止日期，留下 Solana 应用程序来验证其活跃程序中配置的价格源。

该预言机项目在 9 月 19 日的声明中，正如公告报道中所转载的那样，表示其核心开发贡献者 Switchboard Technology Labs 将逐步关闭，所有实现立即弃用。团队敦促集成商迁移到其他提供商，并点名了 Pyth 和 RedStone。9 月 25 日被描述为现有支持的最后一天。一家公司结束支持是一个真实的运营里程碑。但这本身并不能证明每个链上数据源都在午夜停止更新，或者每个曾与 Switchboard 关联的应用程序仍然依赖它。

Switchboard 自己的文档将 Kamino、Jito、marginfi 和 Drift 列为用户。这些是来自一家销售预言机服务的提供商的历史集成声明，而不是 9 月 25 日活跃数据源的实时清单。检查每个项目当前的文档揭示了一幅更复杂的图景。Jito 的 Tip Router 页面仍在其定价流程中描述 Switchboard；marginfi 的 9 月技术升级增加了旨在避免该依赖的路径。一份文档可能过时，而另一份则预期迁移。两者都不能替代对实时账户配置的检查。

早先的 Switchboard 融资轮是在 2024 年 5 月，金额为 750 万美元。这个金额对于该企业的历史是有用的背景信息，但它无法衡量当今的协议风险敞口。相关的计数是那些风险计算仍从无法可靠更新的数据源获取数据的活跃市场的数量和價值，而这个计数无法从客户标识中推断出来。

列出的集成并非活跃的数据源

Switchboard 的公开介绍描述了按需数据源：应用程序创建或调用所需数据，并通过 Solana 账户提供价格。文档可以识别协议知道如何读取 Switchboard 数据源的位置。它可能无法识别特定市场当前选择哪个选项。软件开发工具包可能在最后一个银行切换离开某种预言机类型很久之后仍支持它。相反，网站可能发生变化，而活跃储备仍保留其较旧的预言机账户。

需要区分三个证据层次。第一是营销或集成页面，它表明存在某种关系。第二是程序支持的配置，可在技术文档或代码中看到。第三是实际市场的实时配置和近期更新历史。只有第三层才能支持某个指定市场在特定时间仍依赖 Switchboard 的说法。即使如此，也可能配置了备用源，因此必须根据相关的回退和新鲜度规则来检查主数据源停止的影响。

考虑marginfi 的协议文档。其预言机表格在可用设置中保留了 SwitchboardPull 和场所变体。它说调用者必须在使用前立即触发 Switchboard 拉取数据源。同一表格将 Pyth 推送数据源和 Scope 账户列为其他设置。读者可能会将保留的 Switchboard 行误认为每个 marginfi 银行仍在使用它的证据。该表格描述的是支持的类型，而不是今天哪个银行使用哪个数据源的完整列表。

Marginfi 单独的 Program 0.1.11 说明更新、更具体。它指示开发者应在 9 月 4 日前将 SDK 升级到至少 2.8.0 版本，并表示银行将从该日期起开始迁移到新的预言机设置。该版本新增了九种不依赖 Switchboard 的变体，包括 Kamino Scope 价格源以及针对某些流动性质押和本金代币的基于汇率的定价。该说明并未表示所有银行都已在 9 月 25 日前完成迁移。它确实表明，一个项目在关停公告之前就已公开记录了摆脱受威胁依赖的路径。

这次迁移带来了一个令人意外的第二故障模式。Marginfi 表示，较旧的 SDK 无法解码配置了某个新预言机枚举值的银行。一个带有不受支持值的银行就可能阻止 Project0Client.initialize 和银行读取，而不仅仅是涉及该银行的某个操作。换句话说，更改预言机可以修复一个基础设施依赖，同时却会破坏尚未更新其软件的集成方。Marginfi 的文档告诉集成方如何避免 SDK 问题；这并不是任何特定用户遭遇该问题的证据。

Project 0 描述了跨 Solana 场所的统一保证金，包括 Kamino 和 Drift。跨协议接口又增加了一层必须正确解读预言机迁移的环节。关于较旧 SDK 版本的说明是集成风险的具体证据，但并未证明 Project 0 或任何其他被点名应用发生了故障。负责任的审计应在声称发生中断之前检查软件版本和实时借贷银行配置。

Jito 的 Tip Router 仍记录使用 Switchboard

Jito 基金会的 Tip Router 概览称，Switchboard 决定与 Tip Router 关联的金库中持有的 JitoSOL 和 JTO 等资产的相对权重。该概览指出了一个链上 Tip Router 程序、一个节点运营者客户端和一个无需许可的 cranker。其定价文档将 Switchboard 列为当前预言机价格源，并描述了价格源不可用时的备用权重。

这些文档将 Switchboard 放在一项特定工作中：为小费分配和再质押系统中的权重计算而对金库资产进行定价。它们并未表示 Switchboard 价格源不可用会自动清算 Solana 借贷头寸。Jito 的定价页面描述了一种回退机制，这削弱了那种简单化的说法，即支持终止必然会使所有 Tip Router 操作停止。确切的回退值、激活条件以及当前实时预言机账户仍需进行当前程序状态检查。

在 9 月 25 日检查时，Tip Router 概览显示的最后更新标记为九个月前。这一时间差改变了它的使用方式。它确立了一种有记录的设计，并指明了应在何处提出技术问题。它无法确立当前程序具有相同的价格源配置。Jito 可能已更新链上账户而未修订页面，也可能仍在使用带备用方案的 Switchboard。若没有近期交易检查或 Jito 的当前声明，一个被点名的实时依赖仍未得到验证。

Jito 公开的 Tip Router GitHub 发布说明提到在 keeper 操作中重试 Switchboard 预言机网关。包含此类逻辑的代码库同样展示了技术集成，而不一定是发布时每个金库的依赖。代码可以保留兼容路径数月之久。真正的问题在于，近期的价格更新交易是否针对某个仍承载价值的金库所使用的 Switchboard 账户，以及该账户在支持截止日期后是否继续推进。

当所有预言机用户被放入单一列表时，这种区别往往被忽略。Jito 所描述的计算影响分配系统中资产的相对权重。借贷市场所描述的计算决定抵押品价值和借款人健康度。两者都消费价格数据，但它们的故障路径不同。一场只数标志的审计会给根本不同的用途分配相同的严重程度。

Kamino 的 Scope 是聚合器，而非提供者标签

Kamino Finance 的公开 Scope 仓库描述了一个链上聚合器，它将多个预言机账户中的值复制到一个价格源中，并在预设规则下验证更新。其 README 称，一个源最多支持 512 个价格，并且索引与代币对之间的关联并非完全存储在链上。下游程序可能指向 Scope，而 Scope 本身则依赖其他源来获取所选资产。因此，在银行配置中看到 Scope 只是追踪实际数据源的起点，而非终点。

九月的 marginfi 说明将 Scope 列为一种选项，对于其描述的新设置而言，该选项不依赖于 Switchboard。这并不意味着 Scope 在每一天的每一次部署都排除了每一个 Switchboard 源。聚合器可以更改其底层输入。完整的依赖检查既需要消费者所选的 Scope 账户，也需要用于填充其条目的源映射。Kamino 的仓库提供了架构，而非针对每个应用程序的当前主网源的时间戳清单。

Kamino 一直在将机构引入其借贷生态系统。Galaxy 于九月在该平台上开设了两个稳定币金库。新金库的存在表明，为何在不检查其个别资产的情况下就将整个协议列为风险暴露是不合理的。一个 USDC 金库、一个流动性质押代币储备和一个代币化股票市场可以使用不同的预言机路径。我们尚未核实 Galaxy 的金库是否使用 Switchboard，因此它们未被计入受影响头寸的统计中。

同样，Switchboard 介绍材料中较早列出的 Kamino、Jito、marginfi 和 Drift 名单，并未告诉我们它们之间风险暴露的分布情况。一个项目可能仅将某个预言机用于一个市场，将其用作后备，或在切换实时源后保留代码。唯一站得住脚的分析单位是特定市场或金库及其在指定时间所配置的源。没有这个单位，关于面临风险资金的说法就是反向操作的营销算术。

过时的源可能有不止一种影响

源落后于更新的技术后果取决于消费协议。借贷程序通常需要一个价格来确定抵押品价值和借款能力。如果它拒绝旧值，某项操作可能会失败，或者市场可能会根据其规则暂停。如果它接受过时数据，借款人可能会依据一个不再与市场匹配的价格进行交易。后备源可能会让市场继续运行，但会引入新的更新节奏或置信规则。协议的文档和链上配置决定了适用哪条路径。

Marginfi 明确表示，Switchboard 拉取式源在使用前需要被触发。因此，集成方必须在其交易路径中提供一次新的更新。相比之下，Pyth 推送式源被描述为通过 Pyth 的基础设施保持新鲜。Scope 使用由配置的条目索引所选择的聚合账户值。在这些类型之间切换会改变交易所需的账户以及检查它们的代码。九月的 SDK 警告是这些变化触及应用软件的一个可见例子。

对于 Jito Tip Router，公开文档描述了不可用源的后备权重。这些后备是否能在持续中断期间保持准确的奖励分配，是实时配置和 Jito 运营方需要回答的问题，而不是文档中的一句话所能解决的。如果某个源在公司停止支持后仍通过独立节点运营方持续更新，那么可能不会立即触发后备。如果更新停止但后备处于活跃状态，运营可能会以不同的定价方法继续。这些是有条件的路径，而非对系统当前状态的预测。

九月早些时候，一起无关的预言机事件导致 Vesu 上发生清算。它说明错误定价可能产生经济影响，但这并不是 Switchboard、Jito 或 marginfi 发生事件的证据。不应通过类比将一则关停通知变成清算索赔。实际事件的迹象将是过时的账户时间戳、失败的交易、协议暂停或已确认的损失，而就九月二十五日的截止日期而言，这里尚未展示其中任何一项。

Solana 转向 250 毫秒槽位改变了区块生产的速度，但这并未保证外部价格源会更新。当新价格存在时，更快的槽位可以更早地承载它。当提供价格的节点停止时，它们无法凭空制造价格。协议的新鲜度测试可能按槽位、时间或其他规则来衡量，因此网络时钟的变化可能会改变开发者对旧源配置的解读。

谁来承担迁移工作？

预言机运营方发布或协调数据，但消费协议选择其程序读取的账户以及对该价格施加的限制。借贷协议可以要求治理或管理员为其市场更改预言机地址。其前端和第三方集成方随后必须使用正确的附加账户构建交易。用户可能只会在很久之后，当运营方和协议早已做出技术决策时，才注意到一笔被拒绝的借款或一个被暂停的市场。

运营方结束支持并不一定有权重写客户的程序配置。Switchboard 的通知敦促用户迁移，因为集成所有者必须采取行动。项目应通过其控制的地址和账户更新来评估。如果某个应用在 9 月 19 日之前已经迁移到 Pyth，那么较晚的支持截止日期对该市场没有直接影响。如果它仍然选择 Switchboard 数据源且没有可用的备份，那么 9 月 25 日之后该数据源的行为就是具体问题所在。

对关停警报最强烈的反对解读来自 marginfi 自己 9 月的说明以及 Jito 有记录的备份。应用可以设计冗余或在供应商退出之前先行迁移；代码和文档展示了这样做的机制。Switchboard 的按需模式可以让部分数据源基础设施独立运行，即使核心贡献者已停止支持。该通知没有发布一个经过验证的、每个账户都会停止的时间表，我们也没有发现确立这种普遍截止点的一手证据。

对于一个自行设置回退方案的协议来说，存在另一种连续性疑问。备份价格可以防止完全停止，但会以更低的频率或不同的来源集为资产定价。对于奖励分发流程，临时备份权重可能让 epoch 记账继续推进，尽管分配随后可能依赖备份的假设。对于借贷市场，回退方案可能改变健康检查中使用的价格。这些并非关于当前 Jito 或 marginfi 设置的断言。它们表明，维护者必须披露什么，用户才能判断迁移在运营意义上是否完成，而不仅仅是交易是否仍能执行。

供应商逐步退出也可能产生延迟影响。为请求按需价格而编写的代码可能在独立网关响应时成功，然后在该网关退役或其运营方停止更新特定资产时失败。观察者需要多个截止日期后的时间戳，而不是一笔成功交易，才能推断服务仍在继续。同样的纪律也适用于失败交易：一个用户的错误可能源于过时的 SDK 或账户输入不足，而不是预言机不可用。Marginfi 的迁移文档提供了一个明确的软件解码失败示例，否则它可能被错误地标记为预言机中断。

这种安慰是有限度的。九个月前描述的回退方案需要针对当前状态进行验证，而 9 月描述的迁移选项并不能证明每个银行都采用了它。这两份文件提供了可信的理由，让人不必假设会发生灾难，同时也留下了一个可衡量的缺口。公平的结论比宣传版本和危言耸听版本都更狭窄：公开文件指出了候选依赖关系和逃生路线；需要进行当前逐市场的配置审计，才能确定任何剩余的敞口。

实时清单仍是缺失的文件

这里的原始报道将 Switchboard 列出的四家知名集成商与来自 Jito、marginfi 和 Kamino 的当前一手文件进行了比较。它得出了两项经核实的文件发现。Jito 较早的 Tip Router 文档将 Switchboard 列为金库定价以及不可用数据源的备用方案。Marginfi 9 月的 0.1.11 说明描述了九个独立于 Switchboard 的新设置，并警告称如果集成商不升级，会出现单独的 SDK 中断。Kamino 的 Scope 仓库解释了为什么仅凭聚合器标签无法识别每一个上游数据源。

这项工作并未得出实时未迁移数据源的数量、暴露的用户资金或任何被点名协议发生中断的结果。可用的公开页面不包含所有预言机账户、最新成功更新、备用设置以及每个市场所支持金额的同步 9 月 25 日快照。根据协议 TVL 声称某个具体美元总额是站不住脚的，因为整个协议的资产不一定共享同一个预言机。确切的标题问题在实时账户层面仍然悬而未决。

正确的计数应以市场为行，而不是以协议为行。对于每个活跃的借贷银行、衍生品市场或奖励金库，审计员应记录其程序地址、所选预言机类型、预言机账户、备用来源（如有）、最新成功价格更新、允许的最大时效，以及实际依赖该特定价格的头寸价值。共享同一个预言机账户的重复市场不应被计为不同的数据源；一个使用两个独立预言机的市场，在未阅读其备用逻辑的情况下，不应被计为完全依赖其中任何一个。市场配置的时间戳很重要，因为管理员可能在观察之后更改数据源。

这种方法解释了为什么即使像某个协议过去支持 550 个数据源这样的真实陈述，也不足以回答当前问题。一个数据源可以存在而没有活跃借款人，可以有价格更新而没有消费市场，或者只在休眠代码中被引用。数据源账户的计数衡量的是基础设施。已配置市场的计数衡量的是依赖关系。实际触及这些市场的头寸和抵押品的计数衡量的是经济暴露。这些都不能与某个项目运营的所有产品中存入的总资产互换。

当来源是聚合器时，还有一个进一步的验证步骤。消费者可能识别出一个 Scope 账户和条目索引，而 Scope 映射则进一步指向一个或多个提供者。9 月 25 日之后 Scope 账户中的更新证明某个聚合器产生了一个值，但这本身并不能证明 Switchboard 继续提供底层价格。调查人员需要该次更新所选的条目和来源配置。Kamino 的仓库指出，代币对标签并非完全存储在链上，因此可能需要外部配置或维护者文档才能将索引映射到其资产。在无法获得该映射的情况下，结果应记录为未知，而不是悄悄归因于 Pyth 或 Switchboard。

需要关注什么

• 市场预言机地址：将每个活跃银行或金库配置的数据源与已记录的 Switchboard 账户进行比较。
• 价格更新时间戳：检查已识别的数据源在 9 月 25 日之后是否继续发布新值。
• 备用配置：查找当主数据源落后时使用的来源和新鲜度限制。
• 近期程序交易：检查受影响市场的借贷、结算或小费分配是否仍能完成。
• 带日期的维护者更新：查找有名称的迁移、市场暂停或剩余依赖，并由账户或程序地址支持。

记录每次检查的观察时间；没有区块或时间戳的截图可能很快就会过时。

Marginfi 的升级说明指出，使用新预言机枚举值的银行可能导致较旧的 SDK 无法初始化其客户端，即使用户不与那个特定银行交互。使用 SDK 2.8.0 或更高版本的指示是在 9 月 4 日迁移开始之前发布的，比 Switchboard 的支持截止日期早三周。

常见问题