Skip to main content
Parsed Streams está em beta fechado. O acesso está limitado a ids de projeto em lista branca por enquanto, e a API pode mudar antes da disponibilidade geral. Para participar do beta fechado, inscreva-se aqui.

​
O que é Parsed Streams?

Parsed Streams é um serviço WebSocket que monitora todas as transações Solana confirmadas (excluindo transações de voto), decodifica e envia para você as transações que correspondem a um filtro que você define. Você diz “Eu me importo com instruções de rota do Jupiter” ou “Eu me importo com qualquer coisa que toque esta conta”, e o servidor faz a monitoração, decodificação e correspondência para você. Você recebe transações inteiras, já decodificadas: cada instrução com argumentos nomeados e contas nomeadas, além da taxa, a lista completa de chaves de conta, um summary ao nível da transação do que aconteceu, as transferências de SOL e tokens, e apontadores para as instruções exatas que corresponderam ao seu filtro. Todos os dados são entregues com compromisso confirmado.

​
O modelo mental

Se você já conhece os internos do Solana, pule. Se não, este é o modelo em que toda a API é construída. Uma transação é uma mensagem assinada. Ela nomeia um pagador de taxa, lista cada conta que irá tocar e carrega uma lista de instruções. Quando você olha para uma, vê: uma assinatura (seu id único), o slot em que pousou, a taxa paga, as chaves das contas, se teve sucesso ou falha, e as instruções. Uma instrução é uma ação: execute este programa, com esta entrada, usando essas contas. Uma troca no Jupiter, uma transferência de token, um memorando. Uma transação geralmente carrega várias instruções, e elas são executadas em ordem. Programas podem chamar outros programas. Quando Jupiter executa uma troca, ele não move os tokens por si só. Sua instrução de rota chama o programa de token para mover tokens e os programas de troca que mantêm a liquidez. Essas chamadas aninhadas também são instruções, chamadas de instruções internas (ou CPIs, invocações entre programas). Isso é importante quando você cria um filtro: muita da atividade real, como os movimentos de tokens dentro de uma troca, ocorre nas instruções internas, então seu filtro as corresponde por padrão. Se você deseja apenas as instruções para as quais um usuário assinou, defina includeCpi como falso. Contas são as coisas na cadeia com as quais uma instrução trabalha: carteiras, saldos de tokens, pools, mints. Cada instrução as carrega como uma lista ordenada de endereços, e a ordem é o contrato: o programa define o que cada posição significa. O programa de token, por exemplo, espera que a conta de onde os tokens serão retirados venha primeiro, depois a conta para recebê-los, e então o proprietário aprovando a transferência. Papéis dão nomes a essas posições. A maioria dos programas bem conhecidos publica um manual legível por máquina para sua interface, chamado de IDL. O manual lista todas as instruções que o programa tem, o que seus campos de dados significam e para que serve cada posição de conta. A Helius mantém um catálogo desses manuais para milhares de programas. Usando isso, uma lista de endereços bruta se transforma em contas nomeadas: para uma transferência de token, a posição 0 se torna source, a posição 1 se torna destination, a posição 2 se torna authority. Em vez de adivinhar o que o terceiro endereço significa, você lê {"name": "authority", "pubkey": "9xQe...", "isSigner": true}. Esses nomes são os papéis pelos quais você pode filtrar. Decodificação é a mesma ideia aplicada aos dados de entrada da instrução. No fio, esses dados são bytes opacos. Com o manual do programa, os bytes se tornam valores nomeados: {"in_amount": "1000000", "slippage_bps": 50}. Nem toda instrução pode ser decodificada, então cada uma cai em um dos três estados que você pode ver diretamente de seus campos:
  • Decodificado: a instrução carrega um objeto decoded com args nomeados e accounts nomeados.
  • Reconhecido: além de decoded, a instrução carrega um summary com um type (como swap), um description legível por humanos, e uma carga útil parsedData estruturada, como metadados de troca com quantidades e mints.
  • Não decodificado: o programa ou instrução não está no catálogo, decoded é null, e a instrução carrega os bytes brutos (rawData) e a lista de endereços simples (rawAccounts) em vez disso, então você sempre tem algo com que trabalhar.
Esse é todo o modelo, e seu filtro é construído diretamente a partir dele:
  • programs: qual programa a instrução chama
  • instructionNames: como o manual do programa chama essa ação
  • accounts.include: quais endereços toca
  • accounts.roles: qual posição nomeada deve conter qual endereço
  • includeCpi e includeFailed: se instruções internas e transações falhas contam
Filtros selecionam instruções; notificações entregam a transação inteira.

​
Como se compara

vs Enhanced WebSockets

Enhanced WebSockets transmite transações inteiras ou atualizações de conta sem decodificação. Parsed Streams corresponde ao nível de instrução e decodifica tudo para você.

vs LaserStream gRPC

LaserStream é um firehose gRPC de alta capacidade que você filtra e decodifica no cliente. Parsed Streams é uma API WebSocket que filtra e decodifica no servidor.

vs Parsed Events

Parsed Events aplica a mesma decodificação a transações históricas: parse assinaturas ou percorra o histórico de um endereço sob demanda via REST e GraphQL. Parsed Streams envia novas transações assim que elas chegam.

​
Programas suportados

Parsed Streams decodifica 3.600+ programas de suas IDLs na cadeia, além de programas principais como SPL Token, Token-2022 e o System Program através de decodificadores integrados. Você pode filtrar por qualquer endereço de programa. Instruções que o serviço não pode decodificar são transmitidas como dados de instrução brutos. Alguns dos programas decodificados mais usados:
Não vê um programa? Provavelmente ainda está no catálogo. Chame describeProgram com seu endereço para ver suas instruções, eventos e papéis de conta.

​
Acesso

Somente ids de projeto em lista branca podem se conectar durante o beta fechado. A equipe da Helius compartilha o endpoint de conexão com você quando seu projeto está na lista branca. Autentique-se com a chave da API do seu projeto, passada como o parâmetro de consulta api-key (ou o cabeçalho x-api-key). A chave é verificada quando a conexão é aberta: uma chave ausente, inválida ou não listada é rejeitada com HTTP 401, e um projeto no seu limite de conexões recebe HTTP 429.

​
Como começar

Início Rápido

Conecte-se, envie seu primeiro filtro e leia uma notificação.

Acompanhe Trocas Jupiter

Construa e assine um filtro real usando descoberta de programa.

Acompanhe Mints Pump.fun

Um ouvinte seguro para reconexão que registra cada nova implantação de token Pump.fun.

Gerenciando Reconexões

Detecte desconexões, retroceda, reassine e preencha slots perdidos.