ACX like CRV


The initial supply of ACX is 500 million tokens, which is 40% of the eventual t → ∞ supply of ≈1.25 billion tokens. All of these initial tokens are gradually vested (with every block). The initial inflation rate which supports the above inflation schedule is r = 18% (225 millions per year). All of the inflation is distributed to Acxyn game developer liquidity providers, according to the GGV. During the first year, the approximate inflow into circulating supply is 616,438 ACX per day. The initial circulating supply is 0.

## Liquidity Gauge with the GGV

Inflation is directed to users who provide liquidity within the protocol. This usage is measured via “Liquidity Gauge” contracts. Each pool has an individual liquidity gauge. The **Gauge Controller** maintains a list of gauges and their types, with the weights of each gauge and type. The GGV will help decide the amount of inflation directed back to game devs providing liquidity.

To measure liquidity over time, the user deposits their LP tokens into the liquidity gauge. Coin rates which the gauge is getting depends on current inflation rate, gauge weight, and gauge type weights and GGV score. Each user receives a share of newly minted ACX proportional to the amount of LP tokens locked. Additionally, rewards may be boosted by up to factor of 2.5 if the user vote-locks tokens for Acxyn governance in the Voting Escrow contract.

In theory we would have the inflation rate r changing with every epoch (1 year), gauge weight $w_{g}$and gauge type weight $w_{t}$. Then, all the gauge handles the stream of inlation with the rate $r^{1}$ = $w_{g}w_{t}r$ which it can update every time $w_{g},w_{t}$, or mining epoch changes.

To calculate a user's share of $r^{1}$, we must calculate the integral: $I_u = \int_{ }^{ }r^{\frac{1\left(t\right)b_{u}\left(t\right)}{S\left(t\right)}dt}$, where $b_u(t)$ is the balance supplied by the user (measured in LP tokens) and S(t) is total liquidity supplied by users, depending on the time t; the value $I_u$ gives the amount of tokens which the user has to have minted to them. The user's balance $b_u$ changes every time the user u makes a deposit or withdrawal, and S changes every time _any_usr makes a deposit or withdrawal (so S can change many times in between two events for the user u ). In the liquidity gauge contract, the value of $I_u$ is recorded per-user in the public integrate_fraction mapping.

To avoid requiring that all users to checkoint periodically, we keep recording values of the following integral (named integrate_inv_supply in the contract):

$I_{is}\left(t\right)=\int_{0}^{t}r\frac{1\left(t\right)}{S\left(t\right)}dt$.

The value of $I_is$ is recorded at any point any user deposits or withdraws, as well as every time the rate $r^{1}$ changes (either due to weight change or change of mining epoch).

When a user deposits or withdraws, the change in $I_u$ can be calculated as the current (before user’s action) value of $I_is$ multiplied by the pre-action user’s balance, and sumed up across the user’s balances:

$I_{u}\left(t_{k}\right)=\sum_{ }^{ }_{k}b_{u}\left(t_{k}\right)\left[I_{is}\left(t_{k}\right)-I_{is}\left(t_{k-1}\right)\right]$

The per-user integral is possible to replace with this sum because $b_u(t)$ changed for all times between $t_{k-1}$ and $t_k$.