###### tags: `documentation` `design`

# Trading and Arbitrage Strategies for the AssetFlowControlSystem

[](https://hackmd.io/WyT3EI6XTEScv1zP3875hQ)

First we have to display a very basic set of variables and parameters which would be used for every of our strategies.

## 2 Asset Subsystem

For the sake of simplicity we first look at 2 assets. We call `primaryAsset = P` and `secondaryAsset = S`.

### desiredAsstFractions
- `desiredAssetFractionP = dAFP`
- `desiredAssetFractionS = dAFS`

Which are arbitrarily defined.

### currentAssetFracions
- `currentAssetFractionP = cAFP`
- `currentAssetFractionS = cAFS`
- `currentAssetVolumeP = cAVP`
- `currentAssetVolumeS = cAVS`
- `currentAssetPrice = cAP` (price in $P/S$)
- `totalAsstVolume = tAV`

#### Relations

---

$$
cAVS_P = cAVS_S * cAP_{P/S}
$$
$$
tAV_P = cAVP_P + cAVS_P
$$
$$
cAFP = cAVP_P / tAV_P
$$
$$
cAFS = cAVS_P / tAV_P
$$

---

These are the effective `assetFractions` we have when considering the `currentAssetPrice`.

### currentAssetPrice
...

### virtualAssetFractions
- `virutealAssetFracionP = vAFP`
- `virtualAssetFractionS = vAFS`

These are aribrarily set and adjusted by the Strategy itself.
It reflects moreso what the Strategy believes is the current optimal `assetFraction` to generate the most usable `assetExcess`.

### assetExcess
- `assetExcessP = aEP`
- `assetExcessS = aES`

$$
aEP_P = cAVP_P - vAVP_P
$$
$$
aES_S = cAVP_S - vAVP_S
$$

Here we either could say that the `assetExcess` might also become negative or use the `assetDeficit = -assetExcess` as a separate value.

## Strategy Specifics

Regarding this set of variables we can reduce the responsibility for the Strategy to 2 points.

1. generating the `virtualAssetFractions`
2. dealing with the `assetExcess`

### Robust Volatility Arbitrage Strategy

We start with one `sellHead`.

#### Initial sellHead
The `sellHead` starts selling at current latest asking price -> `initialPrice`.
We sell the `volume` = `minimalAssetBagSize` (= 0.02ETH for example).

$$
aEP_P = cAVP_P - vAVP_P
$$

#### eaten sellHead
When the sellHead becomes eaten we place a buyBackOrder and a nextSellHead.

nextSellHead
distanceFactor = 1 + (minimalDistancePercent / 100) * (magnifier^round)
sellPrice = initialPrice * distanceFactor

Where the magnifier is a base we decide on probably most optimal 2.
And the round is indicating the number of previously eaten sellHeads in series.
Also we get the new volume as:

volume = minimalAssetBagSize * (magnifier^round)

This way we increase the stakes for every eaten sellHead.
buyBack
If we have an 1 then we will take them together to become one single buyBack.

Most relevant here is the buyBackDistance (e.G. 2% -> buyBackDistanceFactor = 0.98)

newBuyPrice = sellPrice * buyBackDistanceFactor
volume = oldBuyVolume + sellVolume
oldWeight = oldVolume / volume
newWeight = oldVolume / volume

buyPrice = newWeight * newBuyPrice + oldWeight * oldBuyPrice

What this entails
As soon as the one buyBack is eaten we exit with a profit.
As long as exclusively the sellHeads become eaten we have to sell exponentially more assets. And in this case also the buyBack will adjust upwards to make it more likely it would become eaten..
As soon as the last affordable sellHead was eaten, we can only wait for the last buyBack to become eaten^^.... this is the only trap.

So in the non optimal case we are reset to 0 on one asset and +profit on the other asset after the buyBack was eaten. As long as the buyBackDistance is bigger than the minmalDistance we may move both up-and downwards.

In addition to that we can of course also have the algorithm running in superposition with the version where the assets to sell and buy are just switched. ;-)
This would be the optimal case for keeping both assets 50:50 while profiting from the volatility and not being vulnerable to large market movements.