Give your colleagues a place to learn about your team, and what you’re working on. Use the + buttons in your left-hand sidebar to add more pages, like process docs or a project roadmap.

<aside> 👋 Welcome to the team! Our mission is to…

Questions? Here’s how to reach us:

• Slack channel:
• Email:
• Team manager: </aside>

Resources

Type the / key to add custom blocks

Main

There / key Here there is a weird quirk when using pools as they only have a singular price rather than a bid and offer. Without slippage and fees, there is only 1 price that p_n can have that will show no arb for the loop p_1,…. p_n where these prices form a loop i.e the price from in P-1 is the same as the to price in p_n. We can see that as there are 3 scenarios. We let the product of all prices p_1,….p_(n-1) = q for the sake of compactness

• If p_n*q=1 no arb and everything is perfectly efficient
• if p_n*q>1 there is an arb as if we put in 1 we will get back more than one
• if p_n*q<1 then by traversing the graph in the opposite direction we can put in less than 1 of the toke and get one out which is an arb.

These fail in practice because of slippage and fees but it is easy to see that we will have har to many possible arbs.

To combat this we should order them by the absolute value of their expected profit and then i.e the larger that the product is or in the case of the last point the larger 1/prod is and then looking at the these. Likely figuring the most profitable trades will need to take liquidity into account and probably a fixed penalty for the number of swap pools to account for additonal gas fees.

Using convex optimizations does eliminate these issues

Tasks