Inventory of queries to load UI

[samsiegart]

Summary

The app requires many vstorage queries to load all the vault info for each user, as well as the user's smart wallet and purse balances. This issue is just for informational purposes to track each one, and potentially identify areas to reduce overall queries.

Queries

For the user's smart wallet info and purse balances, the following 5 queries are done by the wallet component:

• queryBankBalances - to get the user's bank-level asset balances
• ['published.wallet.<address>', 'data'] - to get the users wallet updates, mainly for offer status updates
• ['published.wallet.<address>.current', 'data'] - to get the users non-bank purses, continuing offers (to see their opened vaults), and smart wallet provision status
• ['published.agoricNames.brand', 'data'] - to get the petnames for non-bank purses
• queryBoardAux to get the display info for non-bank purses (this scales with the number of non-bank purses the user has, like kread characters etc.)

To show all the vault managers, the following 5 vstorage queries are required (see service/vaults.ts):

• querySwingsetParams - finds out how much it costs for the user to provision a smart wallet if they don't have one
• ['published.vaultFactory.managers', 'keys'] - to find out all the available collateral types (stOSMO, stTIA, etc.)
• ['published.vaultFactory.governance', 'data'] - to find out the governed params that apply to the vault factory as a whole, namely referencedUI (to know if the app version is old and direct the user to the new version) and minInitialDebt.
• ['published.agoricNames.vbankAsset', 'data'] - to find out the denom info for displaying the amounts relating to each collateral brand
• ['published.auction.schedule', 'data'] - to get the liquidation schedule (time until next liquidation)

Additionally, for each vault manager, the following 4 queries are required:

• ['published.vaultFactory.managers.<managerId>', 'data'] - to get the accrued stability fee rate/snapshot
• ['published.vaultFactory.managers.<managerId>.governance', 'data'] - to get the governed params for the vault type
• ['published.vaultFactory.managers.<managerId>.metrics', 'data'] - to get the metrics for the vault type (total minted, next liquidation price, etc.)
• ['published.vaultFactory.managers.<managerId>.quotes', 'data'] - to get the current oracle price for the vault brand

For each vault the user has open, the following query is required:

• ['published.vaultFactory.managers.<managerId>.vaults.<vaultId>', 'data'] - to get the vault info (current debt, TVL, etc.)

Tally

This means, for a new user with no open vaults, assuming four collateral types currently, theres:

• 5 queries for the user's account/smart wallet
• 5 queries for the general vault factory stuff
• 4 * 5 = 20 queries for all the manager-specific stuff

So a total of 30 queries to load the "Create Vault" page. For each vault the user has open, this adds one additional query. Assuming each query is polled every 6 seconds, that's 5qps per user, which increases by 1qps for every 6 vaults the user has.

Discussion

Some of these queries could be done less frequently, such as the governed params, swingset params, vault manager list, vbankAsset, and boardAux. Roughly estimating, that could subtract 1 query per vault manager, and 6 additional queries from the rest of the list. So assuming 4 vault managers, the number of frequently polled queries could be reduced to 20, for a total of ~3.3qps per user.