Back test of BED:ETH price ratio

Hi All,

I’m heavily involved in INDEXcoop and trying to think about our products and maintaining liqudiity.

With the passing vote on IIP-54, I’ve been looking at backtesting the behaviour of BED:ETH pair on uniswap.

My goal is to try and understand how much the prices diverge over time between / rebalances as this will be a key consideration in setting liquidity ranges on Uniswap v3. Instinctively I think BED:ETH should be pretty stable, but I wanted some data to work with.

Data was downloaded from Coingecko (in both USD and ETH terms) and then manipulated in a spreadsheet.

This analysis assumed that there were no significant spikes in ETH:DPI or ETH:BTC prices between this daily checkpoints.

This is my progress to date:

Note, most of this data is presented in ETH price terms as that is what the liquidity pool will be. It always takes me some time to move from thinking about USD to ETH value, but it is well worth this mental juggling to understand the liquidity pair.

The first chart looks at the components and a simple 1/3 ETH, 1/3 DPI and 1/3 wBTC fund held (without rebalencing) since the start date all prices in ETH. Overall the chart isn’t that informative with DPI and wBTC underperforming ETH over the last 10 months and BED being intermediate.

Chart 1

Overall, it looks like the cold wallet BED has stayed in a range between +0 and -38% vs ETH since creation on 14th September.

This indicates that a very large liquidity range may be required. However, if we assume that the liquidity will be repositioned, it makes sense to look at a range of start dates.

If we just look at buying BTC, ETH, & DPI and hold them cold on the 1st of each month, the chart for the untokenised BED looks like this ugly mess:

Chart 2

image

This is actually more worrying as it implies that there are times when a static (non-rebalancing) BED can undergo significant price changes vs ETH (e.g. 01Mar21 +25% to -35% in 10 weeks). Such a profile implies that we may need large TLV in the pool, or be repositioning it on a frequent basis.

Following this, I looked at what would happen if we rebalance BED each month:

  1. 1st October: Equal values of wBTC, DETH and DPI were purchased, then the portfolio performance was tracked over the month.
  2. 1st November the portfolio value is calculated, and then redistributed 1/3 : 1/3 : 1/3 and allowed to run another month.
  3. Repeat until 14th July 2021.

Note, this calculation is not perfect as the recalculation is assumed to happen over 24 hours with no relative price changes - however, the error is expected to be small

Chart 3
image

Note, this calculation is not perfect as the recalculation is assumed to happen over 24 hours with no relative price changes - however, the error is expected to be small

Compared to the first figure, the rebalancing has a few impacts starting from the 1st October 2020:

  • BED actually out performed ETH in March
  • The drawdown in May was slightly better for the rebalanced BED

Overall the maximum drawdown expected is reduced slightly to ~40% over 10 weeks.

The fourth chart assumes that BED is rebalanced every month (on the 1st) and then looks at the price divergence over the next 40 days (Reblanences may not happen on exactly the same date each month, so adding a few days extra allows us to consider this).

Chart 4

This indicates that starting on any particular 1st of the month, the price divergence is between -30% and +15% over the following 40 days. In addition for the first 7 days, the range is -12% to +8%.

However, while this is pretty encouraging for positioning/repositioning liquidity, there is a possibility that there are more rapid changes hiding in the middle of the data. So, I repeated the process starting every Monday…

Chart 5

As expected it takes some time for the prices to diverge with at least 4 days to exceed a 10% change and 15 days to pass 20% (although it’s close to 20% after 8 days in 1 case).

Using the same data it’s possible to build a heat map of when the price moves past a given % from the starting point:

Table 1

I think this is the most useful visualisation. How we can use it depends on what we are trying to achieve:

  1. Ensure liquidity at all times
  2. Ensure deep liquidity close to the likely price point for as long as possible
  3. Allow additional depth for buying BED at launch.
  4. Maximise fee income for the LP (Where being out of position for short periods may be preferable to being spread too widely).
  5. Reduce the need to reposition liquidity

For example, a +/- 12.5% range would have been in the range after:

  • 15 days 95% of the time
  • 40 days 70% of the time

And so on.

Please note: I’m mainly looking at this data from a product point of view., i.e. what we are trying to do to make things better for traders/purchasers (and not necessarily best for myself as the LP):

  • My objective is keeping a deep pool for trades at all times with acceptable (i.e. infrequent) repositioning work.
  • If the goal was maximising fee income, then the optimum design for positioning liquidity might be different.

I’m happy to bounce a few ideas of people re v3 liquidity ranges based on this data.

Regards

OA

6 Likes

For those thinking of being an an LP on uni v3, I’ve also written a blog on my experience to date.

3 Likes

Great analysis here @OverAnalyser !

I just read through your blog post - experiment on being a uni v3 LP as well.

For those considering being an LP in Uniswap v3 for BED Index - how “active” should one expect to be?

I’m pretty new to being an LP (not a degen) - what’s your recommendation in this regard? Would it be more prudent to start with a more passive pool?

I always thought BED:ETH is going to have a pretty stable pair and so pretty safe.

Also, “Rekt” for this pair means you will end up 100% ETH or 100% BED - not something to complain about. (My MVI:ETH v3 experience lost me ~25% vs holding, but compared to swaping to 100% ETH on the 26th June, I’m 2 ETH UP).

If the goal is to have some skin in the game and to get a feel for being an LP, then I would go wide, +/- 30%, You will get minimal fee income (much less than Average for the pool). But your divergence loss will be less. Also, you are less likely to be forced to reposition at inconvenient times [If history repeats, you have 40 days in range earning income].

If you are an experienced LP, and have a larger position, then going tighter should earn more fees, but will require more attention and gas. Even then, I wouldn’t consider going less than +/- 10% on L1 as the gas costs will eat into the fees.

Another consideration is that the repositioning could be taxible events, so more to track and crystallised profits/losses when you may want to avoid them.

One final consideration is whether to be off centre. Historically BED has underperformed ETH so most times the market price is below the starting point. However, on launch I’m hoping for buy → arbitrage issue–> buy → arbitrage issue cycle. So the pool will be bouncing up above NAV. (But NAV moves over time).

At INDEXcoop we are considering multiple positions (wide, moderate, narrow, and offset) to run in combination. The latter could be -3% to + 10% to make the pool deeper for buyers so they have less price impact and arbitrage kicks in at a lower premium. The offset will require more management, and may not be profitable, but it generates a better experience for our users.

2 Likes

Thanks for such a detailed answer @OverAnalyser - this is gold and really educational.

I’m going to have to look into the strategies you lay out:

  • wide
  • moderate
  • narrow
  • offset

Now that you’re describing what LP-ing means (i’m quite sure i’m doing it in a very naive way - I did a mini-test of ETH/UNI in a v2 pool - set it once and haven’t looked at it :sweat_smile:).

Thanks again, looks like I got some homework to do :pray:

1 Like

There is some more discussion on the strategy in the INDEXcoop forum.

I’ll likely expand here on the coops plans here (Cross post of this, but will the dicscussion will progress towards what we actually deploy):

2 Likes

Moving to archive. Please reply to reopen.