Transferencia muchos a muchos en Solana

Hay tres formas de mover muchos pagos a la vez en Solana y se confunden constantemente. Un multi-sender paga una lista desde una billetera. Un collector recoge muchas billeteras en una sola. Y luego está el caso que ninguna de las dos sabe expresar.

Una transferencia muchos a muchos en Solana mantiene cada emisor con su propio destinatario. La billetera 7 paga a la billetera 7, la 8 a la 8, y ninguna de las dos sabe de la otra.

Suena a detalle menor. En realidad es la diferencia entre tener una sola fuente de fondos y tener cuarenta fuentes completamente independientes entre sí.

• Una fila es una transacción. La billetera emisora de esa fila paga todo lo que hay en ella.
• Comisión de plataforma 0,001 SOL por transferencia, comisión de red 0,000005 SOL.
• Un destinatario que nunca tuvo ese token añade 0,00203928 SOL de depósito de rent.
• Las filas que no pasan se saltan, no se recortan.

Tres formas de transferencia masiva

La herramienta de envío múltiple es uno a muchos. Una billetera, una lista de destinatarios, un pagador. Esa es la forma para un airdrop.

El recolector por lotes es muchos a uno. Veinte billeteras, un destino, y al final todo queda en un sitio.

La herramienta de muchos a muchos es la tercera forma y la única que entiende de pares. La fila uno tiene su propia fuente, la fila dos otra distinta. Sin caja común y sin compensación entre filas.

Lo que cuesta una fila

En una fila pueden aparecer tres partidas, y la billetera emisora de esa fila paga las tres. No hay cuenta de financiación compartida, así que una billetera que no cubre su propia fila no toma prestado de la de arriba. La partida de red es la comisión base de 5.000 lamports por firma que detalla la documentación de comisiones de Solana.

Partida	Modo SOL	Modo token
Comisión de plataforma	0,001 SOL	0,001 SOL
Comisión de red	0,000005 SOL	0,000005 SOL
Cuenta de token del destinatario	no aplica	0,00203928 SOL, y solo si ese destinatario nunca tuvo este token

Lee la tercera fila dos veces, porque es la que sorprende. Enviar un token SPL a una dirección que nunca lo ha tocado significa crear una cuenta para guardarlo, y Solana cobra un depósito de rent por esa cuenta. El depósito es unas doscientas veces la comisión de red y el doble de la de plataforma.

Con cien destinatarios nuevos son unos 0,204 SOL de la factura, mientras la comisión de plataforma se queda en 0,1. El depósito no se quema: se queda en la cuenta de token del destinatario y vuelve a quien cierre esa cuenta más adelante.

Las filas que se saltan

Antes de firmar corren dos comprobaciones, y las dos detienen la fila en lugar de cambiarla.

La primera es aritmética simple. Si la billetera emisora no cubre su importe más las comisiones más cualquier cuenta de token que haya que abrir, la fila se marca y se deja en paz. No sale nada a medias.

La segunda es más extraña y merece entenderse, porque la primera vez parece un fallo. Solana no permite dejar una cuenta con saldo por encima de cero pero por debajo del mínimo exento de rent. Para una billetera corriente ese mínimo es 0,00089088 SOL, y sale de la fórmula que recoge la documentación de cuentas de Solana.

Vaciar una cuenta del todo está permitido. Dejar 0,0005 SOL dentro no lo está. Una fila que empuja a la billetera a ese hueco se marca como rent dust y se queda sin enviar.

Por qué no recortar el importe y ya

La alternativa sería ir rebajando el importe hasta que quepa, y eso es peor. Tú escribiste una cifra. Una herramienta que envía otra cifra sin decírtelo es una herramienta contra la que después no puedes cuadrar una hoja de cálculo.

Envía el saldo entero, o baja el importe hasta que el resto supere el mínimo. La vista previa te dice de antemano qué filas están afectadas, y la herramienta consulta todas las cuentas de destino en una sola llamada antes de firmar nada.

Una transacción por fila, y por qué importa

Como cada fila es su propia transacción, una fila fallida cae sola. En un lote que mete todo en una transacción, un error en la fila 30 se lleva por delante las 29 anteriores.

Eso tiene un coste: cuarenta pares son cuarenta firmas y cuarenta comisiones de plataforma. A cambio obtienes un resultado que se lee fila por fila. Quien quiera saber a qué velocidad entran esas transacciones tiene los números en el artículo sobre la comisión de prioridad.

Cuándo una transferencia muchos a muchos en Solana es la forma correcta

La rotación de billeteras es la respuesta honesta para la mayoría. Tienes un conjunto de billeteras con un historial que prefieres dejar atrás, generas uno nuevo con el generador de billeteras por lotes, y quieres que la vieja 7 financie a la nueva 7 y nada más.

El segundo caso es una lista de pagos donde el pagador cambia en cada línea. Varios proyectos, varias tesorerías, una sola hoja. Un multi-sender no puede expresarlo en absoluto, porque tiene exactamente una fuente.

El tercero es la redistribución tras un snapshot, donde cada holder cobra desde una billetera que ya le has asignado. Cómo leer esa distribución antes de repartir está en la guía para leer la distribución de holders.

Cómo preparar la lista

Haz la primera pasada con dos filas. La tabla de resultados te dice lo que costó una fila de verdad, incluidos los depósitos de cuenta de token, antes de que envíes dos mil.

Comprueba además si tus destinatarios ya tienen el token. En una lista donde la mitad son holders existentes, la partida de depósitos se reduce a la mitad, y con cien filas esa es la cifra más grande de toda la factura.

Y anota antes qué billetera paga qué fila. Después de la ejecución esa correspondencia cuesta más de reconstruir de lo que parece ahora, sobre todo si las emisoras son nuevas y todavía no tienen historial por el que reconocerlas.

Un último detalle sobre el saldo: deja en cada emisora algo por encima de su importe. Si la ajustas al céntimo, la comprobación de rent te apartará la fila y tendrás que volver a fondearla, que es más lento que haber dejado margen desde el principio.

Lo que cambia cuando la lista crece

Con diez filas todo esto es teoría cómoda. Con dos mil, dos cosas se vuelven el trabajo de verdad, y ninguna de las dos ocurre dentro de la herramienta.

La primera es fondear. Cada emisora necesita su importe más las comisiones antes de que empiece nada, y no hay forma de que una fila cubra a otra. Eso significa una pasada previa de reparto, normalmente desde una tesorería, y conviene hacerla con margen en lugar de al céntimo.

La segunda es la conciliación posterior. Con cuarenta filas miras la tabla y ya está. Con dos mil quieres el resultado exportado y cruzado contra la hoja de origen, fila por fila, porque las que se saltaron no aparecen en el explorador: no existen como transacción.

Hay un tercer efecto menos evidente. Si tu lista mezcla destinatarios nuevos y existentes, el coste por fila no es constante, y una media calculada sobre las primeras diez filas te dará un número que no se parece al total. Cuenta cuántos destinatarios abren cuenta y multiplica solo esos por 0,00203928 SOL.

Preguntas frecuentes sobre la transferencia por pares

¿En qué se diferencia de ejecutar el multi-sender varias veces?

El multi-sender tiene exactamente una fuente por ejecución. Cuarenta fuentes son cuarenta ejecuciones y cuarenta cambios manuales de billetera. Aquí es una ejecución con cuarenta filas.

¿Cuesta algo una fila fallida?

No. Una fila que no pasa la comprobación previa nunca se firma, así que no hay comisión de red ni de plataforma.

¿Pueden solaparse emisores y destinatarios?

Sí. Una billetera puede enviar en una fila y recibir en otra. Cada fila se comprueba por separado.

¿Por qué mi fila salió marcada como rent dust?

Porque el resto en la billetera emisora habría quedado entre cero y 0,00089088 SOL. Envía el saldo entero o baja el importe.

¿Necesito SOL en una billetera que solo envía tokens?

Sí. La comisión de red y la de plataforma se pagan en SOL aunque la transferencia sea de un token.

¿Hay un máximo de pares?

En la práctica te limita la preparación, no la herramienta: cada billetera emisora tiene que estar fondeada antes.

En resumidas cuentas

Si tu hoja tiene una columna para el pagador, esta es la forma que necesitas. Si todas las filas salen de la misma billetera, usa el multi-sender y paga una vez en lugar de cuarenta. Y si te falta una fila, mira primero el mínimo de rent antes de suponer un fallo. Sobre ese mínimo hay más en la explicación del error insufficient funds for rent.