Skip to main content
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.
preprocessedSubscribe é um sinal de pré-execução de melhor esforço, não um nível de compromisso. Uma transação transmitida pode falhar, ser descartada ou cair em um fork diferente. Reconcilie com um fluxo processado ou confirmado antes de tratá-la como final.

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:
Cada chave de API é limitada a 10 conexões/inscrições simultâneas.

Inscrever-se

Envie uma solicitação JSON-RPC com o método preprocessedSubscribe. params carrega os filtros de conta e é obrigatório — accountInclude e accountRequired devem especificar pelo menos uma conta entre eles (veja Filtragem):
O servidor reconhece a inscrição com um quadro de texto JSON contendo o ID da inscrição:
Após este reconhecimento, as atualizações de transação chegam como quadros WebSocket binários — veja Carga útil de notificação.

Filtragem

Toda inscrição é delimitada pelos filtros de conta em params. 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.
  • accountInclude e accountRequired devem 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ão accountInclude, 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 que bincode 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-view analisa 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 em VersionedTransaction.
  • 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.deserialize apenas lidam com legados e v0. Use @solana/kit 8.0+ ou @solana/web3.js v3. 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
Considere como receber a “proposta” sem o “resultado” — você vê o que o remetente tentou fazer, mas não o que realmente aconteceu. Atualizações de estado de conta e programa ainda não existem nesta fase; se você precisa de estado de conta em tempo real, use LaserStream gRPC at 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:
  1. Reconectar e re-subscrever após uma conexão ser fechada.
  2. Desduplicar por assinatura de transação.
  3. Tratar o slot como uma observação, não como finalização.
  4. 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.