Cuánto dura en realidad la energía TRON alquilada
Pregunte cuánto dura la energía TRON alquilada y las respuestas no pueden ser todas ciertas: se va en cuanto confirma la transacción; vuelve al cabo de una hora; se queda en la cartera tres días; dura hasta que el vendedor decida recuperarla. Cada una es la respuesta correcta a una pregunta distinta, porque sobre una delegación alquilada corren tres relojes separados y solo uno de ellos es el que la gente quiere decir. Aquí están, cada uno por su lado. La respuesta corta, si solo quiere una: lo que la delegación se quede en la dirección, que en nuestros pedidos son 300 segundos, con todos ellos menos los tres últimos para enviar, y en la mayoría de los vendedores una hora. Pero un plazo no es más que una promesa hasta que hay un bloqueo detrás, y el bloqueo es el reloj que responde de verdad a la pregunta.
Tres relojes
El primero es comercial: el plazo que le vendió el vendedor, que es una cifra en una tarifa y nada más. El segundo es de la cadena: el bloqueo, que es lo único en el protocolo que impide al vendedor recuperar la delegación antes de tiempo. El tercero es del propio recurso: la energía gastada se recupera a lo largo del día siguiente, sea quien sea la cuenta. Son independientes —un vendedor puede vender una hora y no bloquear nada— y la mayoría de las respuestas contradictorias sobre el asunto son alguien contando uno de los tres como si fuera los tres.
El plazo que vendió el vendedor
Los plazos son una decisión de producto, y la horquilla es amplia. De las diecisiete tarifas que leyó nuestro seguimiento del mercado el 7 de septiembre de 2026, dieciséis cotizaban un arrendamiento de una hora y una cotizaba tres días. Los precios detrás de esos plazos, cada uno sellado con el momento en que se leyó, están en la página del mercado; el arrendamiento es la descripción de producto que pone el propio vendedor detrás de ellos. El nuestro es de 300 segundos, que es corto a propósito: crear una delegación no cuesta nada y terminarla tampoco, así que comprar una hora de energía parada para gastar cinco segundos de ella es comprar almacenamiento.
Lo que eso significa para un pedido es un solo campo. Cuando la energía queda confirmada en la dirección que envía, la respuesta lleva send_before: el momento en que se cierra la ventana de entrega, tres segundos antes de que acabe el arrendamiento. Esos tres segundos son aritmética y no protección: hacen que la ventana termine antes que el arrendamiento y nada más. La red fecha el arrendamiento por el bloque que llevó la delegación y nosotros lo fechamos por el momento en que vimos esa delegación confirmada, y entre esos dos instantes hay un sondeo de distancia, así que una transferencia enviada en los últimos segundos de la ventana puede llegar a la cadena cuando la energía ya se ha ido a casa y quemar TRX por ello. Envíe con la señal y no con el plazo: send_before es la cifra con la que hay que planificar, no el arrendamiento ni el reloj de la pared (cómo envía una cartera con energía alquilada recorre el resto de ese flujo).
El bloqueo, y lo que un plazo no hace
Un plazo en una tarifa es una promesa; el mecanismo es lock=true en la delegación. Sin él el vendedor puede retirar la delegación en cualquier momento, un derecho que los vendedores de alquiler corrientes se guardan, porque recuperar es como revenden. Las filas de un pool de vendedor en mainnet, leídas el 3 de septiembre de 2026, no llevaban clave de vencimiento alguna, y al día siguiente el nodo construyó a petición una retirada contra una de sus delegaciones vivas — y una retirada ya construida está a una sola emisión de volver a casa.
Donde hay bloqueo, es exacto. El periodo se cuenta en bloques de tres segundos, por defecto son 86,400 de ellos —tres días— cuando se omite, y en mainnet el 3 de septiembre de 2026 el techo estaba en 864,000 bloques, o treinta días.
Se puede alargar y nunca acortar, y mientras aguanta no hay salida ninguna: aquel día un nodo de mainnet rechazó por igual un periodo de un bloque y uno de cuatro horas —lo que un bloqueo nuevo tiene que superar no es la duración del viejo sino el tiempo que todavía le queda— y rechazó la retirada de plano, sin que el saldo bloqueado contara nada; dos ejecuciones en la red de pruebas Nile el 4 de septiembre de 2026 se llevaron los mismos rechazos contra bloqueos propios, y luego vieron la retirada aceptada en cuanto pasó el vencimiento, a los cinco minutos y a las cuatro horas. La entrada sobre la delegación en sí trae las respuestas del nodo palabra por palabra. Así que la forma honrada de la pregunta es cuánto tiempo no le pueden quitar la energía, y la respuesta a esa es el bloqueo. Un plazo sin bloqueo detrás dura lo que dure el interés del vendedor en dejarlo en paz.
El ciclo diario que hay debajo
El tercer reloj es del propio protocolo. El límite de energía de una cuenta es una asignación, no un saldo: gastar energía no resta del límite, sino que sube un contador de gastado contra él, y ese contador se vacía a lo largo de las veinticuatro horas siguientes. De ahí sale el «vuelve al cabo de una hora»: es más o menos la pinta que tiene una asignación gastada a medias en una cuenta que puso su propio TRX en staking. Para un alquiler eso importa de una sola manera, y es la contraria de la evidente. El contador pertenece a la cartera, no a la delegación, y no se pone a cero cuando la delegación se va a casa: una cartera que acaba de gastar 65,000 unidades las arrastra contra su límite el resto del día. Un plazo de cinco minutos es alrededor de una tricentésima parte de ese día de recuperación, así que casi nada de él se vacía antes del pedido siguiente. Por eso un segundo alquiler tiene que cubrir lo que gastó el primero en vez de entregar otra vez lo mismo — y por eso lo que leemos en la dirección antes de cobrar es la energía disponible, el límite menos lo gastado, y no el límite. En el otro extremo del mercado el ciclo es casi todo lo que se está vendiendo: un arrendamiento de tres días sobre una cartera que hace un puñado de transferencias al día compra la recuperación tanto como la delegación.
«Gastada» no es «desaparecida»
Una transferencia no consume la delegación. La energía se gasta contra el límite; la delegación que subió el límite es una fila entre dos direcciones, y quien gasta no la toca. Termina cuando quien delegó retira la delegación o, con un bloqueo encima, no antes del vencimiento — así que una cartera que acaba de quemar su límite entero sigue teniendo la delegación, y una que no ha gastado nada no tiene más delegación que ella. Por eso el final de un alquiler significa dos cosas distintas según quién mire: la energía se entregó cuando apareció en la dirección, y si se usó o no es un hecho aparte.
Un camino que no hemos medido: qué le hace a una delegación asentada en una cartera el propio staking de esa cartera. Si retira su staking o delega hacia adelante a mitad del plazo, el código del actuador sugiere que hay algo que encontrar, y no lo hemos ejecutado.
Cómo se ve en un pedido el final del plazo
Una posición que llega al cierre de su ventana sin usarse termina como expired, y eso no es un fallo. No lleva error, porque no salió nada mal: la energía se compró, se delegó, se confirmó en la dirección y se mantuvo ahí toda la ventana, y usted no envió. El cobro se mantiene en el mode A exactamente por eso —lo que se vende es energía entregada, no su acto de enviar— y en el mode C, donde se cobra por una cartera antes de que se conozca destinatario alguno, expired es el final normal y no una excepción.
El mode B es el único caso en que una ventana cerrada es nuestra y no suya. Ahí el envío forma parte del servicio: si no hemos emitido su transacción firmada para cuando llega send_before, la posición cierra como failed con broadcast_window_missed y la reserva entera vuelve. Tampoco emitimos tarde, y eso es deliberado y no puntilloso: una transferencia retransmitida después de que la delegación se haya ido quemaría el TRX que nos contrataron para ahorrar. Lo que cada uno de esos estados le hace a una factura está en la página de precios, y las respuestas cortas están en las preguntas frecuentes.
Cuando una cartera necesita energía todo el día
Nada de esto tiene buena forma para una cartera caliente. Un arrendamiento largo que cubra un día de envíos impredecibles paga también las horas muertas; uno corto por transferencia significa un pedido por transferencia. Una regla de Auto-refill es la tercera opción: una dirección y un presupuesto diario, y a partir de ahí cada transferencia que hace la cartera va seguida de una recarga que la devuelve a unas 131,000 de energía, facturada cuando esa energía se ve en la red y no cuando algo la reporta. Una cartera parada no gasta nada, porque no necesitó nada —el presupuesto del día se reserva, no se cobra— y el plazo deja de ser algo con lo que haya que planificar.
Cómo leer usted mismo el plazo que queda
Nada de lo de aquí hay que darlo por bueno a ciegas, porque todo está en la cadena. La delegación entre las dos direcciones es una fila propia, y el campo que responde a toda esta entrada es expire_time_for_energy, una marca de tiempo en milisegundos en la fila de ese par. Una clave ausente significa que no hay bloqueo, no un bloqueo de longitud cero, y es la lectura honrada de la mayoría de los alquileres minoristas.
El vencimiento se sella a partir de la cabecera del bloque anterior y no de la del bloque de la propia delegación, que es la razón por la que la entrada sobre la delegación en sí dice que hay que leer esa cifra y no calcularla nunca. La otra mitad de la respuesta es la cuenta misma: el límite de energía que subió cuando llegó la delegación, y los campos que desaparecen —no se ponen a cero, desaparecen— en cuanto se la llevan.