O suporte de um oráculo da Solana termina hoje. Quem ainda depende dos seus preços?

O prazo de suporte de 25 de setembro da Switchboard transformou um aviso de migração de seis dias em um teste para os feeds de preço da Solana. A documentação pública atual mostra onde seus dados continuam fazendo parte do design de uma aplicação, mas essas páginas não podem provar que um mercado ativo ainda está usando o feed. Jito e marginfi fornecem duas visões nitidamente diferentes da exposição.

A Switchboard atingiu seu fim declarado de suporte técnico em 25 de setembro, deixando as aplicações Solana para verificar as fontes de preço configuradas em seus programas ativos.

A declaração de 19 de setembro do projeto de oráculo, conforme reproduzida na cobertura do anúncio, disse que seu contribuidor principal de desenvolvimento, Switchboard Technology Labs, encerraria as atividades e todas as implementações foram descontinuadas imediatamente. A equipe instou os integradores a migrar para outros provedores, nomeando Pyth e RedStone. 25 de setembro foi descrito como o último dia para suporte existente. Uma empresa encerrando o suporte é um marco operacional real. Isso não prova, por si só, que todo feed onchain parou de atualizar à meia-noite ou que toda aplicação antes associada à Switchboard permaneceu dependente dela.

A própria documentação da Switchboard nomeou Kamino, Jito, marginfi e Drift como usuários. Essas são alegações históricas de integração de um provedor que estava vendendo um serviço de oráculo, não um inventário em tempo real de feeds ativos em 25 de setembro. Verificar a documentação atual de cada projeto revela um quadro mais complicado. As páginas do Tip Router da Jito ainda descrevem a Switchboard em seu fluxo de precificação; a atualização técnica de setembro da marginfi adiciona caminhos projetados para evitar essa dependência. Um documento pode estar desatualizado enquanto outro antecipa uma migração. Nenhum substitui uma inspeção da configuração da conta ativa.

A rodada de financiamento anterior da Switchboard foi de US$ 7,5 milhões em maio de 2024. O valor é um contexto útil sobre a história do empreendimento, mas não fornece uma medida da exposição atual do protocolo. A contagem relevante é o número e o valor dos mercados ativos cujos cálculos de risco ainda obtêm dados de um feed que não pode ser atualizado de forma confiável, e essa contagem não pode ser inferida a partir de um logotipo de cliente.

Uma integração listada não é um feed ativo

A introdução pública da Switchboard descreve feeds sob demanda: as aplicações criam ou chamam os dados de que precisam, e um preço é disponibilizado por meio de contas Solana. A documentação pode identificar onde um protocolo sabe como ler um feed da Switchboard. Ela pode não identificar qual opção um determinado mercado seleciona atualmente. Um kit de desenvolvimento de software pode suportar um tipo de oráculo muito depois de o último banco mudar para outro. Por outro lado, um site pode mudar enquanto uma reserva ativa mantém sua conta de oráculo mais antiga.

Três níveis de evidência precisam ser mantidos separados. Primeiro é uma página de marketing ou integração, que mostra que uma relação existiu. Segundo é a configuração suportada de um programa, visível na documentação técnica ou no código. Terceiro é a configuração ativa e o histórico de atualizações recentes do mercado real. Apenas o terceiro pode sustentar a alegação de que um mercado nomeado ainda dependia da Switchboard em um determinado momento. Mesmo assim, uma fonte de backup pode estar configurada, então o impacto de um feed primário interrompido deve ser verificado em relação à regra de fallback e atualidade relevante.

Considere a documentação do protocolo da marginfi. Sua tabela de oráculos mantém SwitchboardPull e variantes de local entre as configurações disponíveis. Ela diz que um chamador deve acionar um feed pull da Switchboard pouco antes do uso. A mesma tabela lista feeds push da Pyth e contas Scope como outras configurações. Um leitor poderia confundir a linha contínua da Switchboard com prova de que todo banco marginfi ainda a usa. A tabela descreve tipos suportados, não uma lista completa de qual banco usa qual feed hoje.

A nota separada do Program 0.1.11 da Marginfi é mais atual e mais específica. Ela instruiu os desenvolvedores a atualizar o SDK para pelo menos a versão 2.8.0 antes de 4 de setembro, dizendo que os bancos começariam a migrar para novas configurações de oráculo a partir dessa data. A versão adicionou nove variantes que não dependem do Switchboard, incluindo feeds do Kamino Scope e precificação baseada em taxa de câmbio para certos tokens de staking líquido e principal. A nota não diz que todos os bancos haviam migrado até 25 de setembro. Ela mostra que um projeto documentou publicamente uma rota de fuga da dependência ameaçada antes do anúncio de desligamento.

A migração carrega um segundo modo de falha surpreendente. A Marginfi diz que SDKs mais antigos não conseguem decodificar um banco configurado com um dos novos valores de enum de oráculo. Um único banco com um valor não suportado pode impedir o Project0Client.initialize e as leituras de bancos, não apenas uma ação envolvendo aquele banco. Em outras palavras, mudar um oráculo pode corrigir uma dependência de infraestrutura enquanto quebra um integrador que não atualizou seu software. O documento da Marginfi diz aos integradores como evitar o problema do SDK; não é evidência de que qualquer usuário específico tenha sofrido com isso.

O Project 0 descreveu margem unificada entre venues da Solana, incluindo Kamino e Drift. Interfaces entre protocolos criam outra camada na qual uma migração de oráculo deve ser lida corretamente. A nota sobre versões mais antigas do SDK é evidência concreta de um risco de integração, sem provar uma falha no Project 0 ou em qualquer outro app nomeado. Uma auditoria responsável verificaria versões de software e configurações ativas de bancos de empréstimo antes de alegar uma interrupção.

O Tip Router da Jito ainda documenta o Switchboard

A visão geral do Tip Router da Jito Foundation diz que o Switchboard determina o peso relativo de ativos como JitoSOL e JTO mantidos em cofres vinculados ao Tip Router. A visão geral identifica um programa Tip Router onchain, um cliente de operador de nó e um cranker sem permissão. Sua documentação de precificação nomeia o Switchboard como o feed de oráculo atual e descreve pesos de backup quando os feeds estão indisponíveis.

Os documentos colocam o Switchboard em uma função específica: precificar ativos de cofres para cálculos de peso em um sistema de distribuição de gorjetas e restaking. Eles não dizem que um feed do Switchboard indisponível liquidaria automaticamente uma posição de empréstimo na Solana. A página de precificação da Jito descreve um mecanismo de fallback, o que enfraquece a alegação simplista de que um fim de suporte necessariamente faz todas as operações do Tip Router pararem. Os valores exatos de fallback, condições de ativação e contas de oráculo ativas atuais ainda precisam de uma verificação atual do estado do programa.

A visão geral do Tip Router mostrava um marcador de última atualização de nove meses atrás quando verificada em 25 de setembro. Essa idade muda como ela pode ser usada. Ela estabelece um design documentado e identifica onde fazer uma pergunta técnica. Ela não pode estabelecer que o programa atual tem a mesma configuração de feed. A Jito pode ter atualizado contas onchain sem revisar a página, ou ainda pode usar o Switchboard com um fallback. Sem uma inspeção recente de transações ou uma declaração atual da Jito, uma dependência ativa nomeada permanece não verificada.

As notas de versão públicas do GitHub da Jito para o Tip Router referem-se a tentar novamente gateways de oráculo do Switchboard em operações de keeper. Uma base de código contendo tal lógica igualmente demonstra integração técnica, não necessariamente uma dependência de todos os cofres no momento da publicação. O código pode preservar um caminho de compatibilidade por meses. A questão ativa é se transações recentes de atualização de preço visam uma conta do Switchboard usada por um cofre que ainda carrega valor, e se essa conta avança após o prazo de suporte.

A distinção é frequentemente perdida quando todos os usuários de oráculo são colocados em uma única lista. O cálculo descrito da Jito afeta pesos relativos de ativos em um sistema de distribuição. O cálculo descrito de um mercado de empréstimo determina o valor da garantia e a saúde do tomador. Ambos consomem dados de preço, mas seus caminhos de falha diferem. Uma auditoria que conta logotipos atribuiria a mesma severidade a usos fundamentalmente diferentes.

O Scope da Kamino é um agregador, não um rótulo de provedor

O repositório público do Scope da Kamino Finance descreve um agregador onchain que copia valores de múltiplas contas de oráculo para um único feed de preços e valida atualizações sob regras predefinidas. Seu README diz que um feed suporta até 512 preços e que a associação entre um índice e um par de tokens não é totalmente armazenada onchain. Um programa downstream pode apontar para o Scope, enquanto o próprio Scope depende de outros feeds para o ativo selecionado. Ver o Scope em uma configuração de banco é, portanto, um ponto de partida para rastrear a fonte de dados real, não o fim.

A nota da marginfi de setembro lista o Scope como uma opção que não depende da Switchboard para a nova configuração que descreve. Isso não implica que toda implantação do Scope em toda data exclua toda fonte da Switchboard. Um agregador pode mudar suas entradas subjacentes. Uma verificação completa de dependência precisa tanto da conta Scope selecionada pelo consumidor quanto do mapeamento de origem usado para preencher sua entrada. O repositório da Kamino fornece a arquitetura, não um inventário com carimbo de data e hora das fontes atuais da mainnet para cada aplicação.

A Kamino continuou trazendo instituições para seu ecossistema de empréstimos. A Galaxy abriu dois cofres de stablecoin na plataforma em setembro. A existência de novos cofres mostra por que nomear um protocolo inteiro como exposto sem verificar seus ativos individuais seria insensato. Um cofre de USDC, uma reserva de token de staking líquido e um mercado de ações tokenizadas podem usar caminhos de oráculo diferentes. Não verificamos que os cofres da Galaxy usam a Switchboard, portanto eles não estão incluídos em uma contagem de posições afetadas.

Da mesma forma, a lista mais antiga de Kamino, Jito, marginfi e Drift no material introdutório da Switchboard não nos diz a distribuição de exposição entre eles. Um projeto pode usar um oráculo apenas para um mercado, usá-lo como fallback, ou manter o código após trocar os feeds ativos. A única unidade de análise defensável é um mercado ou cofre específico e seu feed configurado em um momento especificado. Sem essa unidade, afirmações sobre fundos em risco são aritmética de marketing executada ao contrário.

Um feed desatualizado tem mais de um efeito possível

A consequência técnica de um feed ficar para trás depende do protocolo consumidor. Um programa de empréstimos geralmente precisa de um preço para determinar o valor da garantia e a capacidade de empréstimo. Se ele rejeitar um valor antigo, uma ação pode falhar ou um mercado pode pausar sob suas regras. Se ele aceitar dados desatualizados, um tomador pode transacionar com base em um preço que não corresponde mais ao mercado. Uma fonte de fallback pode manter o mercado operando, mas introduzir um novo ritmo de atualização ou regra de confiança. A documentação do protocolo e a configuração onchain decidem qual caminho se aplica.

A marginfi diz explicitamente que os feeds pull da Switchboard precisam ser acionados antes do uso. Um integrador deve, portanto, fornecer uma atualização recente como parte de seu caminho de transação. Os feeds push da Pyth, por outro lado, são descritos como mantidos atualizados através da infraestrutura da Pyth. O Scope usa um valor de conta agregado selecionado por um índice de entrada configurado. Mover-se entre esses tipos muda as contas que uma transação precisa e o código que as verifica. O aviso do SDK de setembro é um exemplo visível dessas mudanças chegando ao software de aplicação.

Para o Jito Tip Router, a documentação pública descreve pesos de backup para feeds indisponíveis. Se esses backups preservam a alocação precisa de recompensas durante uma interrupção prolongada é uma questão para a configuração ativa e os operadores da Jito, não algo que uma frase de documentação resolve. Se um feed continua sendo atualizado por operadores de nós independentes após a empresa parar o suporte, nenhum fallback pode ser acionado imediatamente. Se as atualizações cessarem, mas o backup estiver ativo, as operações podem continuar com um método de precificação diferente. Esses são caminhos condicionais, não uma previsão do estado atual do sistema.

Um incidente de oráculo não relacionado levou a liquidações na Vesu no início de setembro. Isso ilustra que precificação incorreta pode ter efeitos econômicos, mas não é evidência de um incidente na Switchboard, Jito ou marginfi. Um aviso de desligamento não deve ser transformado em uma alegação de liquidação por analogia. O sinal de um evento real seriam carimbos de data e hora de contas desatualizados, transações falhas, uma pausa no protocolo ou perdas identificadas, nenhum dos quais foi mostrado aqui para o prazo de 25 de setembro.

A mudança da Solana para slots de 250 milissegundos alterou o ritmo com que os blocos são produzidos, mas não garantiu que uma fonte de preço externa se atualize. Slots mais rápidos podem carregar um novo preço mais cedo quando ele existe. Eles não podem fabricar um preço quando o nó que o fornece para. O teste de atualidade de um protocolo pode ser medido por slot, tempo ou outra regra, então uma mudança no relógio da rede pode alterar como os desenvolvedores interpretam configurações antigas de feed.

Quem arca com o trabalho de migração?

O operador do oráculo publica ou coordena dados, mas o protocolo consumidor escolhe a conta que seu programa lê e os limites que impõe a esse preço. Um protocolo de empréstimo pode exigir governança ou um administrador para alterar os endereços do oráculo em seus mercados. Seu front end e integradores terceiros então precisam construir transações com as contas adicionais corretas. Os usuários podem apenas notar um empréstimo rejeitado ou um mercado pausado, muito depois de o operador e o protocolo terem tomado suas decisões técnicas.

Um operador que encerra o suporte não tem necessariamente o poder de reescrever a configuração do programa de um cliente. O aviso da Switchboard instou os usuários a migrar porque os proprietários da integração devem agir. Os projetos devem ser avaliados pelos endereços e atualizações de conta que controlam. Se um aplicativo já migrou para a Pyth antes de 19 de setembro, o prazo de suporte posterior não tem efeito direto sobre esse mercado. Se ele ainda seleciona um feed da Switchboard e não tem um backup funcional, o comportamento do feed após 25 de setembro é a questão concreta.

A leitura oposta mais forte do alarme de desligamento decorre da própria nota de setembro da marginfi e do backup documentado da Jito. Os aplicativos podem projetar redundância ou avançar antes da saída de um fornecedor; o código e os documentos mostram mecanismos para fazê-lo. O modelo sob demanda da Switchboard pode deixar alguma infraestrutura de feed funcionando de forma independente mesmo que o contribuidor principal tenha interrompido o suporte. O aviso não publicou um cronograma verificado no qual cada conta seria interrompida, e não encontramos evidência primária estabelecendo tal corte universal.

Há um tipo diferente de questão de continuidade para um protocolo que criou seu próprio fallback. Um preço de backup pode evitar uma parada total enquanto precifica um ativo com menos frequência ou com um conjunto de fontes diferente. Para um processo de distribuição de recompensas, um peso de backup temporário pode manter a contabilidade de época em andamento, embora a alocação possa então depender das suposições do backup. Para um mercado de empréstimo, o fallback poderia alterar o preço usado em uma verificação de saúde. Estas não são afirmações sobre as configurações atuais da Jito ou da marginfi. Elas mostram o que um mantenedor deve divulgar antes que os usuários possam julgar se uma migração está completa em termos operacionais, não apenas se as transações ainda são executadas.

O encerramento de um provedor também pode ter efeitos retardados. O código escrito para solicitar preços sob demanda pode ter sucesso enquanto um gateway independente responde, e então falhar quando esse gateway for desativado ou seus operadores pararem de atualizar um ativo específico. Um observador precisa de vários carimbos de data e hora pós-prazo, não de uma única transação bem-sucedida, para inferir serviço contínuo. A mesma disciplina se aplica a uma transação falha: o erro de um usuário pode surgir de um SDK desatualizado ou de entrada de conta insuficiente em vez de um oráculo indisponível. O documento de migração da Marginfi fornece um exemplo explícito de uma falha de decodificação de software que poderia, de outra forma, ser erroneamente rotulada como uma interrupção do oráculo.

Há um limite para essa garantia. Um fallback descrito nove meses antes precisa de validação em relação ao estado atual, e uma opção de migração descrita em setembro não é prova de que todos os bancos a adotaram. Os dois documentos fornecem razões críveis para não presumir catástrofe, ao mesmo tempo que deixam uma lacuna mensurável. A conclusão justa é mais estreita do que tanto as versões promocionais quanto as alarmistas: documentos públicos identificam dependências candidatas e rotas de escape; uma auditoria atual de configuração mercado a mercado é necessária para estabelecer qualquer exposição remanescente.

O inventário ao vivo ainda é o documento que falta

A reportagem original aqui compara a lista da Switchboard de quatro integradores proeminentes com documentos primários atuais da Jito, marginfi e Kamino. Isso produz duas constatações documentais verificadas. A documentação mais antiga do Tip Router da Jito nomeia a Switchboard para precificação de vault e um fallback para feeds indisponíveis. A nota 0.1.11 de setembro da Marginfi descreve nove novas configurações independentes da Switchboard e alerta sobre uma quebra separada do SDK se os integradores não atualizarem. O repositório Scope da Kamino explica por que um rótulo de agregador sozinho não consegue identificar todas as fontes de dados upstream.

O trabalho não produz uma contagem de feeds ao vivo não migrados, fundos de usuários expostos ou uma interrupção em qualquer protocolo nomeado. As páginas públicas disponíveis não contêm um snapshot sincronizado de 25 de setembro de todas as contas de oráculo, atualizações bem-sucedidas mais recentes, configurações de fallback e montantes suportados por cada mercado. Alegar um total específico em dólares a partir do TVL do protocolo seria indefensável, porque os ativos de todo o protocolo não necessariamente compartilham o mesmo oráculo. A pergunta precisa do título permanece em aberto no nível da conta ao vivo.

Uma contagem adequada usaria o mercado como a linha, não o protocolo. Para cada banco de empréstimo ativo, mercado de derivativos ou vault de recompensas, o auditor registraria seu endereço de programa, tipo de oráculo selecionado, conta de oráculo, fonte de backup, se houver, atualização de preço bem-sucedida mais recente, idade máxima permitida e o valor das posições que realmente dependem daquele preço específico. Mercados duplicados que compartilham uma conta de oráculo não devem ser contados como feeds distintos; um mercado usando dois oráculos independentes não deve ser contado como totalmente dependente de qualquer um deles sem ler sua lógica de fallback. O timestamp da configuração do mercado importa porque um administrador pode alterar um feed após a observação.

Esse método explica por que até mesmo uma afirmação verdadeira, como a de que um protocolo suportava 550 feeds no passado, é insuficiente para a pergunta presente. Um feed pode existir sem um tomador ativo, pode ter uma atualização de preço sem um mercado consumidor, ou pode ser referenciado apenas em código dormente. Uma contagem de contas de feed mede infraestrutura. Uma contagem de mercados configurados mede dependência. Uma contagem de posições e garantias que realmente tocam esses mercados mede exposição econômica. Nenhuma delas é intercambiável com o total de ativos depositados em todos os produtos operados por um projeto.

Há uma etapa adicional de verificação quando uma fonte é um agregador. O consumidor pode identificar uma conta Scope e um índice de entrada, enquanto o mapeamento do Scope aponta adiante para um ou mais provedores. Uma atualização na conta Scope após 25 de setembro prova que um agregador produziu um valor, mas não prova por si só que a Switchboard continuou a fornecer o preço subjacente. O investigador precisa da entrada selecionada e da configuração da fonte para essa atualização. O repositório da Kamino observa que os rótulos de par de tokens não são inteiramente armazenados onchain, então configuração externa ou documentação do mantenedor pode ser necessária para mapear um índice ao seu ativo. Onde esse mapeamento não estiver disponível, o resultado deve ser registrado como desconhecido, não silenciosamente atribuído à Pyth ou à Switchboard.

O que observar

• Endereços de oráculo de mercado: Compare o feed configurado de cada banco ou vault ativo com as contas Switchboard documentadas.
• Timestamps de atualização de preço: Verifique se um feed identificado continua publicando valores atualizados após 25 de setembro.
• Configuração de fallback: Procure a fonte e o limite de atualidade usados se um feed primário ficar para trás.
• Transações recentes do programa: Verifique se empréstimo, liquidação ou distribuição de gorjetas ainda são concluídos para o mercado afetado.
• Atualizações datadas do mantenedor: Procure uma migração nomeada, pausa de mercado ou dependência remanescente, apoiada por um endereço de conta ou programa.

Registre o horário da observação para cada verificação; uma captura de tela sem um bloco ou timestamp pode rapidamente ficar desatualizada.

A nota de atualização da Marginfi afirma que um banco usando um novo valor de enum de oráculo pode fazer com que um SDK mais antigo falhe ao inicializar seu cliente, mesmo que um usuário não interaja com esse banco específico. A instrução para usar a versão 2.8.0 ou posterior do SDK foi publicada antes do início da migração de 4 de setembro, três semanas antes do prazo de suporte da Switchboard.

FAQ