The problem DeFi Paper Trading Live Modeling Tool with 0x API solves

Background

Quantitative finance is $14B industry (as of 2021) and DeFi has already reached $20B as of last year. The former has sophisticated modeling tools for paper trading without deploying their algorithms to the real world so they don't lose their billions of dollars of assets under management ($300B in 2023), so why doesn't DeFi for it's billions? ($92B in March '24).

When companies have massive expenditures like a $50M rocket launch, they run thousands of models and simulations to make sure it doesn't crash and burn. Because there isn't a well known, easy to use tool for this type of modeling with a simple enough user interface for initial modeling, nor a comprehensive modeling tool for modifying relevant parametrs in depth, we get disaster scenarios like the $LUNA crash that could've been easily avoided with simple modeling.

Solution

By using DeFiPy - the first and only open source Python package for modelling in DeFi that is a full Python refactor of UniSwap V2 smart contracts, and the 0x real time price API, we were able to combine the two into a live paper trading tool that allows users to select from the various blockchains, tokens, and stablecoins that 0x Price API provides to select a live liquidity pool as the basis of the modeling tool.

We also added the ability for users to select modeling parameters, such as the maximum swap size allowed by the pool, the randomized trading bias between the selected coin and respective stablecoin in the pool, and the profitability of your position based on liquidity provided.

On top of all that we've launched a live dashboard so that users can easily interact with the model and visualize relevant activity and parameters, all while tracking the live pool data from the 0x Price API.

These are the first steps necessary to make simple DeFi modeling a norm in the industry by simulating data based on a live price feed so that we can avoid the all too common crash and burns that plague the industry.

Challenges we ran into

• Double calling the API when attempting to initiate the simulator. The rate limit was throwing errors because of the concurrent calls, but when we realized it was happening twice quickly we reworked the code to avoid that and resolved the issue.
• We also had trouble injecting JS into python using the bokeh library, but were able to work around it using native bokeh elements that use their own JS and were able to build a complete UI using only those tools, making the codebase entirely python based!
• Launching the project to a live server caused some issues, but we were able to do so using codesandbox after debugging some of the requirements in our requirements.txt, after which we were able to confirm it’s live and is accessible in real time and can work concurrently with multiple users.
• Every time the simulator processes the UI would freeze, leading to a bad user experience for interactivity. We were able to resolve this by setting our simulator parameters to return data quickly over 0.25 intervals, but only ran our graph update every 3 seconds so that the code wouldn’t hang 92% of the time (3/3.25) so it’s not noticeable as long as users aren’t spamming buttons repeatedly.
• Were unable to get bokeh to refresh axis data dynamically, so worked around it by using more generic labels but adding additional indicators for what token pairs and networks were being used, and refreshed the graph data so that each new simulation was cleanly displayed.
• Data management such as contract addresses and configuration settings, to solve we implemented a new Python data class