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?

Hello,

Thank you for the great paper, the thoughtful explanation in it and the accompanied code. It really helps someone like me.

I have one or two question please :

1. If I understood very well your formulation about including transaction cost in the objective function and without thinking about the fact that the problem is solvable or not, the way you included the transaction cost is by adding a constant transaction cost for each CFMM, meaning if we do one trade in that CFMM we'll have to pay that transaction cost, while in reality the transaction cost is dependent not on if we did a trade or not on a CFMM but on how many trades we did on that CFMM and your formula omit this detail. Am I right ?

Your response for these questions will be so much helpful.

When attempting to apply the code to real reserve sizes it has become apparent that the distribution of these values presents a significant problem for the underlying numerical solver, namely that the values tend to deviate by several orders of magnitude and thus cannot be normalised by an overall factor to produce a set of O(1) values. This is causing the solver to fail, although it works very well for the example numbers in the code files.

Has the code been used / tested with real world reserve values over a sizable selection of markets or is it considered more of a theoretical / reference implementation?

Is there a recommended normalisation to be used when using real reserve values that may deviate by many orders of magnitude?

Many thanks