Yakovenko pone cinco apps de Solana por delante de validadores y desarrolladores

Anatoly Yakovenko sostuvo que Solana debería optimizarse primero para aplicaciones con muchos activos bajo gestión y actividad minorista, y mencionó cinco productos como prioridades. Su comentario abrió un debate sobre fiabilidad y usuarios, pero no anunció cambios técnicos ni reglas nuevas para los validadores.

***

• Yakovenko nombró Phantom, Pump.fun, Fomo, Jupiter y Kamino por encima de validadores, desarrolladores, creadores de mercado e ingenieros centrales.
• El cofundador de Solana señaló los activos bajo gestión y el volumen minorista como criterios, aunque no aportó cifras ni ordenó las aplicaciones entre sí.
• La declaración fue una postura sobre prioridades de optimización, no un anuncio de modificaciones de protocolo, fondos o participación de validadores.

 

---

Yakovenko prioriza cinco apps de Solana sobre validadores y desarrolladores

Mencionó Phantom, https://t.co/ddiikQGMKx, Fomo, Jupiter y Kamino.

Su criterio: activos bajo gestión y actividad minorista.

No anunció cambios al protocolo ni nuevas reglas para validadores. pic.twitter.com/iKewLVTt2H

— Diario฿itcoin (@DiarioBitcoin) October 23, 2026

Aplicaciones al frente de la discusión

Anatoly Yakovenko, cofundador de Solana, defendió que las necesidades de las aplicaciones con mayor actividad deberían orientar la optimización de la red. En una publicación del 23 de octubre de 2026, mencionó Phantom, Pump.fun, Fomo, Jupiter y Kamino, y las situó por delante de validadores, desarrolladores, creadores de mercado e ingenieros centrales. El planteamiento puso en primer plano la experiencia de quienes utilizan productos construidos sobre Solana, más que las prioridades de los equipos que mantienen su infraestructura.

Yakovenko resumió su criterio en dos indicadores: activos bajo gestión, conocidos por la sigla AUM, y volumen de actividad minorista. Escribió que los productos con una cantidad elevada de activos administrados y un gran volumen minorista eran los dos grupos más importantes para optimizar, pero no proporcionó cifras para medir esos factores ni comparó a las cinco aplicaciones entre sí. Por tanto, su lista expresa una jerarquía general, no una clasificación basada en métricas publicadas.

Al enumerar Phantom, Pump.fun, Fomo, Jupiter y Kamino, el cofundador los usó como ejemplos del tipo de producto que, a su juicio, merece atención prioritaria. Su mensaje no anunció acuerdos con esos equipos, no les concedió autoridad de gobernanza ni identificó una función de Solana que fuera a modificarse para beneficiarlos. Expresar quién debería influir en el diseño de una red no equivale a describir una decisión formal o una actualización ya aprobada.

En una respuesta posterior dentro del intercambio, Yakovenko formuló la prioridad en términos de usuarios y distinguió entre el público minorista y el institucional. La idea amplía su argumento más allá de las cinco marcas citadas: las aplicaciones que concentran activos y actividad son relevantes porque median el acceso cotidiano a la red. Sin embargo, no detalló cómo mediría la calidad de esa experiencia ni qué mecanismo permitiría trasladar las necesidades de esos usuarios a cambios concretos del protocolo.

La comparación con Ethereum y la fiabilidad de Aave

El comentario de Yakovenko apareció durante una discusión sobre si quienes diseñan Ethereum utilizan la red que ayudan a desarrollar. El argumento que detonó el intercambio sostenía que los responsables de diseñar un protocolo deberían depender de su propio producto y asumir consecuencias cuando este falla. Yakovenko respondió con una valoración matizada de la Ethereum Foundation y la vinculó con la fiabilidad que necesita Aave, una plataforma de préstamos.

Según el cofundador de Solana, la Ethereum Foundation ha hecho un trabajo razonable al optimizar para Aave, porque la plataforma necesita que sus transacciones puedan incluirse de forma fiable. Una interrupción o una congestión que impidiera procesarlas, señaló, podría afectar el funcionamiento del servicio de préstamos. Su observación no fue una evaluación técnica detallada de Ethereum, sino un ejemplo de cómo las necesidades de una aplicación pueden influir en las decisiones de infraestructura de una red.

La comparación desplaza el debate desde la identidad de los diseñadores hacia las consecuencias prácticas de sus decisiones. Para una aplicación financiera, no basta con que el protocolo funcione en condiciones normales: la capacidad de procesar operaciones durante momentos de congestión o interrupción puede ser decisiva para sus usuarios. En ese sentido, la referencia a Aave ilustra la postura de Yakovenko, aunque no aporta datos de rendimiento ni una propuesta específica que permita medir la optimización mencionada.

También hay una diferencia entre reconocer las necesidades de una aplicación y convertirlas en el objetivo exclusivo de una cadena. Yakovenko defendió que el uso minorista y los activos bajo gestión deben pesar especialmente, mientras que el debate sobre Ethereum trataba la relación entre quienes construyen el protocolo y quienes dependen de él. Ninguno de los comentarios estableció una política vinculante para Solana ni cambió la forma en que Ethereum procesa las transacciones de Aave.

La discusión previa sobre aplicaciones e ingresos

La postura forma parte de conversaciones anteriores de Yakovenko sobre el vínculo entre las aplicaciones y las redes que utilizan. En otra ocasión, sostuvo que una empresa puede construir sobre Solana, subsidiar los costos de transacción y cobrar a sus clientes a través de su propia interfaz. Esa posibilidad plantea quién asume los costos de usar una blockchain y qué parte de la relación con el cliente queda en manos de la aplicación.

La idea provocó una respuesta de Steven Goldfeder, cofundador de Offchain Labs, relacionada con la decisión de Robinhood de utilizar tecnología de Arbitrum. Goldfeder defendió que Robinhood pudiera conservar una parte importante de los ingresos de su cadena y afirmó que podría retener aproximadamente el 90% bajo el Programa de Expansión de Arbitrum. Esa cifra se refiere a los ingresos netos del protocolo: el programa establece que el 10% se devuelve al ecosistema de Arbitrum.

De esa porción del 10%, el 8% se destina a ArbitrumDAO y el 2% a la Developers Guild, según la información del programa. Así, la afirmación sobre el 90% describe la parte de los ingresos netos que Robinhood podría conservar, no el 90% de cualquier ingreso bruto ni una participación aplicable a todas las aplicaciones construidas sobre Arbitrum. La discusión se refiere tanto a infraestructura como a distribución de ingresos, no solo a la velocidad o fiabilidad de una red.

Ese antecedente ayuda a contextualizar el énfasis de Yakovenko en las aplicaciones, pero no debe confundirse con un nuevo acuerdo comercial. La publicación del 23 de octubre no anunció cambios en el acceso a productos para clientes de Estados Unidos ni describió una alianza con Phantom, Pump.fun, Fomo, Jupiter o Kamino. Su argumento fue más amplio: la red debería prestar atención a los productos que concentran activos y actividad minorista, sin fijar cómo se repartirían ingresos o costos.

Optimización de aplicaciones y tareas de los validadores

Las pruebas de Alpenglow muestran que las aplicaciones y los operadores de infraestructura tienen necesidades técnicas distintas dentro de Solana. Anza activó la actualización en devnet el 25 de septiembre, después de que testnet completara su transición el día anterior. Según la guía de la Fundación Solana citada en reportes sobre la actualización, las aplicaciones que solo envían transacciones y consultan saldos no necesitarían migrar.

En cambio, los servicios que procesan bloques o siguen la actividad de los validadores sí enfrentan cambios en la manera de leer los datos de la red. La distinción separa el uso habitual de una aplicación de las tareas de operadores que dependen de información más cercana al funcionamiento interno del protocolo. Así, que Yakovenko coloque las aplicaciones por delante de los validadores en una discusión sobre prioridades no elimina las necesidades específicas de quienes mantienen servicios de infraestructura.

Los reportes sobre Alpenglow describieron un objetivo de finalidad cercano a 150 milisegundos, frente a unos 12,8 segundos bajo TowerBFT. Esa cifra se refiere a la finalidad del consenso y no a la primera señal de que una transacción llegó a la cadena: son momentos distintos. Algunos reportes situaron el objetivo de activación en mainnet-beta el 21 de octubre, pero esa fecha prevista no confirma por sí sola que el despliegue se completara. Un reporte sobre el calendario previsto para Alpenglow describió esa fecha como un objetivo.

La documentación también abordó un plan de tarifas para validadores que reemplazaría los pagos de votación individuales en cadena por una tarifa plana de admisión de 0,8 SOL por época. Los operadores tendrían que financiarla por encima del mínimo exento de alquiler de su cuenta de voto y pagarla con una época de anticipación; si no pudieran cubrirla, perderían el permiso para votar o producir bloques en la época siguiente. Son detalles de funcionamiento de la red y no medidas presentadas por Yakovenko en su publicación sobre las aplicaciones.

Devnet y testnet cumplen funciones diferentes en estas pruebas: devnet permite a los equipos de aplicaciones verificar software con tokens sin valor real, mientras testnet ofrece a validadores y operadores un entorno más exigente para probar el software de red. En conjunto, estas etapas muestran que las mejoras requieren trabajo de varias partes, aunque el mensaje de Yakovenko sostiene que las prioridades de optimización deberían partir de los productos y usuarios que más dependen de Solana.

---

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.