# Proposal: Market-Cap Indexed Fee Optimization for Pump.fun

## Thesis Summary
We propose a **market-cap indexed fee schedule** that maximizes protocol revenue while balancing user activity, token creator incentives, and LP sustainability.
Our approach uses:
- **Densified binning** in the **Bonding Stage**, recognizing potential revenue concentration in micro-cap tokens.
- **Reallocation logic** in the **Swap Stage**, where tokens that graduate from bonding curve show more stability and growth potential.
- **Numerical simulations** to illustrate trade-offs in each stage, ensuring the schedule is grounded in empirical logic.
This framework aligns with pump.fun’s objectives to:
- Maximize protocol revenue,
- Optimize fee split across stakeholders,
- Quantify trade-offs between revenue and activity,
- Mitigate risks of volatility and LP churn,
- Deliver implementable recommendations.

---

## Stage 1: Bonding Curve (Pre-Graduation)

### Key Mechanics
- **Protocol fee**: A fixed percentage (currently ~1%) applied to every trade.
- Importantly, this fee is **constant in percentage terms** and does *not* increase as more tokens are minted.
- **Slippage**: Emerges from the bonding curve function (price vs. supply).
- As more tokens are minted, the **price rises non-linearly**.
- Early bins (low market cap) have **high *relative* slippage** per dollar of trade, since liquidity is very thin.
- Later bins (closer to the 69K graduation threshold) have **lower relative slippage**, but since notional values are higher, the *absolute* cost to traders can still be large.

### Why This Matters
- Traders in micro-cap bins already face high effective costs due to bonding-curve slippage.
- This means small increases in protocol fee (e.g., 1.0% → 1.2%) will generally be **absorbed without significant impact** on trading activity.
- By contrast, in later bins, slippage falls as curve depth increases, so protocol fee becomes a **larger visible component** of total cost.
- Here, maintaining or even lowering the fee (e.g., 1.0% → 0.7%) can **encourage volume** and push tokens toward graduation.

### Implication for Fee Design
- **Early bins (micro-cap concentration)**: Slightly higher protocol fee is feasible, since slippage already dominates user experience.
- **Later bins (approaching graduation)**: More sensitive to fee levels; lowering protocol fee here can sustain growth and volume.
- Net effect: **Densified binning** in the bonding stage allows protocol to capture additional revenue from micro-caps while still encouraging healthy graduation dynamics.

### Recommended Fee Schedule (Bonding Stage)
| Market Cap Bin (% of graduation MC) | Example MC (USD) | Protocol Fee | Rationale |
|------------------------------------|------------------|--------------|-----------|
| Bin A: 0–1% | $0–1000 | **1.40%** | Lottery trades, high slippage; fee bump absorbed easily. |
| Bin B: 1–5% | $1000–3,500 | **1.20%** | Still speculative; modest uplift safe. |
| Bin C: 5–15% | $3,500–10,500 | **1.00%** | Neutral baseline. |
| Bin D: 15–40% | $10,500–28,000 | **0.80%** | Encourage progression, reduce barriers. |
| Bin E: 40–100% | $28,000–69,000 | **0.70%** | Subsidize tokens nearing graduation, build credibility. |

### Numerical Example (Bonding Curve)
Assumptions:
- **Total bonding notional traded:** $50M
- **Volume distribution:** 60% A, 30% B, 7% C, 2% D, 1% E
- **Baseline flat fee:** 1.00% → $500k protocol revenue

Results under tiered schedule:
- Protocol revenue: **$642k** (+28%)
- Average trader cost rises only ~25 bps (dominated by slippage, ~700–900 bps).
- Strong protection for later bins: D/E effective costs fall despite higher A/B fees.

**Conclusion:** Early-stage densification yields ~30% uplift with minimal UX impact.

---

## Swap Stage (Post-Graduation)

### 1. Current Fee Schedule
Once a token graduates from the bonding curve, it is listed on **PumpSwap**.
The **current fee split** per trade is:

- **0.20% (20 bps)** to Liquidity Providers (LPs)
- **0.05% (5 bps)** to Protocol
- **0.05% (5 bps)** to Token Creator
- **Total = 0.30% (30 bps)**

This structure prioritizes LP incentives (2/3 of total fees), while giving the platform and creator relatively small slices.

---

### 2. Reallocation Under Constant 0.30%
We now explore how **protocol revenue can be increased** by reallocating the 30 bps without changing the user’s total cost of trading.

#### Business Logic:
- **LP fee** can be reduced slightly in higher-MC bins, where liquidity depth is already high, or negative slippage.
- **Creator fee** can decay with token age (older, more stable tokens rely less on creator marketing).
- **Protocol fee** can expand to capture more of the same 30 bps “budget.”

#### Example Reallocation:
- **New Split Proposal (mid-MC bin):**
- LPs: 0.15% (15 bps)
- Protocol: 0.10% (10 bps)
- Creator: 0.05% (5 bps)
- Total = 0.30%

#### Numerical Example:
Suppose a graduated token generates **$100M in Swap trading volume**:
- **Current Split:**
- Protocol = $100M × 0.05% = **$50K**
- LPs = $100M × 0.20% = **$200K**
- Creator = $100M × 0.05% = **$50K**
- Total Fees = $300K

- **Proposed Reallocation:**
- Protocol = $100M × 0.10% = **$100K**
- LPs = $100M × 0.15% = **$150K**
- Creator = $100M × 0.05% = **$50K**
- Total Fees = $300K

**Result:** Protocol revenue **doubles (+$50K)** while keeping user cost constant at 30 bps.

---

### 3. Fee-Corridor Concept (Relaxing 0.30%)
Instead of fixing total fees at exactly 0.30%, we allow a **fee-corridor** of ±0.05% around this benchmark.
- **Range:** 0.25% – 0.35% total fee
- **Rationale:**
- Users are largely insensitive to small changes of ±5 bps, especially in meme-token trading where slippage dominates.
- This corridor allows the protocol to flex fees dynamically across MC bins:
- **Low-MC bins (fragile liquidity):** total fees closer to 0.25% → cheaper trading, encourages activity.
- **High-MC bins (established tokens):** total fees closer to 0.35% → protocol captures more from stable volume.

#### Example With Corridor:
- Token has $200M in swap volume.
- **Case A (low-MC, incentivize activity):**
- Total Fee = 0.25%
- Split: LP = 0.15%, Protocol = 0.07%, Creator = 0.03%
- Protocol Revenue = $200M × 0.07% = **$140K**

- **Case B (high-MC, stable liquidity):**
- Total Fee = 0.35%
- Split: LP = 0.18%, Protocol = 0.12%, Creator = 0.05%
- Protocol Revenue = $200M × 0.12% = **$240K**

Compare to baseline (0.30% total, Protocol = 0.05%):
- Baseline Protocol Revenue = $200M × 0.05% = **$100K**
- Optimized Corridor Protocol Revenue = up to **$240K** (+140%).

---

### Key Takeaways
- **Constant-Fee Optimization:** Within the 30 bps, shifting share from LPs (who already benefit from token appreciation + impermanent loss comp) to Protocol meaningfully boosts platform revenue.
- **Fee-Corridor Optimization:** Allowing a controlled range (25–35 bps) enables dynamic tuning by MC bin:
- Low-MC → reduce trading frictions to boost engagement.
- High-MC → monetize stable, sticky tokens with slightly higher cost.
- **Business Intuition:** Traders mostly care about *total effective cost*, not its composition. By reallocating and introducing a corridor, the Protocol can **capture a larger slice of a nearly inelastic cost pie.**

---

## Implementation Summary

### Bonding Curve Stage
- **Thesis:** Most of Pump’s revenue is generated at the very early stage (micro-cap tokens that rarely graduate).
- **Optimization Approach:**
- Partition the bonding curve into **densified MC bins** (e.g., <5K, 5–15K, 15–35K, 35–69K).
- Adjust **protocol fee by bin**: slightly higher in the earliest bins where trade density is largest, slightly lower as tokens approach graduation to smooth the transition.
- Recognize that costs here = **protocol fee + bonding curve slippage** (no LP or creator fees).
- **Business Rationale:**
- Thousands of micro-cap tokens → stable, predictable revenue stream.
- Traders are already tolerant of high effective cost due to curve slippage → protocol can safely capture more in early bins.
- **Numerical Impact:**
- Example: $10M volume across early bins.
- Baseline protocol fee (1%) = $100K revenue.
- Adjusted fee (1.2% in early bins, 0.8% in later bins) = **$112K revenue** with negligible impact on trader behavior.
- Thesis: **High-cost density in micro-caps = best opportunity for protocol capture.**

---

### Swap Stage (Post-Graduation)
- **Thesis:** Graduated tokens trade under a fixed 0.30% fee (20 bps LP / 5 bps protocol / 5 bps creator). Current design heavily favors LPs.
- **Optimization Approach (two layers):**
1. **Reallocation (constant 0.30%):**
- Reduce LP share in higher-MC bins where liquidity is deep.
- Decay creator share as tokens age.
- Increase protocol share accordingly.
- Example: shifting Protocol from 5 bps → 10 bps doubles revenue on same volume.
2. **Fee-Corridor (dynamic 0.25–0.35%):**
- Low-MC: reduce total fee (≈25 bps) to encourage activity.
- High-MC: raise total fee (≈35 bps) to capture value from sticky volume.
- Protocol share flexes within corridor to maximize capture.
- **Business Rationale:**
- Traders focus on **total cost**, not split.
- LPs already compensated via token appreciation + IL mechanics.
- Creators have diminishing marginal impact post-graduation.
- **Numerical Impact:**
- $200M volume baseline → Protocol earns $100K (5 bps).
- Reallocation only → Protocol earns $200K (10 bps).
- Corridor (high-MC bin) → Protocol earns $240K (12 bps @ 35 bps total).
- Thesis: **Slightly relaxing the 0.30% rule unlocks >2x revenue upside.**

---

### Unified Thesis
- **Lifecycle Segmentation:** Revenue opportunities differ across stages.
- **Bonding Curve:** maximize capture in micro-cap bins (bulk of ecosystem).
- **Swap Stage:** reallocate and introduce corridor to better monetize stable tokens.
- **Key Principle:** Traders anchor to *total effective cost*, not distribution.
- **Outcome:** By rebalancing fees intelligently by stage and MC bin, Pump can significantly increase protocol revenue **without increasing user pain**, while keeping LPs and creators sufficiently incentivized.

---

# Deployment & Monitoring Plan

This appendix defines **what to measure**, **how to deploy**, **how to test**, and **how to roll back** fee changes across lifecycle stages and MC bins.

---

## 1) Key Metrics to Monitor (by Stage & MC Bin)

**Revenue & Cost**
- **Protocol revenue** (USD): per-bin, per-day.
- **LP revenue** (USD): same form using `lp_bps`.
- **Creator revenue** (USD): same form using `creator_bps`.
- **Total fees** (USD): protocol + LP + creator.
- **Effective trader cost (bps)**: fees (bps) + realized slippage (bps).

**Volume & Activity**
- **Trade volume (USD)** per bin/day, **avg trade size**
- **Token funnel**: #created → #graduated; time-to-graduation distribution.

**Market Quality / UX**
- **Realized slippage (bps)** by trade size bucket
- **Price impact curve**: bps impact vs notional (per bin).
- **Failure/abandon rates**: tx dropped, cancelled, or reverted.

**LP Health (Swap)**
- **LP churn**: adds/removes per bin.

**Creator Health**
- **New launches/day**, **returning creators**, **creator earnings**

**Attribution**
- **fee_policy_tag** on every trade/pool: `baseline`, `realloc_30bps_v1`, `corridor_v1`, etc. (Mandatory for causal attribution.)

---

## 2) Deployment Strategy (Gradual + Guardrails)

**A. Phased Rollout**
1. Apply new schedule to ≤ **10%** of *new* tokens (randomized by token ID; stratify by MC bin). Duration: **14 days**.
2. Expand to **25% → 50%** if canary passes guardrails (below). Duration: +**14–28 days**.
3. **General Availability**: roll to 100% with controller limits (rate bands & fee corridors).

**B. Guardrails (per MC bin, evaluated on rolling windows; see §3)**
- **Revenue floor**: ProtRev per bin ≥ **95%** of baseline (or model-predicted) for **2 consecutive windows**.
- **Leakage**: RouteGap ≤ **0 bps** median; 95th pct ≤ **+5 bps**.
- **Volume drop**: ΔVolume/Volume ≥ **−5%** for **2 consecutive windows**.
- **Slippage**: median realized slippage not ↑ by more than **20%** (absolute cap set per bin).
- **LP health**: TVL not ↓ > **10%** with slippage worsening.

---

## 3) A/B Tests, Statistical Checks, Smoothing Windows

**Statistical Checks**
- **Rolling windows**: compute all KPIs on **7d (responsive)** and **14d (stable)** moving windows; update daily.
- 7d flags fast changes; 14d confirms persistence.
- **Significance**: two-sided tests at **α = 0.05**; report effect size + CI.

---

## 4) Rollback (Reverting to Baseline) Guide

**Triggers (any, for 2 consecutive windows in MC bin)**
- Protocol Revenue < **95%** of baseline.
- Volume drop > **5%**.
- Slippage ↑ > **20%**

**Actions**
1. **Freeze**: stop further ramp; lock controller in affected bins.
2. **Revert**: switch fee policy tag to `baseline` (feature flag)
3. **Retry**: re-launch with narrower deltas (e.g., ±2 bps) and stricter guardrails.

---

## Summary

- **Tag everything** with `fee_policy_tag`.
- **Dashboards live**: per-bin revenue, volume, slippage
- **Windows**: track 7d & 14d rolling KPIs; alert on breaches.
- **Ramp**: 10% → 25% → 50% → 100% gated by guardrails.
- **Rollback**: feature-flag reversion in <1h