Lido: el rebase de stETH falla su objetivo por un retraso contable de 32 ETH

El rebase de stETH de Lido no alcanzó su objetivo diario tras un retraso contable de 32 ETH, un desajuste que dejó a los tenedores del token de staking líquido con un rendimiento menor al esperado durante ese ciclo. El incidente, reportado por AMBCrypto, abre la pregunta de si el protocolo puede recuperar el terreno perdido en las siguientes actualizaciones.

stETH es el token que reciben los usuarios cuando depositan ether en Lido, el mayor protocolo de staking líquido de Ethereum. A diferencia de otros activos, stETH aplica un mecanismo de rebase: en lugar de que suba su precio, el saldo del token en la cartera del usuario crece cada día para reflejar las recompensas de staking acumuladas. Cuando ese ajuste diario se queda corto, el rendimiento visible para el usuario también lo hace.

Por qué el rebase de stETH no llegó a su objetivo

Según la información disponible, el fallo se originó en un retraso de contabilidad equivalente a 32 ETH, una cifra que no es casual: 32 ether es exactamente lo que exige la red Ethereum para activar un validador. Cuando la contabilización de las recompensas o del estado de un validador se procesa fuera del ciclo previsto, el oráculo que alimenta el cálculo del rebase reporta un total inferior al real, y el ajuste diario queda por debajo del objetivo.

Publicidad

Este tipo de desfase suele ser temporal. El diseño de Lido contempla que las recompensas no contabilizadas en un ciclo se reflejen en los siguientes, de modo que el rendimiento acumulado tiende a corregirse aunque un rebase puntual se quede corto. La duda que plantean los analistas es sobre el ritmo de esa recuperación y sobre la transparencia con la que el protocolo comunica estos desajustes a sus usuarios.

Qué significa para los tenedores de stETH

Para el usuario promedio, un rebase que falla su objetivo se traduce en un incremento del saldo menor de lo previsto ese día. No implica una pérdida de capital ni un problema de solvencia del protocolo, pero sí introduce ruido en la percepción del rendimiento, especialmente para quienes siguen de cerca la tasa anual de staking.

El punto sensible es la confianza. stETH funciona como colateral en buena parte de las finanzas descentralizadas (DeFi): se usa en préstamos, en pools de liquidez y en estrategias apalancadas. Cualquier señal de que el mecanismo de recompensas no opera con la precisión esperada puede afectar la manera en que otros protocolos valoran el token, aunque el desajuste sea contable y no económico.

Conviene recordar la escala de Lido dentro de Ethereum. El protocolo concentra una porción muy relevante de todo el ether en staking, lo que convierte cualquier fallo en su contabilidad en un asunto de interés para el conjunto de la red, no solo para sus usuarios directos.

El staking líquido, bajo la lupa

El episodio llega en un momento en que el staking gana protagonismo como fuente de rendimiento para el capital cripto. Los productos regulados también empiezan a incorporarlo: recientemente, un ETF de Hashdex anunció que repartirá el rendimiento del staking entre inversores y gestora, una señal de que estos ingresos dejan de ser un asunto exclusivo de los usuarios nativos de DeFi.

En ese contexto, la fiabilidad del mecanismo de recompensas se vuelve un factor competitivo. Los protocolos de staking líquido compiten por atraer depósitos ofreciendo rendimientos consistentes y predecibles; un rebase que incumple su objetivo, aunque se corrija después, alimenta el debate sobre la robustez de la infraestructura que sostiene estos productos.

Lido no es ajeno a este escrutinio. Su tamaño lo ha colocado en el centro de discusiones sobre la centralización del staking en Ethereum, y cada incidente operativo se lee bajo esa lente. La transparencia con la que documente el retraso de 32 ETH y la velocidad con la que normalice los siguientes rebases serán claves para medir la reacción de la comunidad.

¿Puede recuperarse el rebase de stETH?

La mecánica del protocolo apunta a que sí. Al tratarse de un retraso de contabilización y no de una pérdida de recompensas, lo esperable es que el rendimiento no reflejado se compense en ciclos posteriores, devolviendo el saldo acumulado a la trayectoria prevista. La recuperación dependerá de que el oráculo procese correctamente el estado del validador afectado y de que no se acumulen nuevos desfases.

Para los tenedores, la recomendación implícita es observar la evolución de varios rebases consecutivos antes de sacar conclusiones. Un fallo aislado dentro de un sistema que mueve enormes cantidades de ether es distinto a un patrón recurrente. Por ahora, el incidente funciona como un recordatorio de que incluso los protocolos DeFi más consolidados dependen de piezas técnicas —oráculos, contabilización de validadores, sincronización de ciclos— que pueden desajustarse y que conviene vigilar.