# Tokenomics Design

> Designs and audits token economics for Web3 protocols -- distribution, vesting, emission curves, value accrual, governance design, anti-dump and anti-sybil mechanics, and sustainability modeling. Use when designing or reviewing tokenomics, allocation tables, vesting schedules, emission schedules, staking or veToken systems, liquidity-mining programs, airdrops, points programs, governance paramete…

- **Type:** Skill
- **Install:** `agentstack add skill-kaynetik-skills-tokenomics`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [kaynetik](https://agentstack.voostack.com/s/kaynetik)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [kaynetik](https://github.com/kaynetik)
- **Source:** https://github.com/kaynetik/skills/tree/main/tokenomics

## Install

```sh
agentstack add skill-kaynetik-skills-tokenomics
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# Tokenomics Design

Architect-level skill for token economic design and review. Focuses on **what to build, why, and how it fails** -- not on implementation code (route to `solidity-security` and `web3-testing` for that). The body is intentionally thin; depth lives in `references/`. Open only the file you need.

## Companion skills (route to these first)

This skill is the **economic-design layer**. Defer to companion skills for adjacent domains:

| Domain | Use skill |
|--------|-----------|
| Public copy about token, staking, governance, fees | `legalizer` |
| Whitepaper / litepaper authoring | `whitepapers` |
| Cross-chain, custody, governance contract architecture | `ultimate-web3` |
| Solidity vulnerability classes and secure patterns (vesting wallets, governor, timelocks) | `solidity-security` |
| Test design for vesting, emissions, governance (fuzz, invariants, fork) | `web3-testing` |

If the user asks for **how to write the contract**, route to `solidity-security`. If the user asks for **how to publish or describe** a token, route to `legalizer`. Use **this** skill for **what the mechanism should be, what numbers it should use, and how it can fail economically**.

## Token economy rules for the agent

1. Read at most **2 reference files per turn**. Choose by the routing table below.
2. Never improvise legal framing or marketing copy. Token-related public prose must pass `legalizer`.
3. Do not paste back numbers or schedules the user already provided. Critique or extend them.
4. Prefer tables, schedules, and equations over prose.
5. Use `WebSearch` for current unlock-schedule benchmarks, FDV/MCap norms by sector, and recent token launches. Norms change cycle-to-cycle.
6. When the user asks "is this tokenomics good?", run the **Audit workflow** below before commenting.

## Routing table

| User intent or keyword | Open file |
|------------------------|-----------|
| Allocation tables, vesting, cliffs, TGE, ve-token, POL, dual-token, bonding curve, halvings, real yield, points-to-token, RPGF, gauge weights | `references/patterns.md` |
| "Is this safe?", footguns, FDV-vs-float, emission death spiral, cliff dump, governance attack, airdrop dump, velocity, whale concentration, oracle manipulation, forced utility | `references/sharp_edges.md` |
| Numerical review, "does this add up?", allocation sums, cliff durations, TGE %, supply caps, governance safeguards, distribution metrics | `references/validations.md` |

## Golden rules (non-negotiable)

1. **Utility before incentive.** If the token has no functional role beyond capturing future value, it is a security narrative dressed as a token. Define what the token *does* in the running protocol before designing emissions.
2. **Allocations sum to 100% and every wallet vests.** Any insider allocation (team, investors, advisors, foundation employees) must have a cliff and a linear or stepped vesting schedule. No exceptions.
3. **Emissions are a budget, not a feature.** Every emitted token must have a buyer-of-last-resort thesis (protocol revenue, organic demand, lock-up sinks). Without it, the token is selling itself.
4. **FDV / float ratio drives launch dynamics.** A high-FDV / low-float launch concentrates dump risk at every unlock cliff. Model the unlock waterfall before announcing the cap table.
5. **Governance is an attack surface.** Snapshot voting, timelocks, quorum minima, and an emergency multisig are required from day one. Pure on-chain Governor with no timelock is a vulnerability.
6. **Distribution > narrative.** A token concentrated in  10% of circulating supply.

Phase 6: Compliance and disclosure
  - Run all public-facing strings through legalizer.
  - Publish vesting schedule and unlock waterfall before TGE.
  - Cross-link audit reports for vesting and governance contracts.
  Gate: zero legalizer hard-block phrases in any external document.
```

### Audit workflow (existing tokenomics)

Use this when reviewing a published or proposed token model.

```
1. Open references/validations.md and run every check against the user's spec.
   For each failed check, cite the rule and quote the offending line.

2. Open references/sharp_edges.md and match the model against each failure mode.
   For each match, name the failure ID and describe the symptom in this specific design.

3. Compute the unlock waterfall:
   - For each insider cohort: cliff date, total tokens, unlock pace.
   - For each month after TGE: tokens unlocked, % of then-circulating, % of total supply.
   - Flag any month where unlock > 10% of circulating supply.

4. Compute the emission sustainability ratio:
   weekly_emission_value = weekly_token_emissions * current_price
   weekly_buy_pressure = protocol_revenue + organic_demand_estimate + new_capital_inflow
   sustainability_ratio = weekly_buy_pressure / weekly_emission_value
   Flag if ratio = 6 months) and a vesting schedule.
- [ ] TGE unlock for insiders is 0% (or documented exception with justification).
- [ ] Token has at least one functional utility in the running protocol; design survives "remove the token" thought experiment.
- [ ] Emission schedule is bounded (cap, halving, or terminal date).
- [ ] Sustainability ratio modeled for year 1 and year 2; thresholds defined.
- [ ] Unlock waterfall published; no single month exceeds 10% of circulating supply.
- [ ] Governance has timelock (>= 48h), quorum, proposal threshold, emergency multisig.
- [ ] Value accrual mechanism specified (real yield, treasury growth, lockup demand) -- not "buyback hopes".
- [ ] Distribution targets named (top-10, top-100, Gini) and tracked post-launch.
- [ ] All public-facing copy passes legalizer hard-block list.
- [ ] Vesting and governance contracts referenced to audited implementations (e.g. OpenZeppelin v5 `VestingWallet`, `Governor`, `TimelockController`) or carry their own audit.
- [ ] Whitepaper / litepaper section on tokenomics matches this spec exactly.

## Do not

- Do not propose mechanisms that exist purely to create token demand (forced utility, artificial sinks).
- Do not quote APYs above ~30% as sustainable; emissions-funded yields collapse.
- Do not recommend "buyback and burn" as a primary value-accrual story; it is often a red flag for missing utility.
- Do not design 1-token-1-vote governance for any treasury > $1M.
- Do not ship without a published unlock waterfall.
- Do not write public-facing copy from inside this skill; route to `legalizer`.
- Do not invent percentages or vesting numbers when the user provided real ones; critique the user's numbers instead.

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [kaynetik](https://github.com/kaynetik)
- **Source:** [kaynetik/skills](https://github.com/kaynetik/skills)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-kaynetik-skills-tokenomics
- Seller: https://agentstack.voostack.com/s/kaynetik
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.