Las recompensas de staking en Solana pueden seguir cuadrando mientras algunos registros dejan vacío el campo de comisión. Para verificar qué tasa se aplicó, los delegadores necesitan reconstruir el historial del validador y relacionarlo con el período correcto.
***
- Desde el 8 de septiembre, ciertos registros de recompensa no muestran la comisión del validador, según un informe de P2P.org.
- El cambio de Agave no prueba que haya pagos faltantes ni cobros excesivos: afecta la evidencia disponible para explicar el pago.
- El historial de tasas y las instantáneas pueden ayudar a reconstruir la comisión efectiva, aunque su cobertura y contexto importan.
⚠️ Solana omite la comisión en algunos registros de staking
Desde el 8 de septiembre, ciertos registros no muestran la tasa del validador, aunque las recompensas siguen conciliándose.
El dato vacío no significa comisión cero ni prueba pagos faltantes. Auditarla requiere… pic.twitter.com/VCCVI9ZWVj
— Diario฿itcoin (@DiarioBitcoin) November 1, 2026
Solana deja fuera la comisión de algunos registros de recompensa y complica las auditorías
Los pagos de staking de Solana pueden continuar visibles y reconciliarse con los saldos recibidos, aunque algunos registros de recompensa no muestren la comisión del validador que ayuda a explicar ese resultado. La ausencia del dato no demuestra por sí sola que falte SOL ni que un validador haya cobrado de más, pero sí obliga a quienes revisan un pago a buscar evidencia adicional en el historial de tasas y en el período correspondiente.
El asunto afecta una pieza de información contable, no necesariamente el cálculo ni la entrega de la recompensa. En un informe fechado el 30 de octubre, el proveedor de staking y reportes P2P.org señaló que el campo de comisión había desaparecido de ciertos registros de recompensas de voto y de staking desde el 8 de septiembre, pese a que las comisiones seguían cobrándose y los montos de recompensa continuaban conciliándose.
Qué cambia cuando el registro no incluye la comisión
Según el análisis, el cambio técnico se incorporó al cliente Agave mediante la solicitud de cambios número 12588, fusionada el 20 de mayo. A partir de la activación de la función de colectores personalizados, el campo de comisión queda vacío en los metadatos públicos de recompensas acumuladas del validador y en los registros de recompensas individuales de las cuentas de staking; el dato vacío, por tanto, no equivale a una comisión de cero.
La solicitud describe cargas de recompensa utilizadas en consultas de bloques y suscripciones, es decir, datos que servicios y usuarios pueden consultar para examinar qué recompensa se registró. De acuerdo con el análisis, el cálculo de Agave todavía considera la comisión antes de suprimirla del registro final. Por tanto, lo que cambia es la información visible que acompaña al pago, no una afirmación de que el sistema haya dejado de cobrarla o de calcularla.
La función de colectores personalizados responde a otro objetivo: permite que los validadores dirijan ingresos por comisiones a cuentas designadas. La especificación de protocolo SIMD-0232 indica que el cálculo de la comisión por inflación permanece sin cambios y establece nuevas reglas para recolectar esos ingresos; según la lógica expuesta en la solicitud de Agave, una recompensa acumulada puede reunir ingresos enviados a distintos colectores, por lo que asociarla a una sola tasa podría resultar inadecuado.
Sin embargo, el mismo cambio también retira el campo de las recompensas de cuentas individuales de staking, aunque allí el titular examine una delegación concreta. El efecto práctico es que un recibo puede mostrar el SOL recibido, pero no la tasa que permitiría entenderlo de forma inmediata; la verificación exige conectar el pago con registros externos o reconstruir el estado histórico del validador.
La fecha de la recompensa determina qué tasa corresponde
La reconstrucción no consiste simplemente en consultar la comisión que aparece actualmente en la cuenta de voto. Solana aplica un desfase entre los cambios de tasa y el período de recompensa, denominado epoch: bajo la regla SIMD-0249, para una recompensa ganada durante el epoch E, el sistema captura normalmente la tasa al comienzo de E−1 y calcula esa recompensa al comienzo de E+1.
Ese calendario separa la tasa relevante para un pago histórico de la configuración más reciente que muestra la cuenta del validador. En consecuencia, tomar el dato visible hoy y atribuirlo sin más a una recompensa anterior puede llevar a seleccionar una tasa que no fue la que correspondía aplicar; para auditar el pago hacen falta tanto el período como evidencia cronológica compatible con la regla.
La dificultad también se relaciona con la forma en que el historial de una cuenta está disponible. Para cuentas de voto nuevas, el sistema contempla valores de reserva, o fallbacks, cuando no existe el historial de la cuenta anterior; por eso, conocer la tasa actual, el período de recompensa y la delegación de la cuenta de staking al validador son partes distintas de una misma comprobación.
Una discusión de ingeniería del 16 de julio ya había descrito que la tasa efectiva y el colector podían mantenerse en el estado de ejecución en caché, sin que una lectura ordinaria de la cuenta permitiera inspeccionarlos. Los desarrolladores trataron esa dependencia del estado en caché por separado y señalaron que el retraso en la aplicación de las comisiones ya estaba activo en la red principal. Esto implica que consultar la cuenta no siempre basta para conocer la tasa usada en cada período.
Herramientas de reconstrucción y límites de la evidencia
El 18 de octubre, el colaborador de Agave ax-x2 planteó una solicitud para ampliar la respuesta de RPC con la comisión por inflación efectiva, el epoch al que corresponde y el bank slot. La petición advierte que getVoteAccounts y los datos analizados de una cuenta de voto pueden mostrar la configuración más reciente, mientras el cálculo de recompensas utiliza una tasa guardada; al 30 de octubre, la solicitud seguía abierta y no tenía una implementación vinculada.
El ejemplo incluido en esa petición, con una tasa visible baja frente a una tasa guardada más alta, presenta un escenario posible, no un incidente identificado ni evidencia de un cobro excesivo. Distinguir entre una advertencia técnica y un perjuicio demostrado es importante: la información descrita apunta a un problema de trazabilidad del registro y no establece que un validador específico haya retenido fondos de manera indebida.
El Programa de historial de validadores de Jito documenta hasta 512 epochs de historial por validador, incluida la comisión, y su instrucción de copia registra una observación junto con el período y el slot. Ese archivo puede aportar datos para una reconstrucción, pero guardar una observación histórica no demuestra por sí solo que sea exactamente la tasa efectiva, con el desfase correspondiente, que se aplicó a un pago determinado.
Marinade documenta otra vía mediante un analizador de instantáneas que extrae la comisión por inflación de instantáneas de participación del epoch y registra el origen del valor y los contadores de reserva. Esa información de procedencia es relevante porque un número sin contexto sobre cuándo y cómo se capturó no permite asumir que representa la tasa efectiva; el protocolo también advierte sobre límites de archivo y archivos antiguos sin metadatos de origen.
Rendimiento y comisión no son la misma medición
Trillium, proveedor de datos, describe una metodología para estimar el rendimiento de inflación a partir del crecimiento de las cuentas de staking desde el epoch 1070, con controles de elegibilidad y alternativas basadas en RPC, sin depender de la comisión mostrada. Para períodos anteriores emplea métodos distintos, una salvedad que impide interpretar la serie como si todos los epochs compartieran idéntica cobertura y procedimiento.
Medir cuánto aumentó una cuenta puede seguir siendo posible aunque el registro no muestre la comisión que contribuyó a ese resultado. Pero esa estimación del rendimiento no verifica de manera independiente la tasa aplicada, y la metodología de Trillium distingue entre un resultado desconocido y uno de cero cuando no encuentra evidencia adecuada de la cuenta; la ausencia de datos, por tanto, no debe confundirse con ausencia de recompensa.
Para un titular de SOL o un producto de staking, un registro útil debería vincular el monto neto recibido con el período, la delegación al validador y la evidencia de la comisión efectiva. Si la tasa se reconstruye mediante archivos o muestreos, el registro también debe indicar qué parte de la cobertura está disponible y cuáles son sus límites, en vez de presentar una cifra aislada como prueba concluyente.
Entre las posibles mejoras figuran una propuesta de octubre para guardar las tasas de comisión junto con los epochs en que entran en vigor y la solicitud de RPC para consultar la tasa efectiva usada por el sistema. Ninguna de las dos aparece como una solución implementada en los registros descritos, por lo que la propuesta de mejorar la trazabilidad sigue pendiente y no debe confundirse con una capacidad ya disponible.
El alcance de una auditoría también depende de qué ingreso se esté midiendo: la comisión por inflación, la comisión de MEV y el reparto de ingresos de bloque son componentes separados. Hacer visible una tasa no explicaría automáticamente todas las partes del rendimiento de staking, así que los informes deben especificar qué componente cubren y evitar atribuir a una sola cifra una explicación más amplia de la que ofrece.
La cobertura de CryptoSlate sobre los créditos de voto vinculados a recompensas ya había advertido que una medición de rendimiento no permite concluir, sin evidencia a nivel de cuenta, que un titular perdió SOL. La misma cautela aplica aquí: P2P.org sostiene que las recompensas se reconcilian, mientras que explicar la comisión que estuvo detrás de cada pago requiere unir ese recibo con la tasa histórica correcta y comprobar que la evidencia corresponde al mismo período.
ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.
Suscríbete a nuestro boletín
Artículos Relacionados
IA
Linux 7.4 rompe el récord de cambios en el kernel: casi 20.000 commits en su ventana de fusión
Binance
Hacker vinculado a Binance mueve USD $46,4 millones en SOL para convertirlos a BTC
Bitcoin
B14g pierde USD $1,47 millones en un ataque que explotó retiros de valor cero
Empresas
