Dungeon — Technical Whitepaper

Version: 3.0 · Last updated: 2026-07-27 · Publisher: Crypto Dungeon LLC, Dubuque, Iowa, USA

TL;DR

• A sovereign L1 — dungeon-1, with CosmWasm smart contracts, run on company-owned metal in a company-owned data center.
• Four live products people use — three games, a learning platform, a DEX, an NFT marketplace and a wallet on three app stores.
• Bitcoin, Ethereum and Solana bridges, live on mainnet — the Bitcoin one trustless by design, with an on-chain SPV light client rather than a custodial wrapper.
• A game-to-staker revenue loop — net revenue from Dungeon-published games routes to $DGN stakers, with chain inflation stepping down in proportion.
• Everything owned — the chain, the contracts, the servers, the validator keys. No rented blockspace, no consumer-chain handcuffs.

Live numbers are deliberately not printed in this document — they go stale faster than a PDF does. They render live on the front page and are verifiable on the explorer and against the public REST endpoint.

Contents

1. Motivation
2. System architecture
3. Token economics — $DGN
4. Dungeon DEX
5. Pact Hall — OTC and limit orders
6. Hourglass — fair-launch auctions
7. Bridges — Bitcoin, Ethereum, Solana
8. Games
9. Dungeon Academy
10. Marketplace
11. Validator operations
12. Security posture
13. Governance
14. Team and company
15. Competitive positioning
16. Glossary
17. Where to verify everything here
18. Disclaimers
19. Changelog

1. Motivation

Most blockchain-gaming projects fail in one of two ways. Either they ship a game and outsource every on-chain primitive, which leaves the economy brittle the moment DeFi markets move; or they ship a DEX with no games attached and end up competing on commodity liquidity. Dungeon's thesis is that a self-operated DeFi stack, plus a self-operated game studio, running on self-operated validator infrastructure, is the only configuration that survives a full cycle.

That thesis dictates three constraints the platform has held to since inception:

1. Own the chain. dungeon-1 is sovereign. No rented blockspace, no third-party consumer-chain dependency. It runs its own validator set from its own genesis.
2. Own the contracts. DEX, OTC escrow, fair-launch, NFT collections, limit orders, airdrops, staking, the Bitcoin light client and the wBTC mint — all CosmWasm, all written or forked and maintained in-house.
3. Own the metal. 15 physical servers in a company-owned underground data center with triple-redundant internet and on-site power backup. 99.9% measured uptime.

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

2. System architecture

2.1 Chain layer — dungeon-1

• Consensus: proof-of-stake, CometBFT.
• VM: CosmWasm, with tokenfactory and interchain accounts.
• Token: $DGN, base denom udgn, 6 decimals.
• Interoperability: IBC connections to the Hub, AtomOne, Noble and the wider registry, plus native bridges to Bitcoin, Ethereum and Solana (§7).
• Upgrade path: the chain is on v8. The v6 upgrade added a minimum gas price with an admin and relayer exemption, ending zero-fee spam; v7 modernised the SDK, the Wasm runtime and IBC. Every upgrade is scripted, rehearsed on a testnet fork, then executed on mainnet by governance.

2.2 Smart-contract layer

All contracts are CosmWasm, written in Rust, unit-tested with cw-multi-test, and scenario-tested on a testnet before any mainnet store.

2.3 Off-chain services

• Backend — the trading-bot fleet, price-feed aggregation, market-data adapters, REST proxies and the limit keeper, all process-supervised.
• Explorer — consumes chain RPC, REST and contract queries to surface blocks, pools, tokens, validators, APRs and per-token pages.
• Endpoints — public RPC and REST fan out to the correct internal nodes; the explorer always reads from the archival node.

2.4 Frontend

• Web — Next.js for the landing site, the explorer, the marketplace and the Academy; the DEX is a separate app on the same design system.
• Games — Phaser and TypeScript for the 2D titles, packaged for iOS and Android; Unreal Engine 5 for the flagship.
• Wallet — Dungeon Wallet ships as an iOS app, an Android app and a Chrome extension, with the bridges built in. Third-party wallets are supported for every on-chain surface.

2.5 Infrastructure

• 15 physical servers, underground data center, owned hardware. No cloud and no rented VPS carries consensus.
• Triple-redundant internet, on-site UPS and generator.
• 99.9% uptime measured over the trailing 12 months.
• One server carries the archival dungeon-1 node; one carries the public web and service tier; the rest carry the validator set (§11).
• Every validator is under continuous alerting, with a public status board.

3. Token economics — $DGN

3.1 Supply and emissions

• Genesis supply is defined by the canonical dungeon-1 genesis file, which is the source of truth and is linked from the explorer.
• Inflation is a fixed 10%, directed to validator stakers as block rewards.
• No mints outside consensus. No treasury re-mint, no team buyback mint. Every emission is visible on-chain.

3.2 Sinks

3.3 Utility

• Pay gas on dungeon-1.
• Stake to validators to secure the chain and earn block rewards.
• Bond into bond_vault to receive DEX and OTC protocol-fee distributions.
• Receive a share of game revenue as inflation steps down in its place (§3.4).
• Vote in Dungeon DAO once governance contracts are deployed.
• Act as a quote asset on the DEX.
• Pay for game-layer actions — minting premium items, entering featured tournaments, and similar.

3.4 The game-revenue loop

Dungeon is unusual in that it both publishes the games and runs the chain those games settle on. As the games produce recurring net revenue — from premium subscriptions, tournament entries, cosmetics and marketplace royalties — a meaningful portion is routed back to $DGN stakers on a periodic on-chain schedule. The percentage and the cadence are governance-set.

Inflation is designed to scale down as game revenue scales up. The intent is that staking yield shifts over time from emission-subsidised to funded by the products built on the chain: a tighter float, a stronger link between platform performance and holder outcomes, and less dilution carried by long-term stakers.

This is a standing governance commitment, not a hard contract rule. Each step requires a measured revenue floor over a rolling window before a reduction is proposed, and a community vote to ratify it. Revenue-to-staker accounting is published on-chain so every distribution is auditable.

4. Dungeon DEX

4.1 Design

A constant-product AMM with a stable-swap pair type available per pool. Every pool is a separate pair contract instantiated by a central pool_factory. Fees 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 in production was deployed by Dungeon.

4.2 Liquidity flow

• Deposit + Bond — frontend_helper wraps provide_liquidity and open_position into one atomic call. The user picks an unbonding duration and receives a bonded LP position with zero residual LP tokens left in the wallet.
• Zap — single-asset deposits split the input through the pool's own swap rail and deposit the resulting pair, again atomically.
• Withdraw — LP tokens redeem once the configured unbonding duration elapses. Positions at the same duration auto-expand on later deposits.
• Claim-all — one bundled transaction claims across every staking contract the wallet is bonded in.

4.3 Permissionless pairs

Any holder of any chain-registered denom can create a pool. The interface auto-registers unknown native or IBC denoms with the factory as part of the same transaction, checks balances before broadcast, and surfaces an explicit error if the registration step would fail.

4.4 Auto-discovery

The frontend queries pool_factory.pairs on load and merges any pool missing from the static list into the displayed set. Symbols and decimals resolve from on-chain denom metadata where present and are inferred from the denom path otherwise, so a new pool is tradable on the next page load.

5. Pact Hall — OTC and limit orders

Pact Hall is the venue for trades the AMM is a poor fit for. Two contracts sit under one interface.

5.1 Limit order book

Users post an order tied to a specific pool and a target price. A keeper watches AMM price and executes when the target is crossed. The strength is zero slippage at a chosen price while still using existing liquidity; the limitation is that an order must be tied to a pool that exists.

5.2 OTC escrow

Peer-to-peer atomic swaps for any pair, whether or not a pool exists. A maker posts an offer and their funds are held in escrow. Takers fill partially or fully; the contract computes the required amount with ceiling division, returns any excess, pays the maker net of the 0.5% protocol fee and releases the offer funds. Makers can cancel before expiry, and anyone can trigger a refund once an offer's time-to-live elapses.

6. Hourglass — fair-launch auctions

Hourglass is Dungeon's time-weighted fair-launch primitive. A creator deposits a sale asset into a stream with a start and an end. Anyone can deposit the designated input asset during the window; at the end, deposits settle pro-rata against the full sale pool weighted by time contributed.

No front-running, no MEV, no sniping — every deposit-second counts equally. Verified end-to-end on mainnet.

7. Bridges — Bitcoin, Ethereum, Solana

All three are live on mainnet. They are the reason $DGN is not an island.

7.1 Bitcoin — trustless by design

Rather than wrap BTC through a custodian, Dungeon proves deposits to the chain:

• On-chain SPV light client. A CosmWasm contract verifies Bitcoin block headers — compact-target proof-of-work, double-SHA256, cumulative chain work — and Merkle inclusion proofs for individual transactions. It is unit-tested against real Bitcoin blocks and deployed to dungeon-1 mainnet.
• wBTC mint contract. Mints 1:1 against a proven deposit, idempotent by transaction id and output index, with pausable, capped and admin-rotatable safety rails.
• Header relayer. A daemon reads bitcoind and submits headers to the SPV contract, with health and metrics endpoints and a reorg watch over recent blocks.
• Federated withdrawals. Withdrawal transactions are signed by a 3-of-5 FROST-secp256k1 federation against slashable collateral, under a hard bridge cap.

The custody model is comparable to Nomic or Babylon, but with on-chain SPV verification. A conservative cap is maintained while the design accrues operating history.

7.2 Ethereum

ETH deposits credit an EVM address derived from the user's existing wallet seed. No second seed phrase, no second app, no manual key export. Deposits and withdrawals run against Ethereum mainnet and are backed 1:1.

7.3 Solana

SOL deposit and withdrawal rails, live on Solana mainnet, backed 1:1.

7.4 Lightning

A custodial Lightning cashier remains live for the poker tables. It is explicitly custodial, and is scoped to game balances rather than to bridged assets.

8. Games

8.1 Kosmic Dungeon — live

An idle RPG at play.dungeongames.io, launched out of beta on 2026-07-15. Heroes with distinct classes and passives, strategy-card combat with row targeting, gear crafting and enchanting, a city layer, guilds and raids, and a dungeon crawl with an AI-narrated layer. It pays out real $DGN.

Built in Phaser and TypeScript, shipped on web, iOS and Android. The save layer is local-first with a timestamp-based merge against a cloud copy, so a lost connection does not cost progress.

8.2 Kosmic Monsters — live

Collect, train and battle monsters three-a-side. Progress is tied to a wallet via sign-in-with-wallet rather than to a browser, and the on-chain mint pipeline that turns a trained monster into an ownable, tradable CW721 NFT is in build.

8.3 Kosmic Dragoon — live

An existing combat title under ongoing live-ops.

8.4 Kosmic — the UE5 flagship, in development

A shared-world MMORPG for parties of two to six, guided by a single AI Dungeon Master. The differentiators are the honesty and the memory: dice rolls are real and the DM cannot fudge them, and a persistent per-party ledger of grudges, open threads and claims is injected into the DM's context every turn, so the world remembers what a party actually did.

The DM runs on a local model on owned hardware — there is no per-token cost per narration and no third-party dependency in the game loop. The engine is Unreal Engine 5; the AI DM, party server, combat resolver and ledger are engine-agnostic and were carried across unchanged from an earlier client.

Current scope is deliberately narrow: one party at a time, on hardware already owned. Expansion is gated on the quality of the DM interaction, not on infrastructure.

9. Dungeon Academy

A learning platform at dungeon.games/academy with a game attached — subject halls from arithmetic to astronomy, a quest game, a proof journal, a family portal for parents and live payments. It is the same stack as the games and the same art direction, aimed at a different audience.

10. Marketplace

The Hoard, at nft.dungeongames.io. CW721 collections for Heroes and Gear on dungeon-1, with primary-mint and secondary-trade flows and royalties enforced at the contract layer. Metadata and assets are pinned to IPFS.

Cross-game asset portability is the direction of travel: one NFT identity that carries between Kosmic Dungeon, Kosmic Monsters and the flagship.

11. Validator operations

Dungeon operates validators on dungeon-1 plus seven external proof-of-stake networks: the Hub, AtomOne, Pocket, Passage, Mantle, Chihuahua and Jackal. Commission revenue partially offsets platform operating cost and subsidises DEX and game incentive flows during bootstrap.

This footprint is deliberately smaller than it once was. Chains were retired where the economics stopped working; running fewer validators well beats running many badly, particularly at this team size.

• Delegator support: Keplr, Leap and Restake-compatible.
• Slashing record: zero slashing events across all networks to date.
• Hardware: bare metal in a company-owned data center.
• Monitoring: every validator is under continuous alerting for missed blocks, jailing and endpoint health.

12. Security posture

12.1 Current state, stated honestly

• All contracts are written in Rust. There is no Solidity in the stack.
• Unit tests with cw-multi-test across the DEX, staking, fair-launch, OTC, limit-order, airdrop, SPV and mint contracts — every execute path and every error branch.
• Scenario tests on a testnet before any mainnet store. Every mainnet deploy follows a script that can be re-run and diffed.
• No unaudited third-party contracts in production. Any open-source primitive is reviewed line by line, modified in-house and re-tested before deploy.
• Admin keys are multi-signature where the contract supports it. The Bitcoin bridge federation is 3-of-5.
• Key management: validator signing keys live on hardened storage in the data center. Hot keys for automated operations are scoped to their role with bounded balances.

12.2 External audits

No third-party audit has been completed as of publication. That is stated plainly rather than buried. Every contract in production has instead been unit-tested to branch coverage, scenario-tested end to end on a testnet, deployed through a scripted migration, and kept behind a migrate authority so a hot issue can be patched rather than requiring re-instantiation.

Third-party audits are planned for the DEX, OTC, fair-launch and bridge stack as traction crosses a threshold that justifies the cost. Partners, scope and outcomes will be published. In the meantime the source of every mainnet contract is available for independent review.

12.3 Bug bounty

A scoped bounty program will be published alongside the first formal audit engagement. Today, critical issues can be reported privately through the Discord admin channels or by a signed on-chain message to the admin address. Validated findings are paid in $DGN on a severity-tiered scale.

12.4 User risk

Users assume standard DeFi risk: smart-contract bugs, chain halts, relayer issues and third-party wallet compromise. Bridged assets additionally carry federation and reorg risk, which is why a conservative cap is maintained on the Bitcoin bridge. The recommendations are the usual ones and they are meant seriously — never deposit more than you can afford to lose, read the contract source, and use a hardware wallet for large balances.

13. Governance

• Dungeon DAO — governance contracts are built. Voting power scales with bonded $DGN.
• Initial scope — DEX parameters (fee basis points, token whitelist, new deployments), treasury allocations, incentive funding, and marketplace collection moderation.
• Chain-level governance — software upgrades and consensus parameters remain with the validator set; application-layer governance runs through DAO contracts on top.

14. Team and company

• Crypto Dungeon LLC, Dubuque, Iowa, USA.
• Founder — a solo-operator CEO running product, engineering and operations, with a small contractor network for art and audio.
• Operating principle — everything must be maintainable by one person at 99.9% uptime. That constrains complexity by design, and it is why the stack avoids patterns like multi-contract proxies and bespoke off-chain sequencers. It is a real constraint and it is disclosed, not hidden.

15. Competitive positioning

Dungeon occupies a slot no one else does: a chain, an in-house DEX, a shipping game studio and 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 thesis. As the studio's games monetise, $DGN holders capture a share through on-chain distribution and the emission schedule steps down in proportion. The nearest analog in spirit is Immutable X on Ethereum, except that Dungeon self-hosts rather than relying on a general L2, and the studio is first-party rather than a partner program.

16. Glossary

17. Where to verify everything here

• Chain state — the public RPC and REST endpoints, or any independent node.
• Contract source — linked per contract from the explorer.
• Validator performance — public registries and Restake.
• DEX activity — dex.dungeongames.io and the explorer's pool pages.
• Live platform numbers — the front page renders them from the chain on every request.
• Contact — Discord, Telegram, X.

18. Disclaimers

This document describes a live, evolving system. Anything marked as in development is not guaranteed to ship, and its 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

• v3.0 — 2026-07-27 — Moved to dungeon.games/whitepaper from the explorer, and rewritten rather than copied. Added §7 Bridges (Bitcoin, Ethereum and Solana all shipped to mainnet since v2.1) and §9 Dungeon Academy. Chain updated v5 → v8. Kosmic Dungeon moved from "in beta" to launched. Kosmic Monsters added. The flagship's engine and AI DM description corrected. The validator footprint corrected downward to the eight networks actually operated. Hardcoded live-statistics tables removed in favour of the live surfaces — they were the part of v2.1 that had gone most wrong.
• v2.1 — 2026-04-23 — Added the game-revenue loop, competitive positioning, KPI targets, glossary, and the explicit audit and bug-bounty disclosure.
• v2.0 — 2026-04-23 — Full rewrite reflecting mainnet state at the time.
• v1.x — prior internal drafts, superseded.