Invertir cientos de miles para contratar a un equipo subcontratado y desarrollar un proyecto Web3, y que el proyecto por fin salga en línea… pero que, debido a que el proveedor dejó “puertas traseras” técnicas, se robe el patrimonio de los usuarios y el proyecto colapse de inmediato. Este tipo de casos reales no son raros en la industria. Muchos equipos consideran que, al obtener el código fuente, el proyecto queda completamente entregado, pero pasan por alto los riesgos de permisos y de puertas traseras. Al final, el proyecto que costó tanto construir puede pasar a valer cero en una sola noche. En realidad, no necesitamos dominar ni entender código complejo: si nos enfocamos en cuatro puntos clave de revisión, podemos evitar la gran mayoría de riesgos técnicos dejados de forma intencional por personas.
Primero, verificar estrictamente los permisos de los contratos inteligentes: retirar permisos de administrador, de superusuario y los permisos de actualización del contrato. Muchos equipos de desarrollo, al escribir contratos, suelen dejar por defecto permisos de administrador. Un ejemplo real: tras lanzarse un proyecto RWA, el desarrollador mantenía los permisos de administrador del contrato y, directamente, llamó a funciones del panel de control para transferir los activos de participación (staking) de los usuarios dentro del contrato; el equipo del proyecto no tuvo ninguna capacidad de intervenir. Después de completar el despliegue del contrato, lo primero que debe hacer el proyecto es confirmar que los permisos de administrador, los permisos de superoperación y los permisos del proxy de actualización del contrato se transfieran o se eliminen por completo. No dejes que el máximo nivel de permisos del contrato permanezca en manos del equipo de desarrollo; elimina desde la raíz la posibilidad de que alteren reglas o transfieran activos mediante un acceso en segundo plano.
En segundo lugar, controlar de forma estricta todas las carteras del proyecto; la clave privada y los permisos de firma deben quedar totalmente bajo tu control. El proyecto normalmente involucra tres tipos de carteras clave: carteras de despliegue, carteras del fondo (pool) y carteras de multisig para la gestión. Muchos proyectos, para ahorrar trabajo, dejan que el equipo de desarrollo custodie directamente las claves privadas de la cartera. Hubo un proyecto de cadena de juegos (chain game) en el que la cartera del fondo la custodiaba el equipo de desarrollo; después de un periodo de operación del proyecto, los desarrolladores se llevaron directamente decenas de miles de USDT del pool. La parte del proyecto no tuvo forma de reclamar. No importa cuán confiable sea el otro: las claves privadas y los permisos de firma de la cartera de despliegue, de la cartera del fondo y de la cartera multisig, en ningún caso se deben entregar al equipo de desarrollo. Todas las operaciones de firma deben realizarlas por cuenta propia el propio proyecto; no delegues la gestión de los accesos a los activos al equipo de desarrollo.
En tercer lugar, elimina por completo los permisos del panel/servidor en la nube y deja que el nivel más alto de autoridad esté en tus manos. Muchos DApp y plataformas ejecutan el backend en servidores proporcionados por el equipo de desarrollo. Algunos equipos de subcontratación guardan en secreto las credenciales de inicio de sesión del servidor y las entradas de administración del sistema de base de datos. Incluso si el código fuente ya se entregó, mientras ellos conserven permisos sobre el servidor, aún pueden modificar páginas del frontend, manipular los datos del backend y robar información relacionada con los usuarios. Durante la fase de entrega del proyecto, es imprescindible cambiar los usuarios administradores de mayor privilegio de los servidores, el backend y la base de datos, y eliminar todas las cuentas de inicio de sesión del equipo de desarrollo, las claves SSH y los permisos de operación del backend. Al terminar, inicia sesión tú mismo para volver a verificar y confirma que no exista ninguna cuenta residual con puertas traseras.
En cuarto lugar, verificar el código en cadena y en línea, comparar con el código fuente entregado e introducir una auditoría de terceros para detectar posibles riesgos. Aquí es muy fácil caer en una trampa: el código fuente que el desarrollo te entrega y el código que realmente se ejecuta en la cadena pueden no ser el mismo conjunto. Algunos equipos entregan archivos de código fuente “limpios”, pero en el despliegue en cadena se esconden direcciones especiales maliciosas y funciones ocultas para transferir activos. No sirve de nada fijarse solo en el código fuente entregado; es imprescindible comprobar si el bytecode de los contratos ya desplegados en la cadena coincide con el resultado de compilar el código fuente. La mayoría de los proyectos no pueden realizar bien este trabajo; se recomienda encargarlo a una institución de auditoría de terceros para comparar el código y detectar puertas traseras ocultas y direcciones especiales de alto riesgo.
Aquí quiero recordar a todos los responsables de proyectos: la entrega del proyecto no termina con solo recibir el código fuente. El código fuente es solo uno de los entregables. Las cuatro cosas que deben completarse con verificación, y que deben estar bajo el control y custodia del propio proyecto, son: los permisos de los contratos inteligentes, las claves privadas de todo tipo de carteras, los permisos del backend en servidores, y la consistencia del código en cadena. Solo cuando estas cuatro se verifiquen al 100% y queden completamente bajo control del proyecto, se considera que la entrega completa se ha realizado de verdad.
En la industria hay muchas tragedias, y no se deben a vulnerabilidades en el contrato en sí, sino a accidentes provocados por retener permisos de forma intencional o indebida. Muchos proyectos, en su fase inicial, ponen el foco en implementar funcionalidades y pasan por alto las comprobaciones de seguridad al cerrar la entrega; recién cuando los activos son robados es cuando se lamentan.
Los proyectos Web3 tienen un riesgo extremadamente alto para sus activos: no apuestes a la “confianza” ni al buen criterio profesional del equipo de desarrollo. En el proceso, recupera todos los permisos, y asegúrate de que la verificación se ejecute correctamente; solo así podrás evitar que el equipo de desarrollo controle el proyecto posteriormente y mantener el límite inferior de seguridad para los activos del proyecto.