ETHPVP
The first PvP protocol built on Uniswap V4 hooks.
Permanent. Oracle-driven. Self-decommissioning.
1. Vision
1.1 The technical foundation
ETHPVP exists because of Uniswap V4 hooks.
Without them, you cannot run a complete game inside the swap path — no oracle reads, no dynamic fees, no atomic buyback & burn. The protocol is not “built on top of V4.” It IS V4 hooks, pushed to their limit.
This matters because V4 hooks unlocked a new category of on-chain applications: programs that piggyback on every swap, atomically, without keepers or backends. ETHPVP is among the first serious experiments in this category.
1.2 Why “Pool vs Pool,” not “Player vs Player”
Player-vs-Player meme arenas have a structural problem: they burn out. Every win is another player's loss. The community eats itself. The protocol dies.
ETHPVP is structurally different. The war is between two POOLS, not two players. If you buy $ETHUP, your opponent isn't another wallet — it's the $ETHDOWN pool. Every player on your side is your ally. Pick the right side, you win without ever facing another player.
This unlocks something pure-PvP couldn't: alliances, not just trades. PvP without the burnout.
1.3 The two-engine vision
ETHPVP runs on two engines that have to fire together.
- 0 owner, 0 admin, 0 upgrade
- Dev fee retires to 0% in 10 months (hardcoded)
- Burn milestones permanently compress the protocol
- LP permanently locked
This engine guarantees survival. The protocol outlives team disbandment, market boredom, ETH crashes. The code keeps running.
- 100% of dev fee → marketing & community building (until retirement)
- Each burn milestone becomes a community event
- Endgame is a collective achievement, not a team milestone
This engine creates what code alone can't: a culture around the game. Pure protocols have no culture. Pure memes have no mechanics. We need both.
By month 12, both engines should have delivered:
- Zero dev fee (retired permanently)
- Sub-1% trading cost (after multiple compression milestones)
- A perpetual, community-owned, near-frictionless PvP arena
The bet: if both engines fire, ETHPVP becomes the first V4 hook PvP protocol that's both unkillable AND alive.
2. Mechanism
ETHPVP runs two ERC20 tokens — $ETHUP and $ETHDOWN — each living in its own Uniswap V4 pool paired against native ETH. A single hook contract attached to both pools enforces the entire economic logic.
2.1 Trade flow
User V4 PoolManager ETHPVP Hook
│ │ │
│── swap(buy $ETHUP) ─────▶ │
│ │── beforeSwap ─────────▶│ take ETH fee
│ │◀────────── delta ──────│ (dev + prize pool)
│ │ │
│ │── (V4 native swap) ───│
│ │ │
│ │── afterSwap ──────────▶│ (sell flow: take fee)
│ │◀──────────────────────│ if 15min elapsed:
│ │ │ → runTick()
│◀── tokens + ETH change ─│ │
│
├─ readChainlink()
├─ adjustPrizeFee(±0.1%)
├─ swapAndBurn(winner)
└─ checkHalving()2.2 The 15-minute tick
Every 15 minutes (gated on the first eligible trade), the hook reads the Chainlink ETH/USD aggregator. If ETH ticked up since the last reading, the DOWN side's prize pool is drained by 50%, swapped into UP tokens, and the bought tokens are burned. If ETH ticked down, the mirror happens.
The protocol is trade-triggered, not keeper-driven: no Chainlink Automation subscription, no off-chain cron, no admin. The user who happens to be the first to swap after a 15-minute boundary pays ~300K extra gas to run the tick on behalf of everyone.
2.3 Three retirement schedules
ETHPVP enforces three independent “graceful exits”:
3. Math & Economics
3.1 Fee composition
Every swap (buy or sell, either side) pays a single total tax in ETH:
total_tax = current_dev_fee + side_prize_fee
= [0% .. 1%] + [0.5% .. side_cap]
side_cap starts at 10% and decays via halving (see §4).3.2 Steady-state prize pool size
Let V = per-tick volume (ETH), p = probability of one side winning. The expected steady-state pool size for each side is:
P_winner* = (V × prize_fee_pct) / (loss_rate × 50%) Example: V = 1 ETH per tick, prize_fee 3%, p = 0.5 P* = (1 × 0.03) / (0.5 × 0.5) = 0.12 ETH per side at equilibrium
3.3 Burn rate & halving acceleration
Per-tick burn (winner side) ≈ 50% of loser pool ÷ token price. The faster volume grows, the faster halvings trigger. Indicative timelines (assuming mid-cycle 50/50 wins):
| Monthly volume | Approx burn / month | Time to halving #5 (50%) |
|---|---|---|
| $50K (light) | ~1M token | 40+ years |
| $500K (mid) | ~10M token | 4–8 years |
| $5M (hot) | ~100M token | ~1–2 years |
| $50M (viral) | ~1B token | ~months |
Halving speed scales with protocol success. The hotter the protocol, the faster it graduates to lower-friction modes. A positive feedback loop on community growth.
3.4 Single-sided liquidity curve
At launch, 100% of each token's 1B supply is seeded as single-sided liquidity into its V4 pool, with the price anchored at tick 196,000. This sets:
- Launch market cap: ~$5K
- 0.1 ETH first buy at T+0: ~3% supply
- 100 ETH cumulative inflow → MC ~$5.5M (1,120× price increase)
- Curve is steep enough for meme-style upside, gentle enough that single-wallet dumps don't crater the market
4. Burn Milestones & Endgame
Burn milestones are the central long-term mechanism. Each side independently tracks 5 thresholds tied to its own burn counter:
| Level | Trigger | New cap | Total tax range (post dev retirement) |
|---|---|---|---|
| 0 (genesis) | — | 10% | 0.5% – 10% |
| 1 | 10% supply burned | 8% | 0.5% – 8% |
| 2 | 20% burned | 6% | 0.5% – 6% |
| 3 | 30% burned | 4% | 0.5% – 4% |
| 4 | 40% burned | 2% | 0.5% – 2% |
| 5 (Endgame) | 50% burned | 1% | 0.5% – 1% |
Independence: UP milestones never affect DOWN and vice versa. The two sides compress on their own timelines, reflecting their respective burn velocities.
Clip semantics: when a milestone fires, if the side's current prize fee exceeds the new cap, it's clipped down (loser gets relief). If it's already at or below the new cap (winner at floor), it's left untouched.
Permanence: milestones are irreversible. Once level N is reached, it stays ≥ N forever.
4.1 Live state
The current burn-milestone progress of the live deployment:
4.2 Live dev fee retirement
5. Security Guarantees
5.1 Immutability
The hook contract enforces six explicit zeros:
- 0 owner — no privileged caller anywhere
- 0 admin — no setter for fees, oracle, recipient
- 0 pause — protocol cannot be paused
- 0 upgrade — no proxy, no implementation slot
- 0 mint — token supply fixed at genesis
- 0 LP exit — single-sided liquidity is permanently locked, no remove-liquidity path exists
5.2 Anti-manipulation
Halving is triggered exclusively by protocol-driven token burns during the 15-minute tick buybacks. Player-initiated “self-burns” (transferring tokens to 0xdead, the hook contract, or any other address) do NOT count toward halving thresholds. This prevents whales from manipulating the milestone schedule.
The only way to advance halving is real trading volume that fuels the buyback machinery. Halving is therefore a verifiable proof of community engagement.
5.3 External dependencies
- Uniswap V4 PoolManager — singleton AMM, audited by Uniswap Labs + Certora + Cantina ($2.35M security competition). 0x4985...2b2b ↗
- Chainlink ETH/USD aggregator — decentralized oracle network with multiple node operators. 0x7104...Bb70 ↗
5.4 Audit posture
ETHPVP relies on immutable design + open source rather than paid audit reports. The hook source is verified on the block explorer; the math is reproducible from forge tests. Anyone can independently review the entire protocol in an afternoon.
High-risk speculative experiment. Tokens may go to zero. Only deploy capital you can afford to lose entirely. Not financial advice.
6. Acknowledgments
This protocol exists because of the work of others:
ETHPVP is open-source, immutable, and stands on the shoulders of giants. Engine 1 is shipped. Engine 2 is the community. May they fire together, and may the protocol outlive us all.