# 🐙 DEGEN ROYALE ($DGR)

### *Chaos is Coming, Only the Strongest Will Rule the HILL*

---

**Version:** 2.0  
**Date:** July 2026  
**Network:** Base (Ethereum Layer 2)  
**Token Standard:** ERC-20  
**Status:** Testnet — Mainnet Pending

**Official Links:**
- **Website:** https://dgrbase.xyz
- **Telegram Group:** https://t.me/dgrbase_xyz
- **Telegram Channel:** https://t.me/dgrbase
- **X (Twitter):** https://x.com/degenroyale_DGR
- **Info Bot:** @DegenRoyaleDGR_bot

---
## Executive Summary

Degen Royale is not your average memecoin. While most memecoins rely purely on hype and speculation, $DGR builds an entire ecosystem around it — with games, staking, and automated liquidity management that keep degens engaged and the charts pumping.

**The core idea is simple:** every trade fuels the ecosystem. Tax from buys and sells flows into game pools (Lottery, King of the Hill, Blitz Hill), staking rewards, and LP management — creating a self-sustaining economy where activity generates value for everyone.

**Key numbers:**
- **Max Supply:** 1,000,000,000 $DGR (1 billion)
- **Token Allocation:**
  - **15% (150M)** → Initial LP (paired with 80% of ETH raised from presale)
  - **20% (200M)** → Presale (self-hosted contract)
  - **55% (550M)** → Ecosystem Growth (LP Manager)
  - **5% (50M)** → Airdrop (activity-points campaign)
  - **5% (50M)** → Marketing (KOL allocations, locked & vested in Presale)
- **Network:** Base L2 — fast, cheap, and built for degen activity
- **Presale Voucher:** 200M pVDGR (0.7x staking reward) for presale participants

**Why Base?**
- Gas fees under $0.001 per transaction
- Fast block times (~2 seconds)
- Growing degen community
- Backed by Coinbase infrastructure

---

## Trust Model

Degen Royale is built on one principle: **trust the code, not the devs.**

All smart contracts are **immutable** — once deployed, no one can change the rules. The game mechanics, tax rates, and fund allocation are hardcoded and verified on-chain.

| Layer | Guarantee |
|-------|-----------|
| **Contracts** | Immutable, verified on Base block explorer |
| **Dev/Treasury Wallet** | Published address, every transaction traceable on-chain |
| **Presale** | On-chain deposit tracking, funds released only after finalization |
| **Bot (Kraken)** | Dashboard public, all trigger actions logged |
| **Identity** | Anonymous — but code speaks louder than names |

> "Don't trust me. Trust the code."

This project was developed with AI-assisted coding and auditing. All design decisions, architecture, and tokenomics originate from the founding team.

Anonymous + immutable code + on-chain transparency is more trustworthy than a known dev team that can change contract rules at will. Every function, every parameter, every flow is auditable by anyone at any time.


## 1. Token Overview

| Property | Value |
|----------|-------|
| Name | Degen Royale |
| Symbol | $DGR |
| Max Supply | 1,000,000,000 (1B) |
| Standard | ERC-20 (OpenZeppelin v5) |
| Network | Base (Ethereum L2) |
| Initial LP (Mainnet) | Up to 16 ETH + 150,000,000 $DGR (80% of 20 ETH presale hardcap) |
| Reserve | 1,000,000,000 $DGR → LPManager 550M + Presale 450M (150M LP + 200M vesting + 50M airdrop + 50M marketing) |
| Listing Price | revealed after presale |

### Token Distribution

```
1,000,000,000 $DGR (100% minted at deploy)

├── 150,000,000 $DGR (15%) → Initial LP (paired with 80% of raised ETH)
├── 200,000,000 $DGR (20%) → Presale Allocation (self-hosted contract)
├── 550,000,000 $DGR (55%) → Ecosystem Growth (held by LPManager)
├── 50,000,000 $DGR (5%) → Airdrop (activity-points campaign)
└── 50,000,000 $DGR (5%) → Marketing (KOL allocations, locked & vested)
```

### Presale

The presale is conducted via a **self-hosted smart contract** (not a third-party platform). Buyers send ETH directly to the presale contract and receive **pVDGR** (Presale Voucher Token) after finalization.

**Why self-hosted?**
- Zero platform fees (only gas costs)
- Full control over mechanics
- Transparent on-chain tracking
- Telegram bot integration for UX

| Parameter | Value |
|-----------|-------|
| Platform | Self-hosted contract + Telegram bot |
| Token Sold | pVDGR (not DGR directly) |
| pVDGR Supply | 200,000,000 |
| DGR per ETH | minimum 10,000,000 |
| Hardcap | 20 ETH |
| Softcap | 2 ETH |
| Min Buy | 0.001 ETH |
| Max Buy | 1 ETH |
| Duration | 7 days |
| LP Allocation | 80% of raised ETH + 150M DGR |
| DevOps Allocation | 20% of raised ETH |
| Refund | Available only if softcap not reached after 7 days |

### Fund Allocation

All raised ETH is split **80% LP / 20% DevOps** regardless of amount:

| Destination | Share | Purpose |
|-------------|-------|---------|
| LP | 80% | Paired with 150M DGR on Uniswap V2 |
| DevOps | 20% | DevOps & early marketing |

- LP always pairs with **150M DGR** — thicker LP from more ETH raised means lower slippage
- **pVDGR (200M)** is distributed proportionally to each depositor based on their share of total raised

### Refund Policy

Refund is **only available** if the softcap (2 ETH) is not reached within the 7-day presale window.

| Condition | Refund? |
|-----------|---------|
| < 2 ETH raised after 7 days | ✅ Full refund — presale failed |
| ≥ 2 ETH raised after 7 days | ❌ No refund — presale succeeded |

### Presale Vesting

After finalization, participants claim **100% of their pVDGR** directly to their wallet. It is their choice whether to stake it or hold.

**Flow:**
1. Presale finalizes → participants call `claimPVDGR()` → 100% pVDGR sent to wallet (no LP needed for pVDGR)
2. pVDGR is **not auto-staked** — users decide: stake for ETH rewards or hold
3. Staking pVDGR earns ETH at **0.7x** the rate of DGR stakers (no locktime)
4. The first DGR claim unlocks once the dev adds the **initial LP** (`addLiquidity()` — 150M DGR + 80% of raised ETH); only after that can users call `claim()` → pVDGR is burned, DGR is sent weekly

**Weekly DGR claim:**
- Claims 1-2: **5% of original allocation per week, max 250,000 DGR per wallet** (anti-whale)
- Claims 3+: **10% of original allocation per week, max 500,000 DGR per wallet** (anti-whale)
- On each claim: proportional pVDGR is burned, DGR is sent
- When full allocation claimed, all pVDGR burned automatically

**Why pVDGR?**
- Prevents immediate dump — holders are incentivized to stake for ETH rewards
- 0.7x reward ratio reflects the locked/vested position
- Transparent — all vesting and staking is on-chain

### Airdrop (5% — Activity Points)

**50M $DGR (5% of supply)** is reserved for the community airdrop. It rewards real ecosystem activity, not wallet count — no paid participation, no Pinksale-style raffle.

**How points work:**
- KOTH / Blitz Hill leaderboard positions: **5,000 / 3,000 / 1,000 points** (repeatable each round)
- On-chain function interactions across the ecosystem: **200 points per unique function** (once per function, no repeats)
- Social tasks: **200 points per task** (via the Telegram airdrop bot)
- Referral: **100 points per referral** + **0.2×** of the referee's accumulated points + **10,000 points if the referred user joins the presale with a minimum buy of 0.01 ETH**
- Eligibility: must interact with **at least 2 ecosystem functions** before the snapshot

**Allocation & claim:**
- Points are earned **only from on-chain interactions on the testnet after the LP goes live** (pre-presale functions give no points) — users are encouraged to try the live ecosystem post-launch
- Interactions are **recorded live on-chain** (contracts stay exactly as deployed — no redeploy); the **mainnet presale runs in parallel**, and **point counting stops when the mainnet presale finalizes** (snapshot at finalize)
- Total airdrop pool is split **proportionally by points** across all eligible participants (no winner cap)
- Backend computes allocations and pushes them on-chain in **batches of up to 500 users** per `setAirdropAllocations()` call; the contract reverts if the total ever exceeds 50M DGR
- Claim follows the same vesting as presale: **5% (max 250K) for the first 2 claims, then 10% (max 500K) per week**
- First airdrop claim also unlocks only after the **initial LP is added** (`addLiquidity()`)
- Airdrop is claimed directly as **$DGR** (no pVDGR voucher involved)

**Why points-based?**
- Rewards engaged users instead of farmed wallets
- Point values are small enough to prevent sybil farming from being profitable
- The 500K/week cap keeps distribution healthy and spread across many wallets

### LPManager Reserve

The remaining 550M DGR (55%) is held by LPManager and deployed through automated triggers:
- Add-liquidity events on buy triggers, and on sell triggers until unique wallets exceed 5,000 (tier 3 tax) — 10% chance in Tier 1, 3% otherwise
- Buyback-and-burn events on sell triggers only after unique wallets exceed 5,000 — 10% chance in Tier 1, 3% otherwise
- Events queued by transaction on chain, and triggered by kraken immediately. if events not triggered after queued in 3 hours the function will be fallback to communty.
- Manual triggers by Kraken or the devs for ecosystem adjustments later.

> **🔒 LP Token Security:** All LP tokens generated from any add-liquidity operation (automated or manual) are held inside the LPManager contract. These LP tokens **cannot be transferred, removed, or withdrawn** under normal operating conditions — not even by the devs or Kraken. The only way LP tokens can be unlocked is through the `emergencyWithdrawAll()` function, which exclusively activates during the **Termination Event** (see ⚠️ Termination Event section). This means liquidity is effectively locked from the moment it is added until any potential project termination, giving holders verifiable assurance that LP cannot be rugged.

---

## 2. Tax System

### 2.1 Dynamic Tax Tiers

Tax rates change based on the number of unique wallets that have interacted with the token. This creates natural economic pressure:

| Unique Wallets | Buy Tax | Sell Tax | Max TX |
|----------------|---------|----------|--------|
| 0 – 1,000 (Tier 1) | 3% | **12%** | 10% of LP balance |
| 1,001 – 5,000 (Tier 2) | 3% | 6% | 10% of LP balance |
| 5,001+ (Tier 3) | 3% | 6% | No limit |

**Why these numbers?**
- **12% sell tax in Tier 1** — Strong deterrent against early dumps. If you buy early, you pay a premium to sell.
- **3% buy tax across all tiers** — Consistent, predictable entry cost.
- **10% max TX** — Simple, punishes whales. Disappears at 10K wallets.
- **0.001 ETH minimum buy** — Wallet registration threshold.

### 2.2 Tax Flow

When a buy or sell occurs, tax is collected in **$DGR tokens** and accumulates in the contract (`pendingTaxTokens`).

**Tax swap — primary (inline on every sell):**
On every sell transaction, the contract **automatically swaps** all accumulated DGR tax → ETH **inline** via Uniswap V2 Router (`_autoSwapTax()`), then immediately distributes the ETH to all pools and Dev/Treasury Wallet — all in the same transaction. Users never pay extra gas for this swap because it piggybacks on the seller's existing transaction.

**Tax swap — fallback (Kraken trigger):**
If no sell transactions occur for an extended period (accumulated tax reaches **0.5% of LP balance**), Kraken Bot triggers `swapPendingTax()` as fallback to perform the same swap + distribution.

**Distribution allocation:**

| Destination | Share |
|-------------|-------|
| KOTH Pool | 27% |
| Referral Pool | 3% |
| LP Manager | 20% |
| Blitz Hill Pool | 20% |
| Lottery Pool | 10% |
| Staking Pool | 10% |
| Dev/Treasury Wallet | 10% |

### 2.3 Referral Rewards — 0.2% of Referee Trading Volume

- **3% of ETH tax** is routed to the `ReferralPool` contract (KOTH share reduced from 30% to **27%**) to fund referral rewards.
- Referrers earn **0.2% (20 bps)** of their referee's **buy + sell volume (post-tax, in ETH)**. Volume is computed by the backend from on-chain events (`Swap` on the pair + `Transfer` on the token) starting from the referee's binding block.
- **Binding is exclusively pushed from airdrop-bot data** via `ReferralPool.setReferrersFor()` (Kraken/dev only). There is **no public `setReferrer`** — manual binding can be gamed by typing an arbitrary wallet (e.g., a second wallet owned by the same user) without real referral proof.
- Airdrop referrals auto-convert to mainnet referrals by reading the bound wallet address from the bot data — no user signature required; already-bound entries are skipped (idempotent).
- Referrers claim via `claim()`; the un-referred/surplus pool balance is swept to the Dev/Treasury Wallet as additional promo funds.

### 2.4 Dev/Treasury Wallet Allocation (10% of Tax)

All expenses from the Dev/Treasury Wallet are recorded and reported transparently on the Degen Royale website/miniapp for the community to monitor.

---

## 3. Game Mechanics

### 3.1 🎰 Lottery

**How it works:**
Every buy generates a 6-digit ticket number. If it matches the previous buyer's ticket — the previous buyer wins!

**Activation:**
- Lottery activates when pool balance reaches **0.1 ETH** (0.005 ETH testnet)
- All buys participate — **no minimum buy requirement**

**Payout floor (pool growth):**
- Prizes are only queued while the **free pool** (balance minus reserved-for-winners) is at least the activation threshold
- Below it, tickets and matches keep running but wins are **skipped** (`MatchSkippedPoolLow`) until the pool recovers — the pool rebuilds from tax instead of being slowly drained

**Key rules:**
- Ticket is generated from transaction-specific seed (`blockhash(block.number-1)` + timestamp + nonce + sender + receiver)
- Match is checked from trailing digits (right to left)

**Match & Rewards:**

| Digit Match | Multiplier | Probability |
|-------------|-----------|-------------|
| 1 digit | **0.1x** | ~10% |
| 2 digits | **5x** | ~1% |
| 3 digits | **30x** | ~0.1% |
| 4 digits | **100x** | ~0.01% |
| 5 digits | **300x** | ~0.001% |
| 6 digits | **1,000x** | ~0.0001% |

**Prize rules:**
- Max win: **5% of pool balance** per ticket (cap)
- Prize split: **90% winner** / 5% staking / 5% Dev/Treasury Wallet
- prize reward queued by buy transaction on chain, triggered by kraken, fallback to community after 10 minutes.

**Match 1 toggle:**
- Match 1 (0.1x) is **enabled by default** — active from launch
- At **1,000 unique wallets since activation** (testnet: 100), Match 1 auto-disables — no manual disable function exists
- Reactivation requires a **successful community vote**; the devs then execute `enableMatchOne(duration)` with a chosen duration (min 1 hour mainnet / 10 minutes testnet, max 30 days), after which Match 1 auto-disables via a timer
- There is no manual disable — deactivation is always automatic (wallet threshold counts new unique wallets since activation; timer after a voted reactivation)
- Higher matches (2-6 digits) are always active regardless of wallet count

**Example:**
```
Previous buyer: ticket 555836
You buy: ticket 555831
Check from right: 1≠6 → no match ❌

Previous buyer: ticket 555836
You buy: ticket 534836
Check from right: 6=6, 3=3, 8=8 → 3 digits match! 🎉
Previous buyer wins → 30x multiplier!
```

---

### 3.2 👑 King of the Hill (KOTH)

**How it works:**
Compete to hold the highest **single buy**. Your score **decays over time** — creating urgency and opportunities for challengers. Hold #1 for **10 minutes** and you win **50% of the pool!**

**Scoring — Highest Single Buy + Decay:**
- Your score = your largest single buy transaction (in $DGR)
- Leader's score **decays over time**: `score = highestBuy × max(0, 1 - k × t²)`
- After ~9 minutes, leader's score drops to ~50% of their highest buy
- Challengers can overtake once their highest buy exceeds the leader's decayed score
- Staking reduces your highest buy (lowering your competitive position)

**Why decay?**
- Creates dynamic competition — no "buy once and sleep"
- Smaller buyers can overtake whale leaders after decay kicks in
- Every new leader gets a fresh 10-minute hold window
- Automatic on-chain leader rotation — no manual trigger needed

**Activation:**
- **Round 1:** Pool ≥ 1 ETH + ≥ 100 unique wallets — must activate within **14 days** after the first LP is added (the round-1 clock starts when LP enters the pair, not at deployment)
- **Round 2+:** Pool back to its **ATH (all-time high)** balance + ≥ 10 distinct wallets bought after the previous round ended
- **Window:** the next round gets **50% of the last round's duration** to activate (rounded up to whole days, minimum 1 day, maximum 30 days mainnet / 3 days testnet) — the longer the community kept the previous round alive, the more time it gets
- **Challenge:** Community must work together to meet activation requirements — no shortcut

**Rules:**
- Top-10 leaderboard tracked on-chain (sorted by highest buy)
- Leader rotation is **automatic** — contract checks on every buy
- Scoring stays open until the **current** leader completes their 10-minute hold — every new leader gets a full, challengeable window

**Defend & Overtake:**
- **Defend:** leader buys ≥ `peak + (decayed score / 2)` → peak updates, timer does NOT reset. In the last **30 seconds** of the hold, defending is penalized: the leader must buy ≥ **2× their peak**
- **Overtake:** challenger buys ≥ `decayed leader score + 1` → becomes leader, timer resets
- **Same-block rule:** if defend and overtake land in the same block, defend wins
- If leader is overtaken → timer resets for new leader
- Once hold achieved → pool balance snapshotted → **WINNER!**

**Prize:**
- **50% pool** → winner (90%) / 5% staking / 5% Dev/Treasury Wallet
- Winner gets **45% of pool** net (50% × 90%)
- prize reward queued by buy transaction on chain, triggered by kraken, fallback to community after 10 minutes.

### ⚠️ Termination Event

The termination event is an **automated on-chain safety mechanism** — NOT a manual override by the devs.

**How it works:**
- KOTH requires community participation to activate (pool balance + wallet threshold)
- **Round 1** must activate within **14 days** after the first LP is added
- **Round 2+** must activate within **50% of the last round's duration** (rounded up to whole days, minimum 1 day, maximum 30 days mainnet / 3 days testnet)
- If a round **fails to activate in time**, the termination sequence triggers automatically
- **The devs CANNOT trigger this manually** — the smart contract checks `block.timestamp` against the deadline. Only the on-chain clock determines termination.
- Because the window scales with how long the community kept the last round alive, termination effectively only happens when the community is truly inactive.

**Termination sequence:**
1. Buys are disabled → protects remaining holders from further exposure
2. 7-day sell-only exit window opens → users can exit at any time
3. After exit window → remaining funds (ETH + DGR + LP tokens from LPManager) are sweepable by the devs for **community-directed use**

**Why this exists:**
- Without termination, ETH would be locked in contracts forever if the project dies
- The sweep gives the community a chance to decide: restart, redistribute, or wind down
- The devs are stewards, not owners — the community votes on what happens next

**This is a community challenge:**
- Keep KOTH active = keep the project alive
- If the community stops participating for longer than the round window, the project enters termination
- No single person can kill or save the project — it requires collective action

> **A promise from the devs:** We did not promise that the project will live forever, but we promise to do the best to make that alive. The final decision always belongs to the community.

---

### 3.3 ⚡ Blitz Hill (Hourly Competition)

**How it works:**
Hourly rounds — participants compete through **balanced buy-and-sell activity**. The scoring formula rewards both volume and consistent two-sided participation. Top-5 leaderboard is displayed; only top-3 receive ETH payouts.

**Scoring Formula:**
```
Score = (BuyVolume + SellVolume) × sqrt(min(BuyTx, SellTx, MAX_TX))
```

- **BuyVolume / SellVolume:** Cumulative DGR traded this round (post-tax)
- **BuyTx / SellTx:** Number of qualified buy and sell transactions
- **MAX_TX = 50:** Maximum transactions counted toward the sqrt bonus per wallet per round (caps bot advantage)
- **sqrt()** provides diminishing returns on transaction count — encourages balanced activity over pure spam
- Staking reduces buy volume (reduces score proportionally)

**Why this formula?**
- Activity-first design: rewards active participants, not just capital
- Separated from KOTH: whales compete in KOTH (capital game), active traders compete in Blitz Hill (activity game)
- Bot-resistant: sqrt() diminishing returns + MAX_TX cap limits bot dominance
- Tax is the natural equilibrium: each round-trip costs ~15% in tax, making grinding self-limiting

**Activation:**
- **Round 1:** Pool ≥ 0.5 ETH + ≥ 100 unique wallets
- **Round 2+:** Pool must return to its **ATH (all-time high)** balance + ≥ 10 distinct wallets must buy after the previous round ends
- After finalization, Kraken (or community fallback) calls `activateRound()` — rounds do NOT auto-start
- Scoring pauses after round timer expires — activity during gap doesn't count
- Each new round starts fresh: leaderboard resets, scores reset to zero
- **Emergency Override:** `manualActivateRound()` — devs only and requires a passed community vote (one-shot approval); bypasses activation requirements, for dead-project push
- **Anti-drain:** Minimum 10 unique traders required per round. If fewer participate, round finalizes but NO payout occurs — funds stay in pool. Prevents single-wallet win-by-default attacks.

**Leaderboard:**
- Top-5 displayed (for community engagement)
- Only top-3 receive payouts

**Prize distribution (from pool balance):**

| Rank | Pool Share | Winner (90%) | Staking (5%) | Treasury (5%) |
|------|-----------|-------------|-------------|---------|
| 🥇 1st | 12% | 10.8% | 0.6% | 0.6% |
| 🥈 2nd | 5% | 4.5% | 0.25% | 0.25% |
| 🥉 3rd | 3% | 2.7% | 0.15% | 0.15% |

- **Minimum reward threshold:** Rewards below 0.0001 ETH are rolled back into the pool instead of being paid out
- Remaining **80% stays in pool** and carries over to next round
- Payouts are triggered by Kraken after round finalization, fallback to community after 10 minutes.

---

### 3.4 💎 Staking

**How it works:**
Stake $DGR to earn a share of ETH rewards from game pools and tax distribution.

**Reward sources:**
- 10% of every tax distribution
- 5% of every game prize (Lottery, KOTH, Blitz Hill)
- ERC20 airdrops (managed by devs)

**Drip mechanism:**
Rewards don't go directly to the accumulator — they go to a **global pool**, then **2% drips every 5 minutes** to the reward accumulator. The slower drip makes reward distribution smoother and keeps the pool from emptying too quickly between volume spikes.

```
ETH/ERC20 in → Global Pool → dripped every 5 minutes, allocation per drip depend how long the erc20 drop will be active → Accumulator → Claim
```

**Unstake:**
- **Lock 3 days** from last stake
- Lock lifted immediately if project terminated (automated via same 14-day KOTH inactivity trigger — no manual override)

**Security:**
- Only the devs can send ERC20 to the staking pool
- The devs can freeze malicious tokens
- 3-layer protection: whitelist + devs-only distribution + freeze

---


### 3.5 🎫 Presale & Vesting

**Self-hosted presale contract (no third-party platform):**
- **Sells pVDGR** (not DGR directly)
- **Allocation:** 200M pVDGR
- **Price:** min 10,000,000 pVDGR per ETH
- **Softcap:** 2 ETH
- **Hardcap:** 20 ETH
- **Min buy:** 0.001 ETH
- **Max buy:** 1 ETH
- **pVDGR:** 100% distributed to participant wallet after finalization. User decides whether to stake.

**Fund Allocation:**
- **80% ETH raised** → Initial LP 
- **20% ETH raised** → TreasuryOps & early marketing

**Initial LP:**
- 150M $DGR + up to 16 ETH LP (80% of hardcap; added via `addLiquidity()` after finalize)
- **First DGR claim (presale vesting) & first airdrop claim require the initial LP to be added** — pVDGR itself can be claimed right after finalization

**Presale Voucher (pVDGR):**
- Each pVDGR represents a claim right to DGR
- pVDGR stakers earn ETH rewards at **0.7x** the rate of DGR stakers
- 100% pVDGR sent to participant wallet on claim — user chooses to stake or hold
- Earn ETH from game pools while vesting

**Vesting Mechanism:**
- **Claims 1-2: 5% of total allocation (max 250,000 DGR/week)** — claimable after TGE, tradeable immediately
- **Claims 3+: 10% of total allocation (max 500,000 DGR/week)** — cap binds only if 10% exceeds 500K (allocation ≥5M DGR)
- Users with allocation <5M DGR: claim full 5% then 10% per week (cap rarely binds)
- **Claim process:**
  1. User ensures pVDGR is in their wallet (unstake from StakingPool first if staked)
  2. User calls `claim()` on Presale contract
  3. pVDGR is burned proportionally
  4. DGR sent to user (up to 500K/week)
  *Note: ETH rewards from pVDGR staking must be claimed separately via StakingPool.*

**Why this design?**
- max 500K/week cap automatically slows whale dumps
- pVDGR staking keeps presale buyers engaged during vesting
- Trustless — all mechanics enforced on-chain

## 4. LP Management

### 4.1 Automated System

The LP Manager holds 550M $DGR reserve and manages liquidity through a queue system:

| Trigger | Action | Probability |
|---------|--------|-------------|
| Buy | Add liquidity (ETH + DGR) | 10% (Tier 1) / 3% (Tier 2+) |
| Sell (≤ 5,000 unique wallets) | Add liquidity (ETH + DGR) | 10% (Tier 1) / 3% (Tier 2+) |
| Sell (> 5,000 unique wallets) | Buyback & burn DGR | 10% (Tier 1) / 3% (Tier 2+) |

**How it works:**
1. Every buy/sell → 10%/3% chance to queue a trigger
2. Kraken processes queue → executes add liquidity (buy always; sell until 5,000 unique wallets) or buyback (sell only after 5,000 unique wallets)
3. Amount per trigger: 10-60% of ETH balance (random)

**Fallback:** If Kraken goes offline for 3 hours, anyone can trigger.

### 4.2 Manual Triggers

The devs and Kraken can trigger LP operations, but **require community voting approval** for each execution:

| Function | Access | Use Case |
|----------|--------|----------|
| `manualAddLiquidity(eth, dgr)` | Devs/Kraken + community vote | Add LP at specific ratio |
| `manualBuybackAndBurn(eth)` | Devs/Kraken + community vote | Burn DGR at any time |

### 4.3 Community Governance (VotingContract)

All manual triggers by the devs are gated by community voting. The VotingContract enforces a **stake-to-vote** mechanism — one vote per function activation.

**Parameters (hardcoded):**

| Parameter | Value |
|-----------|-------|
| Start vote stake | 0.1% of circulating supply |
| Voting duration | 7 days |
| Success threshold | ≥ 10% of circulating supply staked |
| Unstake (success) | 99% returned, 1% auto-burned |
| Unstake (failed) | 100% returned, no penalty |

> **Circulating supply** = total supply − LPManager holdings − Presale (vesting) holdings − burned. Used for both the start-vote stake and the success threshold. (Vesting lives inside the Presale contract — there is no separate vesting contract.)

**How it works:**

1. **Start vote:** Anyone stakes 0.1% of circulating supply to create a proposal for a specific function
2. **Voting phase:** Anyone can stake any amount of DGR to support the proposal (7 days)
3. **Finalize:** If total staked ≥ 10% of circulating supply → proposal passes (even before 7 days). If 7 days pass without reaching threshold → proposal fails
4. **Execute:** The devs call the gated function → approval consumed (one-shot)
5. **Unstake:** Voters withdraw their DGR (with 1% burn if vote succeeded)

**Functions requiring community approval:**

| Function | Contract | Purpose |
|----------|----------|---------|
| `manualAddLiquidity()` | LPManager | The devs manually add liquidity |
| `manualBuybackAndBurn()` | LPManager | The devs manually trigger buyback |
| `manualActivateRound()` | BlitzHillPool | Devs emergency round activation |

**One-shot rule:** Each approval is consumed on execution. The devs must create a new vote for every function call. No reuse, no shortcuts.

---

## 5. Architecture

### 5.1 Smart Contract Layer

```
┌─────────────────────────────────────────────────────┐
│                    DGRToken (ERC20)                  │
│  • Tax collection on transfer                       │
│  • Wallet counting & tier management                │
│  • Max TX enforcement                               │
│  • Support contract routing                         │
└────────────┬────────────┬────────────┬──────────────┘
             │            │            │
    ┌────────▼──┐  ┌──────▼──────┐  ┌─▼───────────┐
    │   KOTH    │  │   Lottery   │  │  Blitz Hill  │
    │   Pool    │  │    Pool     │  │    Pool      │
    │ (30% tax) │  │  (10% tax)  │  │  (20% tax)   │
    └────────┬──┘  └──────┬──────┘  └─┬───────────┘
             │            │            │
    ┌────────▼────────────▼────────────▼───────────┐
    │              Staking Pool                     │
    │         (10% tax + 5% of prizes)              │
    └──────────────────────────────────────────────┘
             │
    ┌────────▼────────────────────────────────────┐
    │              LP Manager                      │
    │     (20% tax + 550M DGR reserve)             │
    └─────────────────────────────────────────────┘
```

### 5.2 Off-Chain Layer

```
┌─────────────────────────────────────────────────────┐
│                   Kraken Bot                        │
│  • Cron scheduler (30s / 5min / hourly)             │
│  • Event monitoring                                 │
│  • Transaction signing & submission                 │
│  • Manual LP management triggers                    │
│  • Local dashboard (WebSocket + REST)               │
└─────────────────────────────────────────────────────┘
                         │
                         ▼
┌─────────────────────────────────────────────────────┐
│               Telegram Bot (@DegenRoyaleDGR_bot)         │
│  • /status — Full ecosystem status                  │
│  • /token, /lottery, /koth, /blitz, /staking, /lp  │
│  • Auto-notifications (winners, tax swaps)          │
│  • /whitepaper, /guide, /challenge                  │
└─────────────────────────────────────────────────────┘
```

### 5.3 Architectural Principle: Contracts Decide, Kraken Triggers

All game logic, winner selection, and reward distribution are decided **on-chain by smart contracts**. Kraken Bot is only a gas payer that triggers functions — it never makes decisions, never selects winners, and never bypasses contract rules.

**Redundancy layers:**
1. **Fully permissionless functions:** `checkAndDeclareWinner()` can be called by anyone
2. **Dev/Treasury Wallet backup:** The devs can trigger any function immediately
3. **Community fallback:** After delay (10 min for games, 3 hours for LP/Tax)

### 5.4 Fee Transparency & Gas Efficiency

**What users pay (and nothing more):**

| Fee | When | Amount | Goes to |
|-----|------|--------|---------|
| Buy Tax | Every buy | 3% of DGR | Swapped → pools + Dev/Treasury Wallet |
| Sell Tax (Tier 1) | Sell (0–1K wallets) | 12% of DGR | Swapped → pools + Dev/Treasury Wallet |
| Sell Tax (Tier 2–3) | Sell (1K+ wallets) | 6% of DGR | Swapped → pools + Dev/Treasury Wallet |
| Network Gas | Every tx | ~$0.00015–$0.0002 | L2 validators |

**No shadow fees:**
- Tax swap happens inline on every sell (piggybacking seller's gas) — Kraken only triggers the fallback if no sells occur
- Lottery, KOTH, Blitz scoring run inline during swap — **amortized across user's swap gas**
- All game hooks add only ~20,000–30,000 gas — roughly **15–20% overhead**

### 5.5 Security Model

- **Kraken = gas payer, not custodian** — never holds pooled ETH
- **Contracts validate everything** — Kraken triggers, contracts enforce rules
- **Hardcoded parameters** — no admin function can change economic rules post-deploy
- **ReentrancyGuard** — all functions that transfer ETH are protected
- **Non-upgradeable** — what you see is what you get
- **BURN_ADDRESS exempt** — transfers to burn address don't trigger game mechanics
- **Max TX snapshot** — LP balance locked per-block to prevent manipulation
- **Community Voting Gate** — The devs cannot trigger manual LP/game functions without community approval (stake-to-vote, 7-day period, 10% supply threshold)

---

## 6. Deployment

### 6.1 Deployment Order

1. Deploy all 9 contracts: DGRToken, LPManager, LotteryPool, KOTHPool, BlitzHillPool, StakingPool, Presale, pVDGRToken, VotingContract
2. Call `setupSupportContracts()` on DGRToken
3. Transfer 550M DGR to LPManager
4. `Presale.addLiquidity()` → `launchWithLiquidity()` to create initial LP (150M DGR + 80% of raised ETH)
5. Whitelist reward tokens via `allowRewardToken()` on StakingPool
6. Configure Kraken Bot with contract addresses
7. Configure Telegram Bot with contract addresses

### 6.2 Testnet Parameters

| Parameter | Testnet | Mainnet |
|-----------|---------|---------|
| LP | 0.011 ETH + 100M DGR (manual dev LP) | up to 16 ETH + 150M DGR (via `Presale.addLiquidity`) |
| Min buy counted as unique wallet | 0.00001 ETH | 0.001 ETH |
| Sell tax tier caps | 300 / 500 / 501+ wallets | 1,000 / 5,000 / 10,000+ wallets |
| Presale hardcap | 0.02 ETH | 20 ETH |
| Presale softcap | 0.002 ETH | 2 ETH |
| Presale min buy | 0.00001 ETH | 0.001 ETH |
| Presale max buy | 0.001 ETH | 1 ETH |
| Presale duration | 1 day | 7 days |
| Presale vesting | 5% (max 250K) first 2 claims, then 10% (max 500K); interval 5 min | 5% (max 250K) first 2 claims, then 10% (max 500K) per week |
| KOTH hold | 5 min | 10 min |
| KOTH Round 1 activation | pool ≥ 0.01 ETH + 100 unique wallets | pool ≥ 1 ETH + 100 unique wallets |
| KOTH Round 2+ activation | pool back to ATH + 10 new buy wallets | pool back to ATH + 10 new buy wallets |
| KOTH failure (Round 1) | 7 days (from first LP) | 14 days (from first LP) |
| KOTH failure (Round 2+) | 50% of last round duration (min 1 day, max 3 days) | 50% of last round duration (min 1 day, max 30 days) |
| Blitz round | 30 min | 1 hour |
| Blitz Round 1 activation | pool ≥ 0.005 ETH + 100 unique wallets | pool ≥ 0.5 ETH + 100 unique wallets |
| Blitz Round 2+ activation | pool back to ATH + 10 new buyers | pool back to ATH + 10 new buyers |
| Lottery activation | 0.005 ETH | 0.1 ETH |
| Lottery Match 1 auto-disable | 100 unique wallets since activation | 1,000 unique wallets since activation |
| Staking lock | 1 hour | 3 days |
| Staking drip | 2% / 5 min | 2% / 5 min |
| Staking ERC20 reward window | 2 hours | 24 hours |
| Voting start stake | 0.1% of circulating supply | 0.1% of circulating supply |
| Voting success threshold | ≥ 10% of circulating supply staked | ≥ 10% of circulating supply staked |
| Voting duration | 2 hours | 7 days |

---

## 7. Risk Factors

1. **Smart contract risk** — Internally audited, third-party audit pending
2. **Liquidity risk** — Initial LP is up to 16 ETH + 150M DGR (80% of presale hardcap); large trades will have high slippage
3. **Network risk** — Base L2 congestion could delay Kraken Bot triggers
4. **Regulatory risk** — Memecoins operate in uncertain regulatory environment
5. **Parameter immutability** — All economic parameters are hardcoded

---

## 8. Roadmap

| Phase | Milestone | Status |
|-------|-----------|--------|
| Phase 1 | Smart contract development | ✅ Complete |
| Phase 2 | Kraken Bot + Dashboard | ✅ Complete |
| Phase 3 | Telegram Bot (@DegenRoyaleDGR_bot) | ✅ Complete |
| Phase 4 | Community documentation | ✅ Complete |
| Phase 5 | Internal audit + patching | ✅ Complete |
| Phase 6 | Testnet deployment (Base Sepolia) | 🔄 In Progress |
| Phase 7 | Testnet simulation & testing | ⏳ Pending |
| Phase 8 | Third-party audit | ⏳ Pending |
| Phase 9 | Mainnet deployment | ⏳ Pending |
| Phase 10 | Community launch | ⏳ Pending |

---