> For the complete documentation index, see [llms.txt](https://novacont.gitbook.io/nova-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://novacont.gitbook.io/nova-docs/novacont-docs/espanol/auditoria-y-seguridad/revision-de-seguridad-de-novacont-lite.md).

# Revisión de seguridad de NovaCont Lite

**Alcance**

* NovaCont\_Lite.tact

**Metodología**

* Revisión manual de código, realizada en dos rondas: la primera ronda examinó la arquitectura y la lógica de transición de estados, y los hallazgos fueron abordados por el desarrollador; la segunda ronda verificó las correcciones a nivel de código fuente.
* Análisis estático: Misti

| Severidad       | Cantidad | Categoría                                                                                                                                                                                                           |
| --------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Critical / High | 0        | Ninguna                                                                                                                                                                                                             |
| Medium          | 9        | SuboptimalSend: sugiere usar el más eficiente en gas message() en lugar de send(), sin riesgo funcional                                                                                                             |
| Low             | 29       | PreferredStdlibApi (require -> throwUnless), PreferSenderFunction (context().sender -> sender()), EtaLikeSimplifications, UnusedMethodArgument. Todo optimización de gas o estilo, sin diferencia de comportamiento |

El análisis estático con Misti no encontró vulnerabilidades funcionales de seguridad en la base de código. Todo lo marcado está a nivel de optimización de gas o preferencia de API.

**Revisión manual**

Hallazgos identificados en la primera ronda de revisión, abordados por el desarrollador y verificados a nivel de código fuente:

**Bug de orden de mutación de estado en CancelEscrow \[Corregido]**

En la versión inicial, la variable local "escrow\.state" se actualizaba a "STATE\_CANCELLED" *antes* de que se evaluara la verificación "escrow\.state == STATE\_CREATED"; por lo tanto, esta verificación siempre se evaluaba como "false", ya que la variable ya había sido mutada. Solo la condición "acceptTime == 0" estaba realmente en efecto, y esta condición resultó ser un proxy seguro para el estado "STATE\_CREATED", por lo que el bug no tuvo impacto práctico, pero la condición muerta era un riesgo latente que podría convertirse silenciosamente en un bug real en una refactorización futura. El estado original ahora se captura previamente en una variable "wasNotYetAccepted: Bool", y este valor precapturado se usa después de la mutación de estado.

**Riesgo de pérdida silenciosa de fondos vía SendIgnoreErrors \[Corregido]**

Todas las llamadas "send()" han sido cambiadas de "SendIgnoreErrors" (que traga silenciosamente una transferencia fallida) a "SendBounceIfActionFail". Una transferencia fallida ahora rebota la transacción, manteniendo la actualización de estado consistente con el éxito de la transferencia. Verificado en cada llamada "send()" en la base de código.

**Centralización de la lógica de distribución de fondos \[Corregido]**

En la versión inicial, la rama de cancelación con penalización de "CancelEscrow" tenía su propia lógica de división de fondos, independiente de "distributeFunds". Esta duplicación conllevaba el riesgo de que una corrección aplicada a un camino no se reflejara en el otro (y de hecho, el bug anterior permaneció confinado a esta única rama). "CancelEscrow" ahora se enruta a través de una única función central vía "distributeFunds(escrowId, escrow, 5000 or 10000)". Esto elimina la duplicación de código y garantiza que el cálculo de STORAGE\_RESERVE sea consistente en todos los escenarios de distribución de fondos.

**Punto único de fallo en la resolución de disputas \[Corregido]**

En la versión inicial, las disputas se resolvían mediante la dependencia de una única cuenta personal. Ahora existe un grupo de soporte gestionado mediante "AddSupport"/"RemoveSupport", con distribución round-robin a través de "nextSupportAssign". Cuando se presenta una disputa ("RaiseDispute"), se asigna a un miembro de soporte en secuencia. El patrón de intercambio con el último elemento en "RemoveSupport" preserva correctamente la sincronización de index/count/nextAssign.

> Nota: Esto no es una corrección de bug sino una mejora de resiliencia arquitectónica. Reduce el riesgo de centralización pero no lo elimina.

**Riesgo de colisión de EscrowId \[Corregido]**

En la versión inicial, el cliente podía elegir su propio ID de escrow, creando un riesgo de colisión si dos clientes diferentes elegían el mismo ID. "escrowId" ahora se asigna automática y secuencialmente mediante "self.escrowCount".

| Hallazgo                                                              | Estado                                                                                                                                              |
| --------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
| Pérdida por redondeo en división entera                               | Nivel de polvo, sin impacto medible                                                                                                                 |
| Sin verificación de longitud máxima en campos description/evidenceUrl | Baja prioridad, relevante para la previsibilidad del gas                                                                                            |
| Consistencia en nomenclatura de eventos (EscrowCreated vs. otros)     | Cosmético, sin riesgo funcional                                                                                                                     |
| Sin límite inferior mínimo definido para agreedTon                    | Las verificaciones condicionales > STORAGE\_RESERVE en distributeFunds ya previenen implícitamente el riesgo de una transferencia negativa/inválida |

**Conclusión**

Los seis hallazgos de la revisión inicial (incluyendo un hallazgo de severidad High y uno Medium) han sido verificados como corregidos en v1.1.0. El análisis estático de Misti no encontró vulnerabilidades funcionales de seguridad en la base de código. Tras esta ronda de verificación, NovaCont Lite ha alcanzado un nivel de madurez comparable a los contratos principales de NovaCont. Se sigue recomendando una auditoría independiente de terceros, pero la rigurosidad y velocidad del proceso de revisión interna son una señal positiva.
