Busca en todas las páginas de la documentación
Una transacción de Solana viaja desde tu cliente a través de la red hasta un líder productor de bloques, se ejecuta atómicamente en la cadena y recibe votos hasta alcanzar tu nivel de compromiso elegido. Comprender esta ruta explica la latencia, los fallos y la estrategia de reintentos.
Tarjeta de referencia rápida - lista para copiar y pegar.
Cliente construye → Firma → sendTransaction → Líder recibe (Gulf Stream)
→ Ordenamiento PoH → Ejecución Sealevel → Propagación de bloque (Turbine)
→ Votos del validador (TowerBFT) → Sondeo de confirmación RPCimport { createSolanaRpc, createSolanaRpcSubscriptions } from "@solana/kit";
const rpc = createSolanaRpc("https://api.devnet.solana.com");
const rpcSubs = createSolanaRpcSubscriptions("wss://api.devnet.solana.com");
// Después de que sendTransaction devuelva una firma:
const sub = await rpcSubs.signatureNotifications(signature, { commitment: "confirmed" });Cuándo usar esto:
import {
createSolanaRpc,
createSolanaRpcSubscriptions,
createKeyPairSignerFromBytes,
createTransactionMessage,
setTransactionMessageFeePayer,
setTransactionMessageLifetimeUsingBlockhash,
appendTransactionMessageInstruction,
signTransactionMessageWithSigners,
getSignatureFromTransaction,
pipe,
} from "@solana/kit";
import { getTransferSolInstruction } from "@solana-program/system";
import { readFileSync } from "node:fs";
const rpc = createSolanaRpc("https://api.devnet.solana.com");
const rpcSubs = createSolanaRpcSubscriptions("wss://api.devnet.solana.com");
const secret = Uint8Array.from(
JSON.parse(readFileSync(process.env.HOME + "/.config/solana/id.json", "utf8")),
);
const signer = await createKeyPairSignerFromBytes(secret);
// 1. Obtener blockhash reciente (vida útil de la transacción)
const { value: blockhash } = await rpc.getLatestBlockhash().send();
// 2. Construir y firmar
const message = pipe(
createTransactionMessage({ version: 0 }),
(m) => setTransactionMessageFeePayer(signer.address, m),
(m) => setTransactionMessageLifetimeUsingBlockhash(blockhash, m),
(m) =>
appendTransactionMessageInstruction(
getTransferSolInstruction({
source: signer.address,
destination: signer.address, // demo de autotransferencia
amount: 1n,
}),
m,
),
);
const signed = await signTransactionMessageWithSigners(message, [signer]);
const signature = getSignatureFromTransaction(signed);
// 3. Enviar
await rpc.sendTransaction(signed, { encoding: "base64" }).send();
console.log("Enviado:", signature);
// 4. Esperar confirmación
const notifications = await rpcSubs.signatureNotifications(signature, {
commitment: "confirmed",
});
for await (const note of notifications) {
if (note.value.err) {
console.error("Falló en la cadena:", note.value.err);
} else {
console.log("Confirmado en el slot:", note.context.slot);
}
break;
}Lo que esto demuestra:
sendTransaction la transmite al RPC, que la reenvía a través de Gulf StreamsignatureNotifications de WebSocket es más eficiente que el sondeo de getSignatureStatusesconfirmed significa que una supermayoría votó sobre el bloque; finalized es más fuerte| Nivel | Latencia | Seguridad | Caso de uso |
|---|---|---|---|
processed | ~400 ms | Puede ser descartada/reordenada | Solo pistas de UI |
confirmed | ~1-2 s | Supermayoría votó | La mayoría de las acciones de dapp |
finalized | ~12-13 s | Enraizada, sin retroceso | Liquidaciones de alto valor |
processed como final - las bifurcaciones pueden reordenar a este nivel. Solución: esperar confirmed o finalized antes de una UX irreversible.skipPreflight: true oculta los fallos de simulación. Solución: simular primero en desarrollo; decodificar errores antes de reintentar.
| Alternativa | Usar cuando | No usar cuando |
|---|---|---|
| Suscripción de firma WebSocket | UX de confirmación en tiempo real | Scripts CLI de un solo uso |
Sondeo getSignatureStatuses | Scripts simples | Aplicaciones de alto rendimiento |
skipPreflight: true | Transacciones conocidas como buenas, latencia crítica | Desarrollo y depuración |
| Nonce duradero | Sesiones de firma de larga duración | Transacciones de usuario normales |
El RPC reenvía tu transacción a los líderes a través de Gulf Stream. Todavía no está confirmada, solo enviada.
Aproximadamente 60-90 segundos (alrededor de 150 slots). Después de la expiración, la transacción es rechazada incluso si se reenvía.
Descartada: nunca ejecutada en un bloque. Rechazada: ejecutada pero el programa devolvió un error; está en la cadena con un estado de fallo.
TowerBFT requiere suficientes votos de validadores a través de múltiples slots para enraizar un bloque. Esto toma aproximadamente 32 slots.
Las tarifas de prioridad aumentan la prioridad de programación. Los bundles de Jito ayudan durante períodos de alta actividad de MEV. No puedes saltarte el proceso de votación.
El RPC ejecuta tu transacción contra el estado actual antes de transmitirla. Detecta la mayoría de los errores de forma temprana.
Devuelve una firma inmediatamente. La confirmación es asíncrona; sondea o suscríbete por separado.
Un protocolo que reenvía transacciones directamente a los próximos líderes de bloques en lugar de usar un mempool tradicional.
Sí. Si alguna instrucción falla, toda la transacción se revierte (a menos que un programa capture y maneje errores de CPI).
No. Todas las instrucciones tienen éxito o ninguno de los cambios de estado se confirma.
confirmed para la mayoría de los pagos. finalized para acciones de alto valor o irreversibles.
Usa https://explorer.solana.com/tx/<SIGNATURE>?cluster=devnet e inspecciona los logs, CU y el desglose de instrucciones.
Versiones de la pila: Esta página fue escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, anchor-lang 0.32.1, Rust 1.91.1, @solana/kit 7.0.0, Surfpool 0.12.0, y LiteSVM 0.6.x.
Revisado por Chris St. John·Última actualización: 19 jul 2026