wharfkit / antelope

Core types, client interfaces, and other tools for working with Antelope-based blockchains.
Other
42 stars 23 forks source link

Fields missing from voter_info in get_account API response on WAX #77

Closed includenull closed 8 months ago

includenull commented 10 months ago

Summary: The get_account API response on WAX differs slightly from the base response of Antelope.
These include the following fields:

unpaid_voteshare  
unpaid_voteshare_last_updated  
unpaid_voteshare_change_rate  
last_claim_time

Steps to Reproduce:

  1. Call .v1.chain.get_account() against a WAX node.
  2. Get AccountObject response and inspect voter_info.
  3. voter_info object does not include all expected fields.

Expected Results:

{
    "owner": "includenull",
    "proxy": "top21.oig",
    "producers": [],
    "staked": "125699191765",
    "unpaid_voteshare": "1018386344149210818270928864637142440083456.00000000000000000",
    "unpaid_voteshare_last_updated": "2023-08-13T10:01:30.000",
    "unpaid_voteshare_change_rate": "4243396489486260233891840133040504307712.00000000000000000",
    "last_claim_time": "2023-08-13T09:57:03.000",
    "last_vote_weight": "4243396489486260233891840133040504307712.00000000000000000",
    "proxied_vote_weight": "0.00000000000000000",
    "is_proxy": 0,
    "flags1": 0,
    "reserved2": 0,
    "reserved3": "0 "
}

Actual Results:

{
  "owner": "includenull",
  "proxy": "top21.oig",
  "producers": [],
  "staked": "125699191765",
  "last_vote_weight": "4.24339648948626e+39",
  "proxied_vote_weight": "0",
  "is_proxy": 0,
  "flags1": 0,
  "reserved2": 0,
  "reserved3": "0 "
}

Additional Information: I consider this a bug because the available data is not passed through to the object.
These missing fields are required to calculate voter rewards.

I am unaware of any other way to calculate voter rewards without this data, which surprises me that these are missing from the base Antelope response.

aaroncox commented 10 months ago

Voter rewards like this are unique to WAX and not natively a part of Antelope system contracts, which is why we didn't include these fields in the base response. Telos also has a few unique fields (different than WAX) I believe too.

Some examples:

EOS

{
  "owner": "teamgreymass",
  "proxy": "greymassvote",
  "producers": [],
  "staked": 100202,
  "last_vote_weight": "863265464502.93908691406250000",
  "proxied_vote_weight": "0.00000000000000000",
  "is_proxy": 0,
  "flags1": 0,
  "reserved2": 0,
  "reserved3": "0.0000 EOS"
}

Telos

{
  "owner": "teamgreymass",
  "proxy": "",
  "producers": [],
  "staked": "6682315286",
  "last_stake": 0,  // Variation, new field
  "last_vote_weight": "0.00000000000000000",
  "proxied_vote_weight": "0.00000000000000000",
  "is_proxy": 0,
  "flags1": 0,
  "reserved2": 0,
  "reserved3": "0 " // Variation, not an Asset
}

WAX

{
  "owner": "teamgreymass",
  "proxy": "",
  "producers": [],
  "staked": "9039133084986",
  "unpaid_voteshare": "0.00000000000000000", // Variation, new field
  "unpaid_voteshare_last_updated": "2023-08-18T17:24:12.000", // Variation, new field
  "unpaid_voteshare_change_rate": "84871176772458765566336581970335981633536.00000000000000000", // Variation, new field
  "last_claim_time": "2023-08-18T17:24:12.000", // Variation, new field
  "last_vote_weight": "84871176772458765566336581970335981633536.00000000000000000", 
  "proxied_vote_weight": "0.00000000000000000",
  "is_proxy": 0,
  "flags1": 0,
  "reserved2": 0,
  "reserved3": "0 " // Variation, not an asset
}

Because of this, I think what we're going to do is break apart the APIClient instances into chain-specific API instances, where we can individually define these fields on a per-chain basis. There will be a "base" client that expects what the system contract templates define for Antelope, and then "chain" clients that will be usable for specific blockchains.

includenull commented 9 months ago

Just a note related to this and to have a record outside of Telegram.
There are some fields added to the get_account response in 4.0 which are also missing.

These are current_used and last_usage_update_time within cpu_limit and net_limit

aaroncox commented 8 months ago

Closing this here, since this work is now being done in https://github.com/wharfkit/account and was completed here https://github.com/wharfkit/account/pull/15