¿Qué es Firedancer? Cliente Jump Crypto Validator de Solana 2026
— By Tony Rabbit in Tutorials
Firedancer es el cliente validador Solana en lenguaje C de Jump Crypto dirigido a 1 millón de TPS. Explicación del lanzamiento de Mainnet 2026, el híbrido Frankendancer y el impacto de DeFi.
Firedancer: el cliente validador creado para llevar a Solana a 1 millón de TPS
Solana pasó cuatro años prometiendo un millón de transacciones por segundo y nunca lo alcanzó en el hardware de producción. La cadena funcionó rápido, a veces la más rápida de la industria, pero el cliente validador original (ahora llamado Agave) nunca fue diseñado para exprimir cada ciclo de reloj del silicio. En mayo de 2026, ese techo finalmente se resquebrajó. Bailarina de fuego, un cliente de validación de Solana de sala limpia escrito completamente en C por Jump Crypto, comenzó a producir bloques de red principal por primera vez, procesó decenas de millones de transacciones en vivo y demostró que el ancho de banda teórico de Solana siempre fue un problema de software, no un problema de protocolo.
Para los validadores, el lanzamiento remodela la economía. Para los comerciantes de DeFi en Júpiter, Raydium y Drift, promete tarifas más bajas, cumplimientos más rápidos y menos transacciones canceladas durante los frenesíes de las monedas meme. Para el ecosistema más amplio, aporta algo que Solana nunca tuvo: diversidad real de clientes, una propiedad que Ethereum ha promocionado durante mucho tiempo como la base de la descentralización.
Esta guía imperecedera de 2026 explica exactamente qué es Firedancer, por qué Jump Crypto le dedicó años de ingeniería de bajo nivel, cómo se desarrolló el lanzamiento a través de los hitos de la testnet y la producción de bloques de la mainnet, y qué significa para el futuro de las finanzas en cadena de alto rendimiento. Cubrimos el híbrido Frankendancer, la comparación con Agave y Jito-Solana, las implicaciones para los protocolos MEV y DeFi, los riesgos que aún están sobre la mesa y las preguntas prácticas que todas las partes interesadas de Solana se hacen en este momento.
Fragmento destacado: ¿Qué es Firedancer?
Firedancer es un cliente validador de Solana independiente creado desde cero en C por Jump Crypto, el brazo tecnológico de Jump Trading. Su objetivo es un millón de transacciones por segundo, aporta diversidad de clientes a Solana y comenzó a producir bloques de la red principal en vivo en mayo de 2026 después de más de 100 días de operación continua de la red de prueba y más de 50.000 bloques de validación. Aproximadamente el 26% de los validadores de Solana utilizaban Firedancer o su híbrido Frankendancer en el momento del lanzamiento.
Por qué Solana necesitaba un segundo cliente validador
Hasta que Firedancer llegó a la red principal, Solana era efectivamente una red de un solo cliente. Todos los validadores de votación del planeta ejecutaron alguna versión del mismo código base de Rust escrito originalmente por Solana Labs (más tarde rebautizado como Agave, ahora mantenido por el equipo de Anza después de que Solana Labs reestructurara su brazo de ingeniería). Un único cliente significa un único conjunto de errores. Cuando Agave tuvo un problema de presión de memoria o un caso límite de consenso, toda la cadena se detuvo porque estaba ejecutando software idéntico.
Solana experimentó múltiples cortes de varias horas entre 2021 y 2023 exactamente por este motivo. La comunidad conocía la cura (construir un segundo cliente independiente en un idioma diferente, en un modelo de subprocesamiento diferente, con diferentes supuestos de memoria), pero escribir un cliente validador de nivel de producción desde cero es una de las tareas de ingeniería más exigentes de la industria. Requiere experiencia en protocolos de consenso, optimización de redes a nivel del núcleo, primitivas criptográficas implementadas a la perfección y capacidad para manejar condiciones adversas en una cadena que procesa miles de transacciones por segundo.
Jump Crypto se ofreció como voluntario. Respaldado por los recursos de Jump Trading, una de las firmas de comercio cuantitativo más grandes del mundo, el equipo se comprometió en 2022 a crear una implementación limpia en C, el mismo lenguaje utilizado para escribir servidores web, sistemas de comercio de alta frecuencia y motores de juegos donde cada nanosegundo cuenta. La apuesta era simple: si Jump podía cumplir, Solana no sólo obtendría redundancia sino que desbloquearía el rendimiento bruto que el diseño del protocolo siempre prometió.
El caso de la diversidad de clientes en tres líneas
Si un cliente tiene un error crítico, los validadores que ejecutan el otro cliente siguen produciendo bloques, evitando detenciones en toda la cadena.
Diferentes implementaciones exponen diferentes cuellos de botella. Un cliente C escrito para una velocidad bruta permite a la red descubrir su verdadero límite de rendimiento.
Múltiples clientes independientes dificultan que un solo equipo, fundación o jurisdicción controle la dirección del protocolo.
¿Quién es Jump Crypto y por qué lo crearon?
Jump Crypto es la filial centrada en activos digitales de Jump Trading, fundada en 1999 en Chicago y conocida por ser una de las empresas comerciales por cuenta propia más secretas y rentables del mundo. Jump ha sido un proveedor de liquidez activo en los mercados de criptomonedas desde 2017, pero Jump Crypto se formalizó como una unidad de negocios distinta en 2021 bajo el liderazgo de Kanav Kariya, quien anteriormente dirigió los esfuerzos de ingeniería de criptomonedas de Jump y ahora sirve como la cara pública del grupo.
¿Por qué una empresa de comercio de alta frecuencia pasaría años construyendo infraestructura pública para una cadena de bloques? Dos razones. En primer lugar, Jump es uno de los mayores poseedores de tokens SOL sin protocolo y ejecuta un volumen de operaciones significativo a través de Solana DEX, por lo que una Solana más rápida y confiable mejora directamente el propio negocio de Jump. En segundo lugar, el pedigrí de ingeniería necesario para escribir Firedancer (redes de derivación del kernel, estructuras de datos sin bloqueo, criptografía acelerada por SIMD, asignadores de memoria personalizados) es exactamente lo que Jump Trading ya hace para sus sistemas de negociación de futuros y acciones basados en colocación. El conjunto de habilidades transferido.
El proyecto se anunció públicamente por primera vez en Breakpoint Lisboa en 2022. Desde el principio, Jump se comprometió a lanzar Firedancer bajo la licencia de código abierto Apache 2.0, lo que significa que cualquier operador validador puede crear, auditar y modificar el código. La fuente completa se encuentra en GitHub y ha sido objeto de múltiples auditorías de seguridad de terceros desde 2024.
Si es nuevo en cómo las cadenas de bloques estructuran su pila de software, nuestra descripción general de cómo funcionan las criptomonedas en la capa de protocolo cubre los conceptos básicos de nodos, clientes y participación por consenso.
Cómo funciona realmente Firedancer bajo el capó
Un validador Solana hace cinco cosas en paralelo. Escucha las transacciones entrantes en un puerto de red UDP (Solana utiliza un protocolo personalizado llamado QUIC en capas en UDP en lugar de TCP). Verifica las firmas digitales en cada transacción. Ejecuta las transacciones dentro de la Máquina Virtual Solana. Participa en el consenso votando qué bloques son válidos. Y, cuando le llega el turno como líder, produce un nuevo bloque y lo difunde vía Turbine (el protocolo de propagación de bloques de Solana).
Agave maneja las cinco tareas en un único proceso integrado de Rust. Firedancer los divide en procesos separados que se comunican a través de anillos de memoria compartida, un diseño tomado de los sistemas de redes de alto rendimiento. Cada componente se ejecuta como un "mosaico" anclado a un núcleo de CPU específico, con su propia región de memoria y sin bloqueos globales. El mosaico de ingesta de transacciones lee paquetes directamente desde la tarjeta de red sin copiarlos a través del kernel, el mosaico de verificación utiliza instrucciones SIMD para verificar miles de firmas Ed25519 por milisegundo y el mosaico de ejecución mantiene un caché activo de las cuentas tocadas recientemente para evitar lecturas de disco.
El resultado es que un validador Firedancer que se ejecuta en hardware de centro de datos básico puede mantener un rendimiento que Agave físicamente no puede igualar, porque el diseño de Agave fuerza demasiada contención de memoria y demasiadas llamadas al sistema. En puntos de referencia internos (posteriormente confirmados por terceros en devnet), Firedancer demostró tasas sostenidas de verificación de firmas superiores a 1 millón por segundo en una sola máquina de 64 núcleos, el aproximado necesario para alcanzar el objetivo principal de TPS del protocolo.
Arquitectura del Firedancer: los cinco mosaicos
Ingestión UDP de bypass del kernel a través de XDP, lee paquetes QUIC directamente desde la tarjeta de red.
Verificación de firma Ed25519 acelerada por SIMD, paralelizada entre núcleos.
Filtra transacciones duplicadas utilizando un filtro de floración para evitar el desperdicio de trabajo posterior.
Ordena transacciones dentro de un bloque, empaquetándolas de manera eficiente y respetando los presupuestos informáticos.
Codifica el bloque en fragmentos de Turbine y los transmite al resto de la red.
El enfoque de anillo de memoria compartida tiene una gran ventaja para la seguridad: si un solo mosaico falla, los demás pueden seguir ejecutándose y el validador permanece en línea mientras se reinicia el componente roto. En Agave, un pánico en cualquier subsistema puede acabar con todo el proceso. La desventaja es la complejidad. Los operadores tienen que ajustar la afinidad de la CPU y el diseño de la memoria de cada mosaico, que no es el tipo de trabajo que la mayoría de los apostadores de Solana quieren hacer.
Frankendancer: el híbrido que unió a Agave y Firedancer
Crear un cliente validador completo es difícil. Construir uno que produzca bloques correctamente en condiciones adversas en vivo de la red principal es aún más difícil. La respuesta pragmática de Jump Crypto fue Frankendancer, un híbrido que combina la red probada, el consenso y el código de tiempo de ejecución de Agave con el nuevo canal de producción de bloques de alto rendimiento de Firedancer.
Frankendancer se lanzó en 2024 como el primer trampolín. Los validadores podrían optar por ejecutarlo en la red principal, obteniendo la velocidad de producción de bloques del paquete de Firedancer y triturando mosaicos mientras siguen confiando en Agave para la votación por consenso y la capa de ejecución completa de la máquina virtual Solana. Debido a que Frankendancer utilizó el código de consenso probado en batalla de Agave, el riesgo de acabar con la cadena era insignificante. Los validadores que lo ejecutaron informaron un menor uso de la CPU durante los espacios líderes y tasas de inclusión de transacciones ligeramente más altas.
A finales de 2025, aproximadamente el 15% de la participación de Solana administraba Frankendancer. Esos operadores se convirtieron en los probadores beta de facto para el proceso de producción de bloques que eventualmente se convertiría en el cliente Firedancer completo. Cuando llegó el lanzamiento completo de la red principal de Firedancer en mayo de 2026, la ruta híbrida significó que Jump Crypto ya tenía datos de rendimiento del mundo real en las partes más novedosas del código base, lo que redujo considerablemente el riesgo de la transición.
Frankendancer no va a desaparecer. Muchos operadores continuarán ejecutando el híbrido porque ofrece una capa de consenso de Agave en buen estado con ganancias de rendimiento mensurables de la mitad de producción en bloque de Firedancer. Piense en ello de la manera en que los operadores de Ethereum a veces emparejan un cliente de ejecución de un equipo con un cliente de consenso de otro: la flexibilidad de combinar y combinar en sí misma es el dividendo de la diversidad.
Cronograma de implementación de la red principal (2022 a 2026)
Firedancer no llegó en una sola gran explosión. La estrategia de lanzamiento fue deliberadamente incremental, y cada hito exponía una mayor parte del código base a condiciones adversas mientras se mantenía la cadena segura.
Cronología de desarrollo de Firedancer
El momento "Block hits" en mayo de 2026 fue el punto de inflexión. Por primera vez, una base de código no descendiente de Agave finalizó bloques en la red principal de Solana. La cadena no se detuvo, no se detectaron señales dobles y la red siguió funcionando. Para los ingenieros que habían visto a Ethereum pasar una década fomentando la diversidad de clientes, el hito marcó la graduación de Solana a la misma liga.
Firedancer vs Agave vs Jito-Solana: cara a cara
Solana ahora tiene, en términos prácticos, tres clientes validadores de producción en uso activo. Agave es el cliente original de Rust, mantenido por Anza después de la reestructuración de Solana Labs. Jito-Solana es una bifurcación de Agave mantenida por Jito Labs que agrega soporte para paquetes MEV, lo que permite a los creadores de bloques monetizar los pedidos de transacciones. Y Firedancer es el nuevo cliente C de Jump Crypto. Cada uno tiene diferentes fortalezas.
Los números de participación del validador cambian semana tras semana. Lo que importa es la tendencia direccional: la participación de mercado de Agave se ha reducido de casi el 100% en 2023 a aproximadamente el 44% a mediados de 2026, y Jito-Solana y Firedancer absorben el resto. Eso es saludable. También es el tipo de diversificación estructural que se ve en los sistemas descentralizados maduros, similar a cómo la capa de ejecución de Ethereum ahora se divide entre Geth, Nethermind, Besu, Erigon y Reth. Si desea una introducción a la pila de Ethereum para comparar, consulte nuestro guía completa para principiantes de Ethereum.
Qué significa Firedancer para Solana DeFi
Los clientes del Validador son infraestructura y la mayoría de los usuarios nunca los tocan directamente. Pero los efectos posteriores en la capa de aplicación son significativos.
En primer lugar, un mayor rendimiento sostenible se traduce en tarifas medianas más bajas. El mercado de comisiones de Solana es dinámico. Cuando la cadena está congestionada, las tarifas de prioridad aumentan. Una producción de bloques más rápida con una mayor capacidad efectiva de bloques le da más margen al mercado de tarifas prioritarias, lo que mantiene bajos los costos medios incluso durante las manías de las monedas meme o las mentas NFT. Para los usuarios de DEX en Júpiter, Raydium y Drift, esta es la diferencia entre realizar un intercambio en el primer intento y verlo expirar tres veces seguidas.
En segundo lugar, la arquitectura determinista basada en mosaicos de Firedancer hace que la inclusión de transacciones sea más predecible. Solana ha tenido durante mucho tiempo un problema de "transacción perdida" en el que los usuarios envían un intercambio, la transacción nunca se realiza porque el validador la dejó bajo carga y el usuario tiene que volver a intentarlo. El mosaico del paquete en Firedancer está diseñado específicamente para mantener un mempool más profundo y justo, reduciendo las transacciones perdidas. Para los traders activos, menos reintentos significa una ejecución más limpia y menos deslizamiento.
En tercer lugar, la historia del MEV cambia. Hoy en día, la mayoría de los MEV de Solana fluyen a través de paquetes Jito-Solana, donde los buscadores pagan a los validadores directamente para que incluyan sus transacciones en posiciones específicas de un bloque. Firedancer está diseñado para ser conectable a MEV: las versiones futuras permitirán a los operadores elegir sus propias políticas de creación de bloques, incluida la ejecución de versiones modificadas que resistan ataques sándwich o implementen mempools cifrados. Si desea comprender los patrones de ataque que motivan este trabajo, nuestro explicador en Bots MEV, ataques frontales y sándwich cubre la mecánica.
En cuarto lugar, el rendimiento predecible permite nuevas categorías de aplicaciones. Los libros de pedidos en cadena de alta frecuencia, los juegos en tiempo real y las órdenes limitadas en cadena se vuelven más factibles cuando la latencia de confirmación media cae y se mantiene baja. La misma lógica que empujó a Sui y otras cadenas basadas en Move a perseguir ejecuciones paralelas se aplica a Solana una vez que se desbloquea el techo de Firedancer. Nuestro Análisis profundo de la red Sui cubre un diseño alternativo de alto rendimiento para el contexto.
Ejecución de un validador Firedancer: un tutorial de alto nivel
Operar un nodo Firedancer no es una tarea casual. Los requisitos de hardware son agresivos (las especificaciones actuales de Solana recomiendan una CPU de 32 núcleos, 512 GB de RAM y almacenamiento NVMe de alta gama, y Firedancer recompensa aún más núcleos). La superficie de configuración es mayor que la de Agave debido a la arquitectura del mosaico. Y ejecutar en la red principal significa aceptar la responsabilidad del consenso: si su nodo se porta mal, puede ser eliminado o perder las recompensas de votación.
Esquema de configuración de Firedancer en cinco pasos
config.toml para fijar cada mosaico (neto, verificar, desduplicar, empaquetar, triturar, almacenar, reproducir) a núcleos de CPU específicos. Asigne páginas grandes para los anillos de memoria compartida y habilite XDP en la interfaz de red.Si es un delegador (alguien que apuesta SOL con un validador en lugar de ejecutar uno usted mismo), puede preguntarle a su operador qué cliente ejecuta. Muchos paneles de control de apuestas ahora muestran la combinación de clientes de un vistazo. Delegar en validadores de Firedancer o Frankendancer es una de las formas más directas en que los participantes individuales pueden apoyar la diversificación de Solana.
Riesgos y compensaciones honestas
Firedancer es impresionante, pero también es nuevo. Varias categorías de riesgo merecen una mirada clara.
Riesgos abiertos a monitorear
C es un lenguaje no seguro para la memoria. Si bien Jump Crypto ha encargado múltiples auditorías y utiliza extensas pruebas de fuzz, la superficie de ataque para un código base C es fundamentalmente mayor que para uno Rust. Un sutil desbordamiento del buffer en cualquier mosaico podría ser catastrófico.
La cifra de 1 millón de TPS es un punto de referencia de un solo validador, no un rendimiento sostenido de la red. La propagación de redes en el mundo real, la votación por consenso y el crecimiento del Estado todavía obstaculizan la cadena muy por debajo de ese techo.
Los validadores tienen aversión al riesgo por una buena razón. Migrar miles de operadores de Agave a Firedancer lleva años, no meses. Hasta que la adopción alcance una mayoría significativa de participación, el beneficio de la diversidad seguirá siendo parcial.
Jump Crypto es actualmente el único mantenedor significativo de Firedancer. Si Jump retirara la financiación o se reorientara, el proyecto necesitaría una transferencia comunitaria comparable a la transición de Solana Labs a Anza.
Cualquier reimplementación independiente de un protocolo de consenso conlleva el riesgo de una divergencia sutil en el protocolo. Un error que hace que Firedancer no esté de acuerdo con Agave sobre la validez de un bloque podría bifurcar la cadena, que es exactamente el escenario de desastre que la diversidad de clientes debe hacer recuperable.
Ninguna de estas son razones para evitar Firedancer. Son razones para implementarlo con cuidado, que es exactamente lo que han hecho Jump Crypto y la comunidad de validadores de Solana. Los más de 100 días de testnet continuo y los más de 50.000 bloques de validación antes de la red principal no fueron hitos de marketing; eran el precio por eliminar el riesgo de una base de código en esta novela.
Firedancer en contexto: diversidad de clientes en las L1
Vale la pena alejar el zoom. La mayoría de las principales L1 han lidiado con la diversidad de clientes en algún momento de su evolución.
Ethereum es el ejemplo canónico. La capa de ejecución tiene cinco clientes viables (Geth, Nethermind, Besu, Erigon, Reth) y la capa de consenso tiene otros cinco (Prysm, Lighthouse, Teku, Nimbus, Lodestar). Ningún cliente controla más de aproximadamente el 50% de la participación en un momento dado, y la comunidad publica paneles de diversidad mensuales para realizar un seguimiento del progreso. El costo de esta diversidad es el esfuerzo de ingeniería (varios equipos deben implementar cada actualización de protocolo al mismo tiempo), pero el beneficio es que los errores en cualquier cliente no pueden detener la cadena.
Bitcoin tomó una ruta diferente. Bitcoin Core domina la red con una supermayoría de un solo cliente, y las implementaciones alternativas como btcd o libbitcoin son pequeñas. Los bitcoiners argumentan que la estabilidad del protocolo y una base de código pequeña y de lento movimiento reducen el incentivo para la diversidad de clientes, pero el desacuerdo filosófico no se ha resuelto.
Cadenas más nuevas como Mónada, Base y Celestia todavía tienen redes de cliente único, en parte porque son más jóvenes y los recursos escasos. El éxito de Firedancer puede acelerar la misma inversión en otros lugares. Si una empresa cuantitativa de primer nivel puede crear un cliente de clase de un millón de TPS para una importante L1, otras lo seguirán.
Cómo Firedancer cambia el día a día del comerciante
Si es un comerciante activo de Solana, es posible que no note a Firedancer directamente. Pero notarás sus consecuencias.
Los tiempos de confirmación durante la congestión máxima deben comprimirse. Mientras que el lanzamiento de una moneda meme en Pump.fun solía impulsar las tasas de aterrizaje de transacciones a un solo dígito de éxito en el primer envío, los bloques habilitados para Firedancer tienen una capacidad de inclusión considerablemente mayor. Los comerciantes que ejecutan bots que monitorean los tokens recién implementados verán menos llamadas RPC desperdiciadas y tarifas de prioridad más bajas necesarias para realizar la primera compra. Para obtener una visión más profunda de cómo interactúan los ataques de lanzamiento y el avance con los canales de validación, nuestra guía sobre posicionamiento largo versus corto cubre algunas de las dinámicas direccionales.
La precisión de la simulación de transacciones también mejora. El tiempo de ejecución de Firedancer emite rastros de ejecución deterministas que las herramientas posteriores pueden reproducir con precisión. Los proveedores de RPC que muestran datos de simulación en billeteras y interfaces comerciales se benefician de una superficie API más limpia y uniforme. Si simula operaciones antes de firmarlas, los datos que obtiene son más confiables. Nuestro explicador sobre simulación de transacciones explica por qué esto es importante para la seguridad.
Los propios protocolos DeFi pueden aprovechar el nuevo margen de maniobra. Un mayor rendimiento permite que los libros de pedidos como Drift ofrezcan ticks más ajustados, tamaños mínimos de pedido más bajos y ciclos de cancelación y reemplazo más rápidos. Las redes de pago Stablecoin construidas en Solana pueden atender a más comerciantes por segundo. Los protocolos de tokenización que reequilibran periódicamente sus cestas subyacentes pueden hacerlo de forma más económica. Si está explorando las finanzas en cadena de manera más amplia, el Guía de fundamentos de DeFi es un buen punto de partida.
El camino por delante: lo que Firedancer permite a continuación
La producción de bloques Mainnet fue el comienzo, no la meta. Varias actualizaciones están visiblemente en marcha o en la hoja de ruta pública.
Uno es la aceleración de hardware. Algunos de los mosaicos de Firedancer son adecuados para ejecutarse en GPU o FPGA, lo que puede ofrecer un orden de magnitud más de verificaciones de firmas por segundo. Jump Crypto ha demostrado prototipos de mosaicos de verificación respaldados por FPGA en conferencias de desarrolladores, insinuando un futuro en el que los validadores especializarán su hardware para funciones específicas dentro del mismo cliente.
Otro incluye MEV. La arquitectura de Firedancer permite a terceros conectar una lógica de construcción de bloques personalizada. Jito Labs, por ejemplo, podría teóricamente portar su subasta de paquetes para ejecutarse sobre el paquete de Firedancer, obteniendo lo mejor de ambos mundos: la infraestructura MEV madura de Jito con el rendimiento puro de Firedancer. Que esa integración se produzca depende de la alineación comercial entre los dos equipos, pero el camino técnico es claro.
Un tercero son los mempools cifrados. Varios grupos de investigación de Solana han propuesto esquemas de cifrado de mempool que evitan que los buscadores vean las transacciones pendientes antes de aterrizar. El modelo de mosaico de Firedancer hace que sea relativamente sencillo cambiar el mosaico de deduplicación por una variante compatible con cifrado sin tocar el código de consenso. Si se implementan, los mempools cifrados podrían reducir sustancialmente los ataques sándwich en Solana DEX.
Un cuarto son clientes ligeros. Los seguimientos de ejecución deterministas de Firedancer son exactamente el tipo de artefacto que los clientes ligeros y los puentes necesitan para verificar el estado de Solana desde fuera de la red. Una mejor soporte al cliente ligero fortalece los puentes entre cadenas, las cadenas laterales y los L2 construidos sobre la capa base de Solana.
Preguntas frecuentes
P ¿Qué es Firedancer en términos simples?
Firedancer es un segundo software de validación para Solana, escrito desde cero en C por Jump Crypto. Hace el mismo trabajo que el cliente Agave existente (validar transacciones, votar bloques, producir nuevos bloques) pero con un diseño más rápido y eficiente que apunta a hasta un millón de transacciones por segundo. Tener un segundo cliente independiente hace que Solana sea más resistente frente a errores e interrupciones.
P ¿Cuándo se lanzó Firedancer en la red principal de Solana?
La producción completa del bloque de la red principal de Firedancer comenzó en mayo de 2026, después de más de 100 días de operación continua de la red de prueba y más de 50.000 bloques de la red de prueba. El cliente híbrido Frankendancer ya se había utilizado en la red principal desde 2024, pero mayo de 2026 fue la primera vez que un validador Firedancer puro finalizó bloques en la red principal de Solana. La cadena procesó decenas de millones de transacciones en vivo a través de Firedancer en las primeras semanas después del lanzamiento.
P ¿Quién construyó Firedancer y por qué?
Firedancer fue creado por Jump Crypto, la subsidiaria de activos digitales de Jump Trading, una empresa de comercio cuantitativo global fundada en 1999. Kanav Kariya dirige Jump Crypto. El equipo se comprometió con el proyecto en 2022 porque Solana carecía de diversidad de clientes, sufrió repetidas interrupciones causadas por errores de un solo cliente y no pudo obtener el rendimiento que prometía el diseño de su protocolo. La experiencia de Jump en sistemas de baja latencia hizo que fuera una opción natural, y la empresa se beneficia comercialmente de una Solana más rápida y confiable.
P ¿Cuál es la diferencia entre Firedancer y Frankendancer?
Frankendancer es un cliente de validación híbrido que combina el código de consenso y tiempo de ejecución de Agave (el cliente original de Solana) con el proceso de producción de bloques de alto rendimiento de Firedancer. Fue el trampolín de Jump Crypto hacia un cliente Firedancer completamente independiente, lo que permitió a los validadores obtener beneficios de rendimiento parciales sin dejar de confiar en la capa de consenso probada en batalla de Agave. Firedancer es el cliente totalmente independiente, donde cada componente, incluida la votación por consenso, se implementa desde cero en C.
P ¿Firedancer es más rápido que Agave en la práctica?
Sí. En hardware equivalente, Firedancer demuestra tasas de verificación de firmas sustancialmente más altas y un menor uso de CPU por mosaico que Agave. La cifra principal de un millón de transacciones por segundo es un punto de referencia de un solo validador, pero las pruebas del mundo real en la red principal han mostrado mejores tasas de inclusión de transacciones y una reducción de las transacciones descartadas para los validadores que ejecutan Firedancer o Frankendancer en comparación con Vanilla Agave. El límite máximo de rendimiento a nivel de red depende de otros factores como la latencia del consenso y el crecimiento del estado.
Q ¿Firedancer admite paquetes MEV como Jito-Solana?
Aún no de forma nativa, pero Firedancer está diseñado para ser conectable a MEV. Su arquitectura de mosaicos multiproceso permite a terceros reemplazar la lógica de construcción de bloques predeterminada con módulos personalizados, lo que significa que un sistema de paquete estilo Jito podría, en principio, ejecutarse sobre el mosaico de paquetes de Firedancer. Que llegue una integración Jito de nivel de producción y cuándo depende de la colaboración entre Jito Labs y Jump Crypto. Otros experimentos de resistencia a MEV, como los mempools cifrados, también se vuelven más factibles con la arquitectura de Firedancer.
P ¿Cuántos validadores de Solana ejecutan Firedancer hoy?
Alrededor del hito de la red principal de mayo de 2026, más del 26% de los validadores de Solana ejecutaban el cliente Firedancer completo o el híbrido Frankendancer. Esa proporción ha crecido de manera constante desde 2024 y se espera que continúe aumentando a medida que el cliente madure, los operadores ganen confianza y mejoren las herramientas de configuración y monitoreo. Los paneles de diversidad en vivo publicados por rastreadores de la comunidad informan la división actualizada entre la participación de Agave, Jito-Solana y Firedancer o Frankendancer.
P ¿Firedancer reducirá las tarifas de transacción de Solana?
Indirectamente, sí. Firedancer amplía la capacidad efectiva de bloques y reduce las transacciones canceladas, lo que le da al mercado de tarifas de prioridad más margen durante la congestión. La tarifa base de Solana ya es baja, por lo que los ahorros se muestran más claramente en las tarifas prioritarias durante los períodos pico, como los lanzamientos de monedas meme o las mentas NFT. Los operadores de DEX como Jupiter, Raydium y Drift deberían ver menos reintentos y una ejecución más limpia, lo que funcionalmente reduce el costo total de operar en Solana.
P ¿Por qué se cambió el nombre de Solana Labs a Anza?
Anza es una nueva empresa centrada en la ingeniería surgida de Solana Labs para hacerse cargo del mantenimiento del cliente validador de Solana original, que pasó a llamarse Agave al mismo tiempo. La división permite a Anza centrarse exclusivamente en el protocolo central y la ingeniería del cliente mientras Solana Labs continúa con otras iniciativas. Anza ahora mantiene Agave como cliente de referencia alineado con la comunidad, en paralelo con Jito Labs que mantiene Jito-Solana y Jump Crypto que mantiene Firedancer.
P ¿Firedancer es de código abierto y alguien puede auditar el código?
Sí, Firedancer se publica bajo la licencia de código abierto Apache 2.0. El código fuente completo se encuentra en GitHub, donde los validadores, investigadores de seguridad y desarrolladores pueden leer, construir, auditar y contribuir. Desde 2024 se han encargado múltiples auditorías de seguridad de terceros, centradas en las primitivas criptográficas, la capa de red y la implementación de consenso. La revisión externa continua es uno de los principales mecanismos de seguridad del proyecto, dado que el código base está escrito en C, un lenguaje que no es seguro para la memoria.
P ¿Los titulares regulares de SOL necesitan hacer algo debido a Firedancer?
No se requiere acción directa. Las billeteras, los intercambios y las aplicaciones DeFi continúan funcionando normalmente independientemente de qué validadores de clientes se ejecuten. La acción más significativa que puede realizar un delegador es verificar qué cliente ejecuta el validador elegido y considerar delegar a operadores que ejecutan Firedancer o Frankendancer para respaldar la diversidad de clientes. La mayoría de los paneles de control ahora muestran la combinación de clientes de un vistazo, lo que facilita alinear las delegaciones con los validadores que contribuyen a la resiliencia de Solana.
P ¿Qué sucede si Firedancer tiene un error grave después del lanzamiento?
Debido a que Solana ahora tiene varios clientes independientes, un error en Firedancer que haga que sus validadores se detengan o no estén de acuerdo con el resto de la red aún dejaría a los validadores de Agave y Jito-Solana funcionando normalmente. La cadena seguiría produciendo bloques mientras una gran mayoría de las acciones se mantuvieran saludables. Ése es el objetivo de la diversidad de clientes: un error crítico en cualquier cliente se convierte en un evento recuperable en lugar de una interrupción en toda la cadena. Los validadores de Firedancer parchearían y volverían a unirse, y la red continúa.
Conclusión: un cambio silencioso y fundamental
Firedancer no es un lanzamiento simbólico, un DEX llamativo o una moneda meme. Es una pieza de infraestructura que la mayoría de los usuarios de Solana nunca verán y en la que nunca tendrán que pensar. Eso es exactamente lo que lo hace importante. El cliente validador que ejecuta su cadena favorita determina qué tan confiable, rápida y descentralizada es realmente esa cadena. Durante cinco años, Solana trabajó con un solo cliente. Hoy funciona con tres, y el recién llegado (sala limpia construida en C por una empresa comercial cuantitativa de primer nivel) demuestra que una cadena de un millón de TPS no es un eslogan de marketing sino un destino de ingeniería.
Para los comerciantes, la implicación práctica es sencilla: Solana debería parecer más ágil, más justa y más barata que antes. Menos transacciones canceladas, competencia por tarifas de prioridad menos agresiva y resultados de simulación más predecibles se derivan del trabajo que se realiza en la capa de software del validador. Combinado con la evolución paralela de Jito-Solana para la agrupación de MEV y el mantenimiento continuo de Agave bajo Anza, Solana ahora tiene una infraestructura redundante y en capas a la que cualquier L1 seria debería aspirar.
Para los constructores, las implicaciones son aún mayores. Mayor rendimiento, menor latencia y categorías de aplicaciones de desbloqueo de creación de bloques conectables que simplemente no encajaban en una Solana más lenta y de un solo cliente. Los juegos en cadena en tiempo real, los DEX de orden limitada de alta frecuencia, las redes de pago que atienden a miles de comerciantes por segundo y los puentes que dependen de pruebas de estilo de cliente ligero se vuelven más manejables. La próxima ola de aplicaciones de Solana se está diseñando en torno a lo que Firedancer hace posible, no en lo que Agave por sí solo podría ofrecer.
Si está evaluando L1 para un proyecto, una asignación de cartera o simplemente para comprender el panorama, Firedancer cambia la comparación. Solana ya no es la cadena con un diseño de protocolo heroico paralizado por un único cliente anciano; es una cadena cuya pila de clientes ahora refleja la madurez de su ecosistema. Ver crecer las acciones de Firedancer durante el próximo año nos dirá más sobre la trayectoria de Solana que cualquier gráfico de precios simbólicos. Y si quieres seguir explorando el paisaje de la L1, nuestras inmersiones profundas en EVM paralelizado de Monad, Tiempo de ejecución de Sui's Move, Coinbase L2 de la base y Disponibilidad de datos modulares de Celestia completa el panorama más amplio de cómo evolucionarán las cadenas de bloques de alto rendimiento en 2026.
Realice un seguimiento de los datos de mercado de Solana, los tokens principales y los análisis con reconocimiento de validadores en DexTools para mantenerse a la vanguardia de cómo Firedancer remodela la experiencia en cadena. Ya sea que apueste SOL con un validador, ejecute estrategias comerciales en Júpiter y Drift, cree aplicaciones sobre el tiempo de ejecución de Solana o simplemente mantenga el token como parte de una cartera más amplia, la capa de cliente ahora es parte de su diligencia debida. Pregunte qué cliente ejecuta un validador antes de delegar. Lea el historial de confirmaciones de GitHub si desea verificar un reclamo. Observe cómo las cifras de participación de los validadores cambian trimestre tras trimestre a medida que Frankendancer y Firedancer absorben una mayor parte de la red. La cadena que usó ayer no es exactamente la misma cadena que usará mañana, y la diferencia está siendo escrita, un archivo fuente C a la vez, por un equipo de ingenieros que decidió que un millón de transacciones por segundo no era un eslogan sino una fecha límite.