Systematic way to set up pool parameters in the Levva protocol
In this post we discuss the systematic approach one should take when deciding on pool launch with sustainable parameters for smooth production operation.
The first L2 network we launched Levva at is Arbitrum. Arbitrum is a leading L2 solution with great DAO and foundation support. Arbitrum L2 is well known for its strong perp DEX DeFi. Protocols like GMX, GNS, and MUX all operate on Arbitrum, while there are numerous others that mimic their functionality. The leveraged trading landscape is very competitive in Arbitrum, and Levva fits perfectly into this paradigm: we build innovative leverage primitives that push the boundaries of DeFi further forward.
Pools
Levva is a permissionless leverage protocol. We have built Levva’s business logic and smart contracts with dependence on Uniswap v3 pools and TWAP oracles. This fact makes Levva a fully decentralized leverage primitive. This also means that anyone can open their own pool as long as there is a corresponding uniswap v3 pool. However, traders are not limited to speculating only on the Uniswap. Levva supports every major Spot DEX inside Arbitrum via our custom-built router.
We plan to open 6 pools for the mainnet launch. Corresponding Uniswap v3 pools with their respective (at the time of writing) liquidity are presented in the table below.
Risk parameters
To launch smoothly and mitigate possible risks related to volatility and liquidity of underlying assets, we need to carefully consider consistent values for all of the Levva pool parameters
In this article, we would like to outline the details behind risk-related parameters. These parameters are the following:
Now let us briefly cover the steps we take to define each of the parameters above.
Maximum Leverage
- Fit historical returns to Jump-Diffusion distribution: find mean, standard deviation, and jump intensity.
- Simulate 10000 1-year return series using estimates from above.
- Calculate the average worst 1% daily return over all simulations.
- Calculate max leverage = 1 / worst return.
It's worth noting here that tokens besides BTC and ETH don’t have sufficient price and return history, as they’re relatively new. We take this into account by further adjusting calculations for ARB, PEN, GMX, and RDNT tokens.
This process gives us the following values of the maximum leverage parameter for each pool (we adjust the values slightly to make them whole numbers, actual values we got from simulations are specified in parenthesis):
Interest rate
In Levva, interest rate is proportional to asset volatility. To assess volatilities we follow this approach:
- Calculate volatility cones and historical volatility distributions and come up with volatility estimates.
- Find Normal confidence intervals for our volatility estimates.
- Use upper confidence value for volatility parameter for interest rate parameter calculations.
We use daily volatility figures and the numbers are as follows:
We then set interest rate parameters from volatilities by using a scaling coefficient which is by default set to 15 (to roughly target the 100% interest rate at maximum volatility).
More details on the process of volatility estimation are described in Levva docs. Newer instruments like the PENDLE (PEN) token, for example, don’t have enough return data for historical volatility to be approximately normally distributed. Rather, volatility distribution looks like a mixture of two normal distributions with two distinctive peaks. In this case, we consider the right-hand side confidence interval of the right peak:
TWAP
An increasing number of DeFi protocols, Levva included, use Uniswap v3 price oracles. These oracles take the average of the spot price on Uniswap v3 for an asset over some specified period in the past and provide time-weighted average price (TWAP) for an asset, rather than current price.
Although truly decentralized, and much more resilient than the spot prices available on-chain they are nonetheless still susceptible to manipulation. It is crucial for protocols and liquidity providers (LPs) to understand and be able to quantify the risks involved in using these oracles.
At Levva we’ve adapted the great uniswap oracle attack simulator by Euler Finance to work with Arbitrum-based uniswap pools. We then analyze how much capital is required to move 30 min TWAP up or down the worst 1% simulated daily return within 1 block. All the assets except for RDNT and PEN are not susceptible to these kinds of attacks as they require hundreds of millions of dollars to execute. However, since both PEN and RDNT token pools are not very liquid, they require anywhere around $1M in attack funds and $500K in costs to manipulate. This is why we propose to use one-hour TWAP for these tokens.
Liquidity Limits
As a general rule of thumb Levva pool is an aggregate trader on corresponding uniswap pool. We don’t want this trader to become large enough to affect uniswap liquidity and prices in any material way.
We’ve analyzed current and historical liquidity levels in all of the corresponding Uniswap v3 pools and derived approximate liquidity limits based on the price impact that they can have if traded all at once on Uniswap. We wanted this price impact to be less than the worst 1% simulated daily return. Here’s what we ended up with (The last column contains the limit we will use for the pool):
Other parameters
Other pool-related parameters that we need to carefully assess relate to protocol fees, minimum trade parameters, and slippage. The trickiest here is probably the slippage: you can educate yourself about this problem in greater detail by reading this excellent Uniswap blog post
In Levva we set the slippage parameter to 1% by default for all supported pools. Fees are also unified: users will pay 0.1% swap fees when they open and close leveraged trades, as well as a 2% interest fee on top of the standard interest rate. As for minimum traded amounts they are all around $1 - $5:
