feat: tron returns staking/voting data for accounts#1467
feat: tron returns staking/voting data for accounts#1467cranycrane wants to merge 16 commits intomasterfrom
Conversation
cranycrane
force-pushed
the
1451-tron-freezing-governance-data
branch
from
d387c8b to
fd2ffd1
Compare
| } | ||
| } | ||
|
|
||
| func (b *TronRPC) SendRawTransaction(tx string, disableAlternativeRPC bool) (string, error) { |
There was a problem hiding this comment.
this tronBuildStakingInfo method is huge and I don't see a unit test for it, it does many computations. So it should be unit tested perhaps ?
There was a problem hiding this comment.
it is already tested through GetAddressChainExtraData
There was a problem hiding this comment.
Pull request overview
Adds Tron staking/governance metadata to account-level chain extra data so API consumers and the UI can display staking balances, unstaking batches, votes, voting power, rewards, and delegated stake for Tron addresses.
Changes:
- Extend Tron account chainExtraData with
stakingInfopopulated from/wallet/getaccountresource,/wallet/getaccount, and/wallet/getReward. - Render staking/governance details in the Tron address UI template.
- Update generated TypeScript API types and expand unit/integration tests with mocked HTTP responses.
Reviewed changes
Copilot reviewed 13 out of 13 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| tests/dbtestdata/fakechain_tron.go | Extends fake chain extra payload with stakingInfo for fixtures. |
| static/templates/address_chainextra_tron.html | Adds UI section to render staking/voting/unstaking/reward/delegations. |
| server/tron_template.go | Adds template data structs and parsing for staking amounts/unstaking batches. |
| server/tron_template_test.go | Extends template unit test to assert parsed staking fields. |
| server/public_tron_test.go | Updates HTTP/UI expected output and API responses to include stakingInfo. |
| docs/api-tron.md | Documents stakingInfo schema for Tron account chain extra payload. |
| build/tools/typescriptify/typescriptify.go | Includes TronAccountExtraData in TS generation inputs. |
| blockbook-api.ts | Updates generated TS interfaces for Tron staking account data. |
| bchain/types_tron_chainextradata.go | Moves/extends Tron chain/account extra data types; adds staking-related types. |
| bchain/types_chainextradata.go | Removes Tron type definitions moved to dedicated Tron types file. |
| bchain/coins/tron/tronhttp_endpoints.go | Implements concurrent fetching + normalization of staking info for accounts. |
| bchain/coins/tron/tronrpc_test.go | Expands tests for new staking info behavior and failure/omission cases. |
| bchain/coins/tron/tronInternalDataProvider_test.go | Enhances mock HTTP client to return responses/errors per-path and record calls. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| totalVotingPower := resourceResp.TronPowerLimit | ||
| if totalVotingPower < 0 { | ||
| totalVotingPower = 0 | ||
| } |
There was a problem hiding this comment.
| totalVotingPower := resourceResp.TronPowerLimit | |
| if totalVotingPower < 0 { | |
| totalVotingPower = 0 | |
| } | |
| totalVotingPower := max(resourceResp.TronPowerLimit, 0) |
There was a problem hiding this comment.
Same can be applied to availableVotingPower, unclaimedReward, delegatedEnergy and delegatedBandwidth
… the backend concurrently
…oncurrent methods
cranycrane
force-pushed
the
1451-tron-freezing-governance-data
branch
from
0234903 to
f2d6058
Compare
…gInfo big.Int.Add(x, y) stores the sum in the receiver and does not mutate its operands, so the inner new(big.Int).Set(stakedBandwidth) copy was redundant. Drop it and pass stakedBandwidth directly to Add. No behavior change; same result, one fewer big.Int allocation per call.
Previously, a negative limit returned by the Tron API combined with a smaller used value would yield a non-sensical positive availability (e.g., limit=10, used=-50 -> 60). All other resource fields in tronBuildStakingInfo already clamp negative values to zero, so make tronAvailableResource symmetric and treat any non-positive limit as zero availability. Real Tron nodes shouldn't return negative limits, but this hardens the function against malformed responses.
In Stake 2.0, only BANDWIDTH and ENERGY freeze types produce frozen TRX; TRON_POWER is a derived voting weight, not a separate stake. The frozenV2 loop in tronBuildStakingInfo therefore intentionally ignores TRON_POWER entries when summing stakedBalance. Add an inline comment explaining the intent so the silent drop is not mistaken for a missing case.
pragmaxim
left a comment
pragmaxim
left a comment
There was a problem hiding this comment.
There is a possibility to cache stakingInfo to absorb the 3× backend fan-out, but only OPTIONAL and probably necessary only if it turned out to be slow.
Details
GetAddressChainExtraData now issues three concurrent calls (/wallet getaccountresource, /wallet/getaccount, /wallet/getReward) per address request, where it previously issued one. Wall-clock latency is unchanged, but backend RPS for the address endpoint is tripled.
StakingInfo only changes on freeze / unfreeze / vote / withdraw-reward transactions, so a short-TTL per-address cache (e.g. 10–30 s, or invalidated on relevant tx events) would let frequent address-page polling reuse the previous result and bring the steady-state load back down to roughly 1× — while still serving fresh data right after a staking action.
Optional refinement: skip /wallet/getReward when the cached unclaimedReward was 0 and no reward-bearing tx has been seen since.
TronStakingInfo) intoTronAccountExtraData