AccountCapsule` and `Wallet` frozenV2 construction logic

[csc-EricWu]

Issue reproduced on current develop branch.

---

Expected behaviour

For the API walletsolidity/getaccount, the returned frozenV2 field should:

1. Contain only entries with explicit type
2. Have correct amount bound to each type
3. Be returned in a stable and logical order, for example:
   • ENERGY
   • TRON_POWER

Expected example:

"frozenV2": [
  {
    "type": "ENERGY",
    "amount": 20400000000
  },
  {
    "type": "TRON_POWER",
    "amount": 20000000000
  }
]
Actual behaviour

The walletsolidity/getaccount API returns an unexpected frozenV2 structure:

"frozenV2": [
  {
    "amount": 20000000000
  },
  {
    "type": "ENERGY",
    "amount": 20400000000
  },
  {
    "type": "TRON_POWER"
  }
]


Problems observed:

The first entry has no type field

The TRON_POWER entry has no amount

The order of entries is inconsistent and does not match logical resource grouping

amount values appear to be mis-associated across entries

This makes it difficult for API consumers to reliably parse frozenV2.

Frequency

100% (always reproducible for this account state)

Steps to reproduce the behaviour

Run a FullNode / SolidityNode using the develop branch

Ensure an account has:

Stake V2 frozen balances for ENERGY and TRON_POWER

Call the API:

walletsolidity/getaccount


Observe the returned frozenV2 field

Full response example
{
  "account_name": "TestD",
  "address": "TBcBVYnotCt6CtRyBiwnaALjMyoypXH8Wj",
  "balance": 999934031076964,
  "net_usage": 247,
  "latest_opration_time": 1702994064000,
  "free_net_usage": 1403,
  "latest_consume_time": 1702994064000,
  "latest_consume_free_time": 1702991967000,
  "net_window_size": 28271000,
  "net_window_optimized": true,
  "account_resource": {
    "latest_consume_time_for_energy": 1702993065000,
    "energy_window_size": 28800000,
    "energy_window_optimized": true
  },
  "frozenV2": [
    {
      "amount": 20000000000
    },
    {
      "type": "ENERGY",
      "amount": 20400000000
    },
    {
      "type": "TRON_POWER"
    }
  ]
}

Backtrace
N/A

Additional notes

This issue appears to be related to how frozenV2 entries are constructed and ordered
when converting account data to RPC response objects (likely in Wallet RPC layer),
rather than an issue with the underlying AccountCapsule storage itself.

Explicit type assignment and deterministic ordering of frozenV2 entries
would greatly improve API consistency.

[halibobo1205]

This behavior is very likely caused by protobuf JSON serialization omitting default enum / zero values.

In ResourceCode, BANDWIDTH is defined as an enum value 0:

BANDWIDTH = 0x00;
ENERGY = 0x01;
TRON_POWER = 0x02;

Since enum value 0 is treated as the default in protobuf, the type field for BANDWIDTH entries is omitted in JSON output.
Similarly, entries with amount = 0 will omit the amount field.

As a result:

• The BANDWIDTH frozen entry appears as { "amount": ... } with missing type
• The TRON_POWER entry appears as { "type": "TRON_POWER" } with missing amount
• The frozenV2 list becomes malformed and ambiguous for API consumers

The root issue lies in the Wallet RPC layer, specifically when constructing the frozenV2 list, rather than in AccountCapsule storage.

[halibobo1205]

@csc-EricWu As this change may affect compatibility, I suggest discussing it in the Core Devs Community Call 54 for further alignment.

[waynercheung]

@csc-EricWu @halibobo1205

This appears to be a known issue. Given interface compatibility constraints, modifying the protocol is unlikely. Additionally, when defining a new enum in the future, you can set the variable of the enum at index 0 to "unknown XXX", similar to:

enum EntryType {  
    UnknownEntryType = 0;  
    Constructor = 1;  
    Function = 2;  
    Event = 3;  
    Fallback = 4;  
    Receive = 5;  
    Error = 6;  
}