Kwenta State Log

A living document defining the state of Kwenta

Kwenta State Log

Kwenta Improvement Proposals

3. Tokenomics

Table of Content

  1. Allocation breakdown
  2. Inflation Allocation
  3. Vesting Mechanism
  4. Staking Mechanism
  5. Staking V2
  6. Early Vest Fee Distribution

The Kwenta token launched on November 15, 2022. The token follows the below model:

  • Ticker - KWENTA
  • Initial Supply - 313,373
  • Inflation Model - Weekly emissions will start at 14,463.37 $KWENTA the first week and drop to around 200 $KWENTA (1% APY) at the end of four years. Resulting in a total supply at the end of four years of 1,009,409.43 (note that this number was updated after CCs evaluated feasibility).

Allocation breakdown

  • 30% - Synthetix Stakers
  • 5% - synthetix.exchange and early Kwenta Traders
  • 5% - Investment
  • 25% - Community Growth Fund
  • 15% - Core Contributors
  • 20% - Kwenta Treasury

Inflation Allocation

20% of inflation is routed to the treasury, 20% of inflation is dedicated towards trading rewards (10% is earmarked for future trading incentives by the treasury) and 60% of inflation is routed to stakers.

The $KWENTA trading rewards allocation was increased from 5% to 10% of inflation beginning with the first epoch in which the referral program was considered in rewards calculations (epoch 44). The allocation directed towards the treasury and earmarked for future rewards was therefore reduced from 15% to 10% to accomodate this change.

This will enable Kwenta to sustainably fund DAO roles while enabling the community to use the entire token supply as needed.

Inflation is minted once per week by a keeper, however, this mint functionality can be called by anyone in the event the Kwenta DAO keeper is unable to mint rewards. The reward for minting is 1 KWENTA per mint.

Vesting Mechanism

KWENTA printed via inflation will undergo a 1-year lock-up period. The lock-up mechanism will begin with a 90% fee for vesting KWENTA early which will decay linearly. If tokens are vested early, the percentage of tokens that are still applicable to the fee will be taken out of circulation and returned to the Kwenta Treasury. After one year, the fee would reach 0% and no tokens would be forfeited when vesting KWENTA.

Staking Mechanism

The Kwenta staking system will have two primary functions:

  1. Governance: staked KWENTA will gain voting power within the system enabling stakers to vote in elections and CKIPs offering the protocol a decentralized decision making mechanism.

  2. Protocol Rewards: Staked KWENTA will earn inflationary rewards. This mechanism will empower members dedicated to the protocol to increase their influence over decision making. Stakers who are active traders are eligible for additional KWENTA rewards. All trading rewards are limited to Perps V2 usage.

The inflationary rewards will be split into two types of rewards: pure inflationary rewards and trading rewards (determined by a trading score). 60% of inflation is allocated to the pure inflationary (𝜌) rewards. This enables the treasury and growth fund, when staked, to retain a proportion of the supply, better preparing the protocol to operate sustainably and provide additional incentives for trading, DAO roles, marketing, etc.

stakingRewards

20% (15% of this is currently earmarked in the treasury for future use) of inflation will be distributed to KWENTA stakers according to a rewards score that is a function of staking participation and trading activity. The rewards score will be a Cobb-Douglas function with exponential weighting (that ideally will favor trading activity):

rewards_score

For epochs 21 and 22 only, rewards_score will be calculated using the formula rewards_score = fees_paid^a * (staked_KWENTA+0.1)^1-a in order to trial a non-stake $KWENTA rewards program.

It’s important to note that π‘“π‘’π‘’π‘ π‘π‘Žπ‘–π‘‘ is used here rather than π‘‘π‘Ÿπ‘Žπ‘‘π‘–π‘›π‘”π‘£π‘œπ‘™π‘’π‘šπ‘’ to prevent abuse. Since different markets will have lower fees than others (e.g. FOREX markets may have extremely low fees), malicious stakers may inflate their rewards by trading large volumes in low fee markets. Keeper fees are excluded from π‘“π‘’π‘’π‘ π‘π‘Žπ‘–π‘‘ to avoid abuse from self-executed transactions. Limiting 𝑓𝑒𝑒𝑠_π‘π‘Žπ‘–π‘‘ to only include protocol fees levels the playing field for all stakers and ensures that traders must take risk to earn rewards.

To focus rewards on volume generated from Kwenta's frontend, 𝑓𝑒𝑒𝑠_π‘π‘Žπ‘–π‘‘ will be limited to trades with a tracking code of KWENTA starting at epoch 14.

An individual staker’s trading rewards are then evaluated as:

trading_rewards

Configurable Values

  • 𝜌 – share of inflation allocated to pure staking rewards (default = 0.6)
  • Ξ² – diversion to treasury (default = 0.2)
  • π‘Ž – weight applied to π‘“π‘’π‘’π‘ π‘π‘Žπ‘–π‘‘ in π‘Ÿπ‘’π‘€π‘Žπ‘Ÿπ‘‘π‘ π‘ π‘π‘œπ‘Ÿπ‘’ calculation (default = 0.7)

Inflationary KWENTA rewards are locked for a period of 1 year but will have transferability so that the protocol can redirect inflationary rewards earned from the growth fund and treasury as needed. Once the one year vesting period is complete, KWENTA can be withdrawn from the staking portal and freely used at the stakers’ discretion. KWENTA rewards that are vesting can be staked to increase voting power and weekly rewards.

Staking is only available on Optimism (Layer 2) Kwenta.

Staking V2

Staking V2 is the migration of StakingRewards from V1 -> V2 to support new functionality.

StakingRewards was upgraded with an unstaking cooldown and the ability to look up staked amounts at older blocks. These features should facilitate future modules such as fee distribution, automated onchain voting, and onchain trading rewards.

Motivation

The StakingRewards contract cannot support onchain activity using staked balances without tolerating substantial gameability.

Using current staked balances for, say, voting or fee distribution creates a system that can be easily manipulated by actors who decide to stake before a favorable voting or fee distribution event to gain higher share. Historical staked balances are much harder to manipulate especially when the future outcome is unknown (future proposals or fees to be generated that epoch).

Staked amounts will also need to be locked for a meaningful amount of time to discourage disruptive short term actions such as the buying of votes, fee revenue, or locked inflationary rewards.

Specification

The Staking V2 contracts - specifically StakingRewardsV2 and RewardEscrowV2 should be upgradeable following the UUPS proxy standard.

Staking Cooldown

A cooldown (two weeks) timer has been implemented . This cooldown is reset whenever new amounts are staked. During this cooldown period users will not be able to unstake (but they are able to stake more).

uint256 lastStakeTime; // reset to current block timestamp when KWENTA is staked

Two weeks was chosen because an epoch at Kwenta is typically defined as one week (trading rewards, inflation mint). Two weeks, at minimum, should be enough to deter bad actors from attempting to disrupt elections or stake to capture fees/rewards for an epoch. As requested (by the Kwenta Council), this cooldown value will be adjustable, with a minimum of one week to a maximum of one year.

Historical Staked Amounts (Checkpointing)

Additionally, a checkpointing system has been added to StakingRewards to keep track of staked balances and total staked balances over time. The checkpointing system records whenever staked amounts change (ie. staking/unstaking). This also encompases staked escrow and the total staked amounts in the contract. The mechanism was inspired by the various VE tokens.

Each time a token holder stakes, a new entry is added to a list (array) of new total amount staked and the block height at which this change was made. The same is done when unstaking, but the total balance is subtracted from instead. This list is effectively an onchain changelog for the entire balance history of an account.

struct Checkpoint {
    uint128 block;
    uint128 value;
}

mapping(address => Checkpoint[]) private balances;

mapping(address => Checkpoint[]) private escrowedBalances;

Checkpoint[] private _totalSupply;

Example data structure and relevant balance & totalSupply variables.

To provide efficient balance lookups onchain, we implement a binary search on the list for a given block height. And if the list is empty, we simply return 0.

uint256 min = 0;
uint256 max = checkpoints.length - 1;

while (max > min) {
    uint256 midpoint = (max + min + 1) / 2;

    if (checkpoints[midpoint].block <= _block) {
        min = mid;
    } else {
        max = mid - 1;
    }
}

Example algorithm where the resulting min value is the index of the checkpoint we want.

Current balanceOf(), escrowedBalanceOf(), totalSupply() lookups will continue to function as they do in Staking V1, however, under the hood this is simply looking at the most recent addition to (or the end of) the list.

getRewardsOnBehalf and stakeEscrowOnBehalf

V1 KWENTA staking rewards needed to be claimed manually with the opportunity loss of efficient reward compounding. The implemention of getRewardOnBehalf and stakeEscrowOnBehalf methods on the KWENTA staking contracts allow KWENTA stakers to individually enable a third-party solution to trigger those method for them in regular intervals and thus automate the claiming and staking process for optimal compounding.

Both methods are to additionally support an address input parameter that allows stakers to whitelist addresses to enable them to trigger the claim of rewards and stake of escrow on their behalf.

Escrow V2 (Escrow Transferrability)

A new escrow (RewardEscrowV2.sol) contract has been deployed that supports additional escrow functionality. It's important to note existing KWENTA in the old escrow contract (V1) will not have access to these features.

A function called transferVestingEntry() has been created with the parameters of entryID and recipient. The access control should be restricted to the owner of the vesting entry. Calling this function will move the ownership of a vesting entry from one account to another. If necessary, staked escrowed KWENTA should be unstaked and restaked under the new owner to ensure staked escrowed KWENTA is appropriately accounted for*. To prevent a fragmenting of vesting schedules, only a full transfer of the entry is allowed (no partial transfers).

Additionally, stakeEscrowOnBehalf() and unstakeEscrowOnBehalf() will be added as part of KIP-42 to support 3rd party autocompounding of staking rewards.

Invariant: Staked escrowed KWENTA of account N should never be greater than total KWENTA in escrow for account N

Integrator Contract Support

A new IStakingRewardsV2Integrator that requires integrators to use beneficiary function. This will return the address of the beneficiary of the smart contract.

The following functions are added:

  • getIntegratorReward
  • getIntegratorAndSenderReward
  • getIntegratorRewardAndCompound

These functions allow the beneficiary account to claim rewards on behalf of the integrator, and to compound those rewards.

Migration

A migration is required from Staking V1 -> Staking V2. Fully liquid KWENTA staked balances will have to be manually unstaked and then restaked on the V2 contract. There is a UI flow to assist with this process.

The mapping of staked escrowed balances was copied over from the StakingRewards V1 contract to the StakingRewards V2 contract. During this process the V1 contract was paused and the RewardEscrow StakingRewards address was changed from the V1 contract to the V2 contract. This ensured staked escrowed balances carry over smoothly onto the new StakingRewards contract.

The V1 staking contract will continue to function, without rewards, to allow people to migrate or claim their remaining rewards at their own pace. Only the migration of staked escrowed balances will be automatic.

Inflation has been directed to the new V2 staking contract incentivizing immediate migration.

Early Vest Fee Distribution

Currently, when users exit the inflationary reward vesting agreement early, the remaining KWENTA in their vesting package is sent to the Kwenta treasury. The early vest fee distribution reduces the amount of KWENTA sent to treasury by 50%, so that 50% goes to treasury and the other 50% is shared amongst all other KWENTA stakers as escrowed KWENTA (proportional to their stake).

Specification

  1. The distribution be completed once per epoch, to align with the distribution of trading rewards (and potentially with fee-share distributions in future).
  2. Escrowed KWENTA that is forfeited through early vesting and re-distributed to other stakers will have its vesting period re-set to 12 months.
  3. Track all rewards accumulated from vest-early penalties from when KIP-45 was approved to the the launch of V2 staking and put aside 50% of these rewards.
  4. In the epoch that once V2 staking officially was deployed to OP mainnet, the accumulated rewards were distributed to stakers across 20 weeks (5% of the accumulated rewards each week) in escrow.

Lastly, note that rewards are a part of the module that is created for KIP-45's early vest fee redistribution. Therefore accumulated rewards will be in addition to ongoing redistribution rewards at the time of launch.