Skip to main content
Inicie uma assinatura para Pré-confirmações — transações entregues na etapa de transações agendadas, antes de serem coletadas em entradas e convertidas em fragmentos. Este é o sinal de transação com menor latência que Helius oferece. Uma assinatura transmite tanto pré-confirmações Helius quanto pré-confirmações BAM; configure includeBam: false para receber apenas pré-confirmações Helius.

Endpoints

preconfSubscribe é servido a partir do endpoint Helius Gatekeeper:
  • wss://beta.helius-rpc.com/?api-key=<API_KEY>
O hostname beta refere-se à implantação do Gatekeeper, não à maturidade das Pré-confirmações — ele se tornará o endpoint padrão à medida que o tráfego migrar para o Gatekeeper.
O fluxo não é contínuo. A cobertura escala com a participação da rede enviando para Helius ou executando BAM, então espere slots sem mensagens — lide com essas lacunas de maneira adequada. Veja Cobertura.

Autorizações

string
obrigatório
Sua chave de API da Helius, passada como o parâmetro de consulta api-key. Requer um plano Profissional ou superior.

Corpo

array
Opcional. Omita params para receber toda transação agendada tanto de Helius quanto de BAM. Para restringir o fluxo, passe um objeto de filtro como o primeiro elemento — a filtragem ocorre no lado do servidor, então você paga e recebe apenas as transações de seu interesse.
Um valor de conta inválido ou código de região não reconhecido retorna erro JSON-RPC -32602 (parâmetros inválidos). Filtros de conta correspondem a mais do que as chaves de conta estáticas da transação — Helius resolve v0 tabelas de busca de endereços no lado do servidor, então accountInclude, accountExclude, e accountRequired também correspondem a contas que uma transação carrega através de um ALT.

Códigos de região

Para pré-confirmações Helius, a região é onde Helius ingeriu a transação. Para pré-confirmações BAM, é o endpoint regional BAM que emitiu a pré-confirmação, não onde Helius a ingeriu. Os endpoints de Singapura e Dallas do BAM são mapeados para sgp e dal.

Resposta

integer
ID da assinatura (necessário para cancelar a inscrição)

Notificações

Após o reconhecimento JSON, as notificações são entregues como quadros WebSocket binários (não JSON). Pré-confirmações Helius e BAM compartilham o mesmo layout. Cada quadro é um layout de bytes empacotado carregando uma única transação agendada: O payload não tem campo de origem. Não deduza uma origem BAM de tx_index = 0 e status = 2, pois pré-confirmações Helius podem carregar os mesmos valores.
Apenas pré-confirmações Helius carregam um status de execução. Pré-confirmações Helius relatam 0 (falhou) ou 1 (sucesso) quando o validador o fornece, e 2 apenas quando não está disponível. Pré-confirmações BAM sempre relatam 2 (desconhecido), então status sozinho não pode informá-lo se uma transação de origem BAM teve sucesso. Se sua estratégia depende do status de execução, configure includeBam: false ou confirme o resultado na blockchain.
Sempre leia e verifique primeiro o byte version. Atualmente é 1. Se Helius precisar atualizar o formato de payload, a versão será incrementada — faça uma ramificação nele para que seu decodificador continue funcionando através das mudanças no esquema.
Uma pré-confirmação é um sinal antecipado, não uma garantia. A transação ainda não foi confirmada na blockchain e ainda pode falhar ou ser descartada. Confirme a confirmação através de verificações de compromisso padrão antes de tratá-la como final.

Decodificação da transação

Os bytes da transação são encaminhados exatamente como o validador os serializou, na codificação padrão para a versão da transação. Transações Legado e v0 usam o layout com assinaturas primeiro que bincode produz. Transação v1 (SIMD-0385) usa um layout com mensagem primeiro com assinaturas no final, então bincode falha em payloads v1. Use um decodificador que lide com todas as versões. Em Rust, agave-transaction-view analisa transações legadas, v0 e v1 no local e é a opção recomendada; wincode com um SDK Solana atual VersionedTransaction também funciona. Em JavaScript, certifique-se de que sua versão de biblioteca suporta transações v1. Consulte o guia para um exemplo em Rust.

Notificações duplicadas

Pré-confirmações Helius e BAM são desduplicadas por fonte, não entre fontes. Uma pequena parte das transações chega ao Helius por ambos, então você pode receber a mesma assinatura duas vezes, e as duas cópias podem relatar slots diferentes. Desduplique por assinatura no cliente e torne as ações acionadas por transações idempotentes. Consulte o guia.

Preço

Pré-confirmações requerem um plano Profissional ou superior e custam 10 créditos por mensagem — uma mensagem por transação transmitida. Veja Créditos para detalhes. A cobrança é por mensagem, não por assinatura única. Uma transação entregue tanto por Helius quanto por BAM conta duas vezes. Configure includeBam: false se você deseja apenas pré-confirmações Helius.

Relacionados

Visão geral das pré-confirmações

O que são as Pré-confirmações e onde elas se encaixam no pipeline do validador.

preconfUnsubscribe

Pare uma assinatura pelo seu ID.