Why do the fio.token and fio.address accounts have a proxy set?

[n8d]

I've discovered this on FIO Mainnet:

clio get table eosio eosio voters -l 1 -L 37
{
  "rows": [{
      "id": 37,
      "fioaddress": "",
      "addresshash": "0x00000000000000000000000000000000",
      "owner": "fio.token",
      "proxy": "qcic4ydb3vqh",
      "producers": [],
      "last_vote_weight": "0.00000000000000000",
      "proxied_vote_weight": "0.00000000000000000",
      "is_proxy": 0,
      "is_auto_proxy": 1,
      "reserved2": 0,
      "reserved3": "0 "
    }
  ],
  "more": true
}

Which is odd, as qcic4ydb3vqh seems to be a normal user account. That is_auto_proxy value leads me to believe setautoproxy may have been called on these accounts. Is this a bug?

[edrotthoff]

this is pretty odd...I did some code analysis and also some "state of the main net chain analysis" and I cannot seem to find a way that this has come to occur....at any rate we should consider to add protections into the tpid and auto proxy logic to prohibit the participation of the fio protocols system accounts, and we might also consider to add this protection into the voting logic as well (prohibit the fio system accounts from participating in voting)....this may just be an artifact of the earlier days of the chain, but we should consider to help to ensure that this cannot be permitted to happen. since the system accounts are all retired and have private keys burned I do not see a path permitting this to happen in the future, but it might be safest to lock this down specifically just in case..

[edrotthoff]

I think that someone should investigate this from a history perspective and discover how this came to be, then we can possibly verify if the above tactics have any merit..

[0xCasey]

This account registered as a proxy here: https://explorer.fioprotocol.io/transaction/385bbd5e5ecfd49b17fa6cb2c24cd3467429912969ae90dd5711fa2e412e2bf1

[edrotthoff]

im interested in the block explorer entries that show when the is_auto_proxy got set on the fio system accounts..

[edrotthoff]

and also when the fio system accounts were added to the voters table.

[n8d]

im interested in the block explorer entries that show when the is_auto_proxy got set on the fio system accounts..

curl -s "https://fio.eosrio.io/v2/history/get_deltas?code=eosio&scope=eosio&table=voters&payer=fio.token" -H  "accept: application/json" | jq
{
  "query_time_ms": 2.6,
  "total": {
    "value": 1,
    "relation": "eq"
  },
  "deltas": [
    {
      "timestamp": "2020-04-13T21:05:34.000",
      "code": "eosio",
      "scope": "eosio",
      "table": "voters",
      "primary_key": "37",
      "payer": "fio.token",
      "present": true,
      "block_num": 3432683,
      "data": {
        "is_proxy": false,
        "proxy": "qcic4ydb3vqh",
        "last_vote_weight": 0,
        "proxied_vote_weight": 0,
        "staked": null,
        "id": "37",
        "fioaddress": "",
        "addresshash": "0",
        "is_auto_proxy": true,
        "reserved2": 0,
        "reserved3": "0 "
      }
    }
  ]
}

Looking at the transaction that did it:

        "transaction": {
          "expiration": "2020-04-13T21:07:31",
          "ref_block_num": 24805,
          "ref_block_prefix": 1474986508,
          "max_net_usage_words": 0,
          "max_cpu_usage_ms": 0,
          "delay_sec": 0,
          "context_free_actions": [],
          "actions": [{
              "account": "fio.token",
              "name": "trnsfiopubky",
              "authorization": [{
                  "actor": "qcic4ydb3vqh",
                  "permission": "active"
                }
              ],
              "data": {
                "payee_public_key": "FIO5djEBsfS7f629xfchCzMNJ6ai5aXqEHShJDeNv7swRG9Zq5SV5",
                "amount": 80000000000,
                "max_fee": 2000000000,
                "actor": "qcic4ydb3vqh",
                "tpid": "tpid@greymass"
              },
              "hex_data": "3546494f35646a4542736653376636323978666368437a4d4e4a36616935615871454853684a44654e763773775247395a713553563500205fa0120000000094357700000000d0ec1e2779821cb20d7470696440677265796d617373"
            }
          ],
          "transaction_extensions": []
        }

[edrotthoff]

cool Nate!! ill look at this some more in the light of this data, thank you for looking, I appreciate it..the FIO protocol has as a feature that we auto proxy to the domain owner IF the domain owner registers as a TPID....so this auto proxy you see is a feature of the protocol...but ill look into this deeper as well, interested to see where this leads me...

[adsorptionenthalpy]

This must be an artifact from when the chain was first spun and fio.token was used as an actor for the initial call to regproxy, the actor was initially emplaced as an owner.

Here we call regiproxy with the actor as a proxy parameter
https://github.com/fioprotocol/fio/blob/develop/fio.contracts/contracts/fio.system/src/voting.cpp#L1128
actor parameter then gets emplaced into owner field of voters table
https://github.com/fioprotocol/fio/blob/develop/fio.contracts/contracts/fio.system/src/voting.cpp#L1229

[adsorptionenthalpy]

https://github.com/fioprotocol/fio/blob/develop/fio.contracts/contracts/fio.address/fio.address.cpp#L363
https://github.com/fioprotocol/fio/blob/develop/fio.contracts/contracts/fio.token/src/fio.token.cpp#L312
process_rewards is called using get_self() in the actor parameter in these contracts, eventually the actor makes it down the line to regiproxy that gets emplaced as the owner.
Credit to @edrotthoff for finding this.

Edit: all calls to processbucketrewards and process_rewards

[edrotthoff]

looking at the code from the highest level in the call chain, we see code in the fio.token contract for transfer fio using pub key and in the fio.address contract for register address that looks like this..

fio_fees(actor, asset{(int64_t) reg_amount, FIOSYMBOL});
process_rewards(tpid, reg_amount, get_self());

using get_self() on the process rewards passes this value (the system contract account) to the methods/actions that set the tpid and auto proxy....

this is why this showed up....we will get a fix in so it no longer happens..

thanks @n8d for finding this...the protocol is better for your efforts...

[edrotthoff]

To rectify this we need to consider the following:

1. fix the bug (change the get_self() to the proper actor account.

2. look for anywhere else we might be doing this in our system (use get_self() instead of proper actor).

3. consider adding logic to all emplacements where we are assuming a fio actor, and add a check for system account, if its a system account then error!

4. we need to identify all of the affected accounts, the way to do this is to play the chain and capture the register name, and transfer fio public token calls, capture the accounts and tpid information, and then using this information make a migration contract/action that will set the account votes and proxies correctly. There might be more thought needed into this, we want to ensure all auto proxies are set up in state as we expect.

[edrotthoff]

as it turns out, all of the calls to process_rewards and processbucketrewards need to be updated to provide a fix for this, this fix will affect auto proxy voting, but does not affect tpid rewards accumulation, or claiming of tpid rewards...we probably do not need item 4 above, we probably just need to let the system learn the tpids as calls are made from the various wallets and integrators, the auto proxy voting will resolve itself over time...

[ericbutz]

Fixed by:
#141
#145
Released in v2.1.0.
Closing