Gobernanza de Solana: un análisis exhaustivo

Conclusiones prácticas

• Los votos de gobernanza en Solana no son vinculantes y tienen carácter consultivo: funcionan como señales del sentir de la comunidad. Permitir que los validadores indiquen su postura antes de la implementación completa ayuda a orientar el desarrollo y minimizar los desacuerdos. La decisión final ocurre cuando los validadores eligen qué software ejecutar. Las propuestas pueden cambiar incluso después de una votación y, en última instancia, la gobernanza refleja consenso, no imposición.
• Los titulares de tokens SOL participan indirectamente al delegar sus SOL en staking a validadores cuyas decisiones de voto coinciden con sus valores o preferencias. Se trata de un sistema de representación proporcional en el que los validadores pueden considerarse representantes electos. Quienes hacen staking en Solana delegan su participación a validadores, y el poder de voto de cada validador se basa en la participación que le han delegado.
• Las votaciones de gobernanza de Solana se realizan mediante tokens SPL. Los validadores reciben tokens de forma proporcional a la participación activa y los envían a direcciones designadas que representan distintas opciones de voto. Los validadores pueden dividir sus votos entre varias opciones. Una vez emitidos, los votos son definitivos y no pueden cambiarse.
• Todas las actualizaciones del protocolo que rompen el consenso se activan mediante puertas de funciones, que son bifurcaciones duras no compatibles con versiones anteriores. A diferencia de Bitcoin o Ethereum, donde un desacuerdo sobre una bifurcación dura puede causar una división permanente de la cadena, el enfoque de Solana garantiza que las puertas de funciones se activen en todo el clúster en un slot específico. Los validadores actualizan de antemano, lo que evita divisiones de la cadena.
• Varios cambios económicos durante las primeras etapas del desarrollo de Solana —en particular, la introducción de comisiones de prioridad con una quema del 50 %— se implementaron sin votaciones formales de gobernanza, ya que el sistema aún era inmaduro.
• El modelo actual de votación de gobernanza —votación exclusiva de validadores— se estableció tras una votación consultiva en octubre de 2023. Participaron más de 170 validadores, que representaban el 14,3 % de la participación total, y más del 70 % de esa participación favoreció la votación exclusiva de validadores como el punto de partida más práctico y eficiente.
• La reciente votación sobre SIMD-228 alcanzó una participación récord del 74,3 %, lo que la convirtió en el mayor evento de gobernanza de blockchain de la historia por número de participantes y capitalización de mercado, con 281 millones de SOL (~$35 mil millones) y más de 900 validadores que emitieron más de 1.000 votos. Fue la primera participación activa de validadores de grandes exchanges como Coinbase, Kraken y Bybit, lo que destaca la creciente participación institucional en Solana.
• Una preocupación recurrente en el proceso de gobernanza de Solana es el papel limitado de los delegadores en la toma de decisiones. Hoy no existe un mecanismo formal para que los delegadores expresen sus preferencias o anulen las decisiones de los validadores, lo que provoca situaciones en las que los votos de estos pueden entrar en conflicto con las preferencias de sus delegadores.
• El papel de un cuórum definido en las votaciones de gobernanza de Solana también ha generado inquietudes. En la práctica, los cuórums pueden crear incentivos perversos: los participantes retienen estratégicamente sus votos para impedir que una propuesta alcance el umbral requerido. Esto se observó en los patrones de votación de SIMD-228.
• Solana Foundation Delegation Program delega el 10 % del total de SOL en staking (41,01 millones) entre 897 validadores, lo que amplifica su poder de voto. El análisis de la reciente votación de SIMD-288 indica que la participación de SFDP se utilizó principalmente para votar contra la propuesta. Si esa participación hubiera votado SÍ, la propuesta habría sido aprobada. Si la participación delegada por SFDP se hubiera abstenido, la propuesta igualmente habría fracasado, pero por un margen menor: 64,77 % frente al 61,39 % real.
• Aún existe incertidumbre sobre qué amerita una votación de gobernanza. En marzo de 2025, se retiró una votación prevista sobre SIMD-218 (IVC) después de que surgiera el consenso de que no requería aprobación de gobernanza. Del mismo modo, aunque SIMD-123 fue aprobada, no era claramente un cambio económico y podría decirse que no justificaba una votación formal.

Introducción

La gobernanza es un componente esencial de la descentralización. Influye en todo, desde las actualizaciones del protocolo y las políticas económicas hasta el comportamiento de los validadores y las normas de la comunidad. Un sistema de gobernanza que funciona bien mejora la transparencia, la equidad y la confianza, mientras que una gobernanza deficiente puede generar confusión, estancamiento o centralización del poder.

La gobernanza de Solana aún se encuentra en una etapa temprana de desarrollo. Como muchas redes blockchain, no se lanzó con un marco de gobernanza plenamente maduro o formalizado. En cambio, ha evolucionado gradualmente, moldeada por las prácticas de la comunidad, las restricciones técnicas y las lecciones aprendidas. Perfeccionar la gobernanza de Solana es un proceso continuo e iterativo.

El ecosistema de Solana comprende grupos de partes interesadas diversos y superpuestos: titulares de tokens, participantes de staking, usuarios, validadores, operadores de RPC, desarrolladores de aplicaciones e ingenieros del protocolo principal. Cada grupo aporta perspectivas, incentivos y objetivos diferentes. Aunque estos incentivos pueden coincidir en algunas áreas, suelen divergir, especialmente en torno a la distribución de recursos, el control del protocolo y la política económica.

En los sistemas descentralizados, la gobernanza depende tanto del consenso social como del código. Aunque las blockchains suelen describirse con la frase “el código es ley”, la historia ha demostrado que, cuando el consenso de la comunidad lo exige, el código puede cambiar y cambia. Por eso, el diseño de los mecanismos de gobernanza y la capacidad de hacerlos evolucionar con el tiempo son tan importantes como la arquitectura técnica inicial.

Este informe busca aclarar la estructura, la evolución y el estado actual de la gobernanza en Solana. Ofrece una visión exhaustiva de cómo se toman decisiones dentro de la red y cómo se compara su gobernanza con la de otros ecosistemas blockchain. El trabajo se divide en cuatro secciones principales:

• Elementos de la gobernanza de Solana – Examina los componentes centrales del proceso de gobernanza de Solana, incluidos los SIMD, las activaciones de puertas de funciones y las votaciones formales on-chain.
• Análisis de las votaciones de gobernanza – Una visión detallada de todas las votaciones formales de gobernanza hasta la fecha, incluidos los resultados, el comportamiento de los votantes y las métricas de participación.
• Desafíos y recomendaciones – Un análisis de los principales problemas del modelo actual de gobernanza de Solana, acompañado de recomendaciones prácticas cuando corresponde.
• Comparación con redes alternativas – Un análisis de cómo funciona la gobernanza en los ecosistemas comparables de Cosmos y Ethereum, que destaca prácticas que podrían servir para mejorar Solana.

Aunque el informe se entiende mejor al leerlo en orden, cada sección está diseñada para ser independiente y puede leerse por separado.

Elementos de la gobernanza de Solana

La siguiente tabla ofrece una visión general del sistema de gobernanza de Solana, estructurada con un marco analítico adaptado del artículo Análisis de la toma de decisiones en la gobernanza de blockchain de Schädler, Lustenberger y Spychiger (2023). Adaptamos este marco para reflejar los mecanismos y las dinámicas específicas del ecosistema de Solana.

Las modificaciones del protocolo de Solana siguen un proceso de varias etapas que varía según la naturaleza y el impacto del cambio. Los factores clave incluyen si el cambio rompe el consenso, su impacto en las partes interesadas y el nivel de controversia o complejidad involucrado. Un cambio que rompe el consenso es cualquier actualización del protocolo que hace que los nodos que ejecutan distintas versiones del software no coincidan sobre el estado de la blockchain. 

La siguiente tabla describe los pasos habituales para cambios de distinta magnitud. Se consideran ‘cambios grandes’ aquellos que pueden tener un impacto económico.

A continuación, describiremos en detalle los procesos de activación de puertas de funciones, los SIMD y las votaciones de gobernanza.

Activaciones de puertas de funciones

Los equipos principales de desarrollo de Anza y Firedancer publican con frecuencia nuevas funciones, como syscalls, programas nativos y cambios económicos que rompen el consenso. Estas funciones se crean, se incluyen en nuevas versiones del software cliente y permanecen desactivadas de forma predeterminada detrás de una bandera de función. El programa de puertas de funciones, que recientemente migró a un programa Core BPF, registra cada función nueva como una cuenta. El colaborador principal asociado a cada puerta de función posee una clave privada exclusiva para ella. Cuando una cantidad suficiente de validadores con participación actualiza a la nueva versión y esta se considera estable, el interruptor de la función en tiempo de ejecución se activa manualmente mediante una instrucción. La función entra en funcionamiento en todos los nodos de la red al comenzar la siguiente época. El orden y el momento exactos de las activaciones pueden consultarse en el calendario de puertas de funciones. La activación de funciones es independiente del clúster: ocurre primero en Testnet, luego en Devnet y finalmente en Mainnet. Así se genera confianza en las nuevas versiones antes de su activación final en Mainnet.

El ‘piso de versión’ es la versión mínima de software que admite actualmente un clúster. A medida que se activan nuevas puertas de funciones, el piso de versión se eleva para coincidir con la versión de software que incluyó la función. Las nuevas funciones de Solana se activan con una cadencia regular, normalmente en límites de época que coinciden con el horario laboral de días hábiles. Las activaciones se pausan durante las transiciones de versión y se reanudan aproximadamente dos épocas después de que el 95 % de la participación haya actualizado a una nueva versión menor (por ejemplo, de la versión 2.2 a la 2.3).

Las activaciones de puertas de funciones son bifurcaciones duras no compatibles con versiones anteriores que requieren adopción universal para entrar en vigor. Si un validador no actualiza a una versión que reconoce una puerta de función activada, no puede seguir validando el estado global y se separará de la red.

A diferencia de Bitcoin o Ethereum, donde un desacuerdo sobre una bifurcación dura puede causar una división permanente de la cadena, el enfoque de Solana garantiza que las puertas de funciones se activen en todo el clúster en un slot específico. Los validadores deben actualizar de antemano, lo que evita divisiones de la cadena. Por tanto, aunque las puertas de funciones son bifurcaciones duras porque cambian las reglas de consenso, no pueden dar lugar a cadenas competidoras.

Las nuevas versiones del cliente también incluyen muchos cambios que no rompen el consenso, como refactorizaciones de código y optimizaciones de eficiencia, que no requieren puertas de funciones.

Documentos de mejora de Solana (SIMD)

Las propuestas de documentos de mejora de Solana (SIMD) son la documentación formal necesaria para cualquier cambio sustancial en los componentes principales de Solana. Los cambios "sustanciales" se definen como aquellos que suelen modificar el protocolo de red, la validez de las transacciones o la interoperabilidad. Los cambios no sustanciales, como refactorizaciones menores de código o mejoras objetivas de rendimiento, no requieren propuestas. Las propuestas deben documentar la justificación de la función e incluir suficiente información para comprender su implementación. 

Aunque cualquiera puede enviar un SIMD, la mayoría los presentan desarrolladores de equipos de clientes que trabajan a tiempo completo en mejoras del protocolo principal.

Existen dos tipos de propuestas: 

• Propuestas estándar: afectan funciones principales de Solana (por ejemplo, consenso, redes e interfaces de API)
• Metapropuestas: abordan procesos o pautas ajenos al código base

Los SIMD suelen avanzar por etapas de evaluación de la idea, redacción, revisión y aceptación. La revisión formal se realiza públicamente en GitHub. El autor de la propuesta es responsable de recopilar comentarios de colaboradores principales relevantes de los equipos de clientes Agave y Firedancer, quienes determinan si se acepta, revisa o retira considerando la seguridad, las concesiones y la compatibilidad con versiones anteriores.

Los autores no están obligados a implementar sus propuestas, pero generalmente se recomienda que lo hagan, pues es la mejor forma de asegurar que se completen con éxito. Si se aceptan, las propuestas suelen incluir un issue asociado para dar seguimiento a la implementación de la función y normalmente requieren activación mediante el mecanismo de puertas de funciones de Solana. 

Aunque no todas las activaciones de puertas de funciones requieren un SIMD, la mayoría se acompañan de uno para proporcionar contexto, justificación y un registro estandarizado del cambio propuesto.

Votaciones de gobernanza

Los SIMD que alteran significativamente el protocolo, especialmente aquellos que afectan parámetros económicos, requieren votaciones de gobernanza. El proceso de gobernanza de Solana, liderado por miembros experimentados de la comunidad de validadores, se centra solo en asuntos críticos para mantener la participación y evitar la fatiga de gobernanza. Como resultado, solo se celebran unas pocas votaciones al año.  

Las votaciones de gobernanza sirven principalmente para medir la opinión sobre los cambios propuestos. Permitir que los validadores indiquen su postura antes de la implementación completa ayuda a orientar el desarrollo y minimizar los desacuerdos. Implementar un cambio sin un consenso amplio podría generar fricción, especialmente si más de un tercio de la red se resiste a adoptarlo.

La votación se realiza mediante tokens SPL. La cuenta de identidad de cada validador activo recibe tokens en proporción a su participación activa, medida en lamports. El validador puede enviar estos tokens a direcciones designadas que representan distintas opciones de voto, incluida la abstención. Los validadores pueden dividir sus votos entre varias opciones —por ejemplo, asignar un 80 % a SÍ y un 20 % a NO—, lo que les permite reflejar las distintas preferencias de quienes hacen staking con ellos. Una vez emitidos, los votos son definitivos y no pueden cambiarse.

En esta estructura, los titulares de tokens SOL participan indirectamente al delegar sus SOL en staking a validadores cuyas decisiones de voto coinciden con sus valores o preferencias. Se trata de un sistema de representación proporcional en el que los validadores pueden considerarse representantes electos. Quienes hacen staking en Solana delegan su participación a validadores, y el poder de voto de cada validador se basa en su participación activa.

Los límites de la gobernanza on-chain

toly 🇺🇸

@toly

@garious14 There is no “governance”. It’s just a signal to check if the proposed upgrade would cause a contentious fork. It has to come from validators.

17 mar 2025, 3:56 p.m.

En última instancia, la gobernanza de Solana no es vinculante y tiene carácter consultivo. En la práctica, la verdadera votación ocurre cuando los validadores eligen qué versión del software ejecutar. Aunque las votaciones de gobernanza pueden indicar un amplio apoyo u oposición de la comunidad, no obligan a los validadores a adoptar ningún código específico. Las propuestas incluso pueden cambiar después de la votación, y los validadores conservan el control total sobre lo que se ejecuta en su infraestructura. Esta dinámica significa que la gobernanza consiste más en señalar consenso que en imponer resultados.

Colaboradores principales como Anza, Jump y Jito, y proveedores de infraestructura como Helius y Triton, ejercen una influencia informal considerable en este contexto. Como es poco probable que los validadores se opongan a estos grupos y se arriesguen a perder participación o quedar desincronizados de la red, estas entidades pueden determinar de hecho los resultados de las actualizaciones, tengan o no autoridad formal para tomar decisiones.

En un escenario extremo, podría ocurrir una bifurcación si los validadores rechazan una actualización. La bifurcación de The DAO de Ethereum en 2016, que dio lugar a Ethereum Classic, sigue siendo un ejemplo aleccionador. A medida que evolucione el proceso de gobernanza de Solana, aclarar la relación entre los votos indicativos, las versiones de software y la adopción real por parte de los validadores garantizará la transparencia y evitará los riesgos extremos de división de la cadena.

Análisis de las votaciones de gobernanza

La gobernanza inicial de Solana: 2020-2022

El enfoque inicial de Solana sobre la gobernanza era muy distinto del marco actual. La gobernanza inicial se centraba en el Feature Proposal Program, que permitía a los validadores votar sobre cambios del protocolo mediante tokens SPL ponderados por participación. Cuando una nueva versión de una función estaba lista para activarse, los validadores recibían tokens de votación proporcionales a su participación activa. Al devolver esos tokens a una cuenta designada durante un plazo de dos semanas, los validadores podían indicar su aprobación para activar la función propuesta. Al alcanzar un umbral del 67 % de la participación, el cambio se habilitaba directamente on-chain en la época siguiente.

El Feature Proposal Program se utilizó varias veces para realizar votaciones de gobernanza de validadores tanto en Testnet como en Mainnet, sobre todo para activar el calendario de inflación actual.

Los registros en línea de estas primeras votaciones de gobernanza son escasos, ya que los Solana Forums originales se desconectaron y ahora solo se puede acceder a ellos mediante versiones archivadas en Wayback Machine.

Aunque este mecanismo introdujo cierto grado de coordinación on-chain, recibió muchas críticas. Los validadores no tenían forma de expresar desacuerdo: solo se contabilizaban los votos SÍ y no existía un método formal para indicar oposición o abstención. Este sistema también generaba presión social para aprobar cambios, sobre todo después de haber invertido un esfuerzo considerable de ingeniería en implementarlos. 

Más importante aún, el sistema no ofrecía indicios tempranos. Esto significaba que podían desarrollarse funciones complejas sin saber si serían aceptadas, lo que generaba ineficiencias y desperdiciaba tiempo de desarrollo.

En general, aunque el Feature Proposal Program fue un primer paso importante en la trayectoria de gobernanza de Solana, sus limitaciones ayudaron a orientar el desarrollo de los mecanismos de gobernanza más flexibles que se utilizan hoy.

Cabe señalar que varios cambios económicos importantes de este período inicial —como la introducción de comisiones de prioridad con una quema del 50 %— se implementaron sin votaciones formales de gobernanza, lo que refleja una época en la que el sistema aún estaba en sus primeras etapas.

La gobernanza actual de Solana: desde 2023

Tras utilizar el Feature Proposal Program, Solana evolucionó hasta su sistema actual de votación de gobernanza. Hasta ahora, se han realizado cinco votaciones oficiales:

• Votación consultiva inicial de octubre de 2023
• SIMD-33 Créditos de voto oportunos en abril de 2024, de Bryan Ischo y Zantetsu, Shinobi Systems
• SIMD-96 Comisión de prioridad completa para los validadores en mayo de 2024, de Tao Zhu, Anza
• SIMD-123 Distribución de recompensas por bloque dentro del protocolo, de Justin Starry, Anza
• SIMD-228 Mecanismo de emisiones basado en el mercado, de Tushar Jain y Vishal Kankani, Multicoin Capital, y Max Resnick, Anza, en marzo de 2025

Votación consultiva inicial

Una decisión inicial crucial para dar forma al marco actual de gobernanza de Solana fue determinar quién debía participar en el proceso de votación. Se presentaron tres opciones a la comunidad:

1. Votación exclusiva de validadores, con votos ponderados por participación
2. Validadores y cuentas de participación, para permitir que los delegadores anulen el voto de su validador
3. Validadores, cuentas de participación y otras partes interesadas, como operadores de RPC y desarrolladores

En la votación consultiva participaron más de 170 validadores, que representaban el 14,3 % de la participación total. De la participación que votó, más del 70 % apoyó la votación exclusiva de validadores, mientras que el 24 % prefirió un modelo de validadores y delegadores. No se aplicó un umbral mínimo de participación para esta votación.

La votación exclusiva de validadores fue la opción preferida como punto de partida más práctico y eficiente, dado que la infraestructura ya existía y se había probado en la práctica. Los sistemas más complejos que incluían delegadores u otras partes interesadas se consideraron prematuros y potencialmente onerosos para un proceso de gobernanza incipiente. La comunidad reconoció que podían introducirse y perfeccionarse modelos alternativos de votación mediante propuestas futuras a medida que madurara la gobernanza.

Patrones de votación de gobernanza

Desde la votación consultiva inicial se han realizado otras cuatro votaciones de gobernanza, con las mismas tres opciones: SÍ, NO y Abstención. Estas opciones indican el grado de acuerdo con el SIMD propuesto. Para que una votación sea aprobada, al menos dos tercios de los votos combinados SÍ y NO deben estar a favor (es decir, votar SÍ). 

SIMD-33: Créditos de voto oportunos se aprobó con un apoyo abrumador y recibió un 98,4 % de votos SÍ. Este cambio de consenso, que no generó controversia, corrigió incentivos desalineados al eliminar el beneficio que antes obtenían los validadores por enviar votos tardíos, mejorando así el comportamiento y la equidad de la red.

SIMD-96: Comisión de prioridad completa para los validadores se aprobó con un 77,7 % de votos SÍ. Esta propuesta económica buscaba desalentar el procesamiento de transacciones por canales secundarios al dirigir el 100 % de las comisiones de prioridad a los validadores. Aunque logró alinear los incentivos, generó cierta controversia debido a un aumento moderado de la inflación y al favoritismo percibido hacia los validadores frente a los titulares de SOL.

SIMD-123: Distribución de recompensas por bloque dentro del protocolo se aprobó con un 74,91 % de votos SÍ. La propuesta introdujo un mecanismo opcional y estandarizado para que los validadores distribuyan recompensas por bloque directamente a quienes hacen staking. Aunque varios validadores ya lo hacían mediante métodos más manuales, incorporarlo al protocolo generó debate sobre la presión competitiva y la preocupación de que pudiera provocar una "carrera hacia cero" en las tasas de comisión por recompensas de bloque.

SIMD-228: Mecanismo de emisiones basado en el mercado no se aprobó: solo el 61,39 % votó SÍ. La propuesta buscaba que la tasa de inflación de Solana respondiera mejor a la participación en staking, con el argumento de que las emisiones actuales son demasiado altas, no responden a la demanda de rendimiento y hacen que la red pague de más por la seguridad.

Los opositores expresaron inquietudes sobre la viabilidad económica de los validadores más pequeños y la incertidumbre adicional que podría introducir en los rendimientos del staking. La votación resultó muy controvertida, generó un amplio debate y puso de relieve distintas perspectivas sobre el modelo económico a largo plazo de Solana.

Para consultar el comportamiento detallado de los votantes, recomendamos revisar los paneles de votación de código abierto de SIMD-96, SIMD-123 y SIMD-228. Además, ofrecemos una hoja de cálculo con los datos de votación disponibles aquí.

Para SIMD-228 y SIMD-123 se aplicaron umbrales de cuórum del 33 % de participación —incluidos los votos de abstención—. En cambio, propuestas anteriores como SIMD-96 y SIMD-33 no tenían un requisito mínimo de participación, por lo que podían aprobarse sin importar qué proporción de la participación total votara.

Tasas de participación

Las tasas de participación en las votaciones han mostrado una tendencia ascendente con el tiempo. La votación consultiva inicial de octubre de 2023 tuvo una participación mínima: solo votó el 14,3 % de la participación. Desde entonces, aumentó de forma constante hasta culminar en la votación de marzo de 2025 sobre SIMD-228, el mecanismo de emisiones basado en el mercado, que alcanzó una tasa de participación del 74,3 %. Las otras tres votaciones realizadas hasta la fecha registraron niveles de participación relativamente constantes, de entre el 51,2 % y el 57,1 %.

La votación sobre SIMD-228 fue el mayor evento de gobernanza en la historia de las criptomonedas tanto por número de participantes como por la capitalización total de mercado representada. Al momento del debate, la capitalización de mercado de Solana era comparable a la de Bitcoin durante las guerras por el tamaño de bloque de mediados de 2017, lo que subraya la importancia de la decisión. Participaron en la votación 281 millones de SOL, valorados en $35 mil millones, y más de 900 validadores emitieron más de 1.000 votos. En particular, fue la primera vez que validadores de grandes exchanges —como Coinbase, Kraken y Bybit— participaron activamente en la gobernanza on-chain de Solana, lo que señala una creciente presencia institucional en el proceso de toma de decisiones de la red. Este reciente aumento de la participación, especialmente de entidades radicadas en Estados Unidos, también podría atribuirse en parte a un entorno regulatorio más favorable para blockchain bajo la administración actual.

Problemas y recomendaciones

En la siguiente sección analizaremos los principales desafíos del proceso de votación de gobernanza y, cuando corresponda, ofreceremos recomendaciones para mejorar la transparencia, la seguridad y la eficiencia.

Falta de participación de quienes hacen staking

Una preocupación recurrente en el proceso de gobernanza de Solana es el papel limitado de los delegadores en la toma de decisiones. Aunque los validadores votan sobre propuestas con un poder de gobernanza ponderado por participación, no existe un mecanismo formal para que los delegadores expresen sus preferencias o anulen las decisiones de los validadores. Esto puede generar situaciones en las que los votos de los validadores entren en conflicto con los intereses de sus delegadores, dejando a quienes hacen staking sin una forma directa de influir en los resultados de gobernanza.

A los validadores con miles de delegadores les cuesta recopilar las preferencias individuales de voto, y las tasas de participación de quienes hacen staking suelen ser bajas. Varios validadores abordan parcialmente este problema consultando a sus mayores delegadores antes de votar y dividiendo los votos según sus preferencias. Otros han experimentado con herramientas personalizadas que replican el sistema actual de votación mediante tokens, emitiendo nuevos tokens de gobernanza para quienes hacen staking con ellos según su participación proporcional. Sin embargo, esta sigue siendo una solución específica de cada validador, no una función estandarizada en todo el protocolo.

Quienes se oponen a la participación de las personas que hacen staking señalan que la mayoría de los delegadores no tienen conocimientos técnicos, rara vez siguen de cerca las decisiones de gobernanza y carecen de la comprensión profunda de los mecanismos y las concesiones de blockchain necesaria para tomar decisiones informadas. Sus defensores, sin embargo, sostienen que depender exclusivamente de los validadores crea un conflicto de intereses: no es realista esperar que la mayoría de ellos vote a favor de propuestas que benefician a la red si esas propuestas perjudican sus propios incentivos económicos.

Entre las posibles mejoras se incluyen mejores canales de comunicación entre validadores y delegadores, como paneles de gobernanza, herramientas de seguimiento de opinión o incluso notificaciones de wallet para eventos de gobernanza. Una sección posterior de este informe retomará este tema y examinará el enfoque del ecosistema de Cosmos.

Desafíos del debate sobre gobernanza

La gobernanza eficaz en ecosistemas descentralizados depende de una comunicación clara y relevante. Sin embargo, durante la reciente propuesta SIMD-288, los debates acalorados, los ataques personales y el faccionalismo crearon un entorno de gobernanza poco saludable que terminó por obstaculizar el diálogo productivo. Los debates sobre propuestas clave de Solana pueden sufrir ineficiencias y una calidad decreciente de la información en distintas plataformas. Aunque las discusiones técnicas en GitHub y en los foros oficiales de Solana ofrecen un debate estructurado y reflexivo, cuando las conversaciones llegan a Discord y Twitter, el diálogo significativo a veces degenera en guerras verbales y ataques ad hominem, lo que reduce la calidad general de la toma de decisiones.

Además, la mayoría de los participantes solo intervienen durante los últimos días antes de la votación, en vez de aprovechar todo el período de debate. Fomentar una participación más temprana y estructurar mejor los plazos de gobernanza —por ejemplo, al asegurar que las discusiones clave ocurran mucho antes del período final de votación— podría ayudar a mitigar estos problemas.

Las llamadas de gobernanza resultaron eficaces, ya que permitieron la interacción directa, aclaraciones rápidas y menos oportunidades para el troleo o la desinformación. Reforzar la moderación, fomentar debates estructurados y priorizar el análisis basado en hechos sobre los intercambios hostiles son medidas fundamentales para mantener un proceso de gobernanza constructivo.

Agrupación de propuestas de gobernanza

Las decisiones de gobernanza suelen ser más eficaces cuando cada propuesta se vota de forma independiente, lo que permite evaluar cada asunto por sus propios méritos. Una preocupación clave al agrupar propuestas es el sesgo inconsciente: quienes tienen una opinión firme sobre un tema pueden dejar que influya involuntariamente en su postura sobre otros, aunque no estén relacionados. Esto reduce la probabilidad de tomar decisiones con matices y podría impedir la implementación de cambios que de otro modo serían beneficiosos.

Otro riesgo es que la agrupación aumenta la complejidad operativa y hace más probables los errores. Esto se observó durante el período de votación conjunta de SIMD-228 y SIMD-123, cuando una pequeña cantidad de tokens destinados a SIMD-123 se envió por error a la dirección de abstención de SIMD-228. Aunque son poco frecuentes, estos errores distorsionan los resultados y socavan la confianza en el proceso de gobernanza.

Sin embargo, el argumento a favor de agrupar propuestas es que consolidar varias decisiones en menos períodos de votación puede reducir la fatiga de los votantes y fomentar una mayor participación. Aunque esto puede mejorar la participación, lo hace a costa de la claridad y la precisión en la toma de decisiones. Además, cuando las propuestas agrupadas son complejas, suelen requerir períodos prolongados de discusión y revisión antes de que comience la votación, para dar a los votantes —especialmente a quienes suelen participar a último momento— tiempo suficiente para comprender y evaluar a fondo cada componente.

Un enfoque más eficaz podría ser separar las propuestas de gobernanza siempre que sea posible, para garantizar que cada asunto se evalúe de forma independiente. Si es necesario agruparlas, debe justificarse claramente.

Cuórums de votación

El papel de un cuórum definido en las votaciones de gobernanza de Solana ha generado inquietudes. En la práctica, los cuórums pueden crear incentivos perversos: los participantes retienen estratégicamente sus votos para impedir que una propuesta alcance el umbral requerido. En la reciente votación de SIMD-228, esto fue especialmente evidente entre los votantes del NO, quienes durante las dos primeras épocas de votación descubrieron que abstenerse era una estrategia más eficaz que votar activamente contra la propuesta. 

La visibilidad de los recuentos de votos en curso influye en la participación. Algunos validadores pueden optar por no votar si el resultado esperado ya coincide con su preferencia. Para evitar la manipulación del cuórum, una posible mejora sería retrasar la visibilidad de los votos hasta que finalice el período de votación.

Ante estos desafíos, crece el apoyo a reevaluar o eliminar los requisitos de cuórum para fomentar una participación en la gobernanza más directa y transparente.

Efectos de SFDP

Al momento de redactar este informe, Solana Foundation Delegation Program delega SOL a 897 validadores, que representan el 66 % de todos los validadores activos de la red. El total delegado es de 41,01 millones de SOL, el 10 % del total de SOL en staking. Puedes consultar el informe anterior del blog de Helius sobre SFDP para conocer todos los detalles del programa y sus estrategias de delegación.

Con el modelo de gobernanza actual, los validadores del programa ven amplificado su poder de voto y votan en nombre de Solana Foundation. Nuestro análisis interno y el panel público de la reciente votación de gobernanza de SIMD-288 confirman que la participación de SFDP desempeña un papel importante en los resultados. En esta votación, se utilizó principalmente para votar NO a la propuesta. Si la participación controlada por SFDP que votó NO o se abstuvo hubiera votado SÍ, la propuesta se habría aprobado. Si toda la participación controlada por SFDP se hubiera mantenido neutral y se hubiera abstenido, la propuesta igualmente habría fracasado, pero por un margen menor: 64,77 % frente al 61,39 % real (se requería un 66,6 % para aprobarla).

Claridad sobre los criterios para convocar votaciones

Las votaciones de gobernanza de marzo de 2025 incluían originalmente tres propuestas: SIMD-228, SIMD-123 y SIMD-218: Créditos de voto intermedios (IVC). IVC elimina la necesidad de mods ejecutados por validadores que optimizan los créditos de votación de Tower BFT (la variante de Solana del algoritmo de consenso pBFT), al completar automáticamente los créditos de todos los bloques principales cuando los validadores votan por un bloque secundario.

Durante el período de debate, surgió un consenso creciente de que SIMD-218 no debía requerir aprobación de gobernanza. El cambio se consideraba ampliamente una corrección de errores, no una modificación sustancial del protocolo, ya que simplemente mejoraba o corregía la actualización Timely Vote Credits (TVC). TVC ya había superado una votación de gobernanza y demostrado un fuerte apoyo de la comunidad. Una encuesta informal entre validadores en el Discord de Solana Tech reforzó esta opinión con un acuerdo casi unánime.

Además, ingenieros de Anza señalaron que SIMD-123: Distribución de recompensas por bloque dentro del protocolo no era un cambio económico, a pesar de lo que sugiere el nombre. La propuesta introdujo un método opcional dentro del protocolo para distribuir recompensas por bloque a quienes hacen staking. Así formalizó una práctica que varios validadores ya realizaban mediante métodos alternativos y estandarizó lo que antes era una actividad externa al protocolo.

Esto plantea preguntas importantes sobre la gobernanza:

• ¿Quién decide si una propuesta requiere una votación? Actualmente, no existe un organismo oficial ni un proceso estructurado para determinar si una propuesta debe pasar por la gobernanza o implementarse directamente.
• Qué constituye un “cambio sustancial del protocolo” sigue siendo ambiguo. La línea entre una actualización rutinaria y un cambio que justifica una intervención formal de la gobernanza es difusa, y las definiciones actuales dependen en gran medida de la noción algo imprecisa de “impacto económico”.

Problemas de seguridad

El proceso actual de votación de propuestas de gobernanza depende de una herramienta de terceros, solgov-distributor, desarrollada y alojada por Laine, un miembro de la comunidad. Esta herramienta es una bifurcación de un distribuidor de tokens basado en Merkle desarrollado originalmente por Jito. Aunque Laine es un miembro muy respetado de la comunidad, depender de una herramienta controlada externamente introduce supuestos de confianza y riesgos de seguridad.

• Mutabilidad – tanto la herramienta como su documentación son mutables, lo que significa que pueden modificarse unilateralmente en cualquier momento.
• Uso de los pares de claves de identidad de los validadores – Los validadores deben compilar la CLI y reclamar tokens mediante los pares de claves de identidad de sus validadores, que son sumamente sensibles. Todo proceso que dependa de software externo para interactuar con credenciales tan críticas supone un riesgo de seguridad.
• Dependencia de una persona responsable del mantenimiento – Un proceso oficial de gobernanza no debe tener dependencias críticas de terceros externos sin garantías formales de seguridad o auditorías independientes.

Mecanismos alternativos de votación

Existe una herramienta SPL Feature Proposal (documentación aquí), diseñada inicialmente para facilitar la gobernanza on-chain. Sin embargo, los procesos recientes de gobernanza no siguieron este enfoque. En su lugar se utilizó solgov-distributor, lo que plantea la pregunta de si esta herramienta adicional era necesaria.

En principio, el sistema de tokens SPL ya ofrece un método nativo para distribuir el poder de voto de gobernanza. Quien inicia el proceso podría simplemente distribuir tokens SPL a todos los validadores y permitirles votar mediante la CLI estándar spl-token, en vez de depender de una herramienta externa. Esto eliminaría dependencias innecesarias y reduciría la necesidad de confianza en el proceso de votación.

Próximas herramientas de gobernanza on-chain: SIMD-133

La próxima SIMD-133: Obtener la participación de una época, cuya activación en Mainnet está prevista próximamente, introduce nuevas herramientas de gobernanza que permiten a los programas consultar ponderaciones de participación on-chain. Actualmente, los programas on-chain no conocen la distribución de participación de la época actual ni cuánta participación está delegada a cada cuenta de voto.

Con SIMD-133, los programas de gobernanza pueden tomar instantáneas on-chain de las cantidades de participación de los validadores mediante una nueva sysvar, lo que elimina la necesidad de procesos manuales o externos para verificar la participación. Esto agiliza de forma considerable el flujo de gobernanza actual y elimina la necesidad de conciliar manualmente las participaciones.

Comparación con redes alternativas

Cosmos

Las cadenas de Cosmos SDK ofrecen un modelo de gobernanza centrado en el delegador, donde quienes hacen staking pueden anular el voto de su validador directamente desde wallets populares como Keplr y Leap. Esto significa que, aunque un validador emite inicialmente un voto con todo el peso de su participación, los delegadores que no están de acuerdo pueden reasignar su parte de la participación a otra opción de voto. Por ejemplo, si un validador posee el 2 % de la participación total, pero un delegador con un peso de participación del 1 % no está de acuerdo, puede votar por separado, reduciendo el voto efectivo del validador al 1 % y trasladando su 1 % a otra opción.

Este sistema garantiza que los delegadores siempre tengan la última palabra, lo que crea un proceso de gobernanza transparente, accesible y eficiente. La participación en la gobernanza de Cosmos tiene gran visibilidad, ya que la votación se integra directamente en wallets y exploradores de bloques, lo que facilita el acceso a todas las partes interesadas.

Un ejemplo relevante de las diferencias de comportamiento entre quienes hacen staking y los validadores ocurrió durante la votación sobre la reducción a la mitad de ATOM en Cosmos (Propuesta 848, nov. de 2023), que buscaba reducir la tasa máxima de inflación al 10 %:

• El 94,93 % de quienes hacían staking votó SÍ y apoyó el límite de inflación.
• Solo el 53,44 % de los validadores votó SÍ, ya que muchos buscaban preservar mayores fuentes de ingresos.

Esta divergencia destaca la importancia de la participación directa de quienes hacen staking, pues garantiza que las decisiones de gobernanza reflejen la opinión general de la comunidad y no solo las preferencias de los validadores.

El módulo de gobernanza de Cosmos está integrado en el protocolo, lo que refuerza su papel como función central de la blockchain. Ciertas decisiones de gobernanza pueden ejecutarse automáticamente on-chain, mejorando la transparencia y la rendición de cuentas. 

Aunque este modelo ofrece una estructura de gobernanza democrática, depende de la participación activa y supone que los delegadores tienen el tiempo y los conocimientos necesarios para tomar decisiones informadas. Cosmos ofrece un marco de gobernanza alternativo convincente que Solana podría estudiar para identificar posibles mejoras.

Ethereum

La gobernanza de Ethereum sigue un proceso social y off-chain, en lugar de una votación directa basada en la participación. El proceso de toma de decisiones depende principalmente de las propuestas de mejora de Ethereum (EIP), los desarrolladores principales y el consenso de la comunidad.

Los cambios en Ethereum se proponen mediante EIP, equivalentes a los SIMD de Solana. Estas EIP describen nuevas funciones, estándares o actualizaciones del protocolo de Ethereum. Las solicitudes de comentarios de Ethereum (ERC) definen estándares para funciones de la capa de aplicaciones, como los tokens ERC-20 y los NFT ERC-721. Estas propuestas se debaten abiertamente en foros de investigación de Ethereum (Ethereum Magicians), eventos populares de Ethereum (por ejemplo, Devcon, ETHDenver y ETHCC), GitHub y llamadas de desarrolladores principales. La comunidad en general participa en la gobernanza al debatir propuestas en plataformas como Discord, Farcaster y X.

A diferencia de Cosmos o Solana, Ethereum no utiliza una gobernanza basada en la participación o la votación con tokens para las decisiones del protocolo. Desde que Ethereum adoptó Proof-of-Stake, los validadores desempeñan un papel más activo en el consenso, pero no votan formalmente. En cambio, se alcanza un consenso aproximado mediante debates técnicos y un amplio apoyo de la comunidad. Los cambios del protocolo de Ethereum dependen en gran medida de los desarrolladores principales que mantienen sus clientes de ejecución y consenso (por ejemplo, Geth, Nethermind y Prysm).

Las actualizaciones importantes se activan mediante bifurcaciones duras, que exigen a los validadores y operadores de nodos actualizar su software. Los validadores aplican las reglas de la red al decidir si adoptan las nuevas actualizaciones. Aunque es poco frecuente, si un cambio propuesto es controvertido y carece de consenso, podría provocar una división de la cadena, como ocurrió en bifurcaciones anteriores como la de The DAO (2016, Ethereum Classic) y, en menor medida, la transición de Ethereum a Proof-of-Stake (2022, EthereumPoW).

El modelo de gobernanza social de Ethereum prioriza el consenso técnico y el debate comunitario sobre los mecanismos formales de votación. Aunque esto ha mantenido a Ethereum flexible y descentralizado, también implica que los cambios requieren discusiones largas y prolongadas, además de coordinación social, en lugar de una gobernanza directa basada en tokens. Asimismo, no existe una forma formal para que los titulares de ETH o quienes hacen staking voten sobre propuestas, lo que limita la influencia directa de los usuarios.

Conclusión

El sistema de gobernanza de Solana sigue en desarrollo y está moldeado por la experimentación en el mundo real y los aportes de la comunidad. Este informe examinó sus componentes centrales —los SIMD, las activaciones de funciones y las votaciones on-chain—, además de revisar todas las votaciones formales hasta la fecha, los principales desafíos y las comparaciones con redes similares como Cosmos y Ethereum. 

El ecosistema de Solana se sustenta en una sólida cultura impulsada por la ingeniería, que valora la iteración y la ejecución rápidas por encima de los debates prolongados. Aunque esta alta velocidad de actualización distingue a Solana de muchas redes similares, también crea tensiones con los modelos de gobernanza que dependen de largas discusiones comunitarias y una amplia coordinación social, lo que presenta desafíos únicos para equilibrar la velocidad con una toma de decisiones inclusiva.

La gobernanza de Solana aún está tomando forma, pero algo está claro: la participación de la comunidad nunca había sido tan alta. A medida que más partes interesadas dan forma activamente a la red, Solana tiene una oportunidad única de construir un modelo de gobernanza acorde con su ambición, velocidad y ecosistema en crecimiento.

Recursos adicionales

• Medición de la descentralización de Solana: datos y cifras - Blog de Helius
• Laboratorio de ideas sobre la gobernanza de Solana
• Gobernanza de blockchain: programar nuestro futuro - Fred Ehrsam