¿Qué es DYOR?

DYOR es la sigla de «do your own research», es decir, investigar por cuenta propia. En el contexto de los activos cripto significa no tomar de entrada la promoción, las publicaciones o las conclusiones de otras personas como hechos, sino buscar uno mismo los materiales originales, cruzar la evidencia, y separar lo que ya está confirmado de lo que sigue siendo desconocido.

DYOR no es una certificación uniforme, ni un método para hacer que un proyecto sea confiable o para evitar pérdidas. Se parece más a un proceso de revisión de información: primero establecer qué afirma concretamente una declaración, después juzgar qué materiales pueden respaldarla, si esos materiales todavía se aplican a la versión actual, y qué conclusiones son solo conjeturas. Un resultado de investigación tampoco es una simple etiqueta de «se puede comprar» o «no se puede comprar».

La investigación parte de una afirmación que se puede revisar

«Este proyecto es bueno», «la comunidad es fuerte» o «la tecnología está adelantada» son todas difíciles de verificar directamente. Una afirmación más concreta indica dónde buscar evidencia, por ejemplo:

• si una dirección determinada es el contrato de token que el proyecto usa actualmente;
• si el suministro total de tokens puede aumentar, y quién tiene el permiso de emitir más;
• si el contrato puede pausar, actualizar o congelar ciertas operaciones;
• de qué mercados y de qué período viene el volumen de negociación que muestra una página;
• qué versión del código examinó un informe de auditoría determinado;
• si una asociación, una integración o una función de producto fue confirmada por las partes involucradas;
• si una función que se anuncia como activa tiene un registro correspondiente en el código, la interfaz o la actividad en cadena.

Escribir primero la afirmación también evita mezclar preguntas distintas. Que el código fuente de un contrato se haya publicado no significa que el código esté libre de fallas; que la identidad de un equipo se haya publicado no significa que el producto pueda cumplir todos sus planes; y que haya gente negociando en cadena no significa que esas operaciones vengan de usuarios independientes o representen una demanda sostenida.

Afirmaciones distintas necesitan evidencia de distinto tipo

Ninguna fuente por sí sola puede responder todas las preguntas. La evidencia que se usa comúnmente al investigar se divide en varios tipos:

Una «fuente oficial» sirve para confirmar qué declara un proyecto sobre sí mismo, pero sigue siendo material que publica el proyecto. Las fuentes independientes pueden ofrecer otra perspectiva, y también pueden citar información equivocada o desactualizada. Una conclusión confiable normalmente viene de varias fuentes que corroboran la misma afirmación concreta, y no de ponerle a un sitio la etiqueta de «confiable» y después aceptar todo su contenido.

Revisa primero la red y la dirección del contrato, después el nombre y el icono

Los tokens en cadena pueden tener el mismo nombre, y pueden usar el mismo icono y el mismo código de cotización. Al identificar un activo digital, el nombre de la red y la dirección del contrato normalmente distinguen mejor que un nombre de visualización; para un token no fungible, puede que haya que revisar además el número de token.

El sitio o la documentación de un proyecto pueden aportar una dirección de contrato, y un explorador de bloques puede mostrar la transacción de despliegue de esa dirección, sus saldos, las transferencias de tokens y las llamadas al contrato. La presentación de los exploradores de bloques de Ethereum.org enumera datos en cadena comunes como bloques, transacciones, cuentas, contratos y tokens.

Una dirección todavía hay que cruzarla. Un sitio falsificado también puede mostrar un contrato que existe de verdad, y los resultados de búsqueda o las publicaciones en redes sociales pueden apuntar a un token falso del mismo nombre. Qué significa concretamente una marca de «verificado» en una página depende de las reglas de verificación de ese servicio; no se puede concluir solo por un icono o una etiqueta.

Un registro en cadena puede probar qué pasó, pero no explica automáticamente por qué

Una blockchain puede registrar cuándo una dirección determinada inició una transacción, cómo se movieron los activos, y cómo cambió el estado de un contrato. Ese tipo de registro sirve para revisar cambios de suministro, la dirección de los fondos, votaciones de gobernanza y si una función determinada fue llamada.

Un registro en cadena normalmente no le dice directamente a quien lee la identidad real detrás de una dirección, y no puede explicar por sí solo el propósito de una transacción. Una persona puede controlar varias direcciones, y varias personas pueden operar a través de la dirección de una misma plataforma de custodia. Una cantidad de direcciones no se puede equiparar directamente a una cantidad de usuarios, y un conteo de transferencias de tokens no se puede equiparar directamente a un grado de adopción real.

Los datos en cadena además pueden pasar por indexación, etiquetado y cálculo antes de mostrarse. Los campos de transacción que se pueden revisar de forma independiente en cadena pertenecen al registro del protocolo, mientras que las etiquetas de direcciones, las clasificaciones de tenedores y los gráficos estadísticos que aporta un servicio contienen un juicio adicional. Al usar ese tipo de resultados hay que mirar la base de cálculo, las redes cubiertas y la fecha de actualización.

Un código fuente verificado solo indica que el código coincide con la versión desplegada

Un contrato inteligente es un programa desplegado en una blockchain que ejecuta operaciones según su código. En las redes que usan la Máquina Virtual de Ethereum (Ethereum Virtual Machine, EVM), como Ethereum, la verificación del código fuente normalmente recompila el código publicado con los mismos ajustes y después lo compara con el código de máquina que realmente corre en la dirección del contrato. El código de máquina es el resultado compilado que la red ejecuta directamente. La nota de Ethereum.org sobre verificación de contratos separa ese tipo de revisión de coincidencia de la verificación formal; la verificación formal usa métodos matemáticos para revisar si un programa cumple propiedades especificadas de antemano. Otras redes exigen revisar el código del programa según sus propios mecanismos de despliegue y de versiones.

Por eso, «el código del contrato está verificado» normalmente indica que el código que ve quien lee corresponde al programa en cadena; no indica que el código haya pasado una auditoría de seguridad, ni que el programa no tenga fallas de lógica. Los comentarios y los nombres de variables en un código publicado también pueden ser engañosos; el comportamiento real depende de la lógica ejecutable.

Además hay que establecer si un contrato de entrada reenvía las solicitudes a otro código de implementación. Esa entrada suele llamarse contrato proxy. Un proxy actualizable permite que una cuenta con el permiso correspondiente reemplace el código de implementación; la documentación de contratos proxy de OpenZeppelin explica cómo el proxy, el contrato de implementación y el administrador de actualizaciones funcionan en conjunto. Leer solo el código corto de la dirección del proxy puede dejar pasar tanto el contrato que de verdad ejecuta las funciones como los permisos de actualización.

Un repositorio de código muestra un historial de desarrollo, que no equivale a las funciones en producción

Un repositorio de código público puede mostrar archivos, registros de commits, etiquetas de versión, discusiones de problemas y quienes contribuyen. Un commit es un cambio de código registrado, y una etiqueta de versión suele usarse para marcar una publicación determinada. Pueden ayudar a revisar si un proyecto sigue modificando su código, cuándo se agregó una función determinada, y qué cambió entre versiones.

La nota de GitHub sobre la actividad de un repositorio muestra registros como envíos, fusiones, envíos forzados y cambios de ramas. Mucha actividad no significa alta calidad de código, y pocos commits no indican necesariamente que un proyecto se haya detenido; las actualizaciones automáticas, el código copiado y el desarrollo que no ocurre en un repositorio público influyen todos en las cifras de superficie.

El código del repositorio también tiene que corresponder a la versión realmente desplegada. Al investigar una aplicación en cadena, conviene mirar si las etiquetas de publicación, los registros de despliegue o la información de verificación del contrato conectan una versión del repositorio con una dirección en cadena; si no, solo se puede confirmar que «ese código existe en el repositorio», no que esté corriendo en producción.

Un informe de auditoría se lee por alcance, versión, fecha y tratamiento de los hallazgos

Una auditoría de seguridad es que profesionales examinen código, un diseño o supuestos de funcionamiento dentro de cierto alcance y período, y registren los problemas que encuentran. Al leer un informe, lo que importa no es solo que «se hizo una auditoría», sino también:

• si los archivos, direcciones de contrato o commits de código examinados están claramente indicados;
• si el código cambió de forma importante después de terminada la auditoría;
• qué componentes, dependencias externas y condiciones de funcionamiento quedan fuera del alcance de la revisión;
• qué problemas encontró el informe, y cómo respondió el proyecto;
• si las correcciones se volvieron a revisar, y si quedan problemas sin corregir;
• si el informe lo publicó la parte que audita, y si un enlace apunta al archivo completo.

Una auditoría no puede probar que no exista una falla desconocida. La documentación de preparación para la red principal de OpenZeppelin también explica que una auditoría no puede garantizar que un código esté libre de errores. Tomar una versión antigua, un módulo parcial o un informe cuyos hallazgos no se volvieron a revisar como prueba de seguridad de todo el sistema excede lo que el informe mismo puede respaldar.

Un whitepaper expone un plan, que no es un registro de cumplimiento

Un whitepaper normalmente presenta el problema que un proyecto quiere resolver, su enfoque de diseño, los arreglos sobre los tokens o su plan de desarrollo. Sirve para confirmar qué objetivos ha planteado públicamente un proyecto, pero no puede probar por sí solo que esos objetivos se hayan alcanzado.

Al investigar se pueden revisar por separado las afirmaciones verificables de un whitepaper frente a la documentación actual, las publicaciones de código, el despliegue en cadena y las funciones reales. Una fecha de hoja de ruta ya pasada sin registro de publicación correspondiente, reglas de tokens que no coinciden con el contrato desplegado, o documentación sin actualizar por mucho tiempo son todas diferencias que hay que seguir confirmando; por sí mismas no prueban necesariamente que un proyecto sea engañoso.

La documentación además puede describir una versión antigua. La fecha de publicación de una página, su última modificación, la red aplicable y el número de versión determinan si un pasaje se puede usar para el sistema actual. Cuando no hay fecha ni información de versión, marca la conclusión como incierta en vez de completar por tu cuenta el contexto que falta.

La atención en redes sociales no es prueba de un hecho

Los «me gusta», las veces que se comparte, la cantidad de integrantes de un grupo y el interés en las búsquedas describen cómo se difunde un contenido; no pueden probar directamente funciones técnicas, identidad de usuarios, seguridad de los fondos o demanda del mercado. Una cuenta puede estar falsificada o tomada, y las interacciones pueden venir de programas automáticos o de promoción coordinada.

Las redes sociales sirven mejor para encontrar afirmaciones que hay que revisar que como única evidencia de una afirmación. Cuando está en juego una dirección de contrato, una actualización de versión, un incidente de seguridad o una relación externa, se puede volver a la documentación del proyecto, al repositorio de código, a los registros en cadena y a las declaraciones originales de las partes involucradas para confirmar.

Que una fuente revele sus intereses también importa. Quien escribe un contenido puede tener el token en cuestión, recibir un pago, participar en el proyecto o beneficiarse mediante un enlace de recomendación. La falta de revelación no prueba por sí sola que el contenido esté equivocado, pero quien lee no puede juzgar con eso un posible conflicto de intereses, así que el peso de esa evidencia debe quedar aparte de los materiales que se pueden revisar de forma independiente.

Un proceso de revisión completo conserva las preguntas sin resolver

El resultado de un DYOR no debería ser solo una serie de enlaces; también debería indicar a qué respondió cada pieza de evidencia. Un proceso general de revisión de información se puede registrar así:

1. reescribir una valoración vaga como una afirmación concreta y verificable;
2. encontrar el material original más cercano a esa afirmación, y registrar quién lo publicó, la fecha y la versión;
3. cruzar con registros en cadena, código, un informe completo u otra fuente independiente;
4. distinguir los hechos observados directamente, las inferencias hechas a partir de esos hechos y la opinión personal;
5. escribir los conflictos entre fuentes, y qué evidencia sigue faltando;
6. cuando un contrato, un permiso, una versión o una relación externa no se puede confirmar, dejarlo como «incierto»; no tomar un vacío por una conclusión afirmativa ni negativa.

Una misma conclusión de investigación deja de valer con el tiempo. Los contratos se pueden actualizar, los permisos de administración se pueden transferir, la documentación y el alcance de una auditoría pueden cambiar, y la liquidez y la distribución de tokens también se mueven. Al citar información cambiante, conserva el momento al que corresponde el dato; no escribas una sola revisión como una conclusión permanente.

Una señal de alerta común pide seguir revisando, no condenar de inmediato

Las siguientes situaciones indican que el material disponible es insuficiente o está en conflicto, y exigen más revisión:

• una dirección de contrato aparece solo en publicaciones o mensajes privados cuyo origen no se puede confirmar;
• el nombre, el icono y el código de cotización son iguales, pero la red o la dirección del contrato son distintas;
• una página declara que el código es de código abierto, pero no hay repositorio ni registro de verificación que corresponda a la versión desplegada;
• se declara una auditoría, pero no se aporta informe completo, versión examinada ni estado de las correcciones;
• la descripción de suministro o de permisos del whitepaper no coincide con el comportamiento actual del contrato;
• se usa lenguaje como «rendimiento garantizado» o «sin riesgo», o se fabrica una sensación de urgencia;
• se declara respaldo de instituciones externas, pero la parte en cuestión no publicó ninguna declaración revisable correspondiente;
• un administrador puede actualizar, pausar o mover activos, pero la descripción pública no menciona esos permisos;
• una captura de datos no tiene fuente, período ni enlace que se pueda volver a revisar;
• una discusión solo cita artículos que se replican entre sí, y al final no se encuentra material original.

Una señal de alerta aislada no puede probar automáticamente que un proyecto sea fraudulento. Por ejemplo, que un equipo de desarrollo no publique todas las identidades, que las actualizaciones de código sean poco frecuentes, o que un contrato tenga permisos de administrador, pueden tener cada uno razones distintas. Una conclusión tiene que corresponder a compromisos concretos, a la estructura técnica y a registros revisables.

DYOR tiene límites, y no debe usarse para echarle la culpa a quien resultó perjudicado

Quien lee de forma común no puede auditar por su cuenta todo el código, verificar cada dato de un equipo ni detectar un ataque profesional. La información puede estar oculta a propósito, las interfaces y las cuentas pueden estar falsificadas, y las auditorías y los datos públicos también pueden tener puntos ciegos. Investigar por cuenta propia solo puede reducir parte del faltante de información; no puede convertir todo riesgo desconocido en conocido.

«Deberías haber investigado por tu cuenta» tampoco puede sustituir que el proyecto revele con exactitud la información importante, ni excusar una declaración falsa. Cuando alguien sufre una pérdida por materiales engañosos, por falsificación o por una falla técnica, reprocharle sin más que «no hizo DYOR» pasa por alto la asimetría de información y el nivel de especialización que se requiere.

Cuando una pregunta exige un juicio técnico, de seguridad, tributario o legal especializado, una revisión común de información no puede cubrir el mismo rango de evidencia ni la misma responsabilidad.

Preguntas frecuentes

¿Haber leído el whitepaper cuenta como haber hecho DYOR?

No. Un whitepaper explica principalmente los objetivos y el diseño de un proyecto. Todavía hay que revisar si el código actual, el despliegue, los permisos, la actividad en cadena, el alcance de la auditoría y la versión de la documentación coinciden con esas afirmaciones.

¿Que el código del contrato esté verificado quiere decir que es seguro?

No. La verificación del código fuente confirma principalmente que el código publicado coincide con el código de máquina desplegado. No encuentra automáticamente todas las fallas de lógica, y no elimina los permisos de actualización, las dependencias externas ni el riesgo operativo.

Los datos en cadena no se pueden falsificar, ¿entonces una conclusión sacada de ellos es confiable con seguridad?

Los registros de transacciones en cadena se pueden verificar, pero las etiquetas de direcciones, la atribución de identidad, la cantidad de usuarios y los motivos de una transacción normalmente necesitan explicación adicional. Una base de cálculo equivocada, o tomar varias direcciones por varios usuarios, producirá igualmente una conclusión errónea.

¿Un equipo anónimo es necesariamente poco confiable?

No se puede concluir solo por el anonimato. Una identidad publicada puede agregar información revisable, pero no puede probar nada sobre el código, la seguridad o los compromisos; el anonimato reduce el material verificable sobre identidad y trayectoria, y ese faltante de información conviene registrarlo de forma explícita.

¿DYOR me puede decir qué activo debería comprar?

No. DYOR es un proceso para revisar información, fuentes e incógnitas. No produce automáticamente una conclusión de compra, venta o tenencia adecuada para una persona determinada, y no puede predecir precios futuros.

Conceptos relacionados

Continúa con activo digital, contrato inteligente, token cripto y clave privada, o vuelve al glosario de criptomonedas.

Fuentes

• Ethereum.org: Block explorers — los datos de bloques, transacciones, cuentas, contratos y tokens que un explorador de bloques puede mostrar.
• Ethereum.org: Verifying smart contracts — la diferencia entre coincidencia del código fuente, código de máquina y verificación formal.
• OpenZeppelin Docs: Upgrades Plugins FAQ — la relación entre proxy, contrato de implementación y administrador de actualizaciones.
• OpenZeppelin Docs: Preparing for mainnet — auditorías, verificación del código fuente, permisos de administración y límites de una auditoría.
• GitHub Docs: Using the activity view — registros de cambios, envíos, fusiones y actividad de ramas de un repositorio.