🐙 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.

"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

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

Fund Allocation

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

• 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.

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:

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:

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:

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):

• 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:

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:

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):

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:

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):

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

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