Note 6: Pooling Stability Funds

Author	Adam Kay
OIP-Number	1
Status	WIP
Created	2021-04-17

Issue to address with this note:

• How do we realize the potential for huge capital pools to stabilize the system by making yield on funding?

• How do we address the outstanding risk to the system that exists if funding is implemented as currently specified?

Context

A previous note explored the ability of a funding payment mechanism to incentivize yield hunters to balance the Overlay system directional risk. These actors seek yield on either OVL, ETH, DAI (or some other cryptoasset), without taking directional risk. In this note they will be called investors. In practice there are some difficulties with the approach:

1. The funding mechanism as outlined in OIP1 can only ever damp the risk to the system, never eliminate it.
   1. Investors are incentivized to make their balancing trades as small as possible.
   2. If we enforce a minimum size to a trade to collect funding, it must always be much less than the imbalance.
2. The current mechanism design leads to undesirable side-effects.
   1. Balancing trades must occur in the last moment before oracle fetch.
   2. It is not possible to know the imbalance exactly without knowing which transactions in the mempool will be mined in the same block as an oracle fetch.
   3. Last-minute competition can lead to ‘overshoot’, where investors tip the imbalance to the other side and pay funding.
   4. Parasitic capital can gather funding without reducing risk to the system (this will be the main use of the mechanism).
3. Collecting funding is a specialized activity.
   1. To remain profitable, investors must remain nimble, reacting quickly to changes in the imbalance.
   2. Investors must keep track of an increasing number of markets.
4. Collecting funding is expensive.
   1. A funding round trip using ETH or DAI involves buying OVL, locking OVL, unlocking OVL, and selling OVL. This means paying gas and trading fees 4 times each.
   2. Any automation of funding strategies (as in the case of mOVL, mDAI, mETH) will generate front-running strategies.
5. The current mechanism has negative feedback that limits its size.
   1. By 3.1 and 4.1, investors must be nimble to make yield, but this means HFT, which decreases yield through fees.
   2. The greater number of active investors, the more fee competition and overshoot, reducing investors.
   3. By 3.2, the more the system scales, the greater the technical debt for investors, limiting investors.
   4. Problem 4.2 insures that the larger funding becomes, the more front-running, the smaller it becomes.

Problem 1.1 entails that OI caps in one direction could be hit while prices move rapidly. The OVL supply would then inflate significantly. Thus, in extreme cases, the funding mechanism does not fulfil its primary purpose.

The issues collectively seem significant. Because the effectiveness of the funding mechanism is a bottleneck for the system itself, unless these issues can be solved the system cannot scale.

Fortunately, all but one of the above issues can be solved at one time, by distinguishing between traders and investors. Before presenting the solution, however, we show why we must distinguish between them.

Parasitic Capital

Problem 2.4 makes it imperative to distinguish between traders and investors. To get the basic idea across, pretend for a moment that there are two traders on DAI-OVL. One has gone long with size \(n\), and the other has gone long and short, both with size \(N>n\). The imbalance is \(n\), and after one funding period the longs must pay \(kn\), which goes to the short side. In that time, say DAI-OVL rose by \(r\) percent. To update PnL, there will be two mint and one burn calls to the market contract, plus whatever calls are made to effect funding transfers. The first trader has \[n\Big(1 +r - kn\frac{n}{n+N}\Big)\] while the second trader has \[N\Big(1 +r - kn\frac{N}{n+N}\Big) + N(1 - r + kn) = 2N + kn\frac{n}{n+N}\]

This shows that funding can be collected passively without being nimble or even worrying about trading, by simply taking the long and short side in equal parts. This is a weakness of the current funding mechanism since it represents parasitic capital. There is every reason to think that a significant amount of OI will be given over to this type of trade.

Passive Balancing Pools

Funding must flow from OI on the market contract to OI on a different type of contract, to which investors which balance trader OI will deposit. What should the investor contract look like?

It is clear that we cannot have passive pools of locked OVL tracking the value of OVL, DAI, or ETH, because this simply shifts the inflation problem to the investor pools. Since these pools are likely to be large, the problem would be worse. Thus, we need pools of unlocked OVL, along with pools of DAI and ETH (and WBTC and any other base currency we care to list).

In fact, the idea of magic tokens is almost the same as a passive balancing pool. The way the magic contracts would work as proposed in OIP-1 would be to automate the swaps and Overlay calls required to enter balancing trades. It is clear that these swaps must be entered and exited opportunistically, each funding period. The majority of the magic pools would be passively sitting, denominated in OVL, ETH, and DAI, while a small amount of it would be deployed at any time to balance trader OI.

If the funding mechanism is implemented as currently specified, the magic tokens are subject to all the problems above. However, since a distinction between traders and investors is forced on us, we may treat the investors differently than the traders. This represents no system risk since all investor trades are automated by our contracts.

If the Overlay system allowed the magic contracts to make swaps immediately after an oracle fetch and receive the last price (rather than the next one, as traders using the market contract would receive), then the imbalance could be eliminated entirely. More precisely, the logic would be:

1. Traders taking positions using the market contract generate an imbalance \(I\) after the oracle fetch at \(t_0\), getting price \(P_0\).

2. On block \(t_0 + 1\), the magic contract makes the required swaps on an AMM. If \(I>0\) then ETH or DAI is sold for \(I\) worth of OVL. Otherwise \(I\) OVL is sold for ETH or DAI. The price \(P_0\) is saved and associated with this swap.

3. Whenever a trader unwinds at price \(P(t)\), the return \(nr\) to this trader is not generated from a mint or burn call, but a transfer call, either from the \(I\) OVL held by the magic contract, or to it.

4. The magic contracts exit their positions gradually as imbalance changes, or all at once as it changes sign.

Discussion

The funding mechanism has promise but requires significant tuning to fulfil its purpose. The main problems are 1.1 (imbalance can never go to zero), 2.4 (parasitic capital) and all problems 5 (the mechanism is beset with negative feedback).

All of these problems are bugs resulting from the failure to separate traders and investors. Once this separation is forced on us (which it is), it is clear that all funding must flow from traders to investors. This will probably require the funding rate to be lower, since traders are never collecting funding. The \(k\) constant can be tuned depending on trader and investor behavior (rather than, or in addition to, the current factors involved in tuning).

Luckily, separating traders and investors allows us to resolve problems 1, 2, 3, and 5, and all their subproblems. One of the most significant results of this mechanism is that problem 1.1 is resolved. The risk to the Overlay system on markets balanced by investors is zero. This solves the inflation problem completely.

Another very significant result is that the negative feedback of problem 5 becomes positive feedback. Investors do not need to be nimble to make yield, resulting in fewer fees and thus higher yield. There is no fee competition or overshoot. The more the system scales, the larger the yield opportunity with the same level of technical debt. Most significantly, it is clear that the OI caps for the traders should be identified with the depth of the passive pools. Since these pools are likely to be large, the trader caps can be large, increasing volume, and thus increasing yield, and thus increasing pool depth in a positive feedback loop.

The last problem (#4) involves the expense of making four trades to collect funding, along with the concomitant front-running into and out of OVL on an AMM that is sure to emerge. This may be unavoidable. In any case we leave it to a future discussion.