TRON Delegation API: Historical Action vs Current Position

A TRON delegation API query for an account pair is a position lookup, while a DelegateResourceContract record describes a historical action. The action’s balance field is denominated in SUN of TRX stake equivalent. It is not a receipt that the resource recipient received that amount of liquid TRX, and it is not itself a count of Energy units.

This read-only audit compares one actual historical record with a later query that returned an empty object. It includes a directed-pair check, exact unit conversion and an evidence worksheet. Success means reporting what each source supplied without turning an absent pair row into an invented balance or explanation.

Checked October 28, 2026 by the independent Tronscan News editorial team. AI assisted drafting and original diagrams. We inspected public transaction and query responses and tested the local audit below. We did not delegate or reclaim resources, sign a transaction, identify the account owners or test a resource-rental service. About & Standards describes our editorial and corrections policy.

1. Choose the TRON delegation API that matches the question

The GetDelegatedResourceV2 reference describes a Stake 2.0 lookup from fromAddress to toAddress. Those two fields define a direction. The query does not ask for every historical action involving either address.

The official resource-delegation guide explains that staking and delegation are separate operations. Delegation makes resource capacity available to another account while the original TRX remains staked with the delegator. It also distinguishes current Stake 2.0 actions from legacy Stake 1.0 records.

Our staked-versus-available balance guide provides the broader account-reading context. This article’s separate task is to validate the action-to-query comparison, not to create another generic balance lookup page.

Choose the question before selecting a TRON delegation API endpoint. If the intended task is historical reconstruction, a current pair lookup alone is insufficient. If the intended task is a current position check, one old transaction amount cannot replace a dated position response.

2. Inspect the actual historical action

The transaction body used here was retrieved from Mainnet on October 28 at approximately 04:47:05 UTC. It was the first transaction in one returned current block, not a representative sample of delegation behavior. The complete transaction ID is c9b38bc4f2cdce616d2b23e8d45e118438128fbc592d33e1c4f5a7f28cf931f2.

The body contained one DelegateResourceContract with the following selected fields. We retain full hex addresses for exact pair comparison; their appearance does not identify the people or organizations controlling them.

The DelegateResource field reference defines balance in SUN and distinguishes the resource and optional lock fields. We use that construction reference only to interpret field definitions; we did not call its transaction-construction endpoint.

The body reported contractRet SUCCESS. A separately retrieved solidified-state transaction-info response matched the ID and reported block 87,496,515. These are provider observations of a public record, not a transaction performed by this publication or an independent signature and consensus audit.

The selected body did not include explicit lock or lock_period members. This audit does not derive a cancellation time or current lock state from that omission. A later pair position and its history require their own scope and field checks.

3. Keep the TRON delegation API units separate

The exact conversion for the action is 6701000000 SUN / 1000000 = 6701 TRX of stake equivalent. The local program formats that as 6701.000000 so the six-decimal SUN scale remains visible.

Record the unit beside each TRON delegation API amount when copying it into a support note. A column labelled only balance is ambiguous: it might refer to an action amount, a current position, an account’s liquid asset or a resource counter. Changing the label can change the meaning even when the digits stay identical.

Do not attach a USD price to the resource quantity without defining what is being valued. This audit does not estimate a rental price, a payment-service fee or a market value for delegated capacity. It only converts the recorded stake-equivalent unit exactly.

4. Reproduce the directed TRON delegation API query

1. Confirm that the source record is a Stake 2.0 delegation action and retain its complete TxID.
2. Copy the full owner_address into fromAddress and the full receiver_address into toAddress. Do not reverse them.
3. Select the intended network endpoint. For this test we used Mainnet at https://api.trongrid.io/wallet/getdelegatedresourcev2.
4. Use visible false for the hex-formatted query shown here. Keep the request format beside the response.
5. Check both HTTP status and the response body, including any Error field.
6. Save the exact result and retrieval time before interpreting an empty or populated response.

Our request used this JSON body:

{
  "fromAddress": "4177a961eb2498cda471a30ec1aadc8e0823d328e7",
  "toAddress": "41ff7cc632de83f47a815982d41ec0e015a5dfebcc",
  "visible": false
}

The request began at 06:46:50 UTC on October 28 and returned HTTP 200 with the exact body {}. No pair row or amount was returned in that observation. The reference’s sample endpoint uses Shasta, so replacing its host with the intended Mainnet host was an explicit scope choice.

The empty TRON delegation API response does not tell us why no row was returned. We did not establish a later undelegation transaction, complete pair history, current account liquidity or an account owner’s intent. Retain the observed empty shape instead of inventing the missing explanation.

5. Test the local TRON delegation API audit

Save the historical transaction body as historical-body.json, the directed request as position-request.json and the response as delegated-position-source.json. Put this program in audit_delegation.py beside those files and run python audit_delegation.py. It reads local files only; it does not submit a delegation or connect a wallet.

import json
import re
from pathlib import Path

def hex_address(value):
    if not isinstance(value, str) or re.fullmatch(r"41[0-9a-fA-F]{40}", value) is None:
        raise ValueError("This sample requires a full 21-byte TRON hex address")
    return value.lower()

def audit_delegation(body, query, position):
    if not isinstance(body, dict) or "Error" in body:
        raise ValueError("Expected a transaction body")
    contracts = body.get("raw_data", {}).get("contract")
    if not isinstance(contracts, list) or len(contracts) != 1:
        raise ValueError("Expected one contract for this sample")
    contract = contracts[0]
    if contract.get("type") != "DelegateResourceContract":
        raise ValueError("This sample inspects delegation actions only")
    value = contract["parameter"]["value"]
    owner = hex_address(value.get("owner_address"))
    receiver = hex_address(value.get("receiver_address"))
    resource = value.get("resource")
    if resource not in ("ENERGY", "BANDWIDTH"):
        raise ValueError("An explicit resource label is required by this sample")
    amount = value.get("balance")
    if isinstance(amount, str) and amount.isascii() and amount.isdecimal():
        amount = int(amount)
    if type(amount) is not int or not 0 <= amount < 2**63:
        raise ValueError("Expected non-negative integer SUN")
    if query.get("visible") is not False:
        raise ValueError("This query uses hex address formatting")
    if hex_address(query.get("fromAddress")) != owner or hex_address(query.get("toAddress")) != receiver:
        raise ValueError("Query direction does not match the historical action")
    if not isinstance(position, dict) or "Error" in position:
        raise ValueError("Position query error or unexpected body")
    rows = position.get("delegatedResource", [])
    if not isinstance(rows, list):
        raise ValueError("Unexpected delegatedResource shape")
    whole, fraction = divmod(amount, 1_000_000)
    return {
        "historical_resource": resource,
        "historical_stake_sun": amount,
        "historical_stake_equivalent_trx": f"{whole}.{fraction:06d}",
        "pair_direction_matches": True,
        "position_rows_returned": len(rows),
        "position_interpretation": "no pair row returned" if not rows else "inspect returned rows separately",
        "current_liquid_trx": "not established by these records",
        "energy_or_bandwidth_units": "not calculated by this audit"
    }

if __name__ == "__main__":
    def load(name):
        return json.loads(Path(name).read_text(encoding="utf-8"))
    print(json.dumps(audit_delegation(load("historical-body.json"),
        load("position-request.json"), load("delegated-position-source.json")), indent=2))

For our saved sources, the program returned historical_resource ENERGY, historical_stake_sun 6701000000 and historical_stake_equivalent_trx 6701.000000. The pair direction matched, and position_rows_returned was zero. That last field counts returned rows; it is not a claim of zero liquid TRX or zero current resource capacity.

The output explicitly keeps current_liquid_trx unestablished and Energy or Bandwidth units uncalculated. Those are intentional boundaries. Removing them and relabelling the historical amount as a current wallet balance would defeat the purpose of the comparison.

This narrow example accepts full 21-byte TRON hex addresses and requires an explicit ENERGY or BANDWIDTH label. It does not convert Base58 addresses, infer a network from the prefix or implement every possible protocol-default interpretation. If another valid response omits a default-valued resource field, this sample declines to guess; consult that response’s exact schema and serialization rules.

The TRON delegation API audit’s positive-row path reports only that rows were returned and requires separate inspection. Our actual position response was empty, so we did not claim a live test of populated position fields. The example is not a complete position calculator, account-balance service or validator of all delegation rules.

All six local checks behaved as intended. The altered inputs were synthetic fixtures, not additional Mainnet responses or funded actions. The actual source comparison remains one historical action and one later empty pair-query response.

6. Troubleshoot a TRON delegation API mismatch

Wrong direction: compare the complete request addresses with the historical action before changing any other interpretation. A lookup from recipient to owner is not a second way to ask the original owner-to-recipient question.

Wrong network: record the exact host, not just the address format. The same address representation can appear in different TRON environments. A successful test-network query does not establish the Mainnet position.

Wrong staking generation: the selected action here is DelegateResourceContract and our query is the Stake 2.0 V2 lookup. The official delegation guide identifies separate legacy Stake 1.0 records and query paths. We did not perform a live legacy lookup, so do not extend this example to every older staking record without checking its type.

HTTP 200 with an error body: keep the error as a failed observation. Do not discard its Error field and report no delegation. Our actual empty response had no Error member; the synthetic error fixture exists to test that distinction.

No pair row: preserve the source and collection time, as we did here. Possible explanations require additional evidence. This audit does not attribute the absence to a particular reclamation, lock event, provider issue or account owner.

Populated rows: review the returned field definitions, resource type and lock scope before computing a total. This program does not interpret those live amounts. Keep the raw rows and mark that step unfinished instead of copying a historical action amount into the current-position column.

Different observation times: a historical action and a later query are expected to have different time scopes. Do not label their difference as a provider contradiction until the operation history and endpoint scope are known. A comparison can remain useful even when the reason for the later state is unresolved.

If a full sequence of actions is needed, use the transaction-history investigation guide and preserve exact contract types and dates. A current position response alone cannot supply that sequence.

7. Keep a TRON delegation API evidence worksheet

Use this original worksheet to document the next investigation. It is an on-page note template, not a downloadable statement or a proof of ownership. Complete it with your observed sources, retaining unknown fields explicitly.

Synthetic interpretation exercise: suppose someone copies the historical 6,701 TRX stake equivalent into a wallet’s available-balance column. The digits came from a real field, but the column now makes a different claim. Correct the label and identify the separate source required for liquidity instead of adjusting the number to look plausible.

Now suppose the later response is empty and the note says that the owner reclaimed all resources. That explanation might be a hypothesis, but the empty object does not establish it. Keep the observation as no pair row returned and identify the specific history records needed to test the hypothesis.

Finally, suppose a later request returns a populated row. Add that new observation and its date rather than overwriting the earlier empty response. The two source captures can coexist. A later result does not change what the earlier endpoint returned or explain the intervening actions by itself.

These exercises help separate a valid arithmetic conversion from an unsupported account-state conclusion. A note can contain a correct number and still be misleading if its unit, time scope or record type is wrong.

For a broader explanation of addresses and public records, start with our TRONSCAN guide. More English tutorials are available from the Tronscan News homepage. Choose the next source according to the unanswered question rather than treating every delegation figure as a wallet balance.

Frequently asked questions

Does a TRON delegation API action balance mean liquid TRX was sent to the receiver?

No. In the selected DelegateResourceContract, balance describes the SUN stake equivalent used for the resource delegation. It is not a plain TRX transfer receipt or proof of recipient liquidity.

Does 6,701 TRX stake equivalent mean 6,701 Energy units?

No. Those are different units. This audit converts the historical SUN amount into TRX stake equivalent and does not calculate current resource capacity.

Does an empty pair-query response explain what happened later?

No. Our response returned no pair row. It did not identify a cause, a later action or a current liquid balance. Further history and scope evidence would be needed.

Can I reverse fromAddress and toAddress for the same query?

No. That asks about the opposite direction. Match fromAddress to the historical owner and toAddress to the receiver when auditing this action.

Does the local TRON delegation API audit perform a delegation?

No. It reads three saved JSON files, checks the selected action and query direction, converts units and reports returned-row presence. It does not connect a wallet, sign, delegate or reclaim resources.