Summary

Create an onchain VIP program that provides fee rebates to high volume traders.

Abstract

To incentivize larger volume drivers to stick around on Kwenta -- introduce favorable fee rebate program for traders that meet specific volume tiers for a given month. Use ZK-coprocessing to run this rewards program fully onchain.

Motivation

Most other CEXs and DEXs have some sort of loyalty program that provides discounts to larger, recurring traders. To compete with centralized exchange and encourage platform loyalty Kwenta needs to offer fee rebates to high volume traders. Distribution through a VIP program can be more effective than a flat incentives program because it entitles traders to higher rewards as they drive more volume.

There are two ways to use historical data onchain. The first is to proactively push historical data to the chain as it's created (aka transaction time). However, this approach requires forward thinking (would have had to be done before the smart contract was deployed) and is also costly to store batches of data onchain that may only be used once or twice and replicated for each user.

The second way is to aggregate and pull historical data offchain, and use this to execute actions onchain. For example, claiming onchain rewards using historical fees paid aggregated by a subgraph indexed offchain. This is how Kwenta trading rewards works today. The downside of this approach is that requires honest actors (for example Kwenta) to provide data that hasn't been manipulated.

The third, and hybrid approach, is to still aggregate data offchain, but use recent advancements in Zero Knowledge Proofs (ZKP). ZKPs are used to prove the underlying data hasn't been tampered with, which then can be verified by the blockchain, and if valid, subsequent actions can be executed. This VIP program explores a new way to do trading incentives in a robust, transparent, permissionless way.

Specification

Use arbitrary tokens for growth grants, rebate larger, recurring traders in a VIP program. The program opt-in is automatic and requires no effort from a trader other than claiming their rebates. Volume tiers and eligibility will be surfaced on the UI.

Volume is based on a 30 day rolling window similar to centralized exchanges and rebates will be claimable whenever a new trade has been placed. Therefore traders will be able to claim at any time and can let rebates accrue. The implications of a 30 day window is that accrued volume no longer resets by month (in an epoch based claim), but more organically falls off after 30 days have passed. This makes it easier for a trader to "maintain" a certain VIP tier without having to start from 0 each month.

Volume Tiers*

\ Tier levels and rebate percentages are subject to change based off availibility of token grants to prevent early exhaustion of rewards. These values are controlled by the pDAO with input from the council and CCs.*

Architecture

Using a ZK-coprocessing service like Brevis or Axiom, prove access to historical chain data regarding volume and fees paid.

1. Data Query

First step is pulling historical data using Brevis/Axiom SDK.

For volume, pull and aggregate transaction/event data over a specific window of time for a given trader. For example, grab total volume over the month of February by summing all trades (notional value changes) during that time period.

For fees, pull and aggregate event data containing fees paid to perpetuals provider over the same window of time for a given trader. Necessary to determine how much of a rebate a trader will receive.

Previously including keeper fees would be an issue because traders could submit un-fillable orders to accumulate keeper fees (which is a deposit refunded to them). However, Keeper fees can be included in this calculation because a trader will have to do substantial volume to even be eligible for a rebate.

2. Proof Generation

Submit historical offchain data to one of the ZK-coprocessing services for proof generation. Proving is computationally expensive and cannot be done within the browser. These proving services have the hardware capabilities to generate proofs for historical data. However, it is still tamper resistant as the proof still needs to be verified onchain (verifying that the historical data pulled did in fact occur onchain).

3. Proof Verification

Create a smart contract onchain that verifies a proof generated by the previous entity. Run the proof received by the prover through the verification function. Once verified, perform a callback to the original claim. For example, once the proof of volume tier is reached for a given epoch, rebate the % tier in fees paid back to the trader.

Only allow claiming of fee rebates for the previous epoch (week) to prevent partial claims.

Oracle

The rebate contract will have tokens ready for reimbursement. Use an onchain oracle from either Pyth or Chainlink to determine the token amount for the rebate. Latency is not a concern here because there's not much benefit to frontrunning an oracle, however, resiliency to manipulation is critical (hence a proven oracle provider).

There will need to exist an oracle for whichever token is used for rebates.

Gas Costs

There is common concern that a solution like this may be expensive in terms of gas costs to claim rebates. Upon prelimary data and discussions with Brevis/Axiom gas costs to verify a proof onchain range around 200-400k. This is not much more than a claim from a MerkleDistributor contract and already less than it costs to trade on Kwenta.

Latency

Proofs take a long time to generate, however, this application is not latency sensitive like trading. Claiming rebates can be done in the background at the convenience of a trader. It can take around 30 minutes to generate a proof (depending on input size or transactions needed to verify), but once the trader kicks off the action, they only need to wait until the rewards are delivered to their wallet. No need to perform follow up actions.

Configurable Blacklist

To prevent some malicious traders from exploiting properties of the Perps AMM due to discounted fees, some addresses may be excluded from the VIP program at the approval of governance - Kwenta DAO and any integrator (Synthetix or Perennial).

Copyright

Copyright and related rights waived via CC0.