Blog · 7 de noviembre de 2026

Mantener con energía una cartera de pagos: staking, alquiler por transferencia o recarga tras cada una

Una cartera de pagos en TRON gasta energía en cada transferencia USDT que envía: unas 65,000 unidades cuando el destinatario ya tiene USDT, unas 131,000 cuando no tiene. Cuando falta la energía, la red toma TRX en su lugar, a 100 sun por unidad, lo que da 6.5 TRX o 13.1 TRX por transferencia, y el pago se confirma igualmente mientras la cartera tenga ese TRX y el fee_limit de la transacción permita la quema (todo el cálculo). Así que el trabajo de una cartera caliente es tener la energía a punto antes de cada envío sin que nadie la pida a mano. Tres patrones hacen ese trabajo, y cada uno falla a su manera.

Un staking se dimensiona para el día más intenso y se paga todos los días

Poner TRX en staking para tener energía compra una parte de un fondo diario fijo. La asignación diaria de una cartera es su staking multiplicado por el TotalEnergyLimit de la red dividido por el TotalEnergyWeight, y el 3 de septiembre de 2026 esa relación estaba en 180,000,000,000 entre 18,770,236,993: un poco menos de diez unidades de energía al día por cada TRX en staking. El divisor es el staking total de la red para energía, el suyo incluido, así que la cifra va cambiando de un bloque a otro (la fórmula desarrollada).

La energía gastada vuelve poco a poco durante las 24 horas siguientes. Una cartera que paga la mayor parte de su día en una sola tanda a mediodía necesita un staking que cubra esa tanda, y el staking sigue bloqueado también durante las horas tranquilas y los días tranquilos. Salir es lento también. En mainnet, el TRX que se saca hoy del staking se puede retirar catorce días después.

Cuando los pagos superan el staking, las transferencias que encuentran la asignación gastada queman TRX por la diferencia y, con TRX en la cartera y margen en fee_limit, se confirman igualmente. Nada devuelve un error, y la primera señal es una línea de quema en el historial de la cartera (qué pasa cuando el límite es demasiado bajo).

Alquilar por transferencia pone una espera delante de cada envío

El segundo patrón compra energía para cada transferencia según va llegando. Un pedido nombra la cartera de origen y el destinatario. La API responde 202, con la dirección del propio pedido en Location y el intervalo de consulta en Retry-After, y nosotros compramos la energía y la esperamos en la cartera. Cuando la delegación queda confirmada, el pedido lleva send_before, y esa es la señal de su código para enviar. La ventana es el alquiler menos tres segundos: 297 segundos en el alquiler de cinco minutos y 3,597 en el de una hora.

Por eso cada pago espera una compra y un bloque. Medimos esa espera en nuestros propios pedidos en los que el código del cliente hace el envío, desde el momento en que se creó el pedido hasta la última delegación confirmada en la cadena, durante los sesenta días hasta el 8 de septiembre de 2026.

Trece pedidos son una muestra pequeña, y la mayor parte es temprana. Siete son de la primera semana de pedidos reales, los más lentos de la muestra, y las semanas posteriores rondaron los tres o cuatro segundos. No hemos repetido la medición con una muestra mayor.

Una transferencia enviada antes de que llegue la energía quema a la tarifa completa, y una enviada después de send_before puede encontrar la energía ya ida y quemar igual. El TRX que quema no vuelve. La energía que se entregó y no se usó dentro de la ventana se cierra como expired y se cobra, porque se entregó (los tres relojes de un alquiler). Una cola de pagos que envía según su propio calendario tiene que rehacerse en torno a esa señal. Para una tanda de pagos conocida de antemano, un pedido en lote de hasta 500 transferencias reúne la espera en un solo sitio: primero se compra la energía de toda la tanda, y todas sus transferencias comparten un mismo send_before (cómo se ve un lote por dentro).

Una regla que recarga la cartera después de cada transferencia

El tercer patrón es una regla sobre la cartera, que vendemos como Auto-refill, el caso de la cartera caliente de enviar USDT sin tener TRX. Pide dos campos, address y daily_budget_trx, en una sola llamada a POST /v1/auto-refill-rules. Desde entonces la cartera se deja de nuevo en unas 131,000 unidades de energía después de cada transferencia que hace. Eso cubre cualquier siguiente transferencia, incluida una a una dirección que no tiene USDT. La regla no crea pedidos: GET /v1/orders lista solo los que usted hizo.

Una recarga se valora según lo que usó la transferencia anterior. Si esa transferencia gastó unas 65,000 unidades, la recarga se cobra a la tarifa single; si gastó unas 131,000, a la double. Las dos tarifas están en GET /v1/tariff bajo maintenance_price_trx. Son un precio propio y se mueven por separado de los precios de alquiler, y la tarifa que se cobra es la vigente cuando se confirma la recarga. La primera recarga de una regla nueva es siempre double: no hay una transferencia anterior por la que valorarla, y la cartera recibe de golpe las 131,000 completas.

El cobro espera a que la energía sea visible en la cartera en la cadena; que un proveedor diga que entregó no basta. Cada cobro llega como un evento maintenance.topup con rule_id, address, units y charged_trx, y como una línea charge en GET /v1/ledger. Una cartera que no envía nada no recibe recargas y no paga ninguna.

Cómo se detiene la recarga, y qué hace la cartera entonces

El presupuesto diario, daily_budget_trx, se reserva de su saldo disponible cuando la regla arranca y de nuevo al comienzo de cada día UTC, y es lo máximo que la regla puede gastar ese día. Las recargas se descuentan de esa reserva, y lo que queda de ella vuelve al saldo a medianoche UTC. El spent_today_trx de la regla muestra cuánto se ha gastado ya del día. Subir el presupuesto a mediodía añade la diferencia a la reserva y no abre un segundo día.

Cuando el presupuesto se agota, las recargas se detienen hasta el siguiente día UTC. Recibe un evento maintenance.budget_exhausted, con spent_today_trx y daily_budget_trx dentro, y la regla sigue active. Desde ese punto hasta medianoche, toda transferencia que la cartera no pueda pagar en energía quema TRX por la diferencia a 100 sun por unidad. Un presupuesto dimensionado para un día medio se agota en uno intenso.

Cuando su saldo no puede cubrir la reserva del día siguiente, la regla se detiene. Su status pasa a paused con paused_reason en insufficient_balance, y sale un evento maintenance.paused. Una regla en pausa nunca se reanuda sola, y un depósito no la reinicia: espera un PATCH /v1/auto-refill-rules/{rule_id} con {"status": "active"}, y una reanudación que el saldo aún no puede cubrir responde 402. Una pausa que usted mismo pone no lleva motivo, así que paused_reason distingue una regla que espera dinero de una que espera su decisión.

Un presupuesto por debajo de la tarifa double se rechaza con 422, details.reason en budget_below_topup_price y el mínimo en details.min_daily_budget_trx: la primera recarga es double, y una regla con un presupuesto menor se activaría y nunca podría pagarla.

Unas 131,000 unidades en la cartera cubren dos transferencias a direcciones que tienen USDT, o una a una dirección que no tiene. Una transferencia enviada antes de que haya llegado la recarga de la anterior puede encontrar menos de lo que necesita y pagar parte de su camino, o casi todo, en TRX. No hemos medido cuánto tarda en llegar la recarga después de una transferencia. Borrar una regla antes de que sus recargas hayan cubierto lo que pagamos por adelantado para esa cartera cuesta la parte sin cubrir, contando los pagos adelantados y los cobros a partir del 6 de noviembre de 2026; una pausa nunca lo cobra.

Un día de ejemplo, de tres maneras

Para poner los tres lado a lado, tomemos una cartera y un día: treinta pagos a direcciones que ya tienen USDT y diez a direcciones que no tienen. La quema y el staking son aritmética de la red. El precio del pedido y las tarifas de recarga son nuestros, leídos de GET /v1/tariff a las 21:46 UTC del 27 de octubre de 2026; los de hoy están en la página de precios.

A esa hora los pedidos salieron por menos que las recargas, y eso era lo habitual. En los treinta días de historial por horas hasta esa misma noche, las tarifas de recarga no cambiaron ni una vez, y un pedido de cinco minutos para la misma transferencia costó menos que su recarga en la mayoría de las horas.

Lo que una recarga cuesta por encima del pedido compra una cartera que ya tiene su energía cuando sale cada transferencia, y un techo infranqueable a lo que puede gastar en un día. El presupuesto, como un staking, tiene que cubrir el día intenso, pero lo que un día tranquilo deja de él vuelve al saldo a medianoche UTC. No tenemos una cifra de producción de cuántas recargas hace una regla en un día.

Configure una cartera de pagos para que se recargue sola con una petición y un presupuesto diario que usted elige: POST /v1/auto-refill-rules en la referencia de la API →