LeverageX es una plataforma descentralizada que permite a los usuarios abrir posiciones con un alto nivel de apalancamiento, de hasta 150x, sobre múltiples activos financieros, como criptomonedas, acciones y divisas. Dado que el protocolo se gestiona íntegramente mediante contratos inteligentes, ofrece transparencia y la posibilidad de operar con autocustodia desde las carteras de los usuarios. Si bien la complejidad de su funcionamiento aporta estas ventajas, también conlleva posibles fallos de seguridad.

AuditOne ha auditado recientemente de forma manual auditado los contratos inteligentes de LeverageX. Buscamos vulnerabilidades que pudieran poner en peligro la solvencia, la integridad o los fondos de los usuarios del protocolo. Entre los diversos hallazgos de alta gravedad, uno destacó especialmente por el riesgo que suponía para el sistema: un error en la lógica de actualización del apalancamiento que podría aprovecharse para manipular los precios de liquidación, lo que pondría en riesgo la solvencia del protocolo.

El riesgo clave: la actualización del apalancamiento una vez superados los umbrales de liquidación

Es fundamental mantener una lógica de liquidación precisa en los sistemas de alto apalancamiento. El error más importante detectado se encuentra en la función `updateLeverage()` del archivo `UpdateLeverageUtils.sol`. A continuación se explica lo que ocurre entre bastidores:

• El usuario abre una posición con un margen extremadamente bajo, pero con un apalancamiento extremadamente alto.
• Cuando se invoca la función updateLeverage(), esta invoca a _prepareValues(), que vuelve a calcular valores internos como el precio de liquidación (liqPrice).
• Con un valor de collAmount tan bajo, el método interno _getTradeLiquidationPrice() calcula que el valor de collateralLiqNegativePnlInt es inferior a las comisiones del protocolo.
• Esto hace que la función devuelva un valor de liquidación de 1, lo que representa un estado de liquidación activado o no válido.
• Lo más importante es que no se comprueba el valor devuelto; la actualización continúa como si todo fuera bien.

Esta laguna jurídica puede reactivar el apalancamiento incluso si la posición se ha cerrado efectivamente. Una persona puede hacer un uso indebido de esta laguna para atacar el sistema con el fin de provocar situaciones de denegación de servicio (DoS) o generar inestabilidad financiera en el sistema.

La solución: una protección sencilla y eficaz

Esta deficiencia puede subsanarse añadiendo una comprobación de validación. Esta medida de protección básica impide cualquier intento de actualizar el apalancamiento cuando falla la lógica de liquidación, revirtiendo la transacción. Se trata de una solución que requiere poco esfuerzo y que tiene un gran impacto a la hora de garantizar la solvencia del protocolo.

Por qué fue tan difícil detectar este error

Las plataformas de alto apalancamiento son, por naturaleza, frágiles. Pequeños errores de precisión o defectos internos tienen repercusiones enormes en las fases posteriores del proceso. En este caso, la combinación de los cálculos de apalancamiento, garantías y liquidación dio lugar a un caso límite oculto. Dado que el sistema no comprobaba el valor devuelto por la función getTradeLiquidationPrice(), se pasó por alto una simple comprobación de corrección.

Otras vulnerabilidades importantes detectadas

Aunque el error relacionado con la actualización de la palanca financiera fue el más grave, nuestra auditoría también reveló otros errores de gran repercusión:

Manipulación del poder de voto mediante el «re-staking»:

• Podían hacer staking, votar, retirar su staking y volver a hacer staking para votar por segunda vez, lo que, en esencia, duplicaba su poder de voto. Para solucionar esto, LeverageX tuvo que implementar un periodo de espera para las operaciones de retirada y nueva realización de staking, y determinar el poder de voto mediante un contrato JavFreezer específico.

Faltan transferencias de tokens en la lógica de devengo:

• La función depositVesting() contabilizaba los depósitos de tokens, pero no transfería los tokens, lo que provocaba una discrepancia entre el estado del protocolo y los saldos reales. Para resolver este problema, utiliza safeTransferFrom para enviar tokens y asigna una autorización suficiente.

Función de transferencia de garantías públicas:

• La función transferCollateralTo() podría invocarse de forma pública, lo que permitiría a cualquier parte retirar las garantías de los usuarios. La mejor solución sería cambiar la visibilidad a «interna» e implementar controles de acceso.

Falta la autorización mediante token en la actualización del proveedor de préstamos:

• En «updateBorrowingProvider», los tokens no se aprobaban a tiempo, lo que podía alterar los flujos de stop-loss o liquidación. Para solucionar esto, debemos asegurarnos de que las aprobaciones se actualicen de inmediato cuando cambie un proveedor.
  

Conclusión

Esta auditoría pone de relieve la enorme importancia que tiene el tratamiento de los casos extremos en la lógica de apalancamiento y liquidación. Un solo valor de retorno no comprobado puede bastar para que un protocolo, aunque parezca sólido, presente vulnerabilidades sistemáticas. LeverageX ha estado aplicando los parches sugeridos para corregir los problemas, añadiendo así otra capa más de seguridad y protección a un protocolo de negociación descentralizado. La seguridad no es algo que se haga una vez y luego se olvide; es un proceso continuo. En AuditOne, creemos en ayudar a los protocolos Web3 a desarrollarse de forma segura y sólida.

Asegúrate de que tu plataforma siga siendo segura y de que la confianza de tus usuarios no se vea afectada: elige AuditOne para reforzar tus contratos inteligentes y sentar unas bases de seguridad y fiabilidad.
‍‍

Reserva tu consulta gratuita sobre seguridad:

Google Calendar: https://calendar.app.google/Ai15eyQhiV5c1pBXA
Telegram: https://t.me/m_ndr

‍

‍