How to Assess Web3 Project Risks: A Practical User Checklist

In Web3, users often hold their own keys and sign transactions directly. A useful review therefore starts not with “How much can I earn?” but with: What am I signing, which code will gain access to my assets, and who can change the rules?

Ninguna lista de comprobación puede demostrar que un proyecto es seguro. Su propósito es revelar incógnitas, comparar afirmaciones con pruebas verificables y limitar posibles daños.

Este artículo tiene únicamente fines educativos y no constituye asesoramiento financiero, de inversión ni jurídico. Las transacciones Web3 pueden ocasionar la pérdida total de los activos transferidos.

1. Verificar la fuente

• Utilice un marcador guardado o una URL procedente de un canal oficial confirmado.
• Compruebe cada carácter del dominio.
• Evite conectar una billetera desde anuncios, mensajes no solicitados o resultados de búsqueda aleatorios.
• Compare las direcciones de los contratos entre los materiales oficiales del proyecto.
• Nunca revele una frase semilla ni una clave privada.

Stop signal: a site asks you to “synchronize,” “validate,” or “restore” a wallet by entering secret words.

2. Confirmar la red y el activo

Antes de transferir nada, anote:

• red;
• dirección del contrato del token;
• dirección del destinatario o del contrato llamado;
• importe;
• activo utilizado para pagar la comisión;
• acción prevista.

A name such as USDT does not uniquely identify a token. Verify the full token contract address. The same 0x… address format can be used on different EVM networks, but assets and state remain network-specific.

Stop signal: the project gives a ticker but does not publish the network and token address.

3. Inspeccionar el código desplegado

En un explorador de bloques:

• localizar el contrato mediante la dirección oficial;
• comprobar la verificación del código fuente;
• determinar si es un proxy;
• abrir la implementación actual;
• comparar todas las direcciones con la documentación del proyecto.

On BscScan, Exact Match means published source and constructor parameters were matched to deployed bytecode. This improves transparency but is not a security assessment.

Stop signal: no address is published, source is unverified, and the project still claims “full transparency” without explanation.

4. Comprender las facultades administrativas

Busque roles y funciones como:

• propietario, administrador, operador y actualizador;
• pausar y reanudar;
• cambios de comisiones o límites;
• cambios en las direcciones vinculadas;
• acuñación de tokens;
• retiro de activos;
• actualizaciones de la implementación;
• el bloqueo de direcciones.

Pregunte quién controla estas claves, si se utiliza una multifirma, si los cambios tienen un bloqueo temporal y cómo se informa a los usuarios. El control centralizado no es automáticamente fraudulento, pero crea una dependencia de controladores concretos.

Stop signal: one address holds critical powers while the project claims that nobody can change anything.

5. Interpretar correctamente la auditoría

Compruebe si:

• el informe está publicado por el auditor;
• se indican el repositorio y el hash del commit;
• el contrato activo está incluido en el alcance;
• el informe abarca la implementación actual;
• quedan hallazgos sin resolver;
• las correcciones volvieron a probarse;
• se excluyeron componentes importantes.

Una auditoría es una revisión independiente adicional. No puede detectar todos los defectos ni abarca automáticamente el sitio web, la gestión de claves, el modelo de negocio o las futuras actualizaciones.

Stop signal: there is an “Audited” badge but no report or reviewed code version.

6. Comparar las solicitudes con el comportamiento en cadena

Inspeccione varias transacciones para comprobar:

• estado;
• Desde y To / Interacted With;
• movimientos BEP-20;
• llamadas internas;
• registros;
• comisiones;
• cambios en los saldos y en el estado del contrato.

Compare the actual path of funds with the published architecture. Do not draw a system-wide conclusion from one demonstration transaction. Éxito means the code executed without reverting; it does not mean the operation was safe or beneficial.

Stop signal: observable fund flows differ from the stated process and no clear explanation is provided.

7. Separar los activos de las obligaciones

El saldo visible de una dirección es solo un dato. Pregúntese:

• si se han publicado todas las direcciones pertinentes;
• quién controla los activos;
• si pueden retirarse;
• qué obligaciones existen frente a otros usuarios;
• cómo se determina un precio externo;
• si el acceso depende de un puente, un DEX, un oráculo o una contraparte.

Un saldo elevado de tokens no demuestra que exista liquidez. Una gran cantidad de unidades puede tener poco valor realizable.

Stop signal: one address balance is presented as proof of solvency without disclosing obligations or control rights.

8. Explicar el modelo económico en lenguaje sencillo

Busque respuestas claras a estas preguntas:

• de dónde procede cualquier pago;
• quién paga las comisiones;
• qué ocurre si no llegan nuevos usuarios;
• condiciones de salida y bloqueos;
• dónde pueden producirse pérdidas;
• qué parámetros pueden modificar los administradores;
• qué determina el precio del token.

Si el resultado depende de los mercados, nuevos participantes, la liquidez o decisiones del equipo, esas dependencias deben indicarse expresamente.

Stop signal: a fixed outcome is promised without a verifiable source of funds or loss scenario.

9. Controlar las firmas y las autorizaciones de tokens

Antes de confirmar, verifique lo que muestra la billetera:

• red;
• dirección llamada;
• función o acción legible;
• valor del token nativo;
• token e importe de la autorización;
• cambios esperados en los activos.

An approve call does not immediately transfer a token. It may authorize a spender contract to call transferFrom up to an allowance. An unlimited allowance increases potential loss if the spender is compromised or flawed.

Rechace una firma si los datos no están claros o la dirección difiere de la que comprobó. Después de utilizarla, revise y revoque mediante una herramienta de confianza los permisos que ya no sean necesarios.

Stop signal: you are pressured to sign unreadable data or told that a signature “does nothing.”

10. Incluir los riesgos fuera de la cadena

Incluso un código bien revisado no puede evitar todos los casos de:

• vulneración del sitio web o del DNS;
• extensión de navegador maliciosa;
• robo de claves;
• cuenta del proyecto comprometida;
• fallo del backend;
• ataque de ingeniería social;
• restricción jurídica;
• fallo del servicio de asistencia o de las operaciones.

Revise la documentación, los procedimientos de incidentes, los canales de notificación y el historial de cambios. Evalúe las afirmaciones jurídicas a partir de documentos reales y conforme a su propia jurisdicción.

11. Limitar los posibles daños

Incluso después de completar la revisión:

• empiece con el menor importe de prueba que resulte práctico;
• utilice una billetera distinta para las dApps desconocidas;
• no mantenga todos los activos en la billetera conectada;
• nunca firme bajo presión de tiempo;
• guardar los hashes y las direcciones de las transacciones;
• revisar periódicamente las autorizaciones de tokens;
• establecer una exposición máxima cuya pérdida total resulte asumible.

La guía oficial de seguridad de Solidity recomienda limitar la cantidad de activos mantenidos en un contrato: si existe un error en el código, el compilador o la plataforma, limitar la exposición puede limitar la pérdida.

Lista de comprobación antes de una transacción

Answer yes, no, or unknown:

• Verifiqué el dominio.
• Conozco la red exacta.
• Comprobé la dirección del contrato del token.
• Comprobé la dirección del contrato llamado.
• Conozco el estado de verificación del código fuente.
• Comprobé el proxy y la implementación.
• Comprendo las facultades de los administradores.
• La auditoría coincide con la versión activa.
• Inspeccioné transacciones reales.
• Comprendo el origen de los pagos y los escenarios de pérdida.
• Comprendo la solicitud de firma.
• La autorización está limitada de forma razonable.
• Tuve en cuenta los riesgos del frontend, de las claves y jurídicos.
• El importe de prueba no puede causar un perjuicio grave.

For a critical question, unknown is not a neutral answer—it is an unassessed risk. Pausing for verification is usually cheaper than an irreversible transaction.

Preguntas que debe formular un usuario prudente

Is a project safe if its code is open and audited?
No. Those are useful signals, but unknown bugs and administrative, operational, economic, and external risks remain.

If assets are visible on-chain, can they definitely be returned?
No. Return depends on code, current state, control rights, and external dependencies.

Does a small successful test prove a larger transaction will work?
No. It tests one path at one moment. Limits, liquidity, state, and implementation may later differ.

What if I do not understand the signature?
Reject it. Identify the function, called address, asset changes, and permissions before trying again.

Fuentes y lecturas adicionales

1. Solidity Documentation — Consideraciones de seguridad
2. Ethereum.org — Seguridad de contratos inteligentes
3. Ethereum.org — Pruebas de contratos inteligentes
4. BscScan Information Center — Consulta de transacciones
5. BscScan Information Center — Tipos de verificación de contratos
6. BscScan Information Center — ¿Qué es una dirección?
7. OpenZeppelin Docs — Patrón de actualización mediante proxy