Anti Hunter Staking & Locking Whitepaper (Draft v0.2)

Receipts-funded staking for $ANTIHUNTER: 30/60/90/120-day locks, linear streaming, explicit reward sources, and deterministic control rules.

TL;DR

0) Scope & principles

This document specifies staking/locking mechanics and the control rules that govern rewards and buyback behavior. The design goal is boring, auditable tokenomics: if you can’t point to a dashboard + a transaction + a diff, it didn’t happen.

1) Motivation

$ANTIHUNTER is an on-chain venture desk token. Tokenomics should be driven by real inflows and verifiable on-chain receipts—not narrative APY. This staking design aims to: (a) reward commitment, (b) reduce reflexive dumping, and (c) keep the mechanism simple enough to audit.

2) System overview

The staking system is a single on-chain vault coordinating three flows:

3) Lock terms & bonus weights

Stakers choose a lock term. Longer terms receive a higher staking weight (a bonus share of any rewards that are distributed). This is a simple way to reward longer commitment without promising yield.

Lock terms (v0.2)

Weights are parameters (auditable on-chain) and may be revised in future drafts; any change must be disclosed and timelocked.

Other core parameters

4) Reward source hierarchy (and no fake APY)

Rewards are not promised. There is no fixed or target APY. Rewards are funded in this order:

  1. Fees paid in $ANTIHUNTER (primary): protocol fees settle directly in $ANTIHUNTER and are routed 100% to the Rewards Pool.
  2. Early-exit penalties paid by exiting stakers (routed 100% to the Rewards Pool).
  3. Optional emissions only if explicitly enabled and within a hard cap (bootstrapping, not permanent).

Separately: realized P&L (e.g. WETH settled to treasury) is used for on-market buybacks of $ANTIHUNTER under the deterministic rule in Section 7.

Any yield shown in UI/docs must be labeled as either: (a) realized historical yield over a stated window, or (b) a mechanical estimate derived from on-chain inflows. It must never be presented as guaranteed.

5) Locking mechanics (avoid synchronized cliffs)

To avoid a single “epoch unlock day,” v0.2 uses a per-deposit rolling schedule tied to the selected term:

6) Continuation / rollover (re-lock incentive)

To reduce mass “end-of-epoch” sell pressure, the protocol supports an opt-in relock / rollover at maturity (same or longer term).

Rollover incentive (A + cap)

This incentive changes distribution share; it does not create promised yield. Rewards remain receipts-funded and may be 0.

7) Programmatic buyback (fees in $ANTIHUNTER + PnL buys)

Buybacks should be non-discretionary. In this design, fees are paid in $ANTIHUNTER (used for staking rewards and/or burns), while realized P&L (settled in a settlement asset like WETH) is used to buy $ANTIHUNTER on-market.

Inputs (daily)

Buyback controller (deterministic)

Important: this algorithm controls how much realized PnL gets converted into $ANTIHUNTER on-market. It does not guarantee buybacks (if pnl_WETH_t is 0, buyback spend is 0).

8) Emissions cap, runway, and inflows = 0

If emissions are enabled, they must be bounded by a hard cap (e.g., EMISSIONS_MAX_PER_DAY and/or EMISSIONS_MAX_TOTAL). The protocol should publish “reward runway” under (i) current inflows and (ii) a conservative stress case where inflows drop to zero.

In the inflows = 0 case, rewards can only be paid from existing reserves and any remaining emissions budget; if those are exhausted, rewards necessarily decline and may pause. This is an explicit design constraint, not a hidden assumption.

9) Early exit penalty accounting

10) On-chain receipts & verification

Auditability is part of the spec. At minimum, the protocol should expose:

11) Risks

Draft v0.2 — for discussion. This is not financial advice.