Derecho cripto/Nivel VI · Conducta de mercado/6.3 El lanzamiento honesto/Lección 3

Transparencia en la cadena: mostrar a las personas dónde buscar

Por qué los datos de la blockchain pública solo se convierten en divulgación cuando el lanzamiento indica a las personas qué direcciones, contratos y código deben verificar, y qué puede y no puede demostrar esos datos.

Esto es educación, no asesoramiento legal, fiscal ni de inversión. El derecho cripto varía entre países y estados, y cambia con frecuencia. Antes de actuar, verifica las normas vigentes donde vives con un abogado o asesor fiscal calificado.

La vía ligera

La ruta más barata, con menos impuestos, más sencilla y más privada que permite la ley, de mejor a peor. Cada paso indica la norma en que se apoya y la condición que la mantiene dentro de la ley.

Gratis y lo más eficaz: publica el contrato del token o la dirección de acuñación (mint) en un único lugar oficial estable y repítela de forma idéntica en todas partes, ya que EIP-20 hace que los nombres sean opcionales y las copias son fáciles. Ojo: explica públicamente cualquier cambio de dirección.
Verifica el código fuente gratis en Etherscan, o con solana-verify para programas de Solana. Ojo: la verificación solo demuestra que el código publicado es el código desplegado, no que sea seguro, y el código actualizable puede ser reemplazado más adelante.
Publica un mapa que etiquete el pool (pool), los bloqueos (locks), los contratos de vesting, la tesorería y las billeteras del equipo por su función en lugar de por nombre personal, lo cual es una privacidad legítima frente al público. Ojo: las billeteras publicadas son permanentes, las transferencias vinculadas son rastreables y la declaración ante el fisco continúa.
Demuestra cada afirmación con un hash de transacción, ya sea para un bloqueo (lock), una autoridad revocada o un despliegue de vesting; la interpretación de 2026 de la SEC alienta a divulgar el trabajo prometido cuando se completa, y compartir un hash no cuesta nada. Ojo: mantén el mapa actualizado a medida que cambien las direcciones.

MaterialesUn explorador de bloques para la cadena del token, abierto en el contrato del token o en el mintLa lista de direcciones oficiales del proyecto, si publica alguna.El estándar de tokens EIP-20 y la documentación de builds verificados de SolanaLección 6.3.1, sobre lo que requiere una divulgación honesta

Curiosidad

Si de todos modos todo está en la cadena, ¿por qué un lanzamiento necesita publicar algo?
¿Cómo puede un comprador distinguir el token real de una copia con el mismo nombre?
¿Un código fuente verificado significa que el contrato es seguro?

Explorar

Cada transferencia en una blockchain pública es visible, pero la visibilidad bruta no equivale a divulgación de información. Un comprador que se enfrenta a miles de direcciones no puede determinar cuáles pertenecen al equipo, cuáles son los pools, cuáles son los contratos de bloqueo y cuáles son las casas de cambio. La transparencia comienza cuando el creador publica el mapa: el contrato del token o la dirección de emisión, las direcciones de los pools, los contratos de bloqueo, las billeteras del equipo y del tesoro, los contratos de asignación gradual y cualquier dirección de programa o proxy. La regulación propuesta por la SEC sobre activos criptográficos exigiría a los emisores que utilicen sus exenciones que describan “métodos para verificar” el historial de transacciones del token (regla propuesta 103(b)(7)), una propuesta que considera precisamente este mapa como parte de la divulgación de información.
La dirección, y no el nombre, es la identidad del token. El estándar ERC-20 (EIP-20, creado en noviembre de 2015) hace que name(), symbol() y decimals() sean opcionales, y nada impide que alguien implemente un segundo token con el mismo nombre y símbolo. Los tokens imitadores y las cuentas “oficiales” falsas explotan esto (lección 4.2.4). Publicar la dirección del contrato en un lugar oficial estable y repetirla de la misma manera en todas partes es la protección más sencilla que puede ofrecerse al lanzar un token. Un comprador que verifica la dirección en lugar del símbolo evita la trampa más común; un creador que cambia las direcciones sin explicación enseña a los compradores a dejar de verificarlas.
El código también puede hacerse verificable. La documentación de Etherscan explica que al verificar un contrato se publica su código fuente en el explorador, donde cualquiera puede confirmar que coincide con el bytecode desplegado en la cadena. Las versiones verificadas de Solana hacen lo mismo comparando los hashes del programa desplegado con una versión reproducible del repositorio público, utilizando la herramienta solana-verify. La verificación solo demuestra que el código publicado es el mismo que se ha desplegado; no dice nada sobre si el código es seguro o justo, y un programa actualizable o un proxy pueden ser reemplazados posteriormente (lección 6.3.2). La regla propuesta 103(b)(6) exigiría a los emisores que indiquen la dirección donde está disponible el código fuente, si lo han publicado.
El suministro y las tenencias son los siguientes datos que la gente consulta. EIP-20 exige que cada token informe su totalSupply(), y las herramientas de tokens de Solana muestran el suministro total de un emisor. Las listas de tenedores pueden ser fáciles de interpretar erróneamente: los “tenedores” más grandes suelen ser un pool, un contrato de bloqueo, un contrato de vesting o una exchange. Al publicar esos direcciones y explicar cuáles saldos pertenecen a personas internas (lección 6.3.4), se convierte un gráfico intimidante en uno preciso. Los tokens que llegan a una dirección pero no son quemados en el sentido técnico siguen contando dentro del suministro total, lo cual es una de las razones por las cuales hay que tener cuidado con las afirmaciones sobre su quema (lección 6.3.5).
En los EE. UU., la publicación de datos no sustituye a declaraciones precisas; son las afirmaciones que hace el emisor las que son objeto de examen según la legislación sobre valores, materias primas y protección al consumidor (lecciones 5.1.7 y 6.3.1). Pero las pruebas en la cadena de bloques son la forma en que el creador demuestra que dichas declaraciones son verdaderas. La interpretación de la SEC para 2026 (Comunicado n.º 33-11412) alienta a los emisores que prometen realizar trabajos a divulgar públicamente cuándo se completan, y el hash de una transacción relacionada con un bloqueo, una autoridad revocada o la implementación de un vesting es la prueba más directa. En la UE, el artículo 6(1)(h) de MiCA exige que un libro blanco incluya información sobre la tecnología subyacente.
La transparencia conlleva costos que vale la pena mencionar. Una billetera pública vincula a una persona o empresa con todas las transacciones pasadas y futuras realizadas a través de ella, y las billeteras grandes pueden atraer operaciones de copiado de estrategias comerciales y atención no deseada. Un sistema de lanzamiento puede etiquetar direcciones según su función en lugar del nombre personal, pero todo lo que se publica es permanente, y las transferencias entre billeteras etiquetadas y sin etiqueta suelen poder rastrearse. Una verificación práctica: abra el explorador, comience desde la dirección del contrato pública e intente identificar el pool, cada bloqueo, cada billetera interna y cualquier autoridad de actualización utilizando únicamente el mapa proporcionado por el sistema de lanzamiento; todo lo que no pueda encontrarse en ese mapa representa una deficiencia en su divulgación.

Datos clave

El estándar de tokens EIP-20, creado el 19 de noviembre de 2015, hace que name(), symbol() y decimals() sean opcionales, pero exige totalSupply().
La verificación de contratos en Etherscan publica el código fuente y permite a cualquiera confirmar que coincide con el bytecode desplegado en la cadena.
Las compilaciones verificadas de Solana comparan los hashes del programa desplegado con una compilación reproducible del repositorio público de código fuente.
La regla propuesta 103(b)(7) del Reglamento de Activos Criptográficos exigiría a los emisores que describieran los métodos para verificar el historial de transacciones del token.
La regla propuesta 103(b)(6) exigiría que los emisores proporcionaran la dirección del sitio web donde se encuentra el código fuente, en la medida en que lo hayan puesto a disposición del público.
El artículo 6(1)(h) de MiCA exige que un libro blanco sobre activos criptográficos contenga información sobre la tecnología subyacente.

Ejercicio nueve, seis, tres, uno

9ReunirEnumere hasta 9 direcciones o fragmentos de código que un comprador necesitaría verificar para un token que conozca o esté planeando crear (algunas listas son más cortas), como el contrato del token, el pool, un mecanismo de bloqueo, un contrato de vesting o una autoridad de actualización.

6AgruparClásifícalos en 6 categorías: identidad del token, liquidez, tenencias de insiders, bloqueos y vesting, control del código y las actualizaciones, e ítems que aún no tienen dirección pública.

3DestilarReduzca las 6 categorías a 3 grupos: elementos ya publicados y etiquetados, elementos visibles en la cadena pero no explicados, y elementos que el comprador no puede encontrar en absoluto.

1CristalizarEscriba una oración que describa la única dirección o prueba cuya publicación mejoraría más lo que un comprador puede verificar sobre este token.

Verificación de hechos

Fechas, cifras y afirmaciones verificadas con las fuentes publicadas que se enumeran a continuación.

Abrir en la academia interactiva →

EN PT ZH JA KO RU DE FR MS