V1: Deployment Logic

Note: The following is information related to Tokemak v1 , Tokemak v2 "Autopilot" docs are underway and will replace much of the below information.

General

Tokemak deploys a portion of its POA to venues based on the votes of the LDs while using LP provided assets as leverage (defined by the POA multiplier). A portion of these rewards generated by the POA are available to claim by accTOKE lockers.

There are several objectives/constraints when determining liquidity deployments. This system is referred to as the "Tokemak Allocator".

• Follow LD Votes

  Firstly the allocator determines deployments based on liquidity directors votes alone, ignoring all other constraints.

• Enforce Guardrails

  The allocator determines the available capital that can be used for deployments.

  • POA Multiplier (0.5x): Determines the amount of LP assets that can be deployed alongside the POA, both on the Reactor Token and Pair Asset (ETH) side resulting in a deployable amount of assets for those.

  • Available Pair Asset: If the quantity of deployable Pair Assets (eg. ETH) is insufficient to deploy all available liquidity, the ETH is pro rata distributed across the Token Reactors.

More detailed information on the guardrails can be found in the Guardrails & Impermanent Loss section.

The allocator iterates through the above process multiple times with two overarching goals;

• Maintain existing size of individual deployments

• Maximize total utilization of POA and LP assets

It is important to note that the above logic can lead to deployments that at first glance, may not add up. For example; the Token Reactor with the most TOKE/LD votes may not result in the most liquidity deployed if there are fewer POA or LP assets available relative to other Token Reactors.

Note that these are starting parameters and we will be able to significantly relax these as more data becomes available.

The above illustration depicts the mechanics of deploying liquidity to an outside trading venue

Deployment Logic & Equations

Based on POA (assets in reserve)

In a first step, the assets provided by the LPs (AssetLP) are passed through the first guardrail. The assets available owned by the protocol multiplied by the POA Multiplier determine the maximum amount of LP assets deployable (LPAsset_Deployable1). This guardrail is applied to both the Token Reactor assets and the Pair Reactor assets.

This guardrail is calculated based on Qty.

\begin{align*} &\text {IF $POA_{reserve} \times POAMultiplier \geq Asset_{LP}$} \\ &\ \ \ \text {THEN $ Asset_{LP} = LPAsset_{Deployable1}$} \\ &\text {IF $POA_{reserve} \times POAMultiplier < Asset_{LP}$} \\ &\ \ \ \text {THEN $POA_{reserve} \times POAMultiplier = LPAsset_{Deployable1}$} \end{align*}

Based on pair asset available to pair

In a second step, the system compares the amount of available pair assets (eg ETH) in the Pair Reactor (after applying the POA guardrail) to the LP provided assets in order to determine if all assets can be paired up with ETH. Should not enough ETH be available in the Pair Reactor, the system will proceed by equally distributing the ETH across the reactors.

This guardrail is calculated based on notional value.

\begin{align*} &\text {IF $LPETH_{Deployable1} \geq SumAssets_{Deployable1}$} \\ &\ \ \ \text {THEN $ETH_{Pairable}=1$} \\ &\text {IF $LPETH_{Deployable1} < SumAssets_{Deployable1}$} \\ &\ \ \ \text {THEN $ETH_{Pairable}= LPETH_{Deployable1} \div SumAssets_{AssetDeployable1}$} \\ &\rightarrow \ LPAsset_{Deployable1} \times ETH_{Pairable} = LPAsset_{Deployable2} \end{align*}