Formato CSV para transferencias masivas de tokens: plantilla + errores comunes

El CSV para una transferencia masiva de tokens necesita exactamente dos columnas —dirección del destinatario y, después, el importe—, un destinatario por línea, separados por una coma, con punto como separador decimal y sin fila de encabezado. Ese es todo el formato. Descarga la plantilla lista para usar, sustituye las filas de ejemplo por tus direcciones reales y listo; el resto de este artículo existe porque las hojas de cálculo se resisten a esta sencillez de siete formas previsibles, y porque diez minutos de higiene del archivo cuestan menos que una sola transferencia irreversible enviada mal.

Descarga la plantilla

Descargar la plantilla CSV: tres filas de ejemplo en el formato correcto:

TYourRecipientAddressHere111111111,100
TYourRecipientAddressHere222222222,25.5
TYourRecipientAddressHere333333333,10

Una propiedad de seguridad deliberada: las direcciones de ejemplo tienen la forma correcta (34 caracteres, empiezan por T) pero no son direcciones TRON reales, así que el validador de la dApp las rechazará al subirlas. No puedes enviar fondos a la plantilla por accidente: sustituye cada fila por destinatarios reales y el archivo pasará la validación.

El formato, línea por línea

Cada línea es un destinatario y sigue una regla:

<dirección TRON>,<importe>

• Dirección: una dirección TRON en base58; empieza por T y tiene exactamente 34 caracteres. Sin espacios alrededor, sin comillas.
• Coma: el separador de columnas. Una coma por línea, nada más.
• Importe: un número simple. Punto para los decimales (25.5), sin separadores de miles (10000, no 10,000), sin símbolos de moneda, sin espacios al final.
• Sin fila de encabezado. La primera línea ya debe ser un destinatario real: address,amount como texto se marcará como dirección no válida (es el validador diciéndote que la borres).
• Los duplicados se permiten, pero significan algo: la misma dirección dos veces equivale a dos transferencias a esa billetera. Elimina duplicados primero, salvo que eso sea exactamente lo que quieres.

La misma lista de dos columnas también puede pegarse directamente en la dApp como texto, y los archivos XLS/XLSX con esas dos columnas funcionan tal cual: CSV es simplemente el más portable de los tres.

Exportar desde las herramientas que ya usas

El formato es trivial; los exportadores son donde algo falla. Las tres vías más habituales:

Hojas de cálculo de Google. Direcciones en la columna A, importes en la columna B y nada más en la hoja: ni fila de título ni columna de notas. Da formato de número simple a la columna de importes (Formato → Número → Número, y quita la visualización del separador de miles; mejor aún, Formato → Número → Texto sin formato tras introducir los valores con punto decimal). Exporta con Archivo → Descargar → Valores separados por comas (.csv). Google exporta lo que ves: si la columna muestra 10,000, esa coma acaba en tu archivo.

Excel. La variable peligrosa es la configuración regional del sistema: en muchos sistemas europeos, incluido el español, Excel escribe un «CSV» separado por punto y coma con coma decimal, un archivo que parece correcto y se interpreta mal. Dos soluciones: o configuras el punto como separador decimal en el libro (Opciones → Avanzadas → desmarcar «Usar separadores del sistema»), o evitas la trampa por completo y subes el propio .xlsx, que la dApp acepta con la misma estructura de dos columnas.

Todo lo demás (Notion, Airtable, un volcado de base de datos): exporta lo que produzca la herramienta y luego pasa las dos columnas una vez por un editor de texto plano. Eso elimina comillas tipográficas, caracteres invisibles y restos de texto enriquecido de un solo golpe: diez segundos que a menudo ahorran una nueva subida.

Sea cual sea la vía, abre el archivo final una vez en un editor de texto, no en una hoja de cálculo. Lo que veas ahí —comas, puntos, sin comillas, sin encabezado— es exactamente lo que verá el analizador.

Los siete errores clásicos

Años de conversaciones de soporte se resumen en esta lista:

1. Coma decimal. Las hojas de cálculo en muchas configuraciones regionales (casi toda Europa, España, Latinoamérica, Brasil y más) escriben 1,5 para uno y medio. En un archivo separado por comas eso se lee como dos columnas: un importe de 1 y basura detrás. Configura la columna de importes con punto decimal antes de exportar.
2. Separadores de miles. 10,000 se divide en columnas de la misma forma fatal; 10 000 con espacio falla al interpretar el número. Los importes deben ir limpios: 10000.
3. Una fila de encabezado olvidada. address,amount en la primera línea. Bórrala.
4. Espacios y caracteres invisibles. Las direcciones copiadas de chats, Telegram o páginas web llegan envueltas en espacios, tabulaciones o caracteres de ancho cero. El validador las marca, pero recortar la columna antes en tu hoja te ahorra volver a subir el archivo.
5. Valores entre comillas. Algunos exportadores envuelven cada celda en comillas ("TAbc...","100"). La mayoría de analizadores lo toleran, pero las comillas mezcladas o sueltas (una comilla dentro de una dirección) rompen líneas de forma impredecible. Exporta CSV simple, sin comillas.
6. Direcciones de otra red. Una dirección de Ethereum 0x… o un memo de exchange pegado en la columna de direcciones. Las direcciones TRON empiezan por T y tienen 34 caracteres; cualquier otra cosa no puede recibir tokens TRC-20 y será marcada.
7. Erratas en base58. Una dirección editada a mano con un carácter incorrecto suele fallar la suma de verificación y quedar marcada: es el validador funcionando según lo previsto. El caso peligroso es una dirección válida que pertenece a la persona equivocada, y eso no lo detecta ningún software: para eso está la pantalla de revisión.

Revisa el archivo antes de enviar

Una comprobación previa de noventa segundos que lo detecta casi todo:

1. Ordena por la columna de direcciones en tu hoja: los duplicados quedan juntos y saltan a la vista, y las entradas mal formadas se van al principio o al final.
2. Comprueba el número de filas frente a cuántos destinatarios esperas. Una de más o de menos suele significar una fila de encabezado o una línea vacía al final.
3. Suma la columna de importes y anota el total. Tras subir el archivo, la dApp muestra el total interpretado en la pantalla de revisión: ambas cifras deben coincidir exactamente. Si difieren, se ha colado un problema de decimales o separadores.
4. Repasa la lista interpretada en la dApp. La validación ya habrá marcado direcciones mal formadas y duplicados; tu tarea es la revisión humana: ¿los nombres, importes y total se parecen al pago que querías hacer?
5. ¿Primera vez con esta lista? Envía un pequeño lote de prueba a unas pocas filas antes del envío completo, como recomienda la guía paso a paso. Las transferencias on-chain son irreversibles; el ensayo es el único botón de deshacer.

FAQ

¿El archivo necesita un nombre o una codificación concretos? Ningún nombre en particular. Usa UTF-8 simple (lo que exporta cualquier hoja de cálculo por defecto). Evita editores que añadan una marca de orden de bytes (BOM) o conviertan el archivo en texto enriquecido.

¿Puedo usar XLS/XLSX en lugar de CSV? Sí: la dApp acepta CSV, XLS y XLSX con la misma estructura de dos columnas, y también puedes pegar la lista como texto. CSV sobrevive al paso entre herramientas con menos sorpresas, por eso las plantillas se distribuyen en ese formato.

¿Cómo pongo distintos tokens en un mismo archivo? No se puede: un archivo es una distribución de un solo token. El token se elige en la dApp antes de subir el archivo; para tokens distintos, ejecuta lotes separados.

¿Hay un límite de tamaño del archivo? En la práctica, no: las listas de más de unos 150 destinatarios simplemente se procesan como varias transacciones por lotes consecutivas dentro de un mismo flujo. La calculadora de comisiones muestra los costes para cualquier tamaño de lista, y la guía completa cubre todo el proceso de envío en torno a este archivo.