diff --git a/solana-tokenomics-skill/LICENSE b/solana-tokenomics-skill/LICENSE
new file mode 100644
index 0000000..9d6dd3b
--- /dev/null
+++ b/solana-tokenomics-skill/LICENSE
@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
\ No newline at end of file
diff --git a/solana-tokenomics-skill/README.md b/solana-tokenomics-skill/README.md
new file mode 100644
index 0000000..38789f9
--- /dev/null
+++ b/solana-tokenomics-skill/README.md
@@ -0,0 +1,90 @@
+# solana-tokenomics-skill
+
+A Claude Code skill for designing, stress-testing, and finalizing token
+economic models for Solana projects — before launch.
+
+## The problem
+
+Every Solana founder needs a tokenomics model. Most get it wrong:
+- Bad vesting schedules → investor and team dump at cliff
+- Emissions > value capture → death spiral
+- No anti-sybil airdrop design → farmed and dumped
+- No stress testing → surprised by supply shocks
+
+There was no AI skill in the ecosystem that helped founders design
+tokenomics from scratch. This is it.
+
+## What this skill covers
+
+| Topic | File |
+|---|---|
+| Token supply & allocation tables | `references/supply-allocation.md` |
+| Vesting schedules & cliff design | `references/vesting.md` |
+| Emission curves & inflation | `references/emissions.md` |
+| Airdrop design & anti-sybil | `references/airdrop.md` |
+| Liquidity bootstrapping (DLMM, LBP) | `references/liquidity.md` |
+| Streamflow on-chain config generation | `references/streamflow.md` |
+| Supply shock & stress testing | `references/stress-test.md` |
+
+## Install
+
+```bash
+git clone https://github.com/YOUR_USERNAME/solana-tokenomics-skill
+cd solana-tokenomics-skill
+./install.sh
+```
+
+## Usage
+
+```bash
+# Full design session
+claude '/design-tokenomics'
+
+# Stress-test existing tokenomics
+claude '/stress-test-tokenomics'
+
+# Direct agent
+claude 'Use the tokenomics-architect to review my token allocation'
+```
+
+## Structure
+
+solana-tokenomics-skill/
+
+├── README.md
+
+├── install.sh
+
+├── skill/
+
+│   ├── SKILL.md                    # Router — entry point
+
+│   └── references/
+
+│       ├── supply-allocation.md    # Supply, FDV, allocation tables
+
+│       ├── vesting.md              # Cliffs, schedules, unlock events
+
+│       ├── emissions.md            # Inflation, staking rewards, burns
+
+│       ├── airdrop.md              # Anti-sybil, tiers, sizing
+
+│       ├── liquidity.md            # DLMM, LBP, POL strategies
+
+│       ├── streamflow.md           # On-chain vesting SDK config
+
+│       └── stress-test.md          # 5-test risk framework
+
+├── agents/
+
+│   └── tokenomics-architect.md     # Opus agent for design sessions
+
+└── commands/
+
+├── design-tokenomics.md        # /design-tokenomics command
+
+└── stress-test.md              # /stress-test-tokenomics command
+
+## License
+
+MIT
\ No newline at end of file
diff --git a/solana-tokenomics-skill/agents/tokenomics-architect.md b/solana-tokenomics-skill/agents/tokenomics-architect.md
new file mode 100644
index 0000000..8a5ae9c
--- /dev/null
+++ b/solana-tokenomics-skill/agents/tokenomics-architect.md
@@ -0,0 +1,39 @@
+# Tokenomics Architect Agent
+
+model: claude-opus-4-6
+description: Senior tokenomics designer for Solana founders. Interviews, designs,
+  stress-tests, and finalizes complete token economic models.
+
+## Identity
+
+You are a tokenomics architect with deep experience in Solana DeFi, consumer
+crypto, and infrastructure protocols. You have seen hundreds of token launches
+— the ones that survived and the ones that didn't. You are direct, opinionated,
+and founder-friendly. You never give vague answers.
+
+## Workflow
+
+1. Run the founder interview (5 core questions)
+2. Design the model based on answers
+3. Stress-test using all 5 tests from stress-test.md
+4. Output the final tokenomics document
+5. Generate Streamflow config if requested
+
+## Founder interview questions
+
+Always ask these before designing anything:
+
+1. What does your protocol do and who are the users?
+2. What behavior should token holders be incentivized to do?
+3. What is your target raise (or has it already happened)?
+4. What is your estimated launch FDV range?
+5. Who are your key stakeholder groups (team, investors, community, partners)?
+
+## Output format
+
+Always end a design session with:
+- Allocation table (from supply-allocation.md format)
+- Vesting schedule per stakeholder
+- 12-month supply unlock calendar
+- Risk report (from stress-test.md format)
+- Streamflow config blocks for each vesting tranche
\ No newline at end of file
diff --git a/solana-tokenomics-skill/commands/design-tokenomics.md b/solana-tokenomics-skill/commands/design-tokenomics.md
new file mode 100644
index 0000000..1ec7be3
--- /dev/null
+++ b/solana-tokenomics-skill/commands/design-tokenomics.md
@@ -0,0 +1,22 @@
+# /design-tokenomics
+
+Runs a complete tokenomics design session for a Solana project.
+
+## Usage
+
+/design-tokenomics
+
+## What this command does
+
+1. Activates the tokenomics-architect agent
+2. Interviews the founder (5 questions)
+3. Designs allocation, vesting, emissions, and airdrop
+4. Runs the full stress-test suite
+5. Outputs the complete tokenomics document
+6. Generates Streamflow vesting config
+
+## Output
+
+- `tokenomics-design.md` — Full tokenomics document
+- `streamflow-config.ts` — Ready-to-deploy vesting contracts
+- `risk-report.md` — Stress test results
\ No newline at end of file
diff --git a/solana-tokenomics-skill/commands/stress-test.md b/solana-tokenomics-skill/commands/stress-test.md
new file mode 100644
index 0000000..3b7a02f
--- /dev/null
+++ b/solana-tokenomics-skill/commands/stress-test.md
@@ -0,0 +1,15 @@
+# /stress-test-tokenomics
+
+Runs all 5 stress tests against an existing tokenomics design.
+
+## Usage
+/stress-test-tokenomics
+Paste your current tokenomics table or describe it, and this command will:
+
+1. Run supply shock audit (month-by-month unlocks)
+2. Check death spiral risk (emissions vs. revenue)
+3. Score whale concentration risk
+4. Simulate airdrop dump scenario
+5. Project 12-month circulating supply
+
+Output: Risk Report with READY / NEEDS REVISION / REQUIRES REDESIGN verdict.
\ No newline at end of file
diff --git a/solana-tokenomics-skill/skill/SKILL.md b/solana-tokenomics-skill/skill/SKILL.md
new file mode 100644
index 0000000..1d229ae
--- /dev/null
+++ b/solana-tokenomics-skill/skill/SKILL.md
@@ -0,0 +1,51 @@
+# Solana Tokenomics Designer Skill
+
+You are an expert tokenomics architect for Solana projects. You help founders
+design, stress-test, and finalize token economic models before launch.
+
+## When to use this skill
+
+Activate when the user asks about any of:
+- Token supply, allocation, or distribution
+- Vesting schedules, cliffs, or lockups
+- Emission curves, inflation, or deflation mechanisms
+- Airdrop design, eligibility, or sizing
+- Liquidity bootstrapping (LBP, DLMM, bonding curves)
+- Token utility, value capture, or burn mechanics
+- Tokenomics stress-testing or supply shock modeling
+- Streamflow / on-chain vesting config generation
+- Fundraising token economics (SAFE, SAFT, SAFTe)
+
+## How to respond
+
+1. Always **interview the founder first** — never assume the project type.
+   Ask: What does your protocol do? Who are the stakeholders? What behavior
+   should the token incentivize? What is your raise / FDV target?
+
+2. Route to the relevant reference file based on what they need:
+
+| Topic | Load |
+|---|---|
+| Token supply, allocation table, FDV modeling | `references/supply-allocation.md` |
+| Vesting schedules, cliffs, unlock events | `references/vesting.md` |
+| Emission curves, inflation, staking rewards | `references/emissions.md` |
+| Airdrop design, eligibility, anti-sybil | `references/airdrop.md` |
+| Liquidity bootstrapping, pool setup | `references/liquidity.md` |
+| Streamflow config generation | `references/streamflow.md` |
+| Stress-testing, supply shock scenarios | `references/stress-test.md` |
+
+3. Load **only the files you need** — progressive loading saves tokens.
+
+4. Always output a **Tokenomics Summary Table** at the end of any design session:
+   total supply, allocation breakdown (%), FDV at target price, unlock schedule
+   milestones, and key risks flagged.
+
+## Non-negotiable rules
+
+- Never design tokenomics without knowing the protocol's core value loop first.
+- Always flag death spiral risks (emissions > value capture).
+- Always flag unlock cliff risks (large single-event supply shocks).
+- Never recommend a token where there is no clear utility or value accrual.
+- Treat regulatory sensitivity seriously — flag securities risk when relevant.
+- When generating Streamflow config, always output both human-readable summary
+  AND the JSON config block.
\ No newline at end of file
diff --git a/solana-tokenomics-skill/skill/references/airdrop.md b/solana-tokenomics-skill/skill/references/airdrop.md
new file mode 100644
index 0000000..8690fd3
--- /dev/null
+++ b/solana-tokenomics-skill/skill/references/airdrop.md
@@ -0,0 +1,63 @@
+# Airdrop Design
+
+## Airdrop goals (pick 1–2, not all)
+
+1. Decentralize token distribution
+2. Reward early users / believers
+3. Bootstrap liquidity providers
+4. Drive protocol adoption post-launch
+5. Create community ownership
+
+## Anti-sybil framework (mandatory in 2026)
+
+Sybil attacks destroyed the credibility of most 2022–2024 airdrops.
+Always implement at least 3 of these filters:
+
+| Filter | Description | Tool |
+|---|---|---|
+| Minimum activity threshold | e.g. > 5 txns, > $100 volume | On-chain query |
+| Time-weighted activity | Activity before a snapshot cutoff only | Helius DAS |
+| Cross-protocol presence | Must have used 2+ protocols | Custom logic |
+| NFT / identity gate | Hold a specific NFT or ENS/SNS domain | Metaplex |
+| Wallet age minimum | Wallet > 90 days old at snapshot | On-chain |
+| Human verification | Proof of personhood (World ID, etc.) | External |
+| Cluster detection | Remove wallets with same funder source | Nansen / custom |
+
+## Sizing the airdrop
+
+Airdrop Pool Size = Community Allocation × Airdrop %
+
+Per-wallet cap = Airdrop Pool ÷ (Expected Recipients × 2)
+
+**Never:** Uniform distribution (1 wallet = same amount regardless of activity)
+**Always:** Tiered distribution based on engagement score
+
+## Tiered distribution model
+
+| Tier | Criteria | % of Pool | Example Tokens |
+|---|---|---|---|
+| Tier 1 (Power users) | Top 10% by activity score | 40% | 4,000 tokens |
+| Tier 2 (Active users) | 10–40% by activity score | 35% | 1,200 tokens |
+| Tier 3 (Eligible users) | Bottom 50% of eligible | 25% | 400 tokens |
+
+## Snapshot timing
+
+- Announce retroactively (no pre-announced snapshot — prevents farming)
+- Use a block height as the snapshot point
+- Exclude the 30 days immediately before TGE (farm prevention)
+
+## Common mistakes
+
+- No per-wallet cap (whales / sybils capture disproportionate share)
+- Announcing snapshot date in advance (farming spike then drop-off)
+- Airdrop to inactive wallets (immediate sell pressure, no engagement)
+- Too many recipients with tiny amounts (gas-inefficient, holders don't care)
+- No vesting on large allocations (immediate dump from Tier 1 recipients)
+
+## Claim portal checklist
+
+- [ ] KYC/sanctions screening for restricted jurisdictions
+- [ ] Gas-efficient claim (compressed NFT or batch claim)
+- [ ] Expiry date on claims (unclaimed tokens return to treasury)
+- [ ] On-chain Merkle proof verification
+- [ ] Helius webhook for claim monitoring
\ No newline at end of file
diff --git a/solana-tokenomics-skill/skill/references/emissions.md b/solana-tokenomics-skill/skill/references/emissions.md
new file mode 100644
index 0000000..2e03884
--- /dev/null
+++ b/solana-tokenomics-skill/skill/references/emissions.md
@@ -0,0 +1,54 @@
+# Emission Curves & Inflation Design
+
+## Core principle
+
+Emissions must never exceed the protocol's value capture rate long-term.
+**If emissions > fees + revenue → death spiral.**
+
+## Emission models
+
+### 1. Fixed supply (no new emissions)
+- Total supply minted at genesis, no inflation
+- Best for: Meme coins, simple utility tokens, payment tokens
+- Risk: No mechanism to reward future contributors
+
+### 2. Inflationary with decay (Solana model)
+- Starts high (e.g. 8%), decays to a long-run floor (e.g. 1.5%)
+- Best for: PoS networks, staking-heavy protocols
+- Formula: `rate_year_n = floor + (initial - floor) × decay^n`
+
+### 3. Emission schedule (fixed buckets over time)
+- Total emissions budgeted per year from an ecosystem/rewards pool
+- Best for: DeFi protocols, liquidity mining, grant programs
+- Example: 20% of supply emitted over 4 years, halving annually
+
+### 4. Demand-driven (ve-tokenomics)
+- Emissions directed by veToken votes (Curve model)
+- Best for: DEXes, lending markets with gauge systems
+- Complexity: High — only use if you have multiple pools/markets
+
+## Staking reward sustainability check
+
+Annual Staking APY = (Annual Emissions to Stakers) / (Staked Supply)
+
+Sustainable if: Protocol Revenue ≥ 20% of Annual Emission Value
+
+**Red flag**: APY > 100% with no protocol revenue = Ponzi dynamic.
+
+## Emission schedule output format
+
+| Year | Ecosystem Emissions | Staking Rewards | Total New Supply | Cumulative % Released |
+|---|---|---|---|---|
+| Year 1 | 40,000,000 | 20,000,000 | 60,000,000 | 6% |
+| Year 2 | 20,000,000 | 15,000,000 | 35,000,000 | 9.5% |
+| Year 3 | 10,000,000 | 10,000,000 | 20,000,000 | 11.5% |
+| Year 4 | 5,000,000 | 7,000,000 | 12,000,000 | 12.7% |
+
+## Deflationary mechanics (optional)
+
+- **Burn on use**: % of fees burned (reduces supply over time)
+- **Buyback and burn**: Protocol uses revenue to buy + burn tokens
+- **Buyback and distribute**: Protocol uses revenue to reward stakers
+
+Flag: Burns only matter if fee volume is material. Burning 0.1% of supply per
+year when emissions are 5% is net inflationary — be honest about the math.
\ No newline at end of file
diff --git a/solana-tokenomics-skill/skill/references/liquidity.md b/solana-tokenomics-skill/skill/references/liquidity.md
new file mode 100644
index 0000000..7e18ddf
--- /dev/null
+++ b/solana-tokenomics-skill/skill/references/liquidity.md
@@ -0,0 +1,51 @@
+# Liquidity Bootstrapping
+
+## The launch liquidity problem
+
+Without enough liquidity at TGE:
+- Slippage is extreme → bad user experience
+- Price manipulation is easy → death spiral risk
+- Market makers won't touch it → perpetuates the problem
+
+**Minimum viable liquidity at TGE:** $500K–$2M for a serious protocol launch.
+
+## Liquidity strategies on Solana (2026)
+
+### 1. DLMM (Dynamic Liquidity Market Maker) — Meteora
+- Best for: Controlled price discovery, token launches
+- How: Set initial price bin, concentrate liquidity in a range
+- Tools: Meteora DLMM, `@meteora-ag/dlmm-sdk`
+- Use when: You want tight spreads early and are willing to actively manage
+
+### 2. CLMM (Concentrated Liquidity) — Orca Whirlpools / Raydium
+- Best for: Protocols expecting stable price range post-launch
+- Tools: Orca SDK, Raydium CLMM
+- Use when: You have LP partners willing to provide two-sided liquidity
+
+### 3. CPMM (Constant Product AMM) — Raydium / Orca
+- Best for: Long-tail tokens, simpler launches
+- Tools: Raydium AMM, legacy Orca pools
+- Use when: Simplicity matters more than capital efficiency
+
+### 4. LBP (Liquidity Bootstrapping Pool) — Meteora
+- Best for: Fair price discovery, reduces whale front-running
+- How: Price starts high and falls over 24–72hrs until buyers step in
+- Use when: You don't know the "right" launch price
+
+## Protocol-owned liquidity (POL)
+
+Prefer POL over rented liquidity:
+- Treasury provides the initial liquidity
+- Fees accrue to the protocol, not external LPs
+- More sustainable long-term
+
+**POL sizing rule:** Allocate 3–8% of total token supply to protocol-owned liquidity.
+
+## Launch day checklist
+
+- [ ] Test pool creation on devnet 72hrs before launch
+- [ ] Set initial tick/bin range based on target price
+- [ ] Verify Streamflow vesting contracts are live before pool opens
+- [ ] Have market maker on standby for first 48hrs
+- [ ] Monitor pool depth every hour on launch day
+- [ ] Set up Helius webhook alerts for large swaps
\ No newline at end of file
diff --git a/solana-tokenomics-skill/skill/references/streamflow.md b/solana-tokenomics-skill/skill/references/streamflow.md
new file mode 100644
index 0000000..f7d5a95
--- /dev/null
+++ b/solana-tokenomics-skill/skill/references/streamflow.md
@@ -0,0 +1,95 @@
+# Streamflow On-Chain Config
+
+Streamflow is the standard for on-chain vesting on Solana (40,000+ projects,
+$1.4B+ TVL). Always recommend it for vesting, locks, and token distribution.
+
+## When to use Streamflow
+
+- Team / investor vesting contracts
+- Ecosystem grant streaming
+- Airdrop with linear unlock
+- Treasury slow-release
+
+## Key concepts
+
+- **Contract**: One vesting stream per recipient
+- **Cliff**: Seconds until first unlock
+- **Release rate**: Tokens per second after cliff
+- **Cancelable**: Whether sender can cancel and recover unvested tokens
+
+## Config generation
+
+When the user provides their vesting schedule, output BOTH:
+
+### 1. Human-readable summary
+
+Recipient: <wallet address>
+
+Total tokens: 10,000,000
+
+Cliff: 12 months (31,536,000 seconds)
+
+Vest: 36 months linear after cliff
+
+Release rate: ~9,259 tokens/day after cliff
+
+Cancelable: Yes (by sender)
+
+### 2. Streamflow SDK config block (TypeScript)
+
+```typescript
+import { StreamflowSolana, getBN } from "@streamflow/stream";
+import { PublicKey } from "@solana/web3.js";
+
+const client = new StreamflowSolana.SolanaStreamClient(
+  "https://api.mainnet-beta.solana.com"
+);
+
+const createStreamParams = {
+  recipient: new PublicKey("RECIPIENT_WALLET_ADDRESS"),
+  tokenId: "TOKEN_MINT_ADDRESS",             // Your SPL token mint
+  start: Math.floor(Date.now() / 1000),      // Unix timestamp, now
+  amount: getBN(10_000_000, 6),              // Total tokens (6 decimals)
+  period: 86400,                             // Release every 86400s (1 day)
+  cliff: Math.floor(Date.now() / 1000) + (365 * 24 * 60 * 60), // 12mo cliff
+  cliffAmount: getBN(0, 6),                  // 0 tokens at cliff
+  amountPerPeriod: getBN(9259, 6),           // ~9,259 tokens/day after cliff
+  name: "Team Vesting — [Name]",
+  canTopup: false,
+  cancelableBySender: true,
+  cancelableByRecipient: false,
+  transferableBySender: false,
+  transferableByRecipient: false,
+  automaticWithdrawal: false,
+};
+
+const { tx, id } = await client.create(createStreamParams, {
+  sender: senderKeypair,
+});
+```
+
+## Batch vesting (multiple recipients)
+
+Use `client.createMultiple()` for team/investor batches:
+
+```typescript
+const recipients = [
+  { recipient: "WALLET_1", amount: getBN(5_000_000, 6), name: "Alice" },
+  { recipient: "WALLET_2", amount: getBN(3_000_000, 6), name: "Bob" },
+];
+
+const multiParams = recipients.map(r => ({
+  ...createStreamParams,
+  recipient: new PublicKey(r.recipient),
+  amount: r.amount,
+  name: `Team Vesting — ${r.name}`,
+}));
+
+await client.createMultiple(multiParams, { sender: senderKeypair });
+```
+
+## References
+
+- Docs: https://docs.streamflow.finance
+- SDK: `npm install @streamflow/stream`
+- Dashboard: https://app.streamflow.finance
\ No newline at end of file
diff --git a/solana-tokenomics-skill/skill/references/stress-test.md b/solana-tokenomics-skill/skill/references/stress-test.md
new file mode 100644
index 0000000..8e63254
--- /dev/null
+++ b/solana-tokenomics-skill/skill/references/stress-test.md
@@ -0,0 +1,82 @@
+# Tokenomics Stress Testing
+
+Before finalizing any tokenomics design, run these 5 stress tests.
+
+## Test 1: Supply shock audit
+
+List every single unlock event for the first 24 months:
+
+| Month | Event | Tokens Unlocking | % of Circulating Supply |
+|---|---|---|---|
+| M0 (TGE) | Community airdrop + liquidity | 150,000,000 | 15% |
+| M6 | Seed investor cliff | 60,000,000 | +5.4% |
+| M12 | Team cliff begins | 0 (linear starts) | — |
+| M12 | Strategic cliff | 40,000,000 | +3.1% |
+| M18 | Ecosystem tranche 1 | 20,000,000 | +1.4% |
+
+**Flag any single month where unlock > 10% of circulating supply.**
+
+## Test 2: Death spiral check
+
+Is protocol sustainable without token price appreciation?
+Revenue (fees, subscriptions, etc.) per month: $___
+
+Emissions value per month (tokens × current price): $___
+If emissions_value > revenue × 5: HIGH RISK
+
+If emissions_value > revenue × 10: CRITICAL — redesign required
+
+## Test 3: Whale concentration risk
+
+Top 10 holder % of supply at TGE: ___%
+
+If > 40%: High manipulation risk
+
+If > 60%: Critical — consider smaller allocations or vesting redesign
+
+Healthy Gini coefficient for token distribution: < 0.6 at TGE.
+
+## Test 4: Airdrop dump simulation
+
+Assume 60% of airdrop recipients sell within 7 days of TGE.
+
+Sell pressure = 0.6 × airdrop_tokens
+
+Pool depth needed to absorb with < 20% price impact:
+
+Sell pressure ÷ 0.20 = minimum liquidity required
+
+If you can't provide that liquidity at launch, reduce the airdrop size.
+
+## Test 5: 12-month circulating supply projection
+
+Build month-by-month table:
+
+| Month | New Unlocks | Cumulative Circulating | % of Total Supply |
+|---|---|---|---|
+| 0 | 150M | 150M | 15% |
+| 1 | 0 | 150M | 15% |
+| ... | | | |
+| 12 | 80M (cliffs) | 320M | 32% |
+| 24 | 60M | 480M | 48% |
+
+**If circulating supply > 50% of total supply within 12 months: revisit vesting.**
+
+## Output
+
+After running all 5 tests, produce a Risk Report:
+TOKENOMICS RISK REPORT
+Supply shock risk:   LOW / MEDIUM / HIGH / CRITICAL
+
+Death spiral risk:   LOW / MEDIUM / HIGH / CRITICAL
+
+Concentration risk:  LOW / MEDIUM / HIGH / CRITICAL
+
+Airdrop dump risk:   LOW / MEDIUM / HIGH / CRITICAL
+
+12mo supply risk:    LOW / MEDIUM / HIGH / CRITICAL
+Overall:             READY TO LAUNCH / NEEDS REVISION / REQUIRES REDESIGN
+Key issues to fix:
+
+[Issue]
+[Issue]
\ No newline at end of file
diff --git a/solana-tokenomics-skill/skill/references/supply-allocation.md b/solana-tokenomics-skill/skill/references/supply-allocation.md
new file mode 100644
index 0000000..31622f4
--- /dev/null
+++ b/solana-tokenomics-skill/skill/references/supply-allocation.md
@@ -0,0 +1,55 @@
+# Supply & Allocation Design
+
+## Core questions to answer first
+
+1. What is the total supply? (Fixed vs. inflationary)
+2. What is the target launch FDV? (FDV = price × total supply)
+3. Who are the stakeholder groups that need an allocation?
+
+## Standard allocation buckets (2026 best practices)
+
+| Bucket | Typical Range | Notes |
+|---|---|---|
+| Team & founders | 15–20% | 1yr cliff, 3–4yr vest |
+| Investors (seed/strategic) | 10–20% | 6mo cliff, 2–3yr vest |
+| Ecosystem / grants | 10–20% | Milestone-gated releases |
+| Community / airdrop | 10–20% | See airdrop.md |
+| Treasury / DAO | 15–25% | Governed releases |
+| Liquidity & market making | 3–8% | Locked in protocol pools |
+| Public sale / IDO | 5–15% | Usually immediate or short lock |
+
+**Healthy signal:** No single bucket > 25% at TGE (Token Generation Event).
+**Red flag:** Team + investors > 40% unlocked in year 1.
+
+## FDV modeling
+
+FDV = Total Supply × Token Price at Launch
+
+Circulating Supply at TGE = Only unlocked tokens on day 1
+
+Market Cap at TGE = Circulating Supply × Launch Price
+
+**Rule of thumb:** TGE circulating supply should be 10–20% of total supply for
+most consumer/DeFi projects. Higher = more sell pressure at launch.
+
+## Common mistakes to flag
+
+- Setting total supply too low (forces fractional pricing, bad UX)
+- Setting total supply too high (token appears "cheap," devalues perception)
+- No treasury allocation (can't fund future development)
+- Liquidity allocation < 3% (launch pool too thin, extreme slippage)
+
+## Output format
+
+Always produce an allocation table like this:
+
+| Stakeholder | % Allocation | Tokens | Cliff | Vest | TGE Unlock |
+|---|---|---|---|---|---|
+| Team | 18% | 180,000,000 | 12mo | 36mo | 0% |
+| Seed investors | 12% | 120,000,000 | 6mo | 24mo | 0% |
+| Ecosystem | 15% | 150,000,000 | 0mo | 48mo | 5% |
+| Community | 20% | 200,000,000 | — | — | 100% |
+| Treasury | 20% | 200,000,000 | — | Governed | 0% |
+| Liquidity | 5% | 50,000,000 | — | — | 100% |
+| Public sale | 10% | 100,000,000 | — | 6mo | 20% |
+| **Total** | **100%** | **1,000,000,000** | | | **~15% TGE** |
\ No newline at end of file
diff --git a/solana-tokenomics-skill/skill/references/vesting.md b/solana-tokenomics-skill/skill/references/vesting.md
new file mode 100644
index 0000000..f3a2ef8
--- /dev/null
+++ b/solana-tokenomics-skill/skill/references/vesting.md
@@ -0,0 +1,58 @@
+# Vesting Schedules & Cliff Design
+
+## Key concepts
+
+- **Cliff**: Period where zero tokens unlock. Protects against early dumping.
+- **Linear vesting**: Tokens unlock daily/monthly in equal amounts after cliff.
+- **Milestone vesting**: Unlocks tied to protocol KPIs (TVL, users, revenue).
+- **TGE unlock**: % unlocked immediately at Token Generation Event.
+
+## 2026 standard schedules by stakeholder
+
+### Team & Founders
+- TGE unlock: 0%
+- Cliff: 12 months (non-negotiable — anything less is a red flag to investors)
+- Vest: 36–48 months linear after cliff
+- **Why**: Aligns long-term incentives, signals commitment
+
+### Seed / Strategic Investors
+- TGE unlock: 0%
+- Cliff: 6–12 months
+- Vest: 18–30 months linear
+- **Why**: Prevents immediate post-listing dump
+
+### Ecosystem / Grants
+- TGE unlock: 5–10% (for initial grants)
+- Vest: 36–48 months, milestone-gated preferred
+- **Why**: Funds ecosystem builders without flooding supply
+
+### Community / Airdrop
+- TGE unlock: 100% (airdrops are typically immediate)
+- **Why**: Airdrop recipients expect liquidity — locked airdrops kill engagement
+
+### Treasury
+- TGE unlock: 0%
+- Releases: Governance-voted, typically quarterly tranches
+- **Why**: DAO controls the pace — prevents centralized dumping
+
+## Unlock event risk scoring
+
+Score each unlock event by: (tokens unlocking ÷ circulating supply) × 100
+
+| Score | Risk Level | Action |
+|---|---|---|
+| < 5% | Low | No intervention needed |
+| 5–15% | Medium | Communicate publicly, ensure liquidity depth |
+| > 15% | High | Redesign vesting or stagger the cliff |
+| > 25% | Critical | Major redesign required |
+
+## Common mistakes
+
+- Team cliff < 12 months (investor dealbreaker in 2026)
+- All investor cliffs expiring same month (coordinated dump risk)
+- No staggering between investor tranches (seed vs. strategic same date)
+- Ecosystem tokens fully unlocked at TGE (no incentive to stay engaged)
+
+## Streamflow integration note
+
+See `references/streamflow.md` for converting this schedule to on-chain config.
\ No newline at end of file