Logra una ejecución de cero slots con Sender y LaserStream

Introducción

Todos quieren que sus transacciones se confirmen lo más rápido posible. Sin embargo, a medida que la infraestructura de trading de Solana se vuelve más sofisticada y los mercados on-chain maduran, ya no basta con enviar una transacción y esperar lo mejor: la congestión, la competencia y las particularidades de la red convierten lo “rápido” en algo “frustrantemente poco confiable”.

El objetivo es sencillo: cuando aparece una señal —un precio cruza cierto umbral, una cuenta se actualiza o se invoca un programa—, la transacción que reacciona a esa señal debe confirmarse en el mismo slot. 

Esa es la esencia de la ejecución de cero slots, donde la detección y el envío ocurren con tal fluidez que las oportunidades se aprovechan antes de desaparecer en milisegundos. 

En la práctica, lograrlo es cada vez más difícil. Se requiere una ingesta de señales con latencia ultrabaja y una entrega confiable y determinista.

Helius ofrece ambas.

Al combinar LaserStream, que detecta eventos a velocidad vertiginosa, con Sender, que optimiza el envío de transacciones, Helius ofrece un pipeline de extremo a extremo diseñado específicamente para la ejecución de cero slots.

Sin infraestructura fragmentada, conjeturas ni ciclos desperdiciados: solo las señales más rápidas y las rutas más rápidas hacia los líderes, diseñadas para dar a tu operación de trading una ventaja competitiva.

LaserStream y Sender: un flujo de trabajo unificado

Sender complementa a LaserStream para crear un pipeline fluido de extremo a extremo para flujos de trading reactivos en Solana. En la práctica:

1. Usa LaserStream para escuchar señales: la ingesta a nivel de shred y el filtrado avanzado entregan eventos on-chain en tiempo real más rápido que cualquier otro pipeline.
2. Usa Helius Sender para reaccionar a las señales: las transacciones se envían simultáneamente mediante SWQoS y Jito, con enrutamiento global y entrega basada en el validador para maximizar la inclusión y minimizar la latencia.
3. Obtén ganancias: juntos, estos servicios hacen posible aprovechar oportunidades rentables en la práctica, no solo en teoría.

Con Helius, los desarrolladores obtienen una pila integrada verticalmente y diseñada específicamente para ofrecer velocidad y confiabilidad:

• No necesitas unir RPC de terceros, relays ni infraestructura propia.
• El enrutamiento global, los reintentos automáticos y la entrega basada en el validador están integrados.
• Transparente y justo: no hacemos sandwich activamente a los usuarios ni extraemos ningún tipo de MEV negativo de ellos.

Helius ya ofrece la mejor detección de señales de su clase con LaserStream. Entonces, ¿por qué no combinarla con el mejor envío de transacciones de su clase mediante Sender? 

Juntos, forman un único pipeline unificado para flujos de trabajo de Solana donde cada milisegundo cuenta. Deja que Helius gestione el ciclo de lectura y escritura para obtener resultados deterministas y rentables.

Entonces, ¿cómo funciona esto en la práctica?

Cómo encontrar la señal adecuada

Los arbitrajes y las liquidaciones pueden desaparecer en milisegundos en Solana. Detectar a tiempo la señal on-chain correcta es de vital importancia. Aquí, una “señal” se refiere a cualquier evento en tiempo real, como una transferencia de tokens, una actualización de cuenta o la invocación de un programa, que presenta una oportunidad de trading. Sin una ingesta con latencia ultrabaja, las ventajas desaparecen antes de poder aprovecharlas. Por eso, el streaming de datos confiable y de alta velocidad es esencial.

LaserStream es el servicio de streaming de datos de Solana de próxima generación de Helius. Combina la velocidad de la ingesta a nivel de shred con la confiabilidad y el alcance de un servicio distribuido globalmente, sin el costo ni los problemas operativos de ejecutar varios nodos dedicados.

El filtrado avanzado de LaserStream permite a los desarrolladores centrarse en señales específicas, como tipos de transacciones y actualizaciones de cuentas, además del streaming general de bloques. Para obtener una señal aún más temprana, Preprocessed Transactions transmite transacciones firmadas y decodificadas desde shreds hasta 8 ms antes del nivel de compromiso processed, y se combina con Sender exactamente de la misma manera.

La integración es fluida, ya que está diseñada como un reemplazo directo de Yellowstone gRPC y admite varios clientes, incluidos Rust, Go y TypeScript. 

Sin embargo, contar con el mejor servicio de streaming de datos de su clase es solo la mitad de la batalla, porque las oportunidades que presentan las señales tienen dos partes:

• Detección de eventos: identificar posibles señales.
• Envío reactivo de transacciones: crear, enviar y confirmar transacciones en respuesta a una posible señal.

LaserStream ofrece una ventaja en la detección de eventos y permite un envío reactivo de transacciones más eficaz. Sin embargo, LaserStream no es un servicio de envío de transacciones y, lamentablemente, confirmar transacciones de forma eficaz en Solana no es tan sencillo como realizar una simple llamada RPC a sendTransaction.

Optimización de los flujos de envío de transacciones

La inclusión de transacciones es un problema de optimización con múltiples variables que exige comprender en profundidad varias áreas de la arquitectura de Solana. Factores como el tiempo de llegada, el éxito de la simulación, los conflictos de bloqueo de cuentas, las comisiones asociadas y la prioridad interactúan para determinar cuándo se ejecuta una transacción on-chain. 

No considerar alguno de estos factores en tu flujo de detección de señales y creación de transacciones puede tener efectos perjudiciales y convertir una ventaja competitiva en una oportunidad perdida. 

Por ejemplo, aunque un trader detecte una señal milisegundos antes que sus competidores, una llegada tardía o comisiones insuficientes pueden hacer que la transacción falle on-chain un slot demasiado tarde y convertir una oportunidad rentable en ingresos perdidos.

Confirmar transacciones de forma eficaz requiere un flujo integral que maximice la prioridad, minimice la latencia y anticipe cualquier posible error en toda la pila. 

Para confirmar eficazmente una transacción en Solana hoy, un desarrollador debe:

Usar conexiones con stake

Las conexiones con stake aprovechan la calidad de servicio ponderada por stake (SWQoS) de Solana. Priorizan el tráfico de validadores con stake y RPC asociados para mejorar el acceso a los líderes y la velocidad de propagación. Los desarrolladores deben enrutar mediante conexiones con stake para minimizar los errores de propagación y mejorar los tiempos de llegada y las tasas de inclusión, sin depender únicamente de endpoints públicos que pueden sufrir congestión.

Agregar comisiones de prioridad dinámicas

Las comisiones de prioridad ayudan a mejorar la posición de una transacción en el planificador del líder durante la Banking Stage, donde un prio-graph (es decir, una cola de prioridad que tiene en cuenta las dependencias) ordena la ejecución on-chain según las comisiones por CU. Las comisiones de prioridad deben calcularse dinámicamente para evitar valores estáticos que causen pagos excesivos o insuficientes y dificulten la inclusión al acceder a un estado disputado.

Optimizar el uso de CU

Las unidades de cómputo (CU) cuantifican la demanda computacional de una transacción. Superar el presupuesto solicitado provoca errores de ejecución, mientras que solicitar demasiado aumenta los costos de prioridad. A menos que se especifique lo contrario, una transacción solicitará 200,000 CU de forma predeterminada. Las CU de una transacción pueden optimizarse al simularla de antemano para estimar su consumo y solicitar una cantidad específica con la instrucción SetComputeUnitLimit de Compute Budget Program.

Usar el nivel de compromiso adecuado para obtener datos

Los niveles de compromiso determinan la profundidad de confirmación de los datos obtenidos, como los blockhashes, que deben ser recientes para evitar que caduquen y garantizar la validez de una transacción. Usar el nivel confirmed para llamadas a getLatestBlockhash será considerablemente más rápido que usar finalized.

Omitir las verificaciones previas

Las verificaciones previas simulan una transacción en el nodo RPC antes de enviarla. Verifican firmas, instrucciones y ejecución para detectar errores con anticipación. Sin embargo, esto puede añadir más de 100 ms de latencia. Para flujos sensibles al tiempo y casos en los que los desarrolladores estén completamente seguros de enviar transacciones bien formadas, deben establecer el parámetro skipPreflight del método RPC sendTransaction en true.

Ten en cuenta que se recomienda enfáticamente crear el prototipo sin omitir las verificaciones previas, para garantizar que las transacciones tengan el formato correcto y se confirmen on-chain. Aunque aumenta la velocidad, omitirlas implica operar a ciegas: las transacciones pueden fallar por distintos motivos y no habrá información sobre la causa del error.

Establecer el parámetro maxRetries en cero

El parámetro maxRetries del método sendTransaction permite reenvíos automáticos del lado del RPC cuando se producen errores. Esto puede ser ineficiente; por ejemplo, puede enviar transacciones duplicadas con blockhashes obsoletos. Los desarrolladores deben establecer maxRetries en 0 para recuperar el control e implementar sus propios reintentos del lado del cliente. Estos deben usar pausas exponenciales, actualizar los blockhashes y las comisiones al retransmitir, y monitorear la altura del bloque para finalizar los intentos sin errores.

Considerar el uso de Jito

Las propinas de Jito permiten bundles off-chain mediante subastas de MEV, lo que garantiza la inclusión y el orden de las transacciones en bloques parciales. Esto es ideal para traders o arbitrajistas que necesitan ejecución al principio del bloque o atomicidad entre varias transacciones. Resulta extremadamente beneficioso para transacciones de alto valor, sensibles al tiempo o que compiten por un estado disputado. Sin embargo, estas subastas añaden una demora que podría empeorar los tiempos de confirmación frente al envío de una transacción bien optimizada mediante conexiones con stake. Los desarrolladores deben combinar estas subastas externas al protocolo con la confiabilidad de las conexiones con stake para confirmar cualquier tipo de transacción que necesiten lo más rápido posible, en todo momento.

Implementar estas prácticas recomendadas crea un efecto acumulativo que reduce drásticamente las tasas de error y mejora la confiabilidad de la confirmación. Sin embargo, gestionar esto manualmente, mantenerse al día con los últimos desarrollos del protocolo y adaptar los flujos a ellos requiere un esfuerzo de ingeniería considerable. Esto incluye ajustes constantes, cambios de infraestructura y manejo de errores: un esfuerzo que podría aprovecharse mejor en otras áreas.

Sender

Sender es el servicio de envío de transacciones con latencia ultrabaja de Helius. Aprovecha SWQoS y las subastas off-chain de Jito para lograr una inclusión optimizada para MEV, a la vez que incorpora enrutamiento geográfico para minimizar las demoras de propagación. 

Al enviar transacciones simultáneamente mediante conexiones con stake y la casa de subastas de Jito, Sender ofrece dos rutas de confirmación, mejora la confiabilidad y reduce los tiempos de ejecución sin consumir créditos adicionales.

Sender está disponible en todos los planes con un límite predeterminado de 6 TPS, que puede ampliarse previa solicitud. Está diseñado para traders, buscadores de MEV y aplicaciones de alta frecuencia que necesitan resultados deterministas. Sender complementa a LaserStream y permite flujos reactivos fluidos para la ejecución de cero slots.

Cómo funciona Sender

Sender procesa las transacciones igual que el procesamiento habitual: mediante una simple solicitud POST de JSON-RPC, donde la transacción se serializa en base64 y se envía a uno de sus endpoints. 

Sender tiene un endpoint HTTPS global que enruta automáticamente a la región geográfica más cercana. Por eso, se recomienda para aplicaciones frontend que quieran evitar problemas de CORS. 

Sender también tiene varios endpoints HTTP regionales para optimizar la latencia entre servidores (por ejemplo, Salt Lake City, Tokio y Fráncfort).

Es importante destacar que no hay autenticación mediante claves de API. Es un servicio esencial, sin intermediarios entre la recepción y el envío de la transacción, lo que lo hace ideal para casos de uso con latencia ultrabaja. 

Para usar Sender eficazmente, una transacción debe prepararse de la siguiente manera:

• Una propina mínima de 0.0002 SOL para Jito o 0.000005 SOL (5,000 lamports) para envíos exclusivos mediante SWQoS, que puede especificarse al añadir ?swqos_only=true al endpoint
• El parámetro skipPreflight debe establecerse en true: Sender está optimizado para priorizar la velocidad sobre la validación de transacciones
• El parámetro maxRetries debe establecerse en 0: los reintentos añaden latencia
• Deben añadirse comisiones de prioridad para aumentar la prioridad de la transacción en la Banking Stage del líder

Todas las transacciones enviadas mediante Sender deben incluir tanto una propina como comisiones de prioridad. 

Se requiere una propina para acceder a la infraestructura de Jito y a la inclusión de transacciones basada en subastas. Las comisiones de prioridad indican al líder (es decir, el validador responsable de procesar la transacción) la disposición a pagar por un procesamiento prioritario. Esto ofrece un doble beneficio: las propinas dan acceso a la infraestructura de subastas de Jito, mientras que las comisiones de prioridad mejoran la prioridad de una transacción. Ambas trabajan en conjunto para maximizar su inclusión.

Recomendamos obtener las propinas dinámicamente mediante la API de valor mínimo de propinas de Jito (por ejemplo, tomar el percentil 75 y añadir un pequeño margen) y las comisiones de prioridad mediante la API de comisiones de prioridad de Helius. 

Una vez enviada, Sender distribuirá la transacción en paralelo mediante SWQoS y Jito para maximizar su inclusión sin costos adicionales. 

También recomendamos mantener activas las conexiones durante períodos de inactividad (es decir, >1 minuto) con un ping a /ping (es decir, https://sender.helius-rpc.com/ping) para evitar arranques en frío. Además, recomendamos seguir las prácticas recomendadas para el envío de transacciones para garantizar aún más una inclusión óptima. 

Cómo empezar

Así puedes comenzar a hacer trading con LaserStream y Sender:

Trabajar con LaserStream

LaserStream ofrece la misma experiencia de desarrollo que gRPC. Solo cambia el endpoint y la clave de API para que apunten a LaserStream y aprovecha de inmediato todos sus beneficios.

Para el código existente, migrar es tan sencillo como:

// Before: Using standard Yellowstone gRPC
const connection = new GeyserConnection(
  "your-current-endpoint.com",
  { token: "your-current-token" }
);

// After: Using LaserStream (just change the endpoint and token)
const connection = new GeyserConnection(
  "https://laserstream-mainnet-ewr.helius-rpc.com", // Choose the closest region to you
  { token: "your-helius-api-key" }
);

Recomendamos trabajar con uno de los clientes de LaserStream para agilizar el proceso de desarrollo.

Por ejemplo, abrir una suscripción es tan sencillo como:

// Using the dedicated LaserStream SDK
import { subscribe, CommitmentLevel, LaserstreamConfig } from 'helius-laserstream';

const config = {
  apiKey: "your-helius-api-key",
  endpoint: "https://laserstream-mainnet-ewr.helius-rpc.com" // Choose the closest region to you
};

// The SDK automatically handles:
// - Connection management
// - Reconnection with backoff
// - Historical replay after disconnects
// - Subscription management
await subscribe(config, subscriptionRequest, handleData, handleError);

Prueba LaserStream gratis

¿Quieres probar LaserStream antes de migrar? Obtén una prueba gratuita para medir la latencia de LaserStream, compararla con otras soluciones de streaming y evaluarla para tu caso de uso específico.

Trabajar con Sender

Helius Sender está disponible para todos los usuarios y no consume créditos adicionales. No se requieren planes de pago ni acceso especial.

Para comenzar, crea una cuenta en el panel de Helius. Luego, ve a la sección Claves de API y copia la clave proporcionada. La necesitarás para obtener blockhashes y confirmar la transacción, ya que Sender solo gestiona el envío.

A continuación se muestra una transferencia sencilla de SOL con Sender. Este ejemplo incluye todos los componentes necesarios: propina, comisión de prioridad y omisión de las verificaciones previas.

import { pipe } from "@solana/kit";
import {
  createSolanaRpc,
  createTransactionMessage,
  setTransactionMessageFeePayerSigner,
  setTransactionMessageLifetimeUsingBlockhash,
  appendTransactionMessageInstruction,
  signTransactionMessageWithSigners,
  lamports,
  getBase64EncodedWireTransaction,
} from "@solana/kit";
import { getTransferSolInstruction } from "@solana-program/system";
import {
  getSetComputeUnitLimitInstruction,
  getSetComputeUnitPriceInstruction,
} from "@solana-program/compute-budget";

(async () => {
  const HELIUS_API_KEY = "your_api_key";
  const PRIV_KEY_B58 = "your_private_key";
  const RECIPIENT = "recipient_address";
  const TIP_ACCOUNTS = [
    "4ACfpUFoaSD9bfPdeu6DBt89gB6ENTeHBXCAi87NhDEE",
    "D2L6yPZ2FmmmTKPgzaMKdhu6EWZcTpLy1Vhx8uvZe7NZ",
    "9bnz4RShgq1hAnLnZbP8kbgBg1kEmcJBYQq3gQbmnSta",
    "5VY91ws6B2hMmBFRsXkoAAdsPHBJwRfBht4DXox3xkwn",
    "2nyhqdwKcJZR2vcqCyrYsaPVdAnFoJjiksCXJ7hfEYgD",
    "2q5pghRs6arqVjRvT5gfgWfWcHWmw1ZuCzphgd5KfWGJ",
    "wyvPkWjVZz1M8fHQnMMCDTQDbkManefNNhweYk5WkcF",
    "3KCKozbAaF75qEU33jtzozcJ29yJuaLJTy2jFdzUY8bT",
    "4vieeGHPYPG2MmyPRcYjdiDmmhN3ww7hsFNap8pVN3Ey",
    "4TQLFNWK8AovT1gFvda5jfw2oJeRMKEmw7aH6MGBJ3or"
  ];

  // Load signer from base58 private key
  const ownerSigner = await createKeyPairSignerFromBytes(bs58.decode(PRIV_KEY_B58));

  // Init RPC and fetch blockhash
  const rpc = createSolanaRpc(`https://mainnet.helius-rpc.com/?api-key=${HELIUS_API_KEY}`);
  const { value: blockhash } = await rpc.getLatestBlockhash().send();

  // Build and sign transaction
  const tx = pipe(
    createTransactionMessage({ version: 0 }),
    (m) => setTransactionMessageFeePayerSigner(ownerSigner, m),
    (m) => setTransactionMessageLifetimeUsingBlockhash(blockhash, m),
    (m) => appendTransactionMessageInstruction(getSetComputeUnitLimitInstruction({ units: 1000 }), m),
    (m) => appendTransactionMessageInstruction(getSetComputeUnitPriceInstruction({ microLamports: 200_000 }), m),
    (m) =>
      appendTransactionMessageInstruction(
        getTransferSolInstruction({
          source: ownerSigner,
          destination: RECIPIENT,
          amount: lamports(1_000_000n), // 0.001 SOL
        }),
        m
      ),
    (m) =>
      appendTransactionMessageInstruction(
        getTransferSolInstruction({
          source: ownerSigner,
          destination: TIP_ACCOUNTS[Math.floor(Math.random() * TIP_ACCOUNTS.length)],
          amount: lamports(200_000n), // 0.0002 SOL
        }),
        m
      )
  );

  const signedTx = await signTransactionMessageWithSigners(tx);
  const base64Tx = getBase64EncodedWireTransaction(signedTx);

  // Send via Sender
  const res = await fetch("https://sender.helius-rpc.com/fast", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      jsonrpc: "2.0",
      id: Date.now().toString(),
      method: "sendTransaction",
      params: [
        base64Tx,
        { encoding: "base64", skipPreflight: true, maxRetries: 0 },
      ],
    }),
  });

  const { result: sig, error } = await res.json();
  if (error) throw new Error(error.message);

  console.log("Transaction sent: ", sig);
  console.log(`Explorer: https://orb.helius.dev/tx/${sig}?cluster=mainnet`);
})();

Enviar una transacción mediante Sender es sencillo con nuestro SDK de Node.js. El método `sendTransactionWithSender` gestiona dinámicamente todos los cálculos de unidades de cómputo y comisiones, incluidas las propinas de Jito: 

import { createHelius } from "helius-sdk";
import { address, createKeyPairSignerFromBytes, lamports } from "@solana/kit";
import { getTransferSolInstruction } from "@solana-program/system";
import bs58 from "bs58";

(async () => {
  const apiKey = ""; // From Helius dashboard
  const helius = createHelius({ apiKey });

  try {
    const feePayerSigner = await createKeyPairSignerFromBytes(
      bs58.decode(process.env.FEEPAYER_SECRET ?? "")
    );

    const toPubkey = address("your_to_address");

    const transferIx = getTransferSolInstruction({
      amount: lamports(1_000_000n), // 0.001 SOL
      destination: toPubkey,
      source: feePayerSigner,
    });

    const sig = await helius.tx.sendTransactionWithSender({
      signers: [feePayerSigner],
      instructions: [transferIx],
      version: 0,
      commitment: "confirmed",
      minUnits: 1_000,
      bufferPct: 0.1,
      region: "US_EAST",
      swqosOnly: true,
      pollTimeoutMs: 60_000,
      pollIntervalMs: 2_000,
    });

    console.log("Confirmed signature:", sig);
    console.log(
      `Explorer link: https://orb.helius.dev/tx/${sig}?cluster=mainnet`
    );
  } catch (error) {
    console.error("Error:", error);
  }
})();

Este proceso también puede agilizarse con nuestro SDK de Rust mediante el método send_smart_transaction_with_sender().

Trabajar con LaserStream y Sender

El verdadero poder de Helius surge al combinar LaserStream y Sender en un único flujo de trabajo. LaserStream revela señales accionables en cuanto aparecen, mientras que Sender garantiza que las transacciones que reaccionan a ellas se confirmen lo más rápido posible.

El patrón es sencillo:

• Suscríbete con LaserStream para escuchar cambios de cuentas, invocaciones de programas o transferencias.
• Crea una transacción en respuesta a una señal determinada.
• Envía la transacción mediante Sender para garantizar la ruta más rápida y confiable hacia la inclusión.

Este es un ejemplo mínimo que muestra el flujo completo en la práctica: 

import bs58 from "bs58";
import { subscribe, CommitmentLevel } from "helius-laserstream";
import {
  pipe,
  createSolanaRpc,
  createTransactionMessage,
  setTransactionMessageFeePayerSigner,
  setTransactionMessageLifetimeUsingBlockhash,
  appendTransactionMessageInstruction,
  signTransactionMessageWithSigners,
  getBase64EncodedWireTransaction,
  createKeyPairSignerFromBytes,
  lamports,
  address,
} from "@solana/kit";
import { getTransferSolInstruction } from "@solana-program/system";
import {
  getSetComputeUnitLimitInstruction,
  getSetComputeUnitPriceInstruction,
} from "@solana-program/compute-budget";

const HELIUS_API_KEY = "your_api_key";
const LASERSTREAM_ENDPOINT = "https://laserstream-mainnet-ewr.helius-rpc.com"; // Pick the nearest region
const PRIV_KEY_B58 = "your_private_key";
const RECIPIENT = "recipient_address";
const TIP_ACCOUNTS = [
    "4ACfpUFoaSD9bfPdeu6DBt89gB6ENTeHBXCAi87NhDEE",
    "D2L6yPZ2FmmmTKPgzaMKdhu6EWZcTpLy1Vhx8uvZe7NZ",
    "9bnz4RShgq1hAnLnZbP8kbgBg1kEmcJBYQq3gQbmnSta",
    "5VY91ws6B2hMmBFRsXkoAAdsPHBJwRfBht4DXox3xkwn",
    "2nyhqdwKcJZR2vcqCyrYsaPVdAnFoJjiksCXJ7hfEYgD",
    "2q5pghRs6arqVjRvT5gfgWfWcHWmw1ZuCzphgd5KfWGJ",
    "wyvPkWjVZz1M8fHQnMMCDTQDbkManefNNhweYk5WkcF",
    "3KCKozbAaF75qEU33jtzozcJ29yJuaLJTy2jFdzUY8bT",
    "4vieeGHPYPG2MmyPRcYjdiDmmhN3ww7hsFNap8pVN3Ey",
    "4TQLFNWK8AovT1gFvda5jfw2oJeRMKEmw7aH6MGBJ3or"
  ];

// Example: scope the stream to a program you care about
const PROGRAM_OWNER_TO_WATCH = "11111111111111111111111111111111";

(async () => {
  // Setup signer and fetch blockhash
  const ownerSigner = await createKeyPairSignerFromBytes(bs58.decode(PRIV_KEY_B58));
  const rpc = createSolanaRpc(`https://mainnet.helius-rpc.com/?api-key=${HELIUS_API_KEY}`);

  // Setup LaserStream config and request
  const config = {
    apiKey: HELIUS_API_KEY,
    endpoint: LASERSTREAM_ENDPOINT,
  };

  // We keep it scoped to a given program for less noise
  const request = {
    accounts: {
      watch: {
        account: [],
        owner: [PROGRAM_OWNER_TO_WATCH],
        filters: [],
      },
    },
    commitment: CommitmentLevel.PROCESSED, // Can also change to CONFIRMED for more reliability
    slots: {},
    transactions: {},
    transactionsStatus: {},
    blocks: {},
    blocksMeta: {},
    entry: {},
    accountsDataSlice: [],
  };

  // On signal, build and send a reactive transaction via Sender
  const handleData = async () => {
    // Fresh blockhash for lifetime
    const { value: blockhash } = await rpc.getLatestBlockhash().send();

    // Build the transaction with compute-budget ixs first, then user ixs
    const tx = pipe(
      createTransactionMessage({ version: 0 }),
      (m) => setTransactionMessageFeePayerSigner(ownerSigner, m),
      (m) => setTransactionMessageLifetimeUsingBlockhash(blockhash, m),
      (m) => appendTransactionMessageInstruction(getSetComputeUnitLimitInstruction({ units: 100_000 }), m),
      (m) => appendTransactionMessageInstruction(getSetComputeUnitPriceInstruction({ microLamports: 200_000 }), m),
      (m) =>
        // In prod, this could be a buy / sell instruction
        appendTransactionMessageInstruction(
          getTransferSolInstruction({
            source: ownerSigner,
            destination: address(RECIPIENT),
            amount: lamports(1_000_000n), // 0.001 SOL
          }),
          m
        ),
      (m) =>
        appendTransactionMessageInstruction(
          getTransferSolInstruction({
            source: ownerSigner,
            destination: address(TIP_ACCOUNTS[Math.floor(Math.random() * TIP_ACCOUNTS.length)]),
            amount: lamports(200_000n), // 0.0002 SOL tip
          }),
          m
        )
    );

    const signedTx = await signTransactionMessageWithSigners(tx);
    const base64Tx = getBase64EncodedWireTransaction(signedTx);

    // Send via Sender (i.e., skip preflight and no RPC-side retries)
    const res = await fetch("https://sender.helius-rpc.com/fast", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({
        jsonrpc: "2.0",
        id: Date.now().toString(),
        method: "sendTransaction",
        params: [base64Tx, { encoding: "base64", skipPreflight: true, maxRetries: 0 }],
      }),
    });

    const { result: sig, error } = await res.json();
    if (error) throw new Error(error.message);

    console.log("Reactive transaction sent: ", sig);
    console.log(`Explorer:  https://orb.helius.dev/tx/${sig}?cluster=mainnet`);
  };

  const handleError = console.error;

  // Start the stream (signals → reactive sends)
  const stream = await subscribe(config, request, handleData, handleError);
  console.log(`LaserStream subscription started (id: ${stream.id})`);
})();

Por qué Helius

Helius destaca como la opción principal para optimizar flujos de transacciones en Solana gracias a nuestra posición como el mayor validador de la red por stake. Por lo tanto, el ancho de banda con stake no es un problema para nosotros. Esto elimina eficazmente los cuellos de botella y errores relacionados con la pérdida de prioridad de transacciones o de paquetes durante períodos de congestión, y ofrece a tus transacciones una ruta directa y de alta prioridad hacia los líderes, sin limitaciones. 

Al integrar profundamente diversas optimizaciones de hardware y software con nuestro ancho de banda con stake, Helius sigue dominando como el proveedor líder y ofrece la menor latencia promedio de slots, lo que demuestra nuestra experiencia integral en Solana. 

Nuestro compromiso con Solana nos mantiene a la vanguardia de las investigaciones y contribuciones más recientes. Por ejemplo, los hallazgos de Chorus One sobre la latencia de las transacciones muestran que SWQoS a menudo puede superar a Jito al reducir el tiempo de inclusión, especialmente para usuarios cuya latencia p95 supera los 40 segundos. Sender enruta de forma inteligente y simultánea mediante SWQoS y Jito, lo que garantiza la máxima confiabilidad para todo tipo de transacciones. 

En última instancia, tener un stake considerable y enrutar las transacciones mediante conexiones con stake es el factor más importante para reducir el tiempo de inclusión.

Más rápido

LaserStream reduce la latencia y la incertidumbre. Cuanto antes llega una señal, más predecibles son los resultados. En combinación con Sender, las transacciones enviadas en respuesta a una señal ofrecen mayor confianza operativa, decisiones más inteligentes y una confiabilidad superior. Este pipeline unificado no solo optimiza la velocidad de forma aislada, sino también la confianza.

Con LaserStream, los desarrolladores saben que trabajan con el mejor servicio de streaming de datos del mercado. Con Sender, pueden tener la certeza de que sus transacciones se enrutan mediante las rutas más rápidas y confiables hacia los líderes de bloques. 

Juntos, crean un efecto acumulativo:

• Menor latencia E2E: desde la detección del evento hasta la inclusión de la transacción, cada paso se reduce a milisegundos
• Mayores tasas de éxito: las transacciones se confirman donde y cuando deben, por lo que las oportunidades se aprovechan en lugar de perderse
• Menor carga de ingeniería: puedes centrarte más en el producto, la estrategia y el ajuste de los algoritmos de trading, en vez de gestionar y modificar nodos dedicados para optimizar el envío de transacciones
• Ejecución de cero slots: LaserStream muestra notificaciones mientras las transacciones se ejecutan en un slot determinado, no después de que el slot termina. Esto significa que una transacción enviada en respuesta a una notificación podría confirmarse en el mismo slot 

En la práctica, esto significa que los traders aprovechan más arbitrajes, los liquidadores ganan más subastas y las aplicaciones de alta frecuencia ofrecen experiencias de usuario más fluidas. La ejecución de cero slots no es un ideal teórico e inalcanzable, sino un flujo repetible que solo puede lograrse con Helius.

Visita el panel de Helius y comienza hoy mismo.