Reserves are not pair specific about cfmm-routing-code HOT 3 CLOSED

I'm not fully sure I understand the current comment :)

E.g. reserves for pair ABC-DEF on exchange i could be R_ABC = 5 and R_DEF = 10 but then for ABC-GHI could be R_ABC = 2 and R_GHI = 7 (still on exchange i). This is how we get the prices for each pair and is necessary for the correct application of this to real live CFMM markets.

Perhaps some wires are getting crossed here, but we call an "exchange" what some might call a "pool." So ABC-DEF is a pair/exchange/etc., with reserves R_ABC and R_DEF, while ABC-GHI is a different exchange with different reserves amounts R_ABC, R_GHI (perhaps they might reasonably be called R_ABC_ABC-GHI, R_GHI_ABC-GHI, if we're going to be fully explicit?). They are two independent pools, even though they might both be part of "Uniswap v2," for example. For most intents and purposes, there is no relationship between ABC-DEF and ABC-GHI for trading/routing.

Another way of stating it would be to say that the trading function constraints must apply pair-wise, e.g. in the case of Uniswap that changes in values of the reserves for a specific pool / trading pair must preserve the product invariant of the reserves for that specific trading pair.

How does this differ from the current implementation? (Sorry, I'm still not quite sure I'm understanding here!)

from cfmm-routing-code.

Perhaps some wires are getting crossed here, but we call an "exchange" what some might call a "pool." So ABC-DEF is a pair/exchange/etc., with reserves R_ABC and R_DEF, while ABC-GHI is a different exchange with different reserves amounts R_ABC, R_GHI (perhaps they might reasonably be called R_ABC_ABC-GHI, R_GHI_ABC-GHI, if we're going to be fully explicit?). They are two independent pools, even though they might both be part of "Uniswap v2," for example. For most intents and purposes, there is no relationship between ABC-DEF and ABC-GHI for trading/routing.

Ah ok that makes a lot more sense then thank you! I hadn't understood this index referred to a pool, but now your example local indices in the code files make more sense. I do have one more question though, namely regarding these (from arbitrage.py):

local_indices = [ [0, 1, 2, 3], [0, 1], [1, 2], [2, 3], [2, 3] ]

Are the entries here just the values according to the global indexing? (This would seem to be consistent with the explanation in the paper and how the code builds the A matrices just want to check I'm understanding this correctly)

Another way of stating it would be to say that the trading function constraints must apply pair-wise, e.g. in the case of Uniswap that changes in values of the reserves for a specific pool / trading pair must preserve the product invariant of the reserves for that specific trading pair.

How does this differ from the current implementation? (Sorry, I'm still not quite sure I'm understanding here!)

Indeed it doesn't, just the confusion there with the exchange index.

from cfmm-routing-code.

Are the entries here just the values according to the global indexing?

Yes, that is correct :)

The "local" indexing in this case is just the position of the array. We can then think of local_indices[i] as a map from the local indexing to the global indexing for CFMM i, such that local token j has global index local_indices[i][j].

from cfmm-routing-code.