Invalid idle_balances.fetch_assets logic

[armoking32]

Regarding idle_balances: https://github.com/Moonsong-Labs/tq-oracle/blob/master/src/tq_oracle/adapters/asset_adapters/idle_balances.py#L114-L126

Here we should iterate not only over the supported assets, but also over any additional assets that may exist on the balance of the vault or its subvaults (for example, fetched dynamically from the config).

In fact, the supported assets in the Oracle or ShareModule correspond to the assets allowed for deposit and redeem queues. So in the case of tqETH, the supported assets could be [ETH, WETH, WSTETH]. However, a subvault might also hold other assets, such as USDC, which could be received through a CowSwap order execution.

[timbrinded]

We discussed this internally and we arrived at this impl because:

• We assumed that a vault holding any balance of token would be made a supported asset so that it could be eligible for riskManagement
• You incur risk of oracle attacks if you have a dynamically read any old token balance (someone could donate a fraudlent ERC20 to the subvault to inflate the valuation )

Supported Assets !== allowed assets though, so whilst i appreciate that we dont want to support USDC queues, i'd imagine that USDC would still be marked as an allowed asset no?

[armoking32]

I assume USDC will still be marked as a supported asset, right?

@timbrinded

Not exactly. If we use any of these tokens exclusively within a single subvault (i.e swapping WstETH for USDC and bridging everything to HL directly from that same subvault), then there is no need to include USDC in any reports (nor in supported assets) - it will not interact with the risk manager or deposit/redeem queues.

Moreover, including non-correlated assets with "real" prices in the supported assets of the oracle can also cause issues with oracle security parameters. Significant price movements could easily trigger failed report submissions due to max threshold overflows.

For example, in the case of strETH, we include USDC, USDT, and USDS as "supported assets", but they are only added to the oracle with a 1-wei price - just to allow transfers between subvaults (without actual checks of overflows on pull/push operations). It is a bit ad-hoc, but in general, I think, we should follow this approach:

1. Idle balance calculation - include all supported assets of the oracle + additional ones explicitly listed in the config.

2. Oracle report calculation - use only the assets explicitly listed in the config (i.e., a subset of supported assets of the oracle).