Issue Description

FIO Chain (1.9/3.5/2.9) release reverted two previously deployed bug fixes and as a result, users who met all these conditions have had a duplicate entry added to the locked tokens table:

• User unstaked tokens between 2024-01-15 and 2024-02-12
• When unstaking user had an existing lock table entry (e.g. from previous unstake), but that lock entry was already passed. This only happens if:
  • User unstakes
  • Waits 7 days
  • Without any additional fee-collecting or token transfer action unstakes again

However, the following 12 accounts already had multiple lock table entries created as a result of multiple unstakes:

Impact of Issue

👍

The token security or total token balance are not affected by this issue!

By design the lock table should never have more than one entry. If an account already has an existing lock entry, and user unstakes new tokens, the existing entry should have been adapted to represent multiple unlock periods. However, during the period above, when the user unstaked tokens, the code incorrectly added a new entry into the locks table. The existing entry had lock expiry in the past and the newly inserted entry had the lock periods representing correct unstake locks.

Locked tokens

When determining the available balance, the chain would read the first found entry in the table, which in this case was in the past, hence making all unstaked tokens available without any locks immediately after unstake. This will also apply to any new unstake action executed while the account has multiple lock table entries.

get_fio_balance

The get_fio_balance getter has a consistency check, which returns the following error if more than one lock entry exists in the table:

{"message":"Unexpected number of results found for main net locks"}

Locked tokens exceeding available balance

If the user reduces their account’s available balance, below the total amount locked by any one lock entry, an error condition may exist preventing the user from transferring the tokens out of the account, until new tokens are sent to the account to raise the available balance above that locked amount.

Recommended Course of Action

The FIO Chain has functionality which clears expired lock table entries on actions which collect a fee. As a result affected account owners can correct their account if they execute fee collecting actions before any new unstake action is executed.

Account Owners

Account owners are advised to follow this procedure to correct their accounts:

1. Wait at least 7 days (or until last lock entry is in the past) without making any transactions.
2. Execute a small token transfer transaction, e.g. 10 FIO token transfer to account of their choice.
   1. This step will remove the last expired lock entry from the table.
3. Repeat step 2 for every lock entry in the locktokensv2 table.

Some wallets may not allow the user to execute a token transfer or fee-collecting action when the get_fio_balance does not return a positive value. In this case the account owner may consider exporting the private key to another wallet which may not have such restriction.

Integrators

If the wallet does not allow the user to execute a token transfer or fee-collecting action when the get_fio_balance does not return a positive value, the integrator should consider one of the following:

• Allow token transfer or fee-collecting action irrespective of get_fio_balance response.
• Point their wallet to a new version of the FIO Core, which will no longer perform the offending consistency check. The FIO Foundation is currently working on developing this version, and this page will be updated once it is available.
• Temporarily switch to using legacy get_currency_balance endpoint which returns total balance of tokens irrespective of locks
  • Request
    JSON

    {
      "code": "fio.token",
      "account": "5csjyeieegyb",
      "symbol": "FIO"
    }
    

  • Response
    JSON

    [
        "150419.938534209 FIO"
    ]
    

Cause of Issue

On 2024-01-15 new FIO Chain (1.9/3.5/2.9) version was released to Mainnet. Due to version control issues, it reverted two previously deployed bug fixes:

• Unstaking adds new lock entry for user instead of adding lock period to existing lock
• Operational Issue -- unstake on account results in "cannot emplace locks when locks pre-exist."

Issue Resolution

On 2024-02-12 new FIO Chain (2.9.1) version was patched to Mainnet reinstating the bug fixes and eliminating the cause of this issue.