Informe de seguridad
Cómo leer un whitepaper de criptomonedas
Un whitepaper no tiene norma, ni revisor, ni obligación de seguir siendo cierto. Qué leer primero, qué verificar fuera del documento y qué saltarse.
Un whitepaper es el documento que un proyecto publica para explicar qué está construyendo. No hay ninguna norma sobre lo que debe contener, nadie lo revisa antes de publicarlo y ninguna regla exige que siga siendo exacto después. Es un documento de marketing que a veces contiene ingeniería. Leído así resulta realmente útil; leído como un folleto de emisión, le engañará.
Empiece por el final
Lea primero la sección del token, se llame como se llame. Suele estar cerca del final y es la parte que describe lo que realmente estaría comprando: qué hace el token dentro del sistema, cómo aparecen las unidades, quién las recibió antes que usted y con qué calendario esas posiciones se vuelven transferibles. Si el documento explica largamente una tecnología y describe el token en dos párrafos vagos, ese desequilibrio es lo más informativo que contiene.
Pregunte qué problema se resuelve, y para quién
Un buen documento enuncia un problema que existe con independencia de la solución propuesta y que reconocería quien lo padece. La vaguedad aquí no es un defecto de estilo. Si el planteamiento del problema solo tiene sentido una vez que ha aceptado el sistema que le venden, puede que fuera del documento no haya problema alguno.
Separe lo construido de lo planeado
Los documentos describen habitualmente componentes terminados, parciales e hipotéticos en el mismo presente de indicativo. Marque qué es qué mientras lee y contraste después cada afirmación con algo externo al documento: un repositorio público, un contrato desplegado, una red de pruebas en funcionamiento. Una hoja de ruta es una declaración de intenciones, no el registro de nada.
Localice los supuestos de confianza, que rara vez tienen sección propia
Todo diseño depende de algo: de que los validadores se comporten, de que una fuente de precios sea honesta, de un puente, de una empresa que custodia reservas, de una clave de administración capaz de cambiar el código. Un documento serio los nombra y dice qué ocurre cuando cada uno falla. Si en el documento nada puede fallar, no está describiendo un sistema.
Trate al equipo y los respaldos como afirmaciones por verificar
Personas identificadas con trayectorias comprobables significan que el proyecto tiene algo que perder. El anonimato no descalifica automáticamente, pero elimina esa garantía, y el documento tiene que compensarlo en otro sitio. Los logotipos de socios, exchanges, auditores e inversores son afirmaciones, no pruebas: verifique cada una en la fuente que supuestamente la emitió, porque reproducir un logotipo no cuesta nada.
Las partes que puede saltarse
Las secciones introductorias que explican qué es una cadena de bloques en general, las comparaciones largas con redes consolidadas y todo lo planteado como oportunidad de mercado le hablan de la redacción, no del proyecto. Lo mismo vale para las matemáticas decorativas: si las ecuaciones no hacen un trabajo del que dependa el argumento que las rodea, son maquetación.
Conclusión clave
La última comprobación
Anote la versión y la fecha y busque después una más reciente. Los proyectos revisan sus whitepapers, y los repartos cambiados sin ruido y los compromisos retirados sin ruido solo se encuentran comparando.
Más guías
Siguiente