Blog · 5 de noviembre de 2026

Barrido de USDT desde direcciones de depósito en TRON: activación, energía y ancho de banda por barrido

Una pasarela de pagos o un exchange que da a cada cliente una dirección de depósito propia tiene que reunir el USDT TRC-20 de esas direcciones en una cartera principal, la cartera caliente, antes de poder pagar nada de él. En TRON cada uno de esos movimientos es una transferencia USDT corriente, firmada por la dirección de depósito. Necesita una cuenta en la cadena, energía para la llamada al contrato y ancho de banda para los bytes, y una dirección de depósito a la que solo se ha pagado en USDT no tiene ninguna de ellas.

Recibir USDT no crea una cuenta

Un saldo de USDT es una entrada en el almacenamiento del propio contrato del token. Una transferencia entrante escribe esa entrada y no crea ninguna cuenta, así que una dirección puede tener USDT mientras la red no tiene ninguna cuenta para ella. Nuestra medición del 7 de septiembre de 2026 encontró dos direcciones así en mainnet: cada una tenía USDT, y el nodo del que leímos devolvió un objeto vacío al preguntar por la cuenta que había detrás, tanto antes de nuestra llamada de prueba como después. El 27 de octubre las dos seguían teniendo exactamente los saldos que tenían el 7 de septiembre.

La energía se delega a una cuenta, y no la entregamos a una dirección que no la tiene: un pedido en el mode A o en el mode C que nombre una dirección así como from vuelve como 422 invalid_address con details.reason en inactive_wallet. Si la propia cadena aceptaría una delegación a una dirección así no lo hemos probado, porque nuestro rechazo va primero. Nuestras notas de operaciones también registran la respuesta del nodo a un envío desde una cartera que nunca ha recibido nada, no OwnerAccount. Esa nota es sobre TRX enviado desde nuestra propia cartera caliente; no hemos probado una transferencia USDT desde una dirección en este estado. La historia más amplia de este estado está en la entrada sobre las cuentas no activadas.

Activar una dirección exige una transferencia de TRX, que paga el remitente

Cualquier transferencia entrante de TRX crea la cuenta, por pequeña que sea, y desde ese momento la dirección es una cuenta como cualquier otra. El primer intento de esa medición salió mal justo por eso, y lo descartamos: una dirección se leyó sin cuenta, y 22 segundos después alguien le envió un solo sun, lo que creó una. Su propia hora de creación lo decía.

La comisión por crearla recae en quien envía el TRX: en una configuración de barridos, la cartera que financia las activaciones. La fijan dos parámetros de la cadena. Los leímos el 3 de septiembre de 2026, y la red puede cambiarlos, así que vuelva a leerlos antes de presupuestar con ellos.

Cómo se combinan los dos en una transferencia de TRX simple no lo hemos medido con un envío propio: eso exige una transferencia real a una dirección nueva, y no hemos hecho ninguna. En cualquier caso, la comisión se paga una vez por dirección. Una mesa que activa cada dirección cuando se genera la paga en direcciones que quizá nunca vean un depósito, y una que activa en el primer depósito la paga solo donde hay algo que barrer.

Todo barrido toma la cifra de energía más baja

Lo que una transferencia USDT gasta en energía depende del destinatario. Cuando el destinatario ya tiene USDT, la transferencia toma unas 65,000 unidades; cuando su saldo de USDT es cero, toma unas 131,000. Que el destinatario tenga o no una cuenta no interviene. La medición que encontró esas dos direcciones puso las cuatro combinaciones una junto a otra, y el saldo decidió siempre (por qué hay dos cifras).

Un barrido paga siempre al mismo destinatario, la cartera caliente, y la cartera caliente tiene USDT. Así que todo barrido es del tipo más barato, single, sea cual sea el estado de la dirección de depósito. Las llamadas del 7 de septiembre movieron una unidad de una cartera que se quedó con el resto, mientras que un barrido lo mueve todo y deja la dirección de depósito en cero. El 27 de octubre pedimos al nodo que simulara ambas cosas en las mismas dos direcciones, con una cartera que tenía USDT como destinatario.

Vaciar la dirección de depósito no cambió nada, y la cifra es la que dio esa medición para toda transferencia a un destinatario con USDT. Son simulaciones del nodo, y ninguna es el recibo de un barrido emitido; las cifras del 7 de septiembre llevan la misma salvedad. Si las dos direcciones tienen hoy una cuenta no lo volvimos a leer.

La única forma de perder el tipo más barato es vaciar la cartera caliente. Una sola unidad de USDT en el destinatario basta para la cifra más baja, pero en cero el siguiente barrido hacia ella toma unas 131,000 unidades, que son 13.1 TRX si se queman. Quemado, un barrido normal cuesta 6.5 TRX a la tarifa del protocolo de 100 sun por unidad, y lo que cuesta alquilar esa misma energía se mueve con el mercado.

El ancho de banda gratis cubre más o menos un barrido por dirección al día

El ancho de banda mide los bytes de una transacción, donde la energía mide su cómputo (los dos contadores, lado a lado). Toda cuenta recibe una asignación diaria gratuita de él. La transferencia USDT que enviamos y medimos en mainnet el 2 de septiembre de 2026 pagó su ancho de banda en TRX, y eso da con exactitud cuánto ancho de banda se le facturó.

Frente a los 600 diarios, cabe un barrido facturado con esa cantidad y dos seguidos no. Pasada la asignación, la red quema el TRX del remitente por los bytes. Así que el primer barrido de una dirección en un día no cuesta nada de ancho de banda, y una dirección de depósito que además recibe su energía por delegación no necesita TRX propio para enviarlo. Un segundo barrido poco después del primero paga sus bytes con el TRX de la dirección de depósito. Con qué rapidez se recupera la asignación entre los dos no lo hemos medido; nuestro propio barrido cuenta con aproximadamente una transferencia al día por dirección con cargo a la asignación gratuita. Si una dirección va a barrerse más a menudo que eso, la transferencia de activación puede dejarle al mismo tiempo el TRX para esos bytes.

Pedir la energía para una tanda de barridos

El mode A nombra los dos extremos de cada transferencia, la dirección de depósito como from y la cartera caliente como to, y el tipo lo leemos nosotros de la cartera caliente. El mode C nombra solo la cartera a la que dar energía y toma el tipo de usted, lo que conviene a un sistema de custodia que firma sus barridos según su propio calendario y quiere tener la energía esperando antes (el mode C en detalle). Para un barrido ese tipo es siempre single, mientras la cartera caliente tenga USDT. Los dos modos admiten hasta 500 transferencias en un pedido, el mismo techo que una tanda de pagos. El alquiler es de cinco minutos o de una hora, y send_before cae tres segundos antes de su final.

Una sola dirección de depósito sin cuenta hace que se rechace el pedido entero. El 422 la nombra en details.index y details.address, y no se compra nada. Así que filtre primero la tanda. POST /v1/estimate admite las mismas 500 transferencias y no reserva nada, y avisa donde el pedido rechazaría: dele from en cada ítem, y toda dirección de depósito sin cuenta vuelve marcada como inactive_sender. Actívelas, deje que las activaciones se confirmen y envíe el pedido. El rechazo no gasta la Idempotency-Key, y volvemos a leer la activación saltándonos la caché antes de rechazar un pedido por ella, así que la misma clave y el mismo cuerpo valen en cuanto se confirma la transferencia de activación.

Reglas que vale la pena tomar de nuestro propio barrido

Operamos un barrido propio. Los clientes pagan a direcciones de depósito que mantenemos para ellos, y una pasada en segundo plano mueve esas monedas a la única cartera caliente que paga las compras. Mueve TRX, así que gasta ancho de banda y nada de energía, y sus registros no dicen nada del lado de energía de un barrido de USDT.

Nuestro barrido lee la cantidad de la cadena en el momento en que decide. Nuestros propios registros no saben de una comisión que se quemó, ni de un barrido cuya fila en la base de datos no sobrevivió a un proceso caído, y la cadena sí. La misma regla hace segura una repetición: si las monedas ya han salido, no hay nada que enviar.

Mantenemos abierto un barrido emitido hasta que su transacción aparece en un bloque, y lo damos por fallido solo tras una ventana no más corta que la caducidad más larga que nuestro firmante pone a una transacción. Si se cierra antes, una transferencia que aún puede llegar se cuenta como perdida, y la siguiente pasada puede firmar una segunda transferencia del mismo saldo. Mientras un barrido está sin confirmar, su dirección queda fuera de la siguiente pasada.

Nuestro barrido de TRX envía como máximo el saldo menos una reserva para comisión, y conserva esa reserva solo cuando el ancho de banda gratuito de la dirección ya está gastado. Un barrido de USDT paga su comisión en una moneda distinta de la que mueve, así que todo el saldo de USDT sale siempre, y la reserva pasa a ser el TRX que una dirección de depósito necesita para los bytes de un segundo barrido en un día.

Encuentre todas las direcciones de depósito que aún necesitan activarse antes de valorar el barrido, quinientas por petición: POST /v1/estimate con from en cada ítem →