# veTokenomics Draft Design

## Goal
We want to provide a tokenomics scheme that lets subnets access the protocol's hardware pool.

A Convex<>Curve analogy may be a good fit -- Curve is used to pay out over LP rewards from their pools, and Convex is used to vote on pools + fight over the paid out Curve rewards/emissions.

## Primer
Hardware Operator stakes AVAX, and GGP. They earn AVAX and GGP rewards.

Anyone can stake GGP, and start earning veGGP by staking in the GGP-veGGP pool. veGGP is not transferrable or sellable.

veGGP boosts your staked-GGP's rewards. (very similar to how Platypus tokenomics work https://cdn.platypus.finance/Platypus_Liquidity_Mining_Paper.pdf)

You can claim your GGP from the veGGP at any point, but you can only claim the entire pool. When you do so, you lose all your veGGP permanently. To earn it back, you have to stake into the GGP-veGGP pool again and begin earning veGGP over time.

The advantage to having veGGP is that it serves as
1) a way to boost your GGP rewards,
2) counts as your voting token so you can participate in subnet auctions + decide which subnets get validators from the protocol, and
3) allows you to collect subnet rewards from successful + accepted bids

## Liquid Staker ideas
Ideally, we want to let liquid stakers help vote on which subnets get validators from the pool (and at what cost).

### Subnets join the protocol
At mainnet launch, our decentralized staking protocol will have a pool of hardware, and liquid stakers.

For subnets to join the protocol + get access to validator nodes, they need to put up a stake of GGP tokens. For the entire duration of their auction and validation window, their GGP tokens will have to be staked.

Once a subnet operator stakes GGP, they begin accruing veGGP. veGGP is used by subnet operators to begin an auction. The amount of veGGP they have determines how many validator nodes they can request from the pool, and how many auction slots they can open up for bidding.

### Subnet <> Validator Auctions
Since gAVAX represents a staked AVAX, liquid stakers can exchange their gAVAX for a vgAVAX (or maybe just allows them to mint vgAVAX? ) which represents a voting token. When exchanging the token, stakers give us their C Chain address to register their vote. vgAVAX is not sellable or transferable.

When a subnet joins the protocol and opens up an auction, vgAVAX holders can vote on which validation slots to vote on. Needs a minimum of 1000 vgAVAX to accept the auction slot.

Concurrently, a veGGP auction is held. veGGP holders bid on auction slots against each other, competing for the spot.

After a set amount of time, the auction ends and the top bids are accepted. In order for bids on a validator slot to be accepted, the bid must have at least 1000vgAVAX, and more veGGP than the other bids.

For v1 of the auctioning system, in order to finalize the bids, the Hardware Operator must:
1. get the VM binary for the subnet
2. complete the Proof of Authority handshake
3. start validating the subnet
4. Register with the ODAO
5. ODAO reports that the NodeID is successfully validating the subnet

Once they begin validating succesfully (as reported by the OracleDAO), the auction is turned into read-only mode with a new Rewards section added.

Once permisionless subnet validation is added, the entire process above can be handled programatically.

Subnet rewards are paid out proportionally to liquid stakers and hardware operators at a 1:1.5 ratio (hardware operators earn 50% more rewards than liquid staker, to cover the cost of running their hardware. Maybe this ratio is configurable by the auction settings? ). All of the vgAVAX holders that participated in the auction split the rewards (if I owned 50% of vgAVAX that participated in the auction, I get 50% of the rewards paid out to liquid stakers).

## Takeaways (so far)
It's pretty tricky designing tokenomics for subnets, and designing the auction system for subnets, since we don't know how the subnet economy will play out yet.

The biggest risk is in the subnet rewards -- will subnets prefer to have their rewards be paid out on their own blockchains (to be bridged back to the main chain), or will they prefer to pay out subnet rewards directly on the C Chain? Depending on which way subnets (and users) want to handle rewards, our implementation path for reward distributions will have to vary. There is an opportunity here to provide some sort of framework for subnets to plug into, and make their decision simpler.

When thinking through this, I'm in favor of the most framework-y, flexible solution possible. Eg. create a framework that lets subnets configure their auction settings completely arbitrarily.

This way, any subnet usecase can be supported (with us giving a few templates in the beginning), and the auction framework we built is only concerned with actually handling the phases + tokenomics of the auction.

Also ideally, the auction system can be upgraded trivially so we can support different models (eg only KYC validators allowd to participate in the auction).

More design thought is needed for sure, and am seeking disagreement with the design. It will take us a few iterations before landing on something good, and a few conversations with Ava/Crabada/DFK.