owned this note
owned this note
Published
Linked with GitHub
# HydraDX OmniPool Course Research Topic Template
###### tags: `Hydra`
:::info
Institutional DeFi
:::
---
### Research Topic/Question:
a. How would the economic paramaters (price, TVL, interest) develop in a replicated DeFi permissioned application vs. permissionless DeFI applications?
i. With the example of an AMM protocol
ii. How to define the role arbitrageur, which agent can arbitrage accross the white/grey pools
iii. Which arbitrage options are possible (same asset, cross asset, cross application)
b. Can we derive discussions about the future size of both pools?
i. Under what assumptions will the TVL be larger/smaller in permissioned vs permissionless
ii. Under what assumptions will the earned LP fees be larger/smaller
---
### Brief Description:
I would like to investigate how to provide institutional investors, who face stringent regulatory requirements, access to DeFi protocols using a simple example. As there appears to be no lending protocols cloned in python to use as the simplest example, I will likely take simple Uniswap tbd.
The suggested approach will offer private pools of funds where only participants who pass KYC procedures can enter trades. Such an instrument will be considered a complex financial instrument under existing regulation, so not suitable for broader basic retail distribution, but it would be relevant to investigate how to bridge DeFi and TradFi and using cadcad as the simulation tool for an institutional offering of AMM.
In terms of any differences between the pools, the working hypothesis is, that participants with access to both the private and public pools could arbitrage the difference.
---
### _Relevance to Hydra AMM_ (e.g. component, subsystem, mechanism, implementation, cadCAD model,...)
Bridging DeFi with traditional finance as in replicating a DeFi setup to TradFi should be interesting for Hydra AMM commercially as well, there is already media coverage confirming that Balancer and 1inch are building institutional solutions targeted regulated financial firms
---
### Approach
Baseline would likely be a micro economic black box model with some simple assumptions around the ecosystem, using a clone of 2 permissionless AMMs and time series to simulate to demonstrate arbitrage conditions, using simple arbitrage strategies, nailing down the intent of arbitrage and informed arbitrage actors vs LPs, leveraging existing academic work on the same. The state of the system should be described by a state map with a set of state variables with the dynamics of the system described by policy functions and state update functions, which are evaluated with cadCAD according to the definitions set in the partial state update blocks.
A simulation configuration is then comprised of a system model and a set of simulation properties, that need to be developed including “what if” scenarios, for example:
1. Assuming every price difference will lead to arbitrage, every trading point in permissioned (“white”) pool is then perfectly matched by arbitrageurs with access also to permissionless (“grey”) pool -> both pools are equal and price discovery is the same. So the task is to define assumptions, test assumptions incl fees, slippage, time, rebalancing, Oracle/CEX/DEX influence and other realistic constraints affecting arbitrage as it relates to grey/white pool.
2. Simulate results if only 1, 10, 25, 50, 75, 90 pct of trading points in one pool are matched by the other -> ? Investigate/hypothesize under what conditions arbitrageurs will accept KYC "trade-off", ie is there is demand/supply problem we can solve.
3. How long will it take for arbitrageurs to close gaps between the 2 pools, what if the gap is bigger or fee is lower etc. Who will take liquidity from the KYC’d pool, is there an institutional demand what, and what will the supply demand elasticity look like. The grey pool will have more participants and deeper liquidity, what will this look like and how will the white pool evolve via arbitrage.
4. Review existing litterature for more advanced arbitrage strategies and test interactions per 1-3) above incl CEX-DEX lessons and possibly the role of order routing services
5. Validate findings via interviews with key players
To be determined if and how to substitute out Uniswap for Balancer for Hydra during project. As agent behavior is critical to model independently, we choose to build an integration of Tokenspice agent based simulation modelling and cadCAD, actually radCAD for ease of implementation of component bases and performance for simulation.
Trading set up for both directions USD-ETH-USD and ETH-USD-ETH as an arbitrageur will behave rationally and risk neutral in any direction as long as there is a profit opportunity
---
### Pool constraints
a. Both pools should have a fixed comparable size from outset
b. Both pools just 1 trading pair / 2 assets to start with tbd pending data. If we want to open DeFi to TradFi it should be token pair USD/ETH likely in the form of USDC/ETH, USDT/ETH and DEX would be (W)ETH
c. White pool is constrained KYC/AML, we are not modelling KYC in smart contracts, just stipulating policy that white pool is for KYC’d agents only and from beginning
d. Agents: 20 agents in grey pool as more diversified retail audience, 10 agents in white pool, 5 agents overlapping both, so total 25 agents.
e. Trade frequency: Until we have data, we simulate trading behavior for white pool agents similar to what can be observed on eg Coinbase Pro (ballpark 1 ETH mean, 1 std dev trade sizes, lognormal fit) and for grey pool Uniswap (ballpark 10 ETH mean, 1 std dev trade size).
f. Uniswap v2 convex curve, agent behavior and arbitrage should all follow https://web.stanford.edu/~guillean/papers/uniswap_analysis.pdf, where for reserves of coin a and coin b, denominated Ra and Rb respectively, transactions must satisfy (Ra − ∆a)(Rb + y*∆b) = k
g. Slippage set to 0.5 pct tolerance per default but possible to parametrize. Also large trades per default timeweighted if slippage exceeds 2 pct
h. Trade size parametrized with lognormal distribution
i. The agents include liquidity providers (LP) and traders, who also perform arbitrage between the 2 pools as well as traders within each pool, which we call SwapAgents. The more sophisticated arbitraguer agent performing Markowitz portofolio optimization is not included in first version
j. Transaction cost fixed gas fee
k. Fixed AMM trading fee 0,3 pct but allow the model to change from beginning on either pool. We will not simulate a variable AMM fee, as we are not designing an AMM incentive mechanism, we are testing a whitelisted Uniswap concept against a grey ditto.
:::
---
### State model
The approach should analyze the following KPIs consistently across all experiments using cadCAD partial state update and simulation approach. KPIs: Fees earned, Trading volume, Price discovery time, Reserve development.
So, the experimentation should have a base-case and we change only one parameter at a time and then compare
![](https://i.imgur.com/Pde8PVi.png)
:::
---
### Experiments
1. Base case
We start with the 2 pools with similar, but somewhat different size pools and prices unaligned (WP 20m USD / 10k ETH; GP 30m USD / 14k ETH).
Agents perform successive trades by swapping in respective pools and trading across pools as outlined by the default trade agent policies for each pool: buy ETH at the cheaper pool, sell same amount ETH at the higher priced pool as per ROI requirements for each agent. At set timesteps, we observe the KPIs in the respective pools.
2. WP reserve 10X bigger
We start with the 2 pools with very different size pools, WP 10X bigger and prices similarly unaligned (WP 300m USD / 100k ETH; GP 30m USD / 14k ETH). With the slippage tolerance set at standard 0.5 pct, WP can manage much bigger trades compared to GP.
3. WP reserve 10X smaller
We start with the 2 pools with very different size pools, WP 10X smaller and prices similarly unaligned (WP 3m USD / 1k ETH; GP 30m USD / 14k ETH). With the slippage tolerance set at standard 0.5 pct, GP can manage much bigger trades compared
4. Trade frequency impact
Change the trade frequency in GP to 10X, what observations can be made?
5. Fee impact
Set trading fee to zero, to analyze how the pools develop based on trading fee sensitivity
6. Whale impact
An institutional whale enters WP as LP with 15m USD / 70k ETH token pair, what happens
7. ETH price volatility impact
Say, due to a bug in GP traders’ algorithm so between timestep 100-1000, there is a massive selling of ETH only, how does this affect KPIs between the 2 pools
8. Slippage observation
Slippage tolerance is set default to 0,5 pct similar to Uniswap. Now we set slippage tolerance to infinite, ie no slippage tolerance max.
---
### Desired Goal/Overarching Objective (may not be/unlikely to be achieved during the course)
We will not be able to develop methods to analyze network contagion of illicit funds between the 2 pools and how to mitigate/control any such contagion, nor will we develop a protocol for KYC compliance. Extension to many risk tokens, other pool formulas such as Hydra, Integral, Balancer, etc not possible
---
### Attainable Goal/Specific Objective (may be/likely to be achieved during the course)
We will develop a generalized concept for price discovery, reserve development, trade frequency analysis and fee earning model between a permissioned and a permissionless AMM pool construct in cadCAD to be further completed and refined after the training.
---
### Team Members
Henrik Axelsen (@haxelax)
Marc Minnee (Marc#9662)
---
### Team Skills
Good understanding of DeFi
Good understanding of traditional finance risk and compliance protocols
Intermediate python coding skills
Good Solidity, Tokenspice and cadCAD coding skills
---
### Lessons learned
1. Hugely interesting journey
2. Sharp learning curve, good to jump into the deep end of the pool and learn to swim
3. Even a “simple” AMM setup can be very tricky to implement
4. Agent based simulation is very complementary to a cadCAD/radCAD approach as it creates logic in agent policies and improve composability without the additional complexity
5. Articulating the detailed experiments requirements needed to answer the research question up front will make the journey more focused, but not necessarily easier
6. Need a bigger laptop
7. Windows and jupyter notebooks and monte carlo simulation = sloooowww. So, time for Apple or Ubuntu on separate harddisk partition. As Rudi already said long time ago..
---
### Further work
1. Finetune experiments, debug and finalize plot functions to match KPI requirements
2. Incorporate more token pairs
3. Incorporate Markowitz portfolio optimization arbitrageur agents
4. Incorporate external signals/oracles
5. Build Hydra, Balancer, Integral, Uniswap v3 etc
6. Real event data analysis from CEX/DEX to enable more realistic pattern analysis
7. Add lending/borrowing protocol
8. Add derivatives
9. Add regulatory requirements such as reporting, prudential, conduct requirements
---
### Github link
https://github.com/marc4gov/institutional-defi