𝐒𝐨𝐟𝐥𝐞𝐢𝐫𝐞 $𝐒𝐅𝐋𝐑: El lanzamiento falló por tarifas y liquidez, no por un hack – Aquí está el reinicio del snapshot 1. ¿Qué sucedió: Esto no fue un hack. No se robaron claves privadas, ningún contrato fue explotado por un atacante y no se ejecutó ningún “script de venta interna” contra la comunidad. Lo que ocurrió fue un error de configuración en el lanzamiento. Una gran parte de la oferta se colocó en contratos de bloqueo/custodia de Streamflow. En Streamflow, los bloqueos de tokens llevan una tarifa del 0,5% en tokens, además de una pequeña tarifa de creación en SOL. Esa tarifa no es teórica: forma parte del modelo de precios del producto de bloqueo. Al abrir el mercado, esa tarifa interactuó con un segundo problema: liquidez muy limitada en relación con la FDV. - La FDV (valoración completamente diluida) es precio × oferta total, incluyendo tokens que aún no están en circulación. - La liquidez es el capital real disponible en la piscina que puede absorber compras y ventas sin que el precio colapse. Si la FDV es alta y la piscina es pequeña, incluso una venta automática modesta puede hundir el gráfico. Eso es exactamente lo que describió el primer anuncio: el 0,5% de la oferta bloqueada se liquidó automáticamente al abrir debido a que la liquidez era demasiado baja en comparación con la FDV. Entonces, la secuencia fue: 1. Se crearon bloqueos con la estructura estándar de tarifas de Streamflow. 2. El mercado se abrió con profundidad insuficiente. 3. La configuración de tarifa/custodia obligó a los tokens a entrar en el mercado inmediatamente. 4. La liquidez limitada convirtió un evento de tarifa en un evento gráfico. Se trata de un error operativo y de parámetros. El primer comunicado ya aceptó plena responsabilidad por ello. 2. Por qué esto importa más que “el gráfico se ve mal” En un lanzamiento saludable, la oferta bloqueada debe estar fuera del mercado. Los bloqueos existen para que los titulares puedan verificar que los tokens del equipo, tesorería o vesting no puedan impactar el libro de órdenes el primer día. Cuando la infraestructura de bloqueo introduce una tarifa en tokens que debe liquidarse al crear o abrir, dos condiciones deben cumplirse o el diseño falla: 1. Alguien ha financiado previamente la tarifa de forma que no venda dentro de la nueva piscina. 2. La piscina es lo suficientemente profunda como para que cualquier venta residual no defina el precio. Ninguna de estas condiciones se cumplió. La baja liquidez en comparación con la FDV es el desajuste clásico en lanzamientos: el mercado se valora como si toda la oferta fuera valiosa, pero solo una pequeña flotación puede negociarse realmente. Cualquier vendedor forzado —tarifa, sniper, error en la adición de LP o desbloqueo— se convierte en el precio. Por eso el primer mensaje lo llamó un grave error de cálculo en los parámetros de configuración, no un exploit misterioso. 3. Por qué el equipo no está “arreglando el gráfico actual” Tras revisar las opciones durante la noche, el segundo anuncio rechazó una solución temporal sobre el token existente. Arreglar una primera impresión rota suele beneficiar a las personas equivocadas: - Los snipers / bots MEV ya compraron la dislocación. - Los proveedores tardíos de liquidez y los vendedores de la primera hora ya fijaron el daño. - Los titulares del día uno que compraron el lanzamiento previsto se verían obligados a competir con un gráfico que ahora codifica ese fallo. Una reparación que mantuviera la misma emisión, los mismos contratos de custodia y el mismo libro de órdenes contaminado no restauraría una superficie limpia de descubrimiento de precios. Solo transferiría el valor restante hacia quienes actuaran con mayor rapidez cuando la tarifa impactó en la piscina. Esa es la razón explicada para optar por un nuevo token en lugar de una solución cosmética.
