Artículos · Staking
Lo retenido a quienes salen no se entrega de golpe a los que se quedan: se reparte de forma uniforme, y ese reparto tiene una ventana. Parece que varias salidas seguidas deberían encadenar sus ventanas. En el contrato funciona de otra manera, y esa diferencia explica por qué el rendimiento del pool se mueve a dientes de sierra.
5 de octubre de 2026 · verificado al publicar
La ventana se cuenta desde cada salida por separado y nunca supera los siete días. Tres salidas grandes seguidas no dan veintiún días: cada una pone la ventana a cero y cuenta siete de nuevo desde sí misma. Las ventanas no forman una cadena: se solapan.
Las marcas naranjas son los momentos de las salidas, los rectángulos azules son las ventanas de reparto, y la cifra dentro de cada uno es su duración en días. Tres salidas en los dos primeros días cierran el reparto el noveno día, no el vigesimoprimero. Y el final tampoco puede caer más tarde en principio: cada ventana dura exactamente siete días desde su propia salida.
El pool de staking tiene una sola fuente de ingresos: la comisión retenida a quienes salen. Cuando un staker recupera su posición, el contrato deja en el pool el 10% de toda ella, con lo acumulado incluido. Esto se comprueba en el propio código: el contador undistributedFees aumenta exactamente en un punto, dentro de la función de salida.
Pero lo retenido no se reparte de inmediato. Cae en la «olla» de comisiones sin repartir y sale de ahí de forma uniforme, a una velocidad constante rewardRate medida en RNBW por segundo. Mientras sale, sube el precio de la participación: es decir, lo añadido llega a todos los que están en el pool, en proporción al tamaño de su posición. Nadie recibe participaciones nuevas: cada una de las existentes pasa a valer más.
Por eso el rendimiento del staking no depende de cuánta gente entró, sino de cuánta salió. Las entradas lo bajan: el mismo flujo de monedas se reparte entre un pool mayor. Las salidas lo suben, y por partida doble: el pool se encoge y se le añade la décima parte de quien se fue.
Una comisión nueva no se suma sin más a la anterior. El contrato recalcula a qué velocidad se vaciará todo ahora y elige una de tres ramas. La elección se reduce a una única comparación: si la velocidad nueva supera a la actual o no.
No hay reparto en curso: la ventana anterior ya venció
La velocidad es la olla dividida entre siete días. Todo empieza de cero.
ventana: exactamente 7 días
Olla ÷ 7 días no es menor que la velocidad actual: salida grande
La velocidad sube y la ventana se pone a cero y se cuenta de nuevo desde este mismo segundo.
ventana: exactamente 7 días
Olla ÷ 7 días es menor que la velocidad actual: salida pequeña
La velocidad no cambia, el goteo es el mismo. Solo tendrá que gotear más tiempo: lo que quede de ventana más lo añadido dividido entre la velocidad.
ventana: menos de 7 días
Por eso el techo se sostiene sin excepciones. En dos ramas la ventana es igual a siete días por definición. En la tercera es más corta que siete, porque si no la velocidad habría subido y habría actuado la segunda rama. En el código no hay una cuarta opción.
La protección contra bajar la velocidad es deliberada y está comentada en el contrato con las palabras rewardRate can only stay flat or increase. Sin ella, cualquiera podría salir en porciones de céntimos y hundir el rendimiento de los demás con cada salida.
Tres casos a la misma escala. En naranja, cuánto RNBW hay en la olla: se rellena de golpe en una salida y baja de forma uniforme. La pendiente de la línea es la velocidad de reparto: cuanto más inclinada, más rápido llegan las comisiones a los stakers.
A: salida sin reparto en curso. Se retienen 100.000 RNBW con la olla vacía, así que toca repartir 14.286 al día. El séptimo día no queda nada.
C: salida grande a mitad del reparto. El tercer día se retienen otros 100.000. La pendiente se inclinó, la velocidad subió a 22.449 al día, la ventana se puso a cero y el final se corrió al décimo día.
D: tres salidas grandes seguidas. El final cae el noveno día, no el vigesimoprimero. Lo que sí creció es la velocidad: de 14.286 a 37.026 RNBW al día, un reparto 2,6 veces más rápido.
En el caso C está el engaño de la vista. El reparto terminará de verdad más tarde que los siete días iniciales: el décimo. Pero eso no es «una ventana de diez días»: desde la salida del tercer día hasta el final hay exactamente siete. La ventana no se estiró, la movieron.
La tercera rama parece poca cosa, pero es la que actúa casi siempre: en toda la historia, las salidas lo bastante grandes como para subir la velocidad se cuentan con los dedos. Mirémosla de cerca, porque en el gráfico general todo lo decisivo ocurre a una escala que allí no se ve.
El recuadro ① está ampliado 28 veces en vertical; el ②, 15 veces en el tiempo. La línea discontinua en ambos muestra cómo habría ido la cosa sin el aporte.
Lo principal se ve en el recuadro ①: la línea antes del escalón y la de después son paralelas. La velocidad no cambió, el goteo siguió igual; solo subió el nivel de la olla. Por eso el plazo se alarga exactamente lo que el goteo tarda en sacar lo añadido: 1.000 ÷ 14.286 al día = 1 hora y 41 minutos. Se ve en el recuadro ②.
El final del reparto se corrió de 7,00 a 7,07 días, y desde la propia salida hasta el final quedan 4,07: casi tres días por debajo del techo. Pero ese margen de tres días es una propiedad de este ejemplo, no de la rama: salió de que la salida cayó a mitad de la ventana y era minúscula.
Entonces esa misma tercera rama alargará el reparto casi siete días. Su margen no depende solo del tamaño de lo añadido, sino de cuánta ventana quedaba: la prórroga es igual a lo que reste de ventana más lo añadido dividido entre la velocidad.
El eje vertical es la duración de la ventana desde la salida, en días. Cada línea naranja corresponde a un tamaño de retención. El punto B es el caso de la sección anterior: salida el tercer día con un aporte de 1.000. El punto de arriba a la derecha es una salida el día 6,9 con un aporte de 95.000.
Las líneas son paralelas y todas chocan con el techo azul. Cuanto más tarde la salida, menos queda por vaciar, pero más pesa lo añadido frente a ese resto. Un aporte grande al final de la ventana llega casi pegado a los siete días: en una salida el día 6,9 con 95.000 retenidos, 0,10 más 6,65 deja 6,75 días, y sigue siendo la rama «el plazo se alarga».
| Retenido | En la olla | Ventana, d | Final, d | Rama |
|---|---|---|---|---|
| 1.000 | 2.429 | 0,17 | 7,07 | plazo alargado |
| 25.000 | 26.429 | 1,85 | 8,75 | plazo alargado |
| 50.000 | 51.429 | 3,60 | 10,50 | plazo alargado |
| 95.000 | 96.429 | 6,75 | 13,65 | plazo alargado |
| 98.571 | 100.000 | 7,00 | 13,90 | plazo alargado |
| 100.000 | 101.429 | 7,00 | 13,90 | velocidad subió |
Fíjese en las dos últimas filas: ahí está la frontera entre las ramas. Una retención de 98.571 RNBW todavía cae en «plazo alargado», mientras que 100.000 ya sube la velocidad. Y ambas dan lo mismo: exactamente siete días. Entre ellas no hay salto, la frontera es suave: la rama «el plazo se alarga» se acerca a los siete días por debajo y la rama «la velocidad subió» se apoya en ellos. Por eso el techo se sostiene sin excepciones.
La duración en el calendario, en cambio, no está acotada por nada. En la columna «Final», con una retención de 95.000 aparece 13,90 días: casi dos semanas. El techo de siete días acota la ventana de cada salida por separado, no el plazo total. Las salidas que caen cerca del final de una ventana pueden empujarla indefinidamente, y con un flujo vivo de salidas el reparto sencillamente no se detiene nunca, que es lo que ocurre de hecho: la olla no se vacía.
Todo lo descrito aquí se deduce directamente de la función _addFees del contrato de staking 0x288ea8Bcb51d53aD361D786EFa904C401904aF70. El código fuente está publicado y verificado, y puede leerse en el explorador.
El contrato asigna dripEndTime = block.timestamp + dripDuration, donde dripDuration vale 604800 segundos, es decir, exactamente siete días desde el segundo actual. La ventana anterior sencillamente deja de existir.
Aquí es dripEndTime = block.timestamp + undistributedFees / rewardRate. La propia condición de entrada en esta rama garantiza que el cociente es menor que dripDuration, porque si no habría actuado la rama anterior.
El saldo de la olla y la velocidad se leen del contrato con las llamadas undistributedFees() y rewardRate(). Ambos, junto con el historial de todas las salidas y una nota de qué rama actuó en cada una, están en la página Staking.
Las cifras de los ejemplos de este artículo se obtuvieron reproduciendo _syncPool y _addFees paso a paso desde el estado cero, y no se tomaron del sitio, para que no pudieran ajustarse a la conclusión.