# Sifchain Subsidy Program

A subsidy program aims to increase participation and subsequently adoption of a system. Typically a pre-specified amount of tokens are allocated towards subsidy disbursements per time period. Subsidies are disbursed to participants in proportion to each qualifying event that they contributed towards.

In the case of a referral-based subsidy program, we have $n$ referrers who are already a part of the system. They make referrals to $m$ referees encouraging them to participate in some activity in the system. The referee needs to perform an *action* $a$ that results in a qualifying event. A *qualifying event* $q$ is an event that qualifies the referral as one that warrants a subsidy.

The referral graph can be imagined as comprising several $n \rightarrow m$ connections; connections representing referrals. A subsidy policy is applied to every connection to evaluate if the connection is valid; i.e. if the referral results in a qualifying event.

Referrer $n$ made referrals to three referees $m_1$, $m_2$ and $m_3$. $m_1$ received the referral and did not act. $m_2$ performed an action that did not result in a qualifying event. $m_3$ performed an action that resulted in a qualifying event and thus, their referral warrants a subsidy. The connection $n \rightarrow m_3$ is weighted $q_3$ to represent the amount based on which the subsidy will be computed.


A subsidy program needs to satisfy the following requirements:

> **Requirement 1**
>> The susbsidy program can disburse a maximum of $\mathbf {S_X}$ quantity of tokens per time period. This forms the budget of the program.
>
> **Requirement 2**
>> The tokens must flow from the $\mathbf{S_X}$ pool to the circulating supply $\mathbf {S_C}$ as subsidies.
>
> **Requirement 3**
>> The events must be recorded with respect to time. In a bucket-based subsidy program, events need to be batched based on the time period in which they occured. The subsidy is computed based on the batch parameters. In an event-based subsidy program, the event sequence is used to compute the subsidy neccessiated by a qualifying event.

Generally, a subsidy program can adopt one of two types:
1. Event-based
2. Batch-based

#### Event-based Subsidy Program
Event-based subsidy programs are continuous, and disburse subsidies computed based on variables related to the qualifying event independent of the time period of occurence.

#### Batch-based Subsidy Program
Batch-based subsidy programs batch together several events that occur within a pre-specified time period (days, weeks, months). The subsidy is computed based on the subsidy parameters set for that time period and is disbursed at the end of the time period.

## Sifchain Subsidy Program

We design a 12 week batch-based subsidy program that batches events and disburses subsidies weekly. Each week, the subsidy parameters can be adjusted to reflect a different subsidy amount allocated towards that time period.

The subsidy program aims to increase adoption and engagement with the Sifchain DEX. In the Sifchain system, subsidies are given to reward referral activity. Referrals are the *actions* that could result in *qualifying events*.

Given this generalized subsidy program framework, the Sifchain System Income subsystems can characterize their individual subsidy policy based on the subsystem's existing flows or mechanisms.

To satisfy Requirement 1, each subsystem has allocated an upper limit on subsidies to be disbursed over the time period. This is represented by $\mathbf {S_{VS}}$ for the Validator Subsystem, $\mathbf {S_{LS}}$ for the Liquidity Provider Subsystem and $\mathbf {S_{SS}}$ for the Swapping Activity.

As subsidies realize, tokens from the $\mathbf {S_{VS}}$, $\mathbf {S_{LS}}$, and $\mathbf {S_{SS}}$ pools deplete as they are paid out as subsidies, thus flowing into the circulating supply $\mathbf {S_C}$ of the Sifchain system.

## Liquidity Provider Subsidy Policy

Liquidity Provider subsidies are disbursed in addition to the Liquidity Provider rewards to incentivize LP participation in the Sifchain system. Deriving from the generalized subsidy framework, LP subsidies are batched on a weekly basis and disbursed at the end of each time period $T$.

Let $\mathbf r_{\pi,n}$ be the reward earned by a liquidity provider, normalized per time period which accounts for the amount of LP's tokens locked up in the liquidity pool and the duration of lock up.

As the normalized LP reward $\mathbf r_{\pi, n}$ flows in from the revenue generated through swap fees, $\mathbf r_{\pi,n}$ is directly proportional to the control parameter $\lambda_l$ on swap fees. At the same time, we need to ensure that the subsidy falls within budget as imposed by Requirement 1, thus needing to keep track of the amount of subsidy allocated to the LP subsystem $\mathbf {S_{LS}}$ available. The liquidity provider subsidy may be expressed as

$$ \mathbf {d_L} = f(\mathbf {S_{LS}}, \mathbf r_\pi, \lambda_l)
$$

$$ \mathbf {d_L} = \mathbf {S_{LS}} . \mathbf r_\pi . \lambda_l
$$

such that $\mathbf r_\pi . \lambda_l < 1$

### Token Geysers
Alternatively, we recommend the [Token Geysers](https://github.com/ampleforth/token-geyser) model for computing and disbursing Liquidity Provider subsidies
> A [document explaining Token Geysers smart contract](https://hackmd.io/@shrutiappiah/HJKNKVKnD) is presented here.

> Furthermore, the [Token Geyser Smart Contract](https://github.com/ampleforth/token-geyser/blob/master/contracts/TokenGeyser.sol) can serve as a basis for developing detailed specifications around the subsidy for this subsystem.

> For more info on Token Geysers, read about their implementation on Honeyswap in [Honeyswap Docs](https://about.1hive.org/docs/honeyswap/)

## Validator Subsidy Policy
At a given release time the subsidy will be proportional to the block rewards earned over that time. A validator must have earned block rewards $\mathbf{b}$ to be eligible for subsidy rewards.

The subsidy given to validators, $\mathbf{d_{V}}$ is a function of the event triggering action $\mathbf{b}$, the amount of subsidy available $\mathbf{S_{VS}}$, determined at a set time period, $T$.

$$\mathbf{d_{V}} = f(\mathbf{S_{VS}}, \mathbf{b}, T) $$

The block reward policy without subsidy is here:
$$\mathbf{b}(f(\lambda_v))=\frac{I \cdot\mathbf{S}}{\beta}+ f(\lambda_v) \cdot \left[ \frac{ i \cdot {\gamma_v} \cdot \mathbf{S}}{\beta^2} - \frac{i \cdot \mathbf{S_v} }{\beta^2} \right] $$
where the control parameter $\lambda_v$ influences the update to the inflation rate over minted block rewards, in the following manner:
$$\mathbf{b}(\lambda_v)=\frac{I \cdot\mathbf{S}}{\beta}+ |2\lambda_v-1| \cdot \left[ \frac{ i \cdot {\gamma_v} \cdot \mathbf{S}}{\beta^2} - \frac{i \cdot \mathbf{S_v} }{\beta^2} \right] $$

We seek to provide additional matching rewards as some multiplier of earned minted block rewards. This matching reward should be released in timed-batches. $\lambda_v$ moves in the direction of needed rebalancing. It increases where more economic activity is desired in the validator subsytem. It decreases where less economic activity is desired in the validator subsytem. Therefore, it could be expected that any changes to the subsidy rate will increase or decrease in the same direction as $\lambda_v$.

$$\mathbf{d_{V}} = f(\mathbf{S_{VS}}, \mathbf{b}, T, \lambda_v) $$

We can further attenuate the release of subsidies with a coefficient, $G$, controlling the portion of available subsidies released. If the rebalancing policy dictates that the change in inflation is effectively turned off, i.e. $\lambda_v \approx 0$, then the release of validator subsidies will also effectively be turned off.

$$\mathbf{d_{V}} = f(\mathbf{S_{VS}}, \mathbf{b}, T, \lambda_v, G) $$

Over each timed release of subsidies, a product is used to determine the validator subsidy rewards.
The total subsidies released would be:
$$\mathbf{d_{V}} = \mathbf{S_{VS}} \cdot \mathbf{b} \cdot \lambda_v \cdot G $$

And the susbidy given to each validator would maintain that proportionality to the block rewards earned for each validator:
$$\mathbf{d_{V}} = \mathbf{S_{VS}} \cdot \mathbf{b^i} \cdot \lambda_v \cdot G $$

## Subsidies for Swappers

Sifchain will run a 12-week subsidy program to award subsidies to all swappers on the Sifchain liquidity pools.

### Requirements
In this design proces, we need to ensure that this program has certain properties. These are formulated into requirements:

> **Requirement 1**
> The subsidy funds are distributed proportional to remaining funds available, so that the program stays within budget.
>
> **Requirement 2**
> The subsidy distributed for each swap event where fees are incurred is less than or equal to the fee incurred.
>
> **Requirement 3**
> The funds are distributed over the course of the time interval. In this case, it's 12 weeks.

### Notation Table

| Name | Description | Symbol |
|----|----|----|
| Index | Index of swap event | $k$ |
| Time | Time passed since bootstrapping program start | $t$ |
| Time remaining | Time fraction that is remaining until the end of bootsstrapping program end | $\tau$ |
| Swapper subsidy funds | Amount of subsidy funds allocated towards swapping activity remaining | $\mathbf {S_{SS}}$ |
| Swap fee | Fee incurred while performing the $k^{th}$ swap | $f_k$ |
| Raw subsidy | Raw amount subsidized on the $k^{th}$ swap | $d_{raw}$ |
| Capped subsidy | True amount subsidized on the $k^{th}$ swap | $d$ |

### Swapper Subsidy Policy
The subsidy $d_{swap}$ will proportionally eliminate the fee $f_{swap}$ associated with each swap, such that at the end of the 12-week bootstrapping period, the subsidy awarded to a swapper is negligible.

$$
d_{swap, initial} = f_{swap}\\
d_{swap, final} = 0
$$

If a swapper swaps at the start of the subsidy program, they will effectively incur no fee.

$$
\mathbf S^+_{\mathbf L,initial} = \mathbf {S_L} - f_{swap} + d_{swap, initial} = \mathbf {S_L}
$$

Let the total amount allocated towards subsidies for swappers be $\mathbf S_{\mathbf {SS}, initial}$.

$$
\mathbf S_{\mathbf {SS}, k = 0} = \mathbf S_{\mathbf {SS}, initial}
$$

This pool funds the subsidy on swapping activity, so it decreases with every swap according to the following state update function.

$$
\mathbf S_{\mathbf {SS}, k} = \mathbf S_{\mathbf {SS}, k-1} - d_{k-1}
$$

This may also be expressed in the alternate notation.

$$
\mathbf S_{\mathbf {SS}}^+ = \mathbf S_{\mathbf {SS}} - d_{k-1}
$$

The subsidy aims to offset the fees incurred by the swap in a way that is proportional to the remaining bootstrapped funds. This is to ensure that the subsidy satisfies Requirement 1.

$$
d_{raw, k} = f_k \frac{\mathbf S_{\mathbf {SS},k}}{\mathbf S_{\mathbf {SS}, initial}}
$$

The true subsidy is the minimum of the fee incurred through the swap and the raw subsidy. This ensures that the subsidy satisfies Requirement 2.

$$
d_k = min(f_k, d_{raw, k})
$$

The above model is event-based. In order to integrate it with the time-based specification of a *12-week bootstrapping program*, we need to keep track of time remaining until the end of the program. This ensures that the subsidy satisfies Requirement 3.

We define the time fraction remaining until the end of the bootstrapping program $\tau_k$ as

$$
\tau_k = \tau_{k-1} - t_k
$$

Logically following that $\tau$ is initialized as 1

$$
\tau_{k, initial} = 1
$$

The following plot shows how the bootstrapped funds deplete with each swap event.

**Bootstrapped funds remaining vs. remaining time**

Refer the [spreadsheet-based policy experiment](https://docs.google.com/spreadsheets/d/1k3G9j82w64az6bMxyf73Z6E5zFQgYlbvRUA6sqyMoPw/edit?usp=sharing) to play around with the parameters.

------------
------------
## NOTES

Swapper subsidy with fee offset and extra reward tokens on top - rough structure

$$\mathbf {S_L}-\mathbf {S_{L,param}^+}=(1-G) \left((1-\lambda_l) \frac{\mathbf m \mathbf{S_L}}{\mathbf m+\mathbf{M_L}} + \lambda_l\frac{\mathbf{m}\mathbf{S_L}\mathbf{M_L}}{(\mathbf{m}+\mathbf{M_L})^2}\right) + G(X)$$

We give the swapper some fraction of $\mathbf {S_B}$ according to the function:

$$
a_{swap} = p*f_{swap}
$$

where $p$ is a parameter such that $p_{initial} = 1$ and $p_{final} = 0$

$$\mathbf S_{\mathbf B, initial} = \mathbf {S_B}$$
$$\mathbf S_{\mathbf B, final} = 0$$

Quantity of tokens to be allocated towards awards - $S_B$
Duration of bootstrapping period - $t$
Fees incurred - $\phi_k$, same as $f_{swap}$
Index of swap event - $k \in [0,K]$ where $K$ is the final swap

Sequence of fees incurred - $\phi_0, \phi_1, \phi_2 ... \phi_K$

At each swap event, compute a subsidy $a_{swap}$ to offset the fees incurred $\phi_k$, given the total pool $S_B$

$0 \leq s_b^+ \leq \phi$

## Properties
1. Funds are distributed proportional to the remaining funds so that we stay within budget $S_B$
2. Funds are distributed over the course of the time interval $t$
3. Funds distributed for each swap event should be less than or equal to the fee incurred

$a_{swap} = f_{swap} * \frac{funds remaining}{total funds}$

$$a_{swap, k} = f_{swap, k} * \frac{S_{B,k}}{S_{B, 0}}$$

$$a_k = \phi_k * \frac{Q_k}{Q_0}$$

## Liquidity Provider Subsidy Policy

Liquidity Provider subsidies may be disbursed along with Liquidity Provider rewards. Deriving from the generalized subsidy framework, LP subsidies are batched on a weekly basis and disbursed at the end of each time period $T$.

Let $\mathbf r_\pi$ be the reward earned by a liquidity provider per time period which accounts for the amount of LP's tokens locked up in the liquidity pool and the duration of lock up. As the LP reward $\mathbf r_\pi$ flows in from the revenue generated through swap fees, $\mathbf r_\pi$ is directly proportional to the control parameter $\lambda_l$ on swap fees. The liquidity provider subsidy may be expressed as

$$ \mathbf d_l = f(\mathbf r_\pi, \lambda_l, T)
$$

## Validator Subsidy Policy

The block reward policy without subsidy is here:
$$\mathbf{b}(\lambda_v)=\frac{I \cdot\mathbf{S}}{\beta}+ \lambda_v \cdot \left[ \frac{ i \cdot {\gamma_v} \cdot \mathbf{S}}{\beta^2} - \frac{i \cdot \mathbf{S_v} }{\beta^2} \right] $$
where the control parameter $\lambda_v$ influences the update to the inflation rate over minted block rewards.

We seek to provide additional matching rewards as some multiplier of earned minted block rewards. This matching reward should be released in timed-batches. Because $\lambda_v$ moves in the direction of needed intervention. It increases where more economic activity is desired in the validator subsytem. It decreases where more economic activity is desired in the validator subsytem. Therefore, it could be expected that any changes to the subsidy rate will increase or decrease in the same direction as $\lambda_v$.

$$\mathbf {S_{VS}} = f(\mathbf{b}, \lambda_v, T) $$