Cómo distribuir tokens después de una venta de tokens en TRON

La venta cerró, las asignaciones son definitivas y ahora 3,000 participantes están actualizando sus billeteras: la distribución de tokens es el momento en que de verdad se pone a prueba la credibilidad operativa de un proyecto. La buena noticia: entregarla es un problema resuelto y sin código: una lista de asignaciones exportada a CSV, enviada en unas pocas transacciones por lotes, con cada transferencia verificable públicamente en TRONSCAN en cuestión de minutos. Esta guía cubre las partes que de verdad fallan: convertir los datos de la venta en una lista limpia, ser honestos con el vesting, el envío en sí y la comunicación a su alrededor.

De los datos de la venta a la lista de asignaciones

Sea lo que sea lo que gestionó tu venta —una exportación de un launchpad, una hoja de seguimiento de pagos, registros de contribuciones on-chain—, el objetivo es la misma forma de dos columnas: dirección TRON e importe de tokens. Los errores nacen en la transformación, así que trátala como un paso de verdad:

1. Concilia primero las asignaciones. Antes de tocar direcciones, comprueba la columna de importes: ¿la suma de todas las asignaciones es exactamente lo que prometían los términos de la venta para esta ronda? Fija la política de redondeo de forma explícita (redondear hacia abajo, acumular restos, documentarlo) en vez de dejar que decida la hoja de cálculo.
2. Una fila por dirección. Si un comprador aportó en varios tramos, únelos; de lo contrario recibirá varias transferencias, algo inofensivo on-chain pero que genera tickets de «¿por qué me llegaron tres importes pequeños?».
3. Valida la columna de direcciones. Direcciones TRON: prefijo T, 34 caracteres. Los formularios de venta recogen direcciones de la red equivocada con una regularidad deprimente: una entrada 0x… es un comprador que no recibirá tokens y que sí abrirá un ticket. Detéctalo ahora, contáctalo ahora y corrige la lista antes de enviar. La guía del formato CSV tiene la lista de comprobación completa y las trampas clásicas de exportación.
4. Congela la lista. Versiona el CSV final (con fecha y, si quieres, con checksum) y declárala inmutable. Las peticiones posteriores al envío del tipo «en realidad mi dirección era otra» se gestionan en un proceso de excepciones aparte y documentado, nunca como ediciones silenciosas de un archivo activo.

Vesting: lo que las herramientas de lotes hacen y no hacen, con honestidad

Un multisender ejecuta transferencias que tocan ahora. No custodia tokens, no impone bloqueos ni libera nada gota a gota, y es mejor diseñar en torno a eso con honestidad que descubrirlo a mitad de la distribución.

• Desbloqueo único (100% en el TGE): una lista, una sesión de envío por lotes. El caso sencillo; el resto de esta guía lo cubre directamente.
• Vesting por tramos (p. ej., 25% en el TGE y luego trimestral): cada fecha de desbloqueo es su propia distribución: la misma hoja maestra de asignaciones, una columna de importes por tramo y una sesión de lotes por fecha. Operativamente es un recordatorio en el calendario más la disciplina de ciclo recurrente de la guía de nóminas, y el hash del lote de cada tramo se convierte en su prueba pública.
• Vesting continuo/forzado (liberación por bloque, derechos de reclamación transferibles): eso requiere un contrato de vesting específico, que es otra clase de herramienta. Si tus términos lo prometen, presupuesta ese contrato: un multisender lo complementa (para las partes desbloqueadas), pero no lo sustituye.

Sea cual sea el modelo, dilo con claridad en el anuncio: la gente perdona los calendarios; no perdona las sorpresas.

Enviar la distribución

Con la lista congelada, la mecánica lleva minutos:

1. Ensaya en testnet (Shasta/Nile) si es el primer lote del equipo: el flujo es idéntico y gratuito.
2. Conecta y selecciona el token. Para un token recién lanzado, pega la dirección de su contrato TRC-20. Asegúrate de que la billetera de tesorería tenga de verdad el importe total de la distribución más un colchón de TRX para comisiones.
3. Sube el CSV congelado. El validador marca direcciones mal formadas y duplicados; la pantalla de revisión muestra la lista interpretada y el total: compara ese total con la suma conciliada de asignaciones. Deben coincidir exactamente.
4. Aprueba y confirma. Unos 150 destinatarios por transacción; 3,000 participantes son 20 lotes consecutivos en un solo flujo: unos 25 minutos de principio a fin, una firma por lote tras una única aprobación del token.
5. Guarda los hashes. Cada transacción de lote en TRONSCAN muestra todas las transferencias individuales que contiene. Esos enlaces van directos al anuncio.

Coste, calculado con el motor de la calculadora para un escenario realista tras una venta —3,000 destinatarios, aproximadamente la mitad direcciones nuevas (billeteras creadas para la venta), un token tipo USDT, TRX a $0.30—: ≈13,140 TRX ≈ $3,942 con el flujo por lotes y energía alquilada, frente a ≈$9,066 quemando energía una a una; y firmar 3,000 transferencias de una en una no es, de todos modos, una tarde realista. La proporción de direcciones nuevas es la variable dominante; el análisis a fondo de la energía explica por qué duplica el coste por destinatario.

El lote canario

Una técnica tomada de la ingeniería de despliegues se paga sola en cada distribución: envía primero un canario. Antes de los lotes principales, ejecuta un lote diminuto: las billeteras del propio equipo más un puñado de miembros de la comunidad que lo acepten, unas pocas decenas de tokens en total. Recorre toda la ruta real en mainnet: el contrato del token se comporta bien, la autorización tiene el alcance correcto, las transferencias aparecen en TRONSCAN y los importes llegan con los decimales esperados.

Ese último punto merece énfasis. Los decimales del token son la sorpresa clásica del día de lanzamiento: un contrato desplegado con 6 decimales cuando la hoja suponía 18 (o al revés) desplaza cada importe varios órdenes de magnitud, y un canario de doce tokens lo detecta donde un envío completo habría repartido el error entre tres mil billeteras. Cinco minutos, dos firmas, y la distribución principal sigue adelante con descartada ya la única clase de error que ningún validador puede ver.

Si el canario tiene mala pinta en cualquier sentido, para. Una lista congelada y una comunidad a la espera sobreviven a una hora de retraso; una distribución con la escala equivocada, no.

El anuncio: una plantilla que evita tickets

La comunicación de la distribución tiene una sola tarea: que cada participante pueda verificarlo por sí mismo sin preguntarte. Una estructura que funciona:

Distribución completada. Se han enviado todas las asignaciones de la [nombre de la ronda]. Verifica la tuya: abre [enlace al hash del lote 1], [2], [3] en TRONSCAN y busca la dirección de tu billetera: ahí aparecen tu transferencia, el importe y la fecha y hora. Cifras: [N] billeteras, [total] tokens, de acuerdo con los términos de asignación publicados. Vesting: [próxima fecha de desbloqueo y porcentaje, o «totalmente desbloqueado»]. Si algo no cuadra: [canal de soporte único], indicando la dirección de tu billetera. Nota: nunca te escribiremos primero por privado, y no hay nada que «reclamar» en ningún sitio web; cuidado con los imitadores.

Publícalo en la hora siguiente al envío, mientras el equipo está conectado para responder: toda la carga de soporte de una distribución ocurre la primera tarde. La línea antiphishing no es relleno: tras las distribuciones de tokens aparecen sin falta «portales de reclamación» fraudulentos en pocas horas, y adelantarse a ellos protege tanto a tus titulares como la semana de tu equipo.

FAQ

¿Los destinatarios pagan algo o tienen que reclamar? No. Las transferencias llegan directamente a sus billeteras; no hay paso de reclamación, ni gas por su parte, ni ninguna acción necesaria. (Precisamente por eso cualquier «web de reclamación» que aparezca tras tu anuncio es una estafa: dilo.)

Nuestro token acaba de lanzarse: ¿tiene que estar listado en algún sitio antes? No. Cualquier TRC-20 funciona pegando la dirección de su contrato. El flujo por lotes no requiere listados, presencia en mercados ni listas blancas.

¿Qué hacemos con un comprador que dio una dirección equivocada? Antes de congelar: corrígelo en la lista. Después de enviar: una transferencia a una dirección válida es irreversible; por eso existen la pasada de validación, la congelación y el proceso de excepciones documentado. Los tokens nunca salen hacia una dirección mal formada, porque el validador lo bloquea; el caso peligroso es una dirección válida que pertenece a otra persona.

¿Podemos hacerlo todo desde una tesorería multifirma? El flujo firma una autorización y las transacciones de los lotes desde la billetera conectada, así que funciona con la configuración de firma que admita esa billetera. Comprueba primero en testnet cómo maneja tu multifirma concreta la interacción con contratos: justo para este caso existe el paso del ensayo.