Cómo funciona la delegación de energía TRON
La delegación de energía TRON es una transacción y dos campos de cuenta. Una dirección que tiene TRX en staking para energía llama a delegateResource nombrando a un receptor, y desde ese bloque en adelante ese receptor puede gastar energía por la que nunca hizo staking, mientras quien puso el staking conserva hasta el último TRX que congeló. No se transfiere nada, no se aprueba nada del lado que recibe, ninguna clave cambia de manos. Es el mecanismo sobre el que se sostiene todo el mercado de alquiler de energía, y lo que sigue está leído de los propios actuadores de java-tron, de lecturas en vivo de mainnet y de dos ejecuciones con transacciones en la red de pruebas Nile el 3 y el 4 de septiembre de 2026.
Qué cruza y qué se queda
El TRX en staking nunca sale de la cuenta de su dueño: delegar lo mueve entre dos casilleros dentro de esa misma cuenta, del saldo congelado para energía a otro de delegado-para-energía. El TRON Power —el peso de voto— es la suma de los dos casilleros, así que prestar no le cuesta a quien hace staking ni un voto ni una recompensa de voto. Una cuenta de mainnet con staking leída el 3 de septiembre de 2026 lo enseña mejor que la fuente: emitía 3,080,000 votos teniendo sin delegar menos de la mitad de eso, con el resto prestado, y la cifra de TRON Power que el nodo daba para ella eran los dos casilleros sumados.
El receptor se lleva la otra mitad del trato: energía, y nada más. El campo que una delegación escribe en la cuenta que recibe no es un sumando del TRON Power, así que la energía prestada no trae voto consigo: el receptor de aquella misma lectura no tenía cifra alguna de TRON Power, y el nuestro en Nile tampoco.
Qué muestra la cuenta que recibe
Se mueven dos cifras. acquired_delegated_frozenV2_balance_for_energy sube por el importe delegado, y con él sube el límite de energía de la cuenta: el TRX delegado por el TotalEnergyLimit de la red dividido entre su TotalEnergyWeight, truncado. El 3 de septiembre de 2026 un receptor de mainnet con 31246 TRX en delegaciones de dos delegantes mostraba un límite de energía de 299,638, que es exactamente esa aritmética a la proporción que llevaba la red aquella tarde: 180,000,000,000 entre 18,770,236,993.
Ahí es donde se llevan la sorpresa los compradores de energía: una delegación está denominada en TRX, no en energía. El denominador es el peso total en staking de la red, se mueve en cada bloque, y una cifra medida en otro sitio no viaja: aquella semana el mismo staking valía en Nile unas 7.7 veces más energía que en mainnet.
El bloqueo y los cuatro rechazos
Por defecto una delegación se puede retirar en cualquier momento. lock=true en la llamada de delegación es lo que lo impide, y es lo único que lo impide. Lleva un parámetro, lock_period, contado en bloques de tres segundos: un campo que se lee como una duración y es un recuento, así que pedir 300 de ellos porque quería 300 segundos compra quince minutos, en silencio. Dejado a cero u omitido significa 86,400 bloques: tres días. El tope es un parámetro de la cadena, y en mainnet el 3 de septiembre de 2026 estaba en 864,000 bloques, o treinta días.
Un bloqueo se puede alargar y nunca acortar. Una segunda delegación al mismo receptor solo se acepta si su periodo es al menos el tiempo que queda por correr, y entonces reinicia el vencimiento de todo el saldo acumulado y no solo de la parte nueva, así que recargar una delegación bloqueada vuelve a bloquear todo lo que hay debajo. Todo lo demás lo rechaza la red. Estos cuatro rechazos volvieron de un nodo de mainnet el 3 de septiembre de 2026, dirigidos a un par con un bloqueo vivo de veinticuatro horas; el nodo ejecuta la validación del propio actuador mientras construye cualquiera de las dos llamadas, así que las cuatro respuestas son del actuador y no se firmó ni se envió nada:
- un bloqueo de un bloque encima del que estaba vivo —
The lock period for ENERGY this time cannot be less than the remaining time[86241000ms] of the last lock period for ENERGY!, que nombra lo que queda por correr, en milisegundos; - un bloqueo de cuatro horas encima del mismo — el rechazo idéntico. La prueba no es ser más largo que un bloqueo recién puesto, sino más largo que lo que queda;
- un bloqueo un bloque por encima del techo —
The lock period of delegate resource cannot be less than 0 and cannot exceed 864000!; - la retirada misma de la delegación —
insufficient delegateFrozenBalance(Energy), request=1000000, unlock_balance=0. No dice «menos de lo que pidió»: mientras el bloqueo aguanta, el saldo bloqueado no cuenta absolutamente nada.
Una construcción validada no es un bloque, así que se hizo lo mismo con un bloqueo propio. Dos ejecuciones en Nile el 4 de septiembre de 2026 tomaron un bloqueo, pidieron retirar la delegación de inmediato, esperaron a que el bloqueo se cumpliera y volvieron a pedirlo: rechazadas las dos veces con esa última frase carácter por carácter, aceptadas las dos veces una vez pasado el vencimiento, a los cinco minutos y a las cuatro horas. La ejecución larga zanjó además qué cuenta la unidad: entre las dos transacciones el reloj de las cabeceras avanzó 4,801 intervalos de tres segundos mientras la altura de bloque avanzaba 4,785, así que dieciséis intervalos no produjeron bloque y el bloqueo corrió igualmente sus cuatro horas. lock_period cuenta intervalos del reloj de bloques, no bloques que lleguen a producirse.
Terminar una, y ver que terminó
Quien delega llama a undelegateResource, y sin un bloqueo de por medio queda hecho en un bloque. Ninguna de las dos llamadas lleva comisión más allá del ancho de banda —los dos actuadores se cobran a sí mismos a cero—, que es lo que permite siquiera vender energía en unidades de minutos. Contra un bloqueo vivo no hay cancelación ni comisión que compre una salida; volver a delegar con lock=false tampoco lo es, porque eso escribe otra fila aparte y deja en pie la bloqueada.
El bloqueo se ve exactamente en un sitio: la fila de delegación de ese par, donde expire_time_for_energy es una marca de tiempo en milisegundos. Una clave ausente significa que no hay bloqueo, que es la pinta que tiene la delegación de un vendedor de alquiler corriente, y las filas de un pool de mainnet, leídas el 3 de septiembre de 2026, no llevaban clave de vencimiento alguna. Lea esa cifra en vez de calcularla: el actuador la sella a partir de la cabecera del bloque anterior, así que un cálculo hecho desde el bloque de la propia delegación se desvía un bloque, y uno hecho desde la marca de tiempo de la transacción se desvía una cantidad distinta cada vez. Las dos ejecuciones en Nile cuadraron con el valor guardado al milisegundo bajo la primera regla y con ninguna de las otras.
Cuando una delegación termina, los dos campos del receptor no se ponen a cero: desaparecen de la respuesta, y la fila de delegación vuelve vacía. Cualquier cosa que consulte una cuenta tiene que tratar lo ausente como cero, o seguirá mostrando energía que volvió a su dueño hace minutos.
Por qué la cartera que recibe no firma nada
Todo esto pasa del lado de quien delega: al receptor se le nombra en la transacción, se le escribe un campo en su cuenta, y no hay nada que aceptar, aprobar ni conectar, que es también el motivo de que una delegación no pueda llegar a lo que esa cartera guarda. Dos requisitos apuntan en el otro sentido: la dirección tiene que existir ya como cuenta, y no puede ser un contrato, cosa que el actuador rechaza de plano. Eso es lo que hace que la energía se pueda alquilar por API siquiera (qué es la energía y de dónde sale).
Qué construye el alquiler encima
Un vendedor de energía es una cuenta con staking y con costumbre de delegar: delega a la cartera desde la que usted envía durante un plazo, usted gasta la energía en una transferencia USDT, y él recupera la delegación. Los plazos cambian de un vendedor a otro; el nuestro es de 300 segundos, porque una transferencia tarda segundos. Un pedido responde con send_before, el momento en que se cierra la ventana de entrega, tres segundos antes de que acabe ese plazo, y ese campo, no el reloj de la pared, es el que hay que tener en cuenta.
Todo ello se ve mientras corre el plazo, que es la parte útil de alquilar en una cadena pública: la transacción de delegación sobre la cartera que envía, el límite de energía que subió en ella, y la fila entre las dos direcciones en cualquier explorador que lea el estado de delegación. La energía está en la dirección o no está, y el cobro es por lo primero (lo que eso cuesta ahora mismo). Una cartera que envía todo el día es el mismo mecanismo con horario: una regla de Auto-refill la rellena después de cada transferencia en vez de pedirle a usted que haga un pedido.
Dos cosas que no hemos medido, y las dos merecen decirse en voz alta. Una es qué le hace a una delegación asentada en una cuenta la propia actividad de staking de esa cuenta: si un receptor 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. La otra es una recarga: la fuente y la TIP-542 dicen las dos que una segunda delegación aceptada vuelve a bloquear todo el saldo que hay debajo, y no hemos pasado ninguna.