Cinco estructuras que se repiten en los proyectos que terminan mal
Esta página no menciona el nombre de ningún proyecto. Ni uno.
Por dos razones. La primera es que no tenemos capacidad para determinar que algo concreto «es una estafa»: eso exige evidencia, investigación y un proceso legal, y no es lo que hace un sitio que escribe métodos. La segunda es más práctica: señalar nombres no te sirve. Si hoy señaláramos diez, mañana habría cien nuevos. Una lista negra no te alcanza: te hace falta un criterio que puedas aplicar tú a cualquier caso nuevo.
Así que lo que sigue son estructuras: formas de organizarse y secuencias de comportamiento que aparecen una y otra vez en proyectos muy distintos. Cumplir con alguna no significa que haya un problema; los proyectos serios también cumplen una o dos. Pero cuando se dan varias a la vez y todas se inclinan en la misma dirección, al menos sabes cuánta evidencia deberías exigir.
Cómo usar esta página. Todo lo que sigue son rasgos de riesgo, no pruebas de nada. No la uses para calificar a ninguna persona ni a ningún proyecto, y no la uses para acusar a nadie en público. Su único uso correcto es este: cuando estés considerando poner dinero en algo, recorrerla y ver con claridad qué tienes delante. Una altcoin puede valer cero, y estas estructuras son solo una parte de las maneras en que eso ocurre.
1 · Marketing por delante, producto por detrás
Los recursos visibles del proyecto se inclinan claramente hacia la difusión y no hacia el producto: redes muy activas, eventos frecuentes, materiales cuidados; y en cambio el producto utilizable, los commits o los datos de uso real no aparecen durante mucho tiempo.
Lo característico no es «hacer marketing» —todo proyecto necesita darse a conocer—. Lo característico es una desproporción que se mantiene en el tiempo. Tres meses después del lanzamiento hay cientos de publicaciones y el repositorio casi no tiene commits; las funciones que aparecen en la promoción no se pueden abrir en el producto; y en la hoja de ruta, los hitos marcados como cumplidos son cosas que no requieren desarrollo, como «presentación de marca» o «apertura de comunidad».
Por qué merece atención: un proyecto que pone casi todos sus recursos en la difusión probablemente tenga a la difusión como modelo de negocio. El precio del token lo mueve la atención, y la atención necesita inversión creciente para sostenerse. No implica intención de engañar, pero es estructuralmente hostil para quien llega nuevo: cuando compras, la atención ya está en un nivel empujado.
Dónde mirar: el repositorio público (frecuencia de commits, número de personas contribuyendo, fecha del último cambio); si el producto se puede abrir y usar; y de qué naturaleza son los hitos ya cumplidos en la hoja de ruta.
Qué cuenta como problema: repositorio detenido hace mucho o con solo un par de commits iniciales; funciones anunciadas que no existen en el producto; todos los hitos cumplidos son no técnicos. Cómo leer la hoja de ruta mirando lo cumplido y no lo prometido está en qué partes del whitepaper hay que leer.
2 · La promoción se concentra en fechas concretas
Las menciones no se distribuyen de forma pareja: aparecen concentradas en unos pocos días y con formulaciones muy parecidas entre fuentes distintas. Esa sincronía no suele ser casualidad.
El interés genuino es disperso: unos se enteran antes y otros después, cada quien lo cuenta a su manera, hay entusiastas y hay escépticos. La promoción organizada, en cambio, tiene rasgos observables:
- Concentración temporal: decenas de cuentas empiezan a hablar de lo mismo en un par de días, sin haberlo mencionado nunca antes.
- Formulaciones que convergen: las mismas metáforas, los mismos argumentos de venta, las mismas cifras, como salidos de un mismo material.
- Una sola dirección: no aparece prácticamente ninguna objeción ni discusión de riesgos; todo habla del recorrido al alza.
- Cercanía a fechas clave: los picos suelen caer alrededor del listado, antes de un desbloqueo, o antes de alguna campaña.
El último punto es el más informativo. Poner los picos de promoción y el calendario de desbloqueo en la misma línea de tiempo a veces deja ver un orden; por qué la información te llega justo en esos picos está desarrollado en qué significa que los insiders salgan primero. Y aquí hay que ser muy contenido: la proximidad temporal no prueba ninguna causalidad. Solo te avisa de que la información que recibes en ese momento puede no ser neutra.
Hay una autocomprobación todavía más simple: pregúntate cómo me enteré de esta moneda. Si la respuesta es «me apareció», «alguien la puso en un grupo» o «lo mencionó alguien que sigo», y no «la encontré investigando un sector», es bastante probable que lo que recibiste sea parte de esa ola. En qué preguntarle a quien te recomienda una moneda hay un conjunto de preguntas listas para usar.
3 · Bloqueos que son solo promesas
Hay dos clases de bloqueo: el que está escrito en una publicación o en la documentación, y el que está escrito en un contrato en cadena. El primero se puede desdecir en cualquier momento; solo el segundo obliga. La mayoría de los conflictos vienen de confundir uno con otro.
«La parte del equipo está bloqueada tres años» no dice cómo está bloqueada. Hay al menos tres posibilidades:
| Forma | Fuerza obligatoria | Cómo se verifica |
|---|---|---|
| Compromiso verbal en un anuncio o documento | Ninguna: se puede modificar cuando sea | No se puede verificar; solo mirar si ya se desdijeron antes |
| Custodia por un tercero | Depende del acuerdo; suele tener algo de fuerza | Ver si se publicó quién custodia y los puntos del acuerdo |
| Contrato de bloqueo en cadena | La mayor: se ejecuta según el código | Con la dirección del contrato, revisar saldo, fechas y condiciones en el explorador |
Incluso con un bloqueo en cadena quedan cosas por confirmar: qué porción bloquea (si bloquea la parte del equipo pero no la de la fundación, el alcance es limitado), si el propio contrato permite retirar antes de tiempo (algunos conservan una función de administrador), y a quién van los tokens al vencer.
Dónde mirar: busca la dirección del contrato de bloqueo en la documentación oficial y ábrela en el explorador: cuántos tokens tiene, si el código está verificado, si existe alguna función de retiro anticipado.
Qué cuenta como problema: solo hay compromiso escrito y no pueden darte una dirección; el código no está verificado; el contrato tiene una función que permite al administrador retirar cuando quiera; la cantidad bloqueada es muy inferior a la anunciada.
4 · Liquidez que puede retirarse
Los tokens que se operan en cadena dependen de un pool de liquidez. Si el dinero del pool lo puso principalmente el propio proyecto, retirarlo deja al precio sin sostén en muy poco tiempo, y quien tiene el token puede quedarse sin contraparte.
Conviene entender primero la diferencia con un exchange tradicional. Allí tu contraparte son las órdenes de otros usuarios. En un creador de mercado automático en cadena, tu contraparte es un pool: dentro conviven el token y un activo de cotización (por ejemplo, una stablecoin), y el precio sale de la proporción entre ambos.
Esa liquidez la depositó alguien. Quien la depositó puede retirarla. Si más del noventa por ciento del pool de un token nuevo viene de una sola dirección del proyecto, la existencia del pool depende por completo de la voluntad de esa dirección. Cuando ese dinero se retira, el activo de cotización que queda cae en picada y cualquier venta hunde el precio de inmediato.
Lo que se puede mirar antes:
- Quién provee la liquidez: la página del pool en el exchange descentralizado suele mostrar la distribución de proveedores.
- Si los certificados de liquidez están bloqueados o quemados: proveer liquidez entrega un token de certificado, y solo con él se recupera el dinero. Algunos proyectos lo bloquean en un contrato o lo queman, y eso es una acción verificable.
- El tamaño del pool frente a la capitalización: un pool minúsculo respecto de la capitalización significa que hay muy poco dinero real sosteniendo el precio.
Y el límite, otra vez: que el proyecto tenga la liquidez no significa que la vaya a retirar. Que un proyecto temprano provea su propia liquidez es lo habitual y lo hacen también proyectos serios. Lo verificable es «si renunciaron voluntariamente a ese derecho», no «si lo van a usar». Cómo se mide la liquidez en sí está en liquidez y slippage.
5 · Lo que puede estar guardado en los permisos del contrato
Un contrato de token puede incluir funciones que te dejan en posición pasiva: emitir más, poner direcciones en lista negra, suspender transferencias. Si existen y quién las controla es consultable en el explorador de bloques.
| Permiso | Qué permite hacer | Qué significa para ti |
|---|---|---|
| Emisión (mint) | Crear tokens nuevos de la nada | El suministro, la tasa de circulación y el FDV que calculaste pueden dejar de valer |
| Lista negra | Impedir transferencias desde ciertas direcciones | Tu posición podría quedar congelada de forma unilateral |
| Pausa | Detener todas las transferencias | Podrías no poder vender justo cuando más quieras hacerlo |
| Ajuste de comisiones | Cambiar el porcentaje cobrado al operar | El costo de vender puede subir de un momento a otro |
| Propiedad (owner) | Invocar todas las anteriores | Si se renunció o no a la propiedad es el interruptor clave |
Hay que decirlo con claridad: que esas funciones existan no implica mala intención. Las stablecoins reguladas suelen incluir lista negra y pausa, precisamente para poder colaborar con el congelamiento de fondos robados. Los contratos actualizables tienen usos legítimos, como corregir vulnerabilidades. Lo que decide no es «si existen», sino tres cosas: si el proyecto lo explica por su cuenta, quién controla esos permisos (una dirección común o una firma múltiple) y si hay una auditoría independiente que cubra esa parte.
Dónde mirar: la pestaña de contrato de la dirección del token en el explorador de bloques.
Qué mirar: si el código fuente está verificado (sin verificar = imposible de revisar); si es un contrato proxy actualizable; si la dirección de propiedad se transfirió a la dirección cero (renuncia); si hay enlace a una auditoría independiente publicada.
Qué cuenta como problema: código sin verificar; propiedad todavía en una dirección común y el proyecto nunca lo menciona; auditoría inexistente, o con hallazgos de alta severidad marcados como no corregidos.
Cómo se lee cada campo está ordenado en el mapa de consultas en cadena.
Por qué suelen aparecer juntas
Porque sirven a lo mismo: trasladar las fichas de unas pocas manos a muchas en el menor tiempo posible, haciendo que el proceso parezca una oportunidad de inversión.
Ordenadas en el tiempo, las cinco tienen una secuencia:
- Primero se arma la estructura. Reparto, permisos del contrato, quién provee la liquidez: todo eso queda definido en el momento en que se emite el token, cuando afuera todavía nadie sabe que el proyecto existe.
- Después se construye el volumen de voz. Marketing por delante, promoción concentrada, atención acumulada hacia una fecha. Ese paso tiene un costo presupuestable.
- Luego llega la absorción. Listado, apertura, pico de conversación, entrada de compradores nuevos.
- Y al final, la salida. Vencimiento de bloqueos, retirada de liquidez, o simplemente una distribución sostenida en cantidades pequeñas.
Entender esa secuencia tiene un uso directo: los rastros que deja el primer paso ya se pueden consultar antes de que ocurra el segundo. La tabla de reparto, los permisos del contrato y la dirección del contrato de bloqueo son públicos desde antes de que el proyecto se ponga de moda. Cuando te enteras, en el tercer paso, los dos primeros ya ocurrieron, pero esa evidencia estructural sigue estando ahí; simplemente nadie la menciona.
Por eso el uso real de este capítulo no es reconocer patrones después del hecho, sino en el momento en que te recomiendan algo, ir a mirar qué dejó el primer paso. Nunca es tarde para hacerlo y no necesitas que nadie te dé la respuesta.
Los proyectos serios también cumplen algunas
Hay que insistir en este límite, porque decide si esta página se usa bien o mal.
Un proyecto temprano que trabaja en serio puede perfectamente: darle mucha importancia al marketing (necesita darse a conocer), no tener producto utilizable todavía (lo está construyendo), proveer casi toda la liquidez (nadie más la provee) y conservar permisos de actualización (necesita poder corregir fallos). Cumple las cuatro y no hizo nada malo.
Lo que de verdad distingue no es cuántas cumple, sino tres preguntas adicionales:
- ¿Lo explica por su cuenta? Conservar permisos de actualización y decir por qué no es lo mismo que conservarlos y no mencionarlo jamás.
- ¿Converge con el tiempo? Proveer la propia liquidez al principio es normal; seguir igual un año después indica que la participación externa nunca se formó.
- ¿Los compromisos se volvieron obligaciones? Dijeron que iban a bloquear: ¿lo pusieron en cadena? Dijeron que iban a renunciar a la propiedad: ¿la transfirieron efectivamente a la dirección cero?
Las tres se pueden consultar y sus respuestas son binarias: se hizo o no se hizo. Perseguir esas tres preguntas rinde mucho más que ponerle una etiqueta a un proyecto.
Y si hubiera que comprimir las cinco estructuras en tres frases portátiles: lo que debería ser público no lo es; el compromiso y la obligación están en planos distintos, así que mira la obligación y no la promesa; y el momento en que entras no lo elegiste tú, te lo empujó el flujo de información. Cada vez que notes que te está moviendo el calendario de otro, conviene frenar.
Para recorrer estos rasgos uno por uno está el comparador de frases de venta: marcas lo que escuchaste y te devuelve a qué estructura suele corresponder. El recorrido completo de las seis dimensiones está en las seis comprobaciones.
Preguntas frecuentes
Si un proyecto cumple varias de estas estructuras, ¿ya es una estafa?
No. Son rasgos de riesgo, no pruebas. Un proyecto serio puede dar mucha importancia al marketing o pasar meses sin producto utilizable. Que se cumplan varias solo indica que su estructura te deja en una posición desfavorable y que deberías exigir evidencia más fuerte; no habilita a calificar a nadie.
No sé leer código, ¿puedo revisar igual los permisos del contrato?
Sí. La ficha del contrato en el explorador muestra si el código fuente está verificado, si es un contrato actualizable y si se renunció a la propiedad. Nada de eso exige leer código. Además puedes buscar si existe una auditoría independiente publicada y qué hallazgos de alta severidad quedaron sin corregir.
Si los tokens están bloqueados, ¿ya está resuelto?
Depende de dónde esté el bloqueo. Un compromiso publicado en redes no obliga a nada y puede cambiarse. Un contrato de bloqueo en cadena sí obliga, pero hay que confirmar qué porción bloquea, hasta cuándo, a quién van los tokens al vencer, y si el propio contrato permite retirar antes de tiempo.
¿Dónde empiezo si solo tengo diez minutos?
Por la tercera y la quinta: pide la dirección del contrato de bloqueo y mira los permisos del contrato en el explorador. Son las dos que dejan rastros verificables desde el día de la emisión, no dependen de interpretar comportamientos, y sus respuestas son binarias: la dirección existe o no existe, la propiedad se renunció o no.
El límite, otra vez. Este capítulo describe estructuras, no juzga proyectos. No damos nombres, y te recomendamos no usar estos rasgos para acusar públicamente a nadie: lo que ves son apariencias, no evidencia. Su único uso es ayudarte a ver la forma de aquello en lo que estás por poner dinero. Verlo con claridad no impide perder: una altcoin puede valer cero, y hacer la tarea no cambia ese hecho.