search

angeris / cfmm-routing-code

Convex optimization for fun and profit.
253 stars 47 forks source link

Reserves are not pair specific #4

Closed Granger7 closed 1 year ago

Granger7 commented 2 years ago

It seems that the reserves here have been handled as though there is a quantity for each token, but in fact on CFMMs there is of course a pair of reserve values for each trading pair. 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.

(To me it looks like R_i should already be a 2 dimensional object - for each pair of tokens there should be a length 2 tuple of reserve values, considering that the exchange index 'i' ranges over more than one exchange should then make it 3 dimensional. Then we should be translating local PAIR indices (rather than token indices) to global and vice versa with matrices analogous to the A matrices).

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.

Thoughts?

angeris commented 2 years ago

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!)

Granger7 commented 2 years ago

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.

angeris commented 2 years ago

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].