Seis cosas que mirar antes de tocar nada, en orden, sin saber programar. Y las que no se arreglan con contexto.
🎯 Objetivo de la lección
Convertir todo lo anterior en un método: qué mirar en un proyecto concreto, en qué orden, y qué hacer con lo que encuentres. Sin saber programar y sin más herramientas que un navegador.
🧭 Para qué sirve esto y para qué no
Una advertencia antes de empezar, para que el método no prometa lo que no puede dar.
Esto no sirve para saber si algo va a funcionar, ni si conviene participar, ni si tiene futuro. Nadie sabe eso y quien diga lo contrario te está vendiendo algo.
Sirve para otra cosa, más modesta y más útil: saber de qué depende lo que estás mirando. Qué tendría que fallar y quién tendría que fallar para que salga mal. Con eso se decide con criterio; sin eso se decide por impresión.
1️⃣ Qué problema dice resolver, y quién lo tenía
La primera pregunta es la de la lección anterior: ¿hay alguien con motivo y capacidad para manipular el registro, a quien no se pueda obligar?
Si el proyecto no responde a eso, todo lo demás da igual. Y hay una señal muy fiable: cuando la descripción empieza por la tecnología en vez de por el problema —«usamos blockchain para…»—, suele ser porque el problema se buscó después.
Señal complementaria: si funcionaría igual con una base de datos normal, es que es una base de datos normal.
2️⃣ Quién puede cambiar las reglas
La pregunta de la lección 2.2, y la más importante de las seis.
Hay que buscar si los contratos son actualizables y quién tiene esa capacidad. Lo que se busca, en orden de lo que más tranquiliza a lo que menos:
Nadie puede cambiarlos. Lo más rígido y lo más predecible; también significa que un fallo no se arregla.
Una decisión colectiva con demora, de forma que se pueda ver venir un cambio y salir antes.
Varias firmas repartidas entre personas u organizaciones distintas.
Una sola dirección, que puede cambiar, pausar o vaciar cuando quiera. Aquí hay un tercero de confianza sin contrato contigo.
Ninguna opción es descalificadora por sí sola. Lo descalificador es que el proyecto no lo diga, o que diga «descentralizado» cuando es lo último.
3️⃣ Qué parte está realmente descentralizada
El inventario de la lección 1.3, aplicado a este caso. Cinco piezas, y cada una puede estar en un sitio distinto:
El registro donde vive: quién lo mantiene y cuán repartido está.
La web por la que entras: quién la aloja, qué pasa si cae, si hay forma de operar sin ella.
Los archivos, si los hay: dónde están de verdad y quién paga por mantenerlos.
Los datos de fuera que el contrato necesita: de dónde salen los precios o los resultados.
La gobernanza: quién decide y en proporción a qué.
La respuesta útil no es un sí o un no, sino una lista de cinco respuestas. Eso es el perfil de riesgo de lo que estás mirando.
4️⃣ Cómo se repartió al principio
Esto se mira poco y condiciona todo lo demás.
Si una parte grande de las unidades fue a parar a un grupo reducido al empezar, entonces la gobernanza está decidida de antemano, por mucho que el mecanismo sea una votación abierta. Y si esas unidades se liberan por etapas, hay un calendario de gente que puede vender en fechas conocidas.
No es una acusación: repartir algo hay que repartirlo de alguna forma, y financiar el desarrollo también. Lo que importa es que esté publicado y se pueda comprobar. Cuando esta información no aparece por ninguna parte, esa ausencia ya es una respuesta.
5️⃣ Quién está detrás y qué ha hecho antes
Aquí conviene un matiz que se pasa por alto.
Que un equipo sea anónimo no es descalificador por sí mismo: el sistema más sólido del sector lo creó alguien que desapareció. Lo que importa es la combinación. Anonimato más capacidad de cambiar las reglas más custodia de fondos ajenos es un conjunto muy difícil de justificar.
Lo que sí se puede comprobar de cualquiera: si hay trabajo público anterior, si el código está publicado, si ha habido revisiones externas —y si las hubo, qué decían y si se corrigió—, y cómo respondieron cuando algo salió mal, que es lo más revelador de todo.
6️⃣ Cómo se comporta la comunidad
La última, y la que menos cuesta comprobar: entra donde se hable del proyecto y haz una pregunta técnica sencilla.
Si te responden con detalles, con enlaces y admitiendo lo que no saben, es buena señal.
Si te responden con entusiasmo, con promesas o preguntando cuánto tienes, es otra.
Si preguntar molesta, ya tienes la respuesta. Un proyecto sólido agradece las preguntas técnicas; uno que no lo es las trata como deslealtad.
Esta señal es de las más fiables que existen y no exige entender nada técnico. Aparece también en Seguridad básica, lección 1.2, por el mismo motivo.
🚩 Lo que no se arregla con contexto
Seis cosas que, cuando aparecen, no necesitan más investigación:
Rentabilidad garantizada, en cualquier forma y por cualquier cifra.
Prisa: plazas limitadas, precio que sube, ventana que se cierra.
Recompensa por traer gente como parte central del funcionamiento.
Contratos sin publicar en algo que pide dinero.
Dificultad para retirar, o pasos extra que aparecen solo al salir.
Que te escriban primero por privado ofreciendo ayuda u oportunidad.
⏱️ El método en versión corta
Cuando no hay tiempo para las seis, tres preguntas cubren la mayor parte:
¿Quién puede cambiar las reglas?
¿Qué parte de esto no está descentralizada?
¿Qué pasa si el equipo desaparece mañana?
Si las tres no tienen respuesta clara y comprobable, lo que falta no es información: eso ya es la información.
📌 En resumen
El método no dice si algo funcionará. Dice de qué depende: qué y quién tendría que fallar.
Si funcionaría igual con una base de datos normal, es una base de datos normal.
La pregunta principal es quién puede cambiar las reglas. Lo descalificador no es la respuesta, es que no la haya.
Hay cinco piezas que pueden estar descentralizadas o no: registro, web, archivos, datos externos y gobernanza. El perfil de riesgo es la lista de las cinco.
El reparto inicial condiciona la gobernanza. Si no está publicado, esa ausencia ya es una respuesta.
El anonimato no descalifica solo; anonimato más control más custodia, sí.
Si preguntar molesta, ya tienes la respuesta.
➡️ Qué viene después
Ya tienes el mapa y el método. La última lección recoge qué has visto, qué se ha quedado fuera a propósito y por dónde seguir según lo que quieras hacer con esto.