Technical overview RO
Compare our findings! To model the optimization yourself, you can use the following Desmos Link.
And follow these steps:
Desmos: Modify the weights (R1, D1, and D2) and Ain to simulate. Weights are set at 3x Route 1 vs. Route 2 depth and 1% total inbound asset transaction, but you can modify these values to simulate other cases.
Desmos: To refresh, R1 is how much deeper Route 1 Pool 1 is compared to Route 2 Pool 1. D1 and D2 are how much each route’s second pool is bigger than the first. If Pool 2 along Route 2 is half as deep as Pool 1 of Route 2, then D2 = 0.5. Use Ain as the percentage of the overall inbound asset in pools (Route 1 + Route 2) that you wish to simulate a trade for.
Desmos: Look for the local maximum y point in the graph between 0 < x < 1. You can find it by clicking the line. A small circle should appear at the maximum value. If you hover over the circle, coordinates for x and y at that point should appear right above the circle.
Desmos: The x-coordinate of that point in the graph is “p”, and the y-coordinate in the graph is “Aout”.
Excel: Compare the simulation with this excel sheet: https://bit.ly/3y8UToo, which uses Thorchain’s classic slip-based fee formula to compare Single Route to Double Route. Double Route here means that a transaction passes through $RUNE in Thorchain and $CACAO in Maya, respectively. You can modify the values in the yellow cells to play around with the model. Only make sure they are changed in Desmos as well. Thorchain is used as Route 1, and Maya as Route 2.
Excel: If you use any other “p” partition value between 0 and 1, the slip fees should always be greater than that of the optimized “p” value that was found using the Desmos simulation. You can compare this by ensuring that the 2nd and 3rd simulation cases have values below and above the optimized “p” partition in the red box.
Excel: The final balance of the outbound asset should be equal between the classic calculation compared to calculating using Aout * (TOD + MOD) from the Desmos simulation. You can compare this at the bottom of the 1st simulation case. If the amounts are slightly different, it is because of significant figures used by Desmos; running the simulation on Python yields exactly the same result for the Maya Route Optimization compared to Classic CLP derivation in steps.
Remember, none of the above has been implemented in our code or on-chain since neither $USc or Maya 3.0 has been implemented yet. No code has been developed for the use of User Interfaces either because their approaches and technologies vary a lot. Nevertheless, we believe the optimizations discussed can easily be incorporated into their processes.
Their implementation can choose to do the derivative and find the relevant zero in y’ between 0 < x < 1, and then use that value as the partition. Another option is to calculate the maximum value of y using a 0.01 step (or any other arbitrary step size) for x between 0 < x < 1 and use the value of x at the maximum as the partition proportion. The second implementation is simpler but can lead to more computational work.
Our recommendation is that User Interfaces set an “Auto” setting, where bigger transactions calculate and use this optimization and where smaller transactions are simply routed through the deeper route, taking into account inbound and outbound chain gas fees.
They can also implement an “Auto / Manual” toggle, where their users decide whether they want to use this optimization across THORChain and Maya or only one of them (or another future similar provider!). Recurrent checks can monitor both protocols’ health too. If one of them is not working optimally, said User Interface can automatically route all their transactions through the other one without optimizing.
Finally, the liquidity provided into our “Stable Pools” by any node will never count towards its bond. In other words, the LP tokens that help them churn in can only come from bonding with $CACAO to help it stay as our main trading token and as the majority of our liquidity. Remember also that, as we covered in Chapter 5, $USc has a capped supply amount, which comes from the limits of the underlying stablecoins that comprise it, to prevent over-leverage in the system. Between these two phenomena, the Stable Pool share of total liquidity will always remain below 33% but realistically will be as low as 10% to 15%. Above 33% Stable Pool share, Liquidity Rewards are 0, and all block rewards go to Nodes equally, providing no incentive for LPs or Nodes to add more $USc paired liquidity and even remove it while incentivizing new Nodes to pair $CACAO in pools to churn-in.
Last updated