Cómo revisar un contrato inteligente antes de interactuar

No necesitas saber leer código para evitar la mayoría de los desastres con contratos. La mayoría de las pérdidas provienen de un pequeño número de condiciones verificables.

1. ¿El contrato está verificado?

Un contrato verificado tiene su código fuente publicado, y un explorador de bloques ha confirmado que compila exactamente al bytecode desplegado. No verificado significa que nadie fuera del creador sabe qué hace.

Trata un contrato no verificado como hostil. No hay ninguna razón legítima para que un proyecto que te pide dinero oculte su código fuente. Esta sola comprobación elimina muchísimo.

2. ¿Qué puede hacer el propietario?

Incluso en código verificado, alguien sin conocimientos de programación puede buscar las funciones que importan. Busca:

• mint — ¿puede el propietario crear nuevos tokens de forma ilimitada? Eso te diluye hasta la nada, a su antojo.
• pause / blacklist — ¿pueden impedirte vender, o bloquear tu dirección específica? Los tokens honeypot funcionan exactamente así: puedes comprar, pero después no puedes vender.
• setFee / setTax — ¿se puede cambiar la comisión de transferencia después de que compres? Una comisión elevada al 99% es una trampa.
• onlyOwner — ¿cuántas funciones están restringidas a una sola dirección, y esa dirección es una clave única o una multisig?

Muchos exploradores ahora muestran esto automáticamente. Si el propietario puede acuñar, pausar o gravar a voluntad, las reglas del token son lo que decida mañana.

3. Entiende lo que estás aprobando

Aquí es donde ocurre la mayoría de los vaciados de billeteras. Para permitir que un contrato mueva tus tokens, otorgas una allowance (autorización). Dos cosas sorprenden a la gente:

• Las allowances suelen ser ilimitadas. Muchas interfaces aprueban por defecto la cantidad máxima posible, de modo que el contrato puede mover todos los tokens de ese tipo que tengas, ahora y los que adquieras después.
• Persisten indefinidamente. La aprobación permanece después de que termines, hasta que la revoques. Un protocolo comprometido un año más tarde todavía puede actuar sobre una allowance que otorgaste hoy.

Lee la pantalla de aprobación. Tu billetera muestra qué contrato y qué cantidad. Si dice ilimitado y estás haciendo un swap puntual, establece en su lugar una cantidad específica.

4. Reconoce una solicitud de firma maliciosa

No toda firma es una transacción. Algunas solicitudes te piden firmar un mensaje que otorga permisos fuera de la cadena (off-chain); una técnica muy utilizada en sitios falsos de mint y airdrop.

Señales de alerta: una solicitud de firma que tú no iniciaste; una solicitud que aparece justo después de hacer clic en un enlace desde un mensaje directo o un anuncio; una solicitud cuyo contenido tu billetera no puede decodificar en algo legible; o cualquier aviso en un sitio al que llegaste desde una fuente no solicitada. Ante la duda, recházala. Una acción legítima siempre se puede repetir.

5. Revoca aprobaciones antiguas

Conviértelo en un hábito. Usa una herramienta de revocación de buena reputación —a la que llegues escribiendo la dirección directamente, ya que existen sitios falsos de revocación y son exactamente el tipo de trampa que atrapa a usuarios conscientes de la seguridad— y elimina las allowances que ya no necesites, especialmente las ilimitadas y las de protocolos que ya no uses.

6. Trata la palabra «auditado» con cautela

Una auditoría es una revisión puntual hecha por personas falibles, a menudo de una versión que después cambió. Muchos protocolos auditados han sido explotados igualmente.

Preguntas útiles: ¿quién la realizó?, ¿es público el informe?, ¿qué problemas de qué gravedad se encontraron?, ¿se corrigieron?, ¿se ha modificado el contrato desde entonces? «Auditado por» sin un informe enlazado es marketing.

7. Prefiere contratos puestos a prueba por el tiempo

La señal más fuerte disponible es la supervivencia. Un protocolo que ha custodiado un valor significativo durante años sin sufrir un ataque ha estado bajo ataque continuo de adversarios bien financiados, y ha resistido. Es una prueba más exigente que cualquier auditoría.

Los contratos nuevos no están probados por definición, sin importar cuán bien se vea el código.

Una lista de verificación previa

• Contrato verificado en un explorador de bloques
• Sin funciones ilimitadas de mint, pause, blacklist o comisión mutable, o propiedad renunciada
• Alcance de la aprobación entendido, y limitado cuando sea posible
• Solicitud de firma iniciada por mí, en un sitio al que navegué directamente
• El protocolo tiene un historial operativo significativo y valor en juego
• Estoy usando una billetera que solo contiene lo que puedo permitirme perder

Qué leer a continuación

Has terminado el itinerario de Ganancias y DeFi, y los cuatro itinerarios completos. El glosario cubre cualquier término que quieras repasar, y el centro de aprendizaje muestra tu progreso.