Open Interest Updates Plan

Throughout the syncVirtualPriceImpact script as well as the simulation scripts the open interest in tokens from markets that have homogenous backing tokens is double counted, as the scripts always assume that the backing collateral tokens don’t point to the same storage key slot in the dataStore. This can be observed by the output of the simulation scripts, the output for tBTC is as follows:

│   11    │    'BTC tBTC-tBTC'     │ '0xd6206869...' │          '678687328'           │          '639758694'           │  '$606498 / $598881'  │  '$574195 / $564530'   │    'Longs / Longs'    │  '4.733089e-8 / 4.733089e-8'  │     '+0.00%'     │  '0.000000e+0 / 0.000000e+0'  │      '0.00%'      │ '1.518152e-8 / 1.518152e-8'  │   '+0.00%'   │  'Longs / Longs'  │  '$33.14 / $33.14'   │  '+$0.00 (+0.00%)'  │     '-$547.36 / -$753.65'     │   '+37.68% / -$206.29'   │    '-$13644.79 / -$240.45'     │  '-98.23% / +$13404.33'   │

Claiming that the long OI is 678687328 in tokens, however the corresponding key in the dataStore only shows half of that: (Figure. See the PDF report.)

This will perturb every virtual inventory that includes a market with homogenous backing tokens.

A divisor check and application for homogenous markets would be the most straightforward fix, as is done in the contracts. However we should avoid dividing by 2 to create any rounding errors unnecessarily. Instead, for homogenous markets simply only query the key once for the long side and the short side, with the knowledge that the collateral tokens are the same.

The syncVirtualPriceImpact.ts script is intended to read the net size in tokens across all markets in a virtual inventory group and the pass that result to be synced onchain through the Config. However the time at which the values for the size in tokens are read and the time at which the configuration is synced onchain are at two different times, and may have blocks recorded on the Arbitrum network in-between them. The time at which the script records the size in tokens across markets in a group is at script execution time. The time at which the configurations are synced is at the time of the block which ultimately ends up including the configuration transaction. If any action which updates the size in tokens in any market within that group occurs in a block between those two times, then this will cause a desync between the value stored in the virtual inventory and the value of size in tokens actually within the markets inside the virtual group.

Consider adding an additional step, which is a script that checks the values in the virtual inventory for tokens and compares it with the actual aggregate size in tokens of the markets in the group to ensure that no desync has occurred. If one has occurred then another configuration can be made specifically for that market which probabilistically will not have the same issue.

The virtual inventory script is meant to sync the current net long or net short exposure in tokens to the new virtual inventory in tokens. The plan steps are as follows:

1. run script to create long and short positions for all markets

2. run script to sync virtual inventory

3. turn on flag

4. re-run script to create long and short positions for all markets

5. re-run script to sync virtual inventory

The contracts will not begin to track updates to the virtual inventory in tokens until the flag is switched. Therefore if anyone performs an action between steps 2 and 3 that would change the sizeInTokens of any position in any market then it will cause a desync between the value stored in the virtual inventory in tokens and the actual market value. In step 5 there is a re-sync of the virtual inventory which should correct any de-sync that could have happened. However it may be the case that in the event of a de-sync after step 2 that the price impact results from the virtual inventory can be wrong and there could be unexpected reverts that occur as a result of the virtual inventory being de-synced. This may interfere with the completion of step 4.

Be aware of this risk when executing the scripts. Consider turning off access to actions through the UI during the migration, or halting keepers from execution position actions / pausing markets to totally remove the possibility of a desync.

The simulation script does not use exactly the script that will be executed in the actual migration, the syncVirtualPriceImpact script, to do it’s syncing simulation. This could create a gap between the simulation and the actual migration.

Consider re-running the simulation adapting it for the actual syncVirtualPriceImpact script which will be run.

At steps 1 and 4 it may be possible that the orders created fail in some markets due to market conditions, validations, or gas issues.

Be aware of this possibility and ensure that all orders are successfully executed before moving on to the next step.