Cómo revisar la mecánica de un lanzamiento DeFi antes de distribuir

Un lanzamiento está listo para distribuirse solo cuando el equipo puede explicar quién puede participar, cómo funcionan las asignaciones, qué requieren las operaciones de liquidez y qué contratos controlan cada paso. Trato cada elemento como una dependencia documentada con un responsable. Un campo vacío o sin respaldo permanece como desconocido. Esta lista de verificación es un método de evidencia, no una previsión de demanda ni del rendimiento del token. La documentación de Uniswap v4 es un ejemplo específico de arquitectura de pools, no una especificación universal de lanzamientos.

Define el recorrido del participante y las reglas de elegibilidad

Escribe el recorrido del participante desde el primer descubrimiento hasta completar una acción de distribución. Identifica dónde se entera una persona del lanzamiento, qué billetera o cuenta necesita, qué red debe usar, qué activos necesita y qué ocurre si no cumple los requisitos. Cita los términos oficiales sobre listas de permitidos, restricciones geográficas o de identidad, ventanas de reclamación, límites y vías de apelación. Si el lanzamiento no tiene un filtro de elegibilidad, documéntalo también.

Prueba el recorrido desde una billetera nueva o un entorno de pruebas. Comprueba la cadena requerida, las aprobaciones de tokens, la secuencia de transacciones, el activo para comisiones, los mensajes de error y el canal de soporte. Una página de destino que dice «conecta la billetera» no documenta todas las dependencias. Un contrato que acepta una transacción no demuestra que las instrucciones públicas estén completas. Compara el texto dirigido al usuario con la mecánica desplegada o configurada y registra cualquier diferencia antes de abrir la distribución.

Asigna un responsable a cada comprobación operativa. Producto puede encargarse del recorrido, legal del lenguaje de elegibilidad, ingeniería de la configuración de contratos y soporte de la escalada de incidentes. El responsable es la persona que puede resolver un fallo, no simplemente quien redactó la lista de verificación.

Verifica la mecánica y las restricciones de asignación

Documenta cómo se calcula la asignación y dónde se encuentra la regla de autoridad. Para una asignación fija, registra el total, las unidades, las categorías de destinatarios, el periodo de reclamación y el tratamiento de las cantidades no reclamadas. Para una asignación variable o con exceso de demanda, explica la fórmula, el límite, el orden, la aleatorización o la regla prorrata. Cita un contrato, una configuración firmada, una decisión de gobernanza o los términos oficiales del lanzamiento. No presentes una etiqueta de interfaz como prueba de una regla en cadena.

Comprueba si la implementación puede cambiar después del lanzamiento. Revisa los roles administrativos, las vías de actualización, las funciones de pausa, las modificaciones de listas de permitidos y los controles de emergencia. Estos controles pueden ser funciones legítimas de seguridad. Su existencia debe ser visible en el registro de preparación porque afecta a quién puede cambiar la mecánica del lanzamiento y bajo qué condiciones. Si no es posible verificar la fuente, registra la limitación y no afirmes que el comportamiento está confirmado.

Usa una matriz campo por campo en lugar de una sola casilla de «asignación verificada». Incluye la afirmación, la URL o dirección de evidencia, el valor observado, la hora de comprobación, el responsable y el estado. Marca un campo como «no aplicable» solo con una justificación. Una fuente ausente es desconocida, no cero. Una discrepancia entre la interfaz y el contrato es un problema del lanzamiento que debe resolverse, no un detalle de redacción.

Traza la liquidez y las dependencias de los contratos

Describe el recorrido de la liquidez en términos operativos. ¿Qué pool o plataforma se crea? ¿Qué activos y parámetros se utilizan? ¿Quién aporta la liquidez inicial? ¿Quién puede cambiar las comisiones o los parámetros? ¿Qué transacción debe completarse antes de que los usuarios puedan operar? Estas respuestas varían según el protocolo y el despliegue. Usa la documentación oficial del protocolo correspondiente y las direcciones o la configuración reales del lanzamiento que estás revisando.

La documentación de Uniswap v4 describe un PoolManager singleton que gestiona el estado y las operaciones de los pools, con hooks que pueden ampliar el comportamiento. Esa arquitectura es específica de Uniswap v4. No establece los requisitos de otro DEX, un puente, una plataforma de lanzamiento o un mercado personalizado. Para una integración con v4, revisa el PoolManager desplegado, la clave del pool, los hooks, la configuración de comisiones y la ruta de integración. La descripción general del protocolo dirige a los desarrolladores a conceptos, guías, repositorios, auditorías y referencias de despliegue. Usa esas fuentes para rastrear la implementación en lugar de generalizar a partir de la descripción general.

Ejecuta la secuencia operativa completa en un entorno controlado. Confirma que el pool o la distribución se inicialicen como se espera, que los roles y saldos coincidan con el plan aprobado y que la monitorización esté activa. Documenta los criterios de reversión o pausa y la persona autorizada para utilizarlos. No insinúes que la profundidad de liquidez garantiza un precio estable o un lanzamiento exitoso.

Usa una matriz de preparación y mantén visible la incertidumbre

Antes de abrir la distribución, revisa cuatro áreas de evidencia: acceso de participantes, asignación, liquidez y operaciones. Para cada una, registra el requisito, la fuente primaria, el resultado actual, el responsable y la pregunta sin resolver. La matriz ayuda a tomar decisiones. No convierte la evidencia incierta en una puntuación ni garantiza un resultado.

Una revisión útil de preparación pregunta si un nuevo participante puede seguir el recorrido indicado, si los términos de asignación coinciden con la implementación, si la secuencia de liquidez tiene un operador identificado y si la monitorización y los controles de incidentes están activos. Si alguna respuesta es desconocida, decide si el lanzamiento puede avanzar con esa incertidumbre, si debe cambiar la información comunicada o si la dependencia debe resolverse primero. Registra la decisión y quién la aprobó.

Los fallos habituales incluyen usar una lista de verificación genérica para un mecanismo específico de un protocolo, depender de una dirección de despliegue desactualizada, pasar por alto una configuración privilegiada y tratar una transacción de prueba exitosa como prueba de que todos los usuarios pueden participar. Conserva los enlaces de evidencia junto con la lista de verificación y repite las pruebas después de cualquier cambio en contratos, interfaz, elegibilidad o liquidez. Para comparaciones más amplias de modelos de lanzamiento, consulta mi guía sobre [marcos de lanzamiento DeFi](marcos de lanzamiento DeFi) y la [lista de verificación GTM para DeFi](lista de verificación GTM para DeFi).

El gráfico cuenta las listas de pasos de la página de PoolManager de Uniswap v4: cinco para un intercambio y siete para una modificación de liquidez. Los recuentos solo sirven para recordar que una operación tiene múltiples comprobaciones y hooks. No describen todos los hooks, integraciones ni lanzamientos DeFi desplegados. Para otro protocolo, reconstruye esta lista de evidencias a partir de su propia documentación y configuración desplegada.

Registro de evidencias

Preguntas frecuentes

¿Un pool de liquidez garantiza un lanzamiento de tokens exitoso?

No. Un pool es un mecanismo de mercado. No garantiza demanda, acceso justo, liquidez suficiente ni un precio estable.

¿Qué debe comprobarse antes de abrir la distribución de tokens?

Verifica el acceso de los participantes, las reglas de asignación, las operaciones de liquidez, la configuración de contratos, la monitorización y los responsables. Usa fuentes primarias y marca como desconocidos los campos sin resolver.

¿Puede usarse una lista de verificación de Uniswap v4 para cualquier lanzamiento DeFi?

No. La documentación de Uniswap v4 describe su propia arquitectura. Otros protocolos y despliegues tienen contratos y requisitos operativos diferentes.

¿Qué ocurre si la interfaz y el contrato muestran términos de asignación diferentes?

Pausa la decisión de preparación y resuelve la discrepancia con el responsable correspondiente. Registra la evidencia exacta y actualiza los términos dirigidos a los participantes antes de confiar en cualquiera de las dos versiones.

Referencias

1. https://docs.uniswap.org/contracts/v4/concepts/PoolManager, consultado el 2026-11-09.
2. https://docs.uniswap.org/contracts/v4/overview, consultado el 2026-11-09.