Beta Pública.
preprocessedSubscribe está disponível em todos os planos pagos
e é contabilizada em 0,1 créditos por mensagem (uma mensagem por transação entregue).O que é preprocessedSubscribe?
preprocessedSubscribe é um método Helius WebSocket que transmite transações pré-processadas — transações Solana pré-execução entregues antes de atingirem o nível de compromisso processed. O Helius agrega múltiplas fontes de pré-execução — principalmente shreds decodificados diretamente à medida que chegam ao validador, complementados por sinais de pré-confirmação — e as entrega como um único fluxo deduplicado de mensagens binárias compactas, sem infraestrutura de desfragmentação do seu lado.
As transações provenientes de sinais de pré-confirmação chegam mais tarde neste feed do que no produto dedicado Pré-confirmações, que continua sendo o acesso mais antecipado a elas.
É o sucessor do produto LaserStream (gRPC) pré-processado. Se você consome transações pré-processadas via gRPC hoje, mude para este método — ele entrega a mesma classe de dados por meio de uma conexão WebSocket simples com menor latência, e a entrega via gRPC será descontinuada.
Endpoint
preprocessedSubscribe é servido em wss://beta.helius-rpc.com — o endpoint do Helius Gatekeeper — em vez de mainnet.helius-rpc.com. Autentique-se com sua chave de API como um parâmetro de consulta:
Inscrever-se
Envie uma solicitação JSON-RPC com o métodopreprocessedSubscribe. params carrega os filtros de conta e é obrigatório — accountInclude e accountRequired devem especificar pelo menos uma conta entre eles (veja Filtragem):
Filtragem
Toda inscrição é delimitada pelos filtros de conta emparams. A filtragem acontece do lado do servidor, então você só recebe as transações que interessam:
Regras de filtro:
- Os três filtros são combinados com lógica AND.
accountIncludeeaccountRequireddevem especificar pelo menos uma conta entre eles — não há fluxo completo sem filtro.- As contas são chaves públicas codificadas em base58. Cada lista aceita até 5.000 endereços.
Resolução de tabela de pesquisa de endereços (ALT)
Os filtros de conta correspondem a mais do que as chaves de conta estáticas da transação — Helius resolve tabelas de pesquisa de endereços no lado do servidor, entãoaccountInclude, accountExclude e accountRequired também correspondem a contas que uma transação carrega por meio de um ALT. Basta passar a chave pública da conta; não há necessidade de manter mapeamentos ALT ou resolver tabelas por conta própria.
Carga útil de notificação
Notificações são entregues como quadros WebSocket binários (não JSON). Cada quadro carrega uma única transação em um layout de byte compactado:
Leia o prefixo fixo de 73 bytes na ordem, depois decodifique os bytes restantes para ler instruções, contas e buscas na tabela de endereços. A assinatura está incluída no prefixo para que você possa identificar e desduplicar uma transação sem decodificar todo o corpo da transação.
Sempre leia e verifique primeiro o byte
version. Se o Helius precisar atualizar o formato da carga útil, a versão será incrementada - bifurque nela para que seu decodificador continue funcionando em mudanças de esquema.
Decodificação da transação
Os bytes da transação são encaminhados exatamente como observados na rede, na codificação padrão de linha para a versão da transação. Transações Legacy e v0 usam o layout de assinaturas-primeiro quebincode produz. A transação v1 (SIMD-0385) usa um layout de mensagem-primeiro com assinaturas no final, então bincode falha em cargas v1. Use um decodificador que lide com todas as versões:
- Rust:
agave-transaction-viewanalisa transações legadas, v0 e v1 no local, sem uma cópia intermediária. Esta é a opção recomendada.wincode, o serializador compatível com bincode usado pelos SDKs atuais do Solana, também decodifica v1 emVersionedTransaction. - JavaScript / TypeScript: certifique-se de que a versão da sua biblioteca seja compatível com a transação v1. Implementações mais antigas
VersionedTransaction.deserializeapenas lidam com legados e v0. Use@solana/kit8.0+ ou@solana/web3.jsv3. Veja Suporte para Transação v1.
Exemplo
Quais dados estão disponíveis?
Cada notificação carrega a transação assinada, sua primeira assinatura e seu slot. Como a entrega ocorre antes da execução, o fluxo não inclui:- Status ou erros de execução
- Saldos pré/pós ou mudanças no saldo dos tokens
- Mensagens de log ou instruções internas
- Unidades de computação consumidas
processed commitment.
Pressão de Retorno
O fluxo não armazena em buffer indefinidamente para consumidores lentos. Se o seu cliente ler muito lentamente e mais de 4.000 mensagens se acumularem no lado do servidor, o Helius fecha a conexão — você recebe um quadro de fechamento limpo do WebSocket. Dreno os quadros mais rapidamente do que eles chegam: mantenha trabalho pesado como decodificação de transações e lógica de estratégia fora do loop de recepção, e reconecte-se e re-subscreva após uma desconexão.Garantias de Entrega
A entrega é de melhor esforço, não garantida, e não há repetição histórica. Os clientes devem:- Reconectar e re-subscrever após uma conexão ser fechada.
- Desduplicar por assinatura de transação.
- Tratar o slot como uma observação, não como finalização.
- Conciliar contra um fluxo processado ou confirmado quando os resultados de execução importam.
Preços
preprocessedSubscribe está disponível em todos os planos pagos e medido em 0,1 créditos por mensagem — uma mensagem por transação entregue, cobrado do seu plano. Veja Créditos para detalhes.
Relacionados
Pré-confirmações
Transações transmitidas antes de se tornarem shreds — o sinal de transação mais precoce.
Shreds Brutos (UDP)
Pacotes de shreds não processados via UDP. Você implementa a desfragmentação.
transactionSubscribe
Transações pós-execução com filtragem rica e metadados de execução.