📜 Dungeon — Technical Whitepaper

Version: 2.1 Last Updated: 2026-05-08 Publisher: Crypto Dungeon LLC · Dubuque, Iowa, USA

TL;DR

• 🏰 Sovereign Cosmos SDK chain (dungeon-1) with CosmWasm, 21 active validators, run on 15 company-owned servers.
• 💱 In-house CosmWasm DEX on dungeon-1 + cosmoshub-4: AMM, one-tx Deposit + Bond, OTC escrow, fair-launch (Hourglass), permissionless pairs.
• 🎮 Dungeon-published games including Kosmic Dungeon (Phaser idle RPG, shipping) and Kosmic (UE5 flagship with AI Dungeon Master).
• 💰 Game-to-staker revenue loop — Kosmic Dungeon net revenue routes to $DGN stakers, inflation scales down proportionally.
• 🛡️ Everything owned — chain, contracts, metal, validator keys. No rented blockspace, no external audit dependency, no consumer-chain handcuffs.

Abstract

Dungeon is a self-hosted blockchain gaming platform that combines (a) a sovereign Cosmos SDK chain, (b) a production CosmWasm DEX with integrated OTC escrow and fair-launch primitives, (c) a live NFT marketplace, (d) multiple shipping games across web, mobile, and upcoming 3D, and (e) a commercial validator operation spanning 14+ Cosmos chains. Every component is operated on infrastructure owned by the company, and every contract is written and tested in-house.

This paper describes the current state of the system as of April 2026 — what is live, how it works, and how the pieces fit together. It is intended to be accurate rather than promotional; items that are in development are marked as such.

Table of Contents

1. Motivation
2. System Architecture
3. Token Economics — $DGN
4. Dungeon DEX
5. Pact Hall — OTC + Limit Orders
6. Hourglass — Fair-Launch Auctions
7. Games
8. Marketplace
9. Validator Operations
10. Security Posture
11. Governance
12. Team + Company
13. Competitive Positioning
14. On-Chain Numbers (Live)
15. 12-Month KPI Targets
16. Glossary
17. Verification Sources
18. Disclaimers
19. Changelog

1. Motivation

Most blockchain-gaming projects today fall into one of two failure modes: (1) ship a game but outsource every on-chain primitive, leaving the economy brittle when DeFi markets move, or (2) ship a DEX with no games attached, competing on commodity liquidity. Dungeon's thesis is that a self-operated DeFi stack + a self-operated game studio, running on self-operated validator infrastructure, is the only configuration that survives a full crypto cycle.

That thesis dictates three constraints the platform has observed since inception:

1. Own the chain. dungeon-1 is a sovereign Cosmos SDK chain. No rented blockspace, no third-party consumer-chain dependencies.
2. Own the contracts. DEX, OTC, streamswap, NFT marketplace, limit orders, airdrop module, staking — all CosmWasm, all written or forked and maintained internally.
3. Own the metal. 15 physical servers in a company-owned underground data center with triple-redundant internet. 99.9 % measured uptime.

Everything else — token listings, game distribution, partnerships — is scaffolding around those three constraints.

2. System Architecture

graph LR
    subgraph USER[" 👤 Users "]
        Web[Web Browser]
        Mob[Mobile App]
        Wlt[Wallets: Keplr, Leap, Dungeon]
    end

    subgraph FE[" 🖥️ Frontend Layer "]
        DEXUI[DEX UI<br/>Next.js]
        EXPUI[Explorer UI<br/>Next.js]
        MKTUI[Marketplace<br/>Next.js]
        GAMEUI[Kosmic Dungeon<br/>Phaser+Capacitor]
    end

    subgraph BE[" ⚙️ Backend Services "]
        BOTS[Trading Bots<br/>arb + volume]
        PROXY[REST/RPC Proxy]
        GECKO[GeckoTerminal Adapter]
        KEEPER[Limit Keeper]
    end

    subgraph CHAIN[" ⛓️ dungeon-1 Chain "]
        SDK[Cosmos SDK v0.50]
        CW[CosmWasm 1.5]
        TF[TokenFactory]
        IBCX[IBC Transfer]
    end

    subgraph CONTRACTS[" 📜 Smart Contracts "]
        DEX[Dungeon DEX<br/>AMM Fork]
        HELP[Frontend Helper]
        OTC[OTC Escrow]
        LIM[Limit Orders]
        STR[Hourglass Streamswap]
        INC[Incentive Factory]
        WL[Bond Vault + Fees]
        NFT[CW721 Collections]
    end

    subgraph INFRA[" 🏛️ Owned Infrastructure "]
        SRV2[Server 2 — Archive]
        SRV11[Server 11 — Public]
        VAL[13× Validator Servers]
    end

    USER --> FE
    FE --> BE
    BE --> CHAIN
    FE -.->|direct RPC| CHAIN
    CHAIN --> CONTRACTS
    CHAIN --> IBCX
    INFRA -.->|runs| CHAIN
    INFRA -.->|runs| BE
    INFRA -.->|runs| FE
    Wlt -->|signs| CHAIN

    classDef user fill:#3c2a1a,stroke:#f2c94c,color:#fff
    classDef fe fill:#1a3a3c,stroke:#00d4aa,color:#fff
    classDef be fill:#3c1a3a,stroke:#d946ef,color:#fff
    classDef chain fill:#2d1b0e,stroke:#ff9500,color:#fff
    classDef ctr fill:#0e2d1b,stroke:#00d4aa,color:#fff
    classDef infra fill:#1a1a2e,stroke:#f2c94c,color:#fff
    class Web,Mob,Wlt user
    class DEXUI,EXPUI,MKTUI,GAMEUI fe
    class BOTS,PROXY,GECKO,KEEPER be
    class SDK,CW,TF,IBCX chain
    class DEX,HELP,OTC,LIM,STR,INC,WL,NFT ctr
    class SRV2,SRV11,VAL infra

2.1 Chain layer — dungeon-1

• Framework: Cosmos SDK v0.50, Tendermint / CometBFT consensus.
• VM: CosmWasm (wasmd, tokenfactory, interchain-accounts).
• Token: $DGN (base denom udgn, 6 decimals).
• Consensus: Proof-of-Stake with LSM deferred pending governance.
• IBC: Connected to cosmoshub-4 (channel-1, two-hop and direct paths), Osmosis, AtomOne, Noble, plus the full Cosmos-chain registry.
• Upgrade path: v5 → v6 scripted and tested on dungeontest-1; mainnet upgrade pending a signalling vote. Future upgrades follow the same test-to-main pattern.

2.2 Smart-contract layer

All contracts are CosmWasm 1.5, written in Rust, unit-tested with cw-multi-test, and scenario-tested on dungeontest-1 before mainnet store.

2.3 Off-chain services

• Backend services — backend.dungeongames.io runs the trading-bot fleet (arb-bot + volume-bots), price feed aggregator, GeckoTerminal adapter, REST proxies, PM2-supervised.
• Indexers / Explorer — explorer.dungeongames.io consumes chain RPC + REST + contract queries to surface pools, tokens, validators, APRs, airdrops, and per-token pages.
• Rest proxy — api.dungeongames.io + rpc.dungeongames.io fan out to the correct internal nodes; explorer always goes via the archival node on server 2.

2.4 Frontend

• Framework: Next.js App Router where possible (Explorer, Marketplace) and Pages Router where Chakra UI + cosmos-kit compatibility dictated (DEX).
• Wallet: cosmos-kit, supporting Keplr, Leap, Cosmostation, and custom Dungeon Wallet (Capacitor build).
• Mobile: Phaser + Capacitor for Kosmic Dungeon; Firebase App Distribution for iOS + Android builds.
• 3D client (Kosmic flagship): Unreal Engine 5, AI-narration driven by a local Ollama 70B model on an RTX 5090 workstation.

2.5 Infrastructure

• 15 physical servers, underground data center, owned hardware.
• Triple-redundant internet, on-site UPS + generator.
• 99.9 % uptime measured over the past 12 months.
• Server 2 — archival dungeon-1 node + Pocket Network validator + Cosmos Hub testnet.
• Server 11 — primary public-facing: PM2 (DEX frontend, bots, trading, rest-proxy, limit keeper), nginx, Docker (backend, EMR, explorer), deploy target for every web property.
• Remaining 13 servers — validator set across 14+ Cosmos chains: dungeon-1, cosmoshub-4, osmosis-1, juno-1, stargaze-1, migaloo-1, omniflix-1, jackal-1, pocket-1, plus several more.

3. Token Economics — $DGN

Utility Flow

flowchart LR
    HOLD[Hold $DGN] --> STAKE[Stake to Validator]
    HOLD --> BOND[Bond in Bond Vault]
    HOLD --> GAS[Pay Gas on dungeon-1]
    HOLD --> GAME[Game Services<br/>Marketplace, Tournaments]
    HOLD --> GOV[Dungeon DAO Vote]

    STAKE --> REW1[Block Rewards]
    BOND --> REW2[Protocol Fee Share<br/>0.5% of DEX + OTC]

    SWAPS[DEX Swaps] -->|0.5% fee| DIST[Fee Distributor]
    OTCTR[OTC Fills] -->|0.5% fee| DIST
    DIST --> REW2

    classDef hold fill:#2d1b0e,stroke:#ff9500,color:#fff
    classDef reward fill:#0e2d1b,stroke:#00d4aa,color:#fff
    classDef sink fill:#3c1a3a,stroke:#d946ef,color:#fff
    class HOLD hold
    class REW1,REW2 reward
    class STAKE,BOND,GAS,GAME,GOV,SWAPS,OTCTR,DIST sink

3.1 Supply + Emissions

• Genesis supply: as per genesis file (dungeon-1 canonical genesis is the source of truth, linked from explorer.dungeongames.io).
• Inflation: standard Cosmos-style block-reward emissions directed to validator stakers.
• No new mints outside consensus. No treasury re-mint, no "team buyback" mint. All emission schedules are visible on-chain.

3.2 Sinks

3.4 Game-Revenue Loop

Dungeon is unusual in the Cosmos ecosystem because it both publishes games and runs the chain those games settle on. As Kosmic Dungeon (and future titles) begin producing recurring net revenue — from premium subscriptions, tournament entries, cosmetic sales, and marketplace royalties — a meaningful portion is routed back to $DGN stakers on a periodic schedule. The exact percentage and cadence are governance-set via Dungeon DAO.

Inflation scales down as game revenue scales up. The chain's emissions schedule is designed to be reduced in proportion as game-revenue distributions grow. The intent is that $DGN staking yield over time shifts from emission-subsidized to organically-funded by the products built on the chain. The result is a tighter float, a stronger link between platform success and token holder outcomes, and a smaller dilution burden on long-term stakers.

This is codified as a standing governance commitment rather than a hard contract rule — it requires both (a) a measured revenue floor over a rolling window before a reduction is proposed, and (b) a community vote to ratify each step. The Dungeon DAO will publish revenue-to-staker accounting on-chain so every distribution is auditable.

3.3 Utility

• Pay gas on dungeon-1.
• Stake to validators to secure the chain + earn block rewards.
• Bond into bond_vault to receive DEX protocol-fee distributions.
• Stake to receive a share of Kosmic Dungeon (and future game) net revenue as inflation is stepped down in its place.
• Collateral in dungeon-dao governance once live.
• Primary quote asset alongside ATOM + USDC on the DEX.
• Required for certain game-layer actions (minting premium items, entering featured tournaments, boosting stream participation).

4. Dungeon DEX

Deposit + Bond Flow

sequenceDiagram
    autonumber
    participant User
    participant UI as DEX Frontend
    participant Helper as frontend_helper
    participant Pair as Pool Pair
    participant Staking as Incentive Staking

    User->>UI: Select pool, enter amounts, pick lock duration
    UI->>UI: Build single tx (+ optional CW20 allowances)
    User->>Helper: deposit { pair_address, assets, duration }
    Helper->>Pair: provide_liquidity
    Pair-->>Helper: LP tokens minted (reply)
    Helper->>Staking: open_position OR expand_position
    Staking-->>Helper: Position created/expanded
    Helper-->>User: Bonded, zero residual LP

4.1 Design

Constant-product AMM with stable-swap pair type available per pool. Every pool is a separate pair contract instantiated by a central pool_factory. Fees are split between LPs, the protocol-fee address, and (optionally) a burn address, configurable at pool creation. The codebase is CosmWasm Rust, maintained in-house, and every contract on both chains was deployed by Dungeon.

4.2 Liquidity flow

• Deposit + Bond — the frontend_helper contract wraps provide_liquidity and open_position into a single atomic call. Users choose an unbonding duration (minimum 1 day, maximum 10 days on current factory config) and receive a bonded LP position. Zero residual LP tokens stay in the user wallet.
• Zap — single-asset deposits split input 50/50 through the pool's own swap rail and deposit the resulting pair, again routed through frontend_helper for atomicity.
• Withdraw — LP tokens can be redeemed after the configured unbonding duration elapses. Positions at the same duration auto-expand on subsequent deposits.
• Claim-All — single bundled tx iterates every staking contract the user is bonded in.

4.3 Permissionless pair creation

Any holder of any chain-registered denom can create a pool. The UI auto-registers unknown native or IBC denoms with the factory's add_native_token_decimals whitelist as part of the same transaction. Create-Pool surfaces balance checks before broadcast and produces explicit errors for the registration step if a user does not hold at least one base unit of both tokens.

4.4 Auto-discovery

The frontend queries pool_factory.pairs on load and merges any pool not in the static pools_list.json into the displayed pool list, tagged isAutoDiscovered. Symbols + decimals are resolved from bank.denoms_metadata where available, otherwise inferred from the denom path. New pools are visible in swap + LP UI within the next page load.

4.5 Cross-chain deployment

The same dungeon-dex bytecode runs on both dungeon-1 and cosmoshub-4. Pool addresses differ per chain, but every feature (Deposit, Bond, Zap, Claim-All, frontend_helper, auto-register, 30-token chain-registry sync) is identical across both deployments.

5. Pact Hall — OTC + Limit Orders

OTC Offer Lifecycle

stateDiagram-v2
    [*] --> Open: create_offer<br/>(escrow maker funds)
    Open --> Open: accept_offer<br/>(partial fill)
    Open --> Filled: accept_offer<br/>(clears remaining)
    Open --> Cancelled: cancel_offer<br/>(maker only)
    Open --> Expired: claim_expired<br/>(past TTL, anyone)
    Filled --> [*]
    Cancelled --> [*]: refund maker
    Expired --> [*]: refund maker

Pact Hall is the large-trade + non-AMM venue for any token pair. It has two distinct contracts under one UI:

5.1 Limit Order Book (v1)

• Keeper-driven fills. Users post a place_order tied to a specific DEX pool + target price. A keeper bot watches AMM price and broadcasts execute_order when the target is crossed.
• Strength: zero slippage at the user's chosen price, plays nicely with existing AMM liquidity.
• Limitation: tied to existing pools, no partial fills at contract layer.

5.2 OTC Escrow (v2 — shipped April 2026)

• Peer-to-peer atomic swaps. A maker posts create_offer with any native / IBC / factory denom + asks for any other denom. Maker funds are held in the escrow contract.
• Partial fills. Takers call accept_offer { offer_id, amount }; contract computes required ask amount with ceiling-division, sends excess back, pays maker (minus 0.5% protocol fee), releases offer funds to taker.
• Maker-cancellable before expiry; anyone can call claim_expired to refund an un-taken maker after the TTL elapses.
• Works for any token pair, independent of whether a pool exists.
• Expiries bounded to [min_duration_secs, max_duration_secs] (default 5 min to 30 days).

Both contracts appear as tabs in the same Pact Hall UI. A user picks Limit Orders for AMM-coupled trades, OTC Escrow for arbitrary-pair large trades.

5.3 Current addresses

6. Hourglass — Fair-Launch Auctions (Streamswap)

Hourglass is Dungeon's time-weighted fair-launch primitive. A project or creator deposits a sale asset into a stream with a defined start + end window. Anyone can deposit a designated input asset during the window; at the end, deposits are settled pro-rata against the full sale asset pool based on time-weighted contribution. No front-running, no MEV, no sniping — every deposit-second counts equally.

End-to-end verified on mainnet (April 22, 2026). Live on dungeon-1 (code 94) and cosmoshub-4 (code 542).

7. Games

7.1 Kosmic Dungeon — Live, Beta → Ship

• Stack: Phaser 3 + Vite + TypeScript + Capacitor.
• URL: play.dungeongames.io.
• Features: idle RPG loop, 6+ hero classes with unique passives, strategy cards, row-targeting combat, NPC quests with voiced lines (ElevenLabs) + portraits, dungeon explorer, city map, guild system, premium subscription, trading bots-free battle market.
• Distribution: web (Cloudflare Pages → server 11 nginx), Android + iOS via Capacitor + Firebase App Distribution, iOS Simulator streamed via Appetize.io from Codemagic builds (no Mac hardware required).
• Save layer: IndexedDB primary, localStorage fallback, timestamp-based merge to recover from state divergence.
• Status: in beta, hardening for v1.0 launch.

7.2 Kosmic (UE5) — In Development

• Stack: Unreal Engine 5.
• Premise: hyperrealistic 3D fantasy D&D with an AI Dungeon Master, VR-ready.
• AI DM: local 70B model on RTX 5090 (Ollama), narrates scenes and triggers game events in real time.
• Current scope: vertical slice — single room, one AI DM session, one playable character. Expansion gated on AI DM interaction quality.

7.3 Kosmic Dragoon — Live

Existing combat title, ongoing live-ops.

7.4 Upcoming — Fantasy Sports, Casino, PvP Arena, Guild Wars

Additional game titles leveraging the same chain + NFT + DEX foundation. Roll-out order determined by Kosmic Dungeon + Kosmic stabilization.

8. Marketplace

• Repo: dungeon-marketplace (Next.js + Express + IPFS).
• Collections: Heroes + Gear NFTs as CW721 on dungeon-1.
• Primary-mint + secondary-trade flows, royalties enforced at the contract layer.
• Cross-game asset portability planned: the same NFT identity carries into Kosmic Dungeon, Kosmic, and future titles.

9. Validator Operations

Dungeon operates validators on 14+ Cosmos chains including dungeon-1, cosmoshub-4, osmosis-1, juno-1, stargaze-1, migaloo-1, omniflix-1, jackal-1, pocket network, plus regional chains. Commission revenue partially offsets platform operating cost and subsidizes DEX + game incentive flows during bootstrap periods.

• Delegator UX: Keplr, Leap, and Restake-compatible.
• Slashing record: zero slashing events across all chains to date.
• Hardware: bare-metal in a company-owned data center. No cloud, no rented VPS for consensus.

10. Security Posture

10.1 Current State (Honest)

• All contracts written in Rust. No Solidity in the stack.
• Unit tests with cw-multi-test: DEX, staking, streamswap, OTC, limit-order, airdrop — every execute path and every error branch covered.
• Scenario tests on dungeontest-1 before mainnet store. Every mainnet deploy follows a tested upgrade script.
• No third-party unaudited contracts in production. Any open-source primitive we build on is reviewed line-by-line, modified in-house, and re-tested before deploy. Every contract currently in production was written, reviewed, and deployed by Dungeon.
• Admin keys are multi-sig where the contract supports it, and migrate-authority is rotated off a single-owner key before contracts go to production where feasible.
• Key management: validator signing keys are on air-gapped HSM-adjacent storage in the underground data center; hot keys for automated ops (bots, limit keeper, fee claimer) are scoped to their specific role with bounded balances.

10.2 External Audits

No third-party audit has been completed as of publication. Every contract in production has been:

• Unit-tested with cw-multi-test, covering every execute branch and every documented error path.
• Scenario-tested on dungeontest-1 before mainnet store — full end-to-end flows, not isolated unit cases.
• Deployed via scripted migrations that can be re-run and diffed.
• Kept behind admin / migrate keys until a user-facing launch window, so hot issues can be patched via migration rather than re-instantiation.

Third-party audits are planned for the DEX + OTC + Hourglass stack as traction crosses a revenue + TVL threshold that justifies the cost. Audit partners, scope, and outcomes will be published on-chain via Dungeon DAO. In the meantime the source of every mainnet contract is available for independent review.

10.3 Bug Bounty

A scoped bounty program will be published alongside the first formal audit engagement. Today, critical issues can be reported privately via the Dungeon Discord admin channels or a signed on-chain message to the admin address; validated findings will be paid in $DGN on a severity-tiered scale consistent with Cosmos-ecosystem norms.

10.4 User Risk

Users assume standard DeFi risk: smart-contract bugs, chain halts, IBC relayer issues, and third-party wallet compromise. We recommend (1) never depositing more than you can afford to lose, (2) reading the contract source (linked from explorer pages), and (3) using a hardware wallet for large balances.

11. Governance

• Dungeon DAO — DAODAO fork, rebranded, contracts built and ready to deploy. Voting power scales with bonded $DGN.
• Initial governance scope: DEX parameters (fee bps, whitelist tokens, new chain deployments), treasury allocations, incentive-flow funding, content moderation for marketplace collections.
• Validator-only governance remains at the chain-param level (software upgrades, consensus params); app-layer governance runs through Dungeon DAO contracts on top.

12. Team + Company

• Crypto Dungeon LLC, Dubuque, Iowa, USA.
• Founder: solo-operator CEO running product, engineering, and operations with a small remote-contractor network for art + audio.
• Operating principle: everything one person + a tight set of tools can maintain at 99.9 % uptime. No process that requires a team of five to run. This constrains complexity by design and is why the platform shies away from patterns like multi-contract proxies or bespoke off-chain sequencers.

13. Competitive Positioning

Dungeon occupies a different slot from every Cosmos DEX or Cosmos game chain in production:

Dungeon's unique combination: a chain + an in-house DEX + a shipping game studio + validator operations — all under one operator, with explicit token-holder value accrual from the games published on the chain.

The Game-Revenue Loop (§3.4) is the central thesis: as the studio's games monetize, $DGN holders capture a share via on-chain distribution, and the chain's emission schedule steps down in proportion. This converts $DGN from a pure "DEX + validator" token into a claim on operating game revenue — without ever being a security, because the mechanism is governance-set and distribution is automatic, not discretionary.

The closest competitive analog in spirit is Immutable X on Ethereum — but Dungeon self-hosts rather than relying on a general L2, and the game studio is first-party rather than a partner program.

14. On-Chain Numbers (Live)

All of the following can be verified against dungeon-1 or the public REST at api.dungeongames.io.

Stats above snapshot at 2026-04-23; current live values render on explorer.dungeongames.io.

15. 12-Month KPI Targets

Targets are what we intend to measure ourselves against. These are directional goals, not revenue projections or investment forward-looking statements.

Quarterly progress is published in the Dungeon DAO forum and echoed on the roadmap page.

16. Glossary

17. Where To Verify Everything In This Document

• Chain state: rpc.dungeongames.io and api.dungeongames.io (public) or via any other Cosmos endpoint.
• Contract source: linked per-contract from explorer.dungeongames.io.
• Validator performance: public registries + Restake.
• DEX activity: dex.dungeongames.io, explorer.dungeongames.io/pools, GeckoTerminal adapter.
• Token listings: chain-registry PRs (upstreamed), Keplr asset lists, Osmosis pools (Pool 2888 DGN/ATOM, Pool 2889 DGN/OSMO).
• Companies + contact: dungeongames.io, Twitter @cryptodungeonma, Discord, Telegram @cryptodungeonen.

18. Disclaimers

This document describes a live, evolving system. Features listed as "In Development" or "Upcoming" in the companion roadmap are not guaranteed to ship, and their final form may differ from what is described here. Nothing in this paper is investment, legal, or tax advice. Do your own research.

$DGN is a utility token used to pay gas, stake for validator security, bond for fee distribution, and access on-platform services. It is not a security offering and confers no claim on Crypto Dungeon LLC's revenue or assets outside the on-chain mechanisms described above.

19. Changelog

• v2.1 — 2026-04-23 — Rebrand pass (removed prior fork references), added §3.4 Game-Revenue Loop, §13 Competitive Positioning, §14 On-Chain Numbers, §15 12-Month KPI Targets, §16 Glossary, TL;DR + Table of Contents, expanded §10 Security Posture with explicit audit + bug bounty disclosure.
• v2.0 — 2026-04-23 — Full rewrite reflecting current mainnet state: frontend_helper deployed, OTC escrow shipped on both chains, 30-token Hub list, Hourglass fair-launch primitives, v6 chain upgrade in testing, Create-Pool balance guards, Pact Hall tabs, updated infrastructure details.
• v1.x — prior internal drafts, superseded.