Technical
Whitepaper.

Version: 3.3 · Last updated: 2026-10-21 · Publisher: Crypto Dungeon LLC, Dubuque, Iowa, USA

Overview

Dungeon combines a sovereign blockchain, games, a desktop launcher, wallet, trading services and an NFT marketplace. The aim is a usable gaming platform: players understand what they are opening, what a signature authorizes, where progress is saved and which assets a game actually supports.

The launcher distributes and connects products; it does not turn every game into an on-chain game, make every save portable or make every NFT useful in every title. Those capabilities require explicit integrations and verification.

This revision distinguishes public products, bounded playtests, implemented source and future commitments. Current fees, market values, contract parameters and service availability should be checked at the point of use. A static whitepaper is not a live quote or an operational status page.

1. Purpose and operating model

Crypto Dungeon LLC builds games and operates the infrastructure that supports its platform. Company-owned physical servers are colocated in an underground data center. The company owns the machines; that does not mean it owns the building. The founder operates a broad product surface, so maintainability, recovery and bounded scope determine what can responsibly ship.

The architectural principles are to maintain the chain and integrations, minimize unnecessary dependencies in the game loop, preserve player progress, and make ownership and payment behavior inspectable. Availability targets are operating goals, not guarantees that eliminate outages or losses.

2. System architecture

Chain and contracts

dungeon-1 is a sovereign proof-of-stake chain with its own validator set and CosmWasm contracts. It has not been a Cosmos Hub consumer chain since its fresh sovereign genesis on 2025-03-27. Historical ICS imports do not change that model.

The native denomination is udgn: 1 DGN = 1,000,000 udgn. IBC connects supported Cosmos routes; other networks use distinct bridge infrastructure. The public node-info API reported application version 12.0.0 and Cosmos SDK v0.55.0 on 2026-10-21. These are dated observations; use current node and governance records when planning an upgrade or integration.

Contracts cover exchange, bonding, incentives, OTC offers, auctions, collections and bridge components. Each contract's address, code, authority, configuration and migration permissions matter. An interface label is not a substitute for checking the actual contract and network.

Services and clients

Off-chain services provide game logic, accounts, saves, catalog review, relaying and operational monitoring. The desktop launcher uses Electron; browser and mobile games retain their own engines and save systems. Kosmic and Oathforge use native clients; their game updaters and save behavior remain separate from installing the desktop launcher.

A wallet signature can authorize a specific operation. A signed-in player account can identify a player to a game service. Neither fact alone establishes a paid entitlement, ownership of a particular NFT or a successful cloud save.

3. Token economics — $DGN

Supply and emissions

The canonical genesis and current chain state are the supply records. The mint parameters queried on 2026-10-21 set annual inflation minimum and maximum to 10%, with a zero annual rate-change parameter. Inflation is token emission, not a promised 10% staking return. Validator commission, the bonded share, community tax and protocol behavior affect individual rewards.

The staking parameters queried on the same date set undelegation to 1,728,000 seconds (20 days). Governance can change parameters. Check the current staking interface and chain response before committing funds.

Current utility and contract terms

DGN pays chain transaction fees and can be delegated to support validator security. It is also used by supported game services, NFT flows and markets. DEX liquidity positions, protocol-fee bonding, liquid staking and validator staking are separate mechanisms with different contracts, restrictions and risks.

The previous paper described 0.5% DEX/OTC protocol fees. A static percentage is not a quote for every pool or offer: inspect the current pool, offer and receipt. A validator delegation does not automatically enroll its owner in a separate bonding contract or establish a company-revenue entitlement.

Castle Siege: burn and season pot

Castle Siege runs weekly seasons on dungeon-1. DGN spent on entry and castle builds is split: half is destroyed with a BankMsg::Burn, reducing supply, and half funds that season's pot. At the season's end the contract finalizes on chain and pays the pot to ranked castles. Raids are settled with drand randomness and take Renown, not tokens. Season 1 finalized on 2026-10-19 (transaction A31A966CD4677838938A0B3E194CDED76B7134121D747F891B30F48CF845CB11, height 22,028,723) and paid 1,888,000 DGN to 10 castles. Pot sizes, burned totals and standings belong to the live contract, not to this paper.

The game-revenue governance commitment

Dungeon retains its commitment to propose a periodic on-chain distribution of a meaningful portion of measured net revenue from Dungeon-published games to DGN stakers, with inflation designed to step down proportionally as game revenue supports it. The percentage and cadence are governance-set.

This is a standing governance commitment, not a universal hard contract rule. Each step requires the stated measured revenue floor over a rolling window, a published proposal and community ratification. Distributions must be supported by auditable accounting and on-chain receipts. This revision does not claim that the first distribution has occurred or promise revenue, yield or a date. It does not silently change the existing economic commitment.

4. Trading and cross-chain access

Dungeon DEX provides supported pool, liquidity and bonding flows. Pact Hall handles supported OTC offers; Hourglass provides time-weighted auction flows. Their active contracts and interface terms determine settlement and cancellation behavior. Trading, providing liquidity and bonding are different decisions.

Dungeon Go presents supported swap/bridge routes. A wallet's ability to hold an asset on a network does not prove that a particular bridge route is currently available in that client. Check the route, source and destination networks, recipient, exact token identity, quote expiry, fees and final receipt.

Native Injective USDC

Circle-native USDC on Injective uses base denomination erc20:0xa00C59fF5a080D2b954d0c75e46E22a0c371235a with six decimals. The direct route is Dungeon channel-5320 ↔ Injective channel-490. On Dungeon its denomination is ibc/873B9E8BAA6E423691F506F6F9AC3151AA390F67D2B655A02EF406175F04FC4F.

Legacy Noble-origin USDC, Injective's legacy USDC and this asset are distinct. Do not rely on the symbol alone. IBC packets can remain pending while a relayer is online; completion requires chain receipt and acknowledgement, or a protocol refund when applicable. Never send another transfer merely to “unstick” one.

Bridge trust boundaries

Bitcoin deposit verification uses an on-chain SPV design, while withdrawals have a federated signing dependency. Verified deposit proofs do not make the entire two-way system free of operator or custody assumptions. Inspect the current federation, caps, pause/migration authorities and settlement behavior.

Ethereum, Solana and Base routes have their own contracts, relayers and security assumptions. The Base DGN warp route uses collateral on Dungeon and a synthetic representation on Base. Cross-chain collateral, message validation, relayer availability, fees and reorganization risk remain relevant. A custodial Lightning cashier is a separate game-balance service.

5. Dungeon Launcher

The launcher provides a game store/library, supported signed native-launcher installation, an integrated wallet, chat, Tabletop and Developer Studio. Public packages are linked from the launcher page. As of beta 81 (2026-10-21) the catalog holds 23 games, including twelve Arcade titles. Community rooms of up to six people support optional cameras, joined muted with the camera off.

Tabletop: Lastlight is a 5th-edition SRD table for a GM and players: a shared 3D board with elevation, fog, doors and miniatures; guided character creation and level-by-level class play for all twelve SRD classes; linked combat health, rests and resource tracking; and a GM session journal. Players join with private single-use campaign codes. The GM adjudicates effects, targets and rules exceptions; the tools record and apply what the GM confirms. Supported packages and automatic-update behavior vary by operating system; the release page and feeds are authoritative for the current desktop version.

Browsing does not require an unlocked wallet. Starting a game through the launcher does require wallet unlock under the platform's launch policy. A game may then have its own account, license, invitation or transaction requirement. Unlocking the launcher does not purchase anything or grant an invitation.

Browser games can receive only the wallet/player integrations approved for that game. Address access, signatures and transactions have separate consent paths. External-browser games use the browser's own account/wallet environment. Native games use their own supported connection. No game receives the launcher's recovery phrase or account session token through these integrations.

Developer publishing

Submissions are open; public publication requires Dungeon approval. Developers save a listing and release, select supported integrations, optionally connect a collection, then submit an immutable revision. A newer draft stays separate from the approved public version. Review can request changes; a listing can be withdrawn without erasing a player's library history.

A native Windows launcher requires the reviewed bytes and publisher certificate and must pass signature checks. A browser review approves listing metadata, origins and permissions; it does not freeze all future content on the developer's host. Developers remain responsible for their game and updates.

NFT collections and utility

The Hoard supplies collection creation with its own terms, fees and wallet approval. Studio self-service checks support the standard code-49 collection and code-98 launch template. Submission and approval recheck current minter or launch-creator authority against the verified developer wallet. Custom contracts require compatibility review.

An NFT proves a token's ownership under its contract. A game's server must authenticate the player, query current ownership and apply its implemented rules before granting utility. A launcher inventory entry is not a permanent entitlement, and transferring a token can invalidate previous access. Cross-game utility is built game by game, not conferred by a shared standard.

6. Games and access

Game-specific FAQs explain access, saves and ownership boundaries. Gameplay currency is not automatically DGN. A hero or item in a save is not automatically an NFT. Rewards, prices and availability must be read from the active game rather than inferred from this paper.

7. Saves, accounts and recovery

A launcher library entry records access/history; it is not a backup of every save. The player integration offers game-scoped saves when a game implements it. Other games use their own cloud or local storage. Signing in to the launcher does not silently migrate browser or native-client progress.

Players should preserve the original device/profile and any game-provided export before troubleshooting. Retry a known account and inspect the saved identity before creating a new one. For a missing purchase, record the receipt, wallet/account, game and approximate time. Do not share passwords, keys or recovery phrases with support.

8. Infrastructure, governance and security

The company operates its own chain infrastructure and a fleet of physical servers. A server count is not a validator count, and running a node does not prove an active bonded validator. Verify each current validator and commission on its network instead of relying on old lists of external chains.

Chain governance and application DAOs are distinct. A chain delegation may grant chain-proposal voting power; a particular DAO uses its own membership and voting rules. Governance decisions can change parameters, authorities and upgrade behavior; an interface should show the exact proposal and intended action.

Guarded release processes verify committed source, the current live release, build provenance and health before publication. Recovery and rollback paths are part of those controls. Tests reduce risk but do not prove every path safe. This revision does not claim a completed independent audit without a published report and scope. Historical internal tests and coverage are not third-party audit certification.

Relevant risks include contract and client bugs, lost device storage, account compromise, chain or service outages, slashing, bridge/federation failure, reorganizations, migration/admin authority and unavailable game features. An open-source implementation or valid signature does not eliminate those risks.

9. Verification and document maintenance

• Public chain API
• Mint parameters
• Staking parameters
• Explorer
• DEX
• The Hoard
• Roadmap
• Game FAQs
• Official support

The website Markdown/FAQ sources are canonical. Launcher copies identify their review date and source fingerprint and can be read offline. A bundled snapshot can be older than the website. Current transaction terms and chain records supersede historical observations in either copy.

10. Revision history and limits

3.3 — 2026-10-21: added Castle Siege's burn/pot design and the verified Season 1 payout; launcher beta 81, its 23-game catalog, community video and Tabletop: Lastlight; Sky Mercenaries and Castle Siege in the games table; the Oathforge Early Access target. Chain observations re-read on 2026-10-21 (unchanged).

3.2 — 2026-10-16: reorganized around architecture, access, player recovery and reviewed publishing; added the launcher and NFT authority boundaries; corrected the dated node version and 20-day undelegation observation; preserved the existing game-revenue governance commitment; removed unsupported uptime, validator-count, universal ownership and universal save guarantees. Clarified SPV versus federated withdrawal trust and distinct USDC denominations.

3.1 — 2026-09-20: added Base, liquid staking, Dungeon Go and the Injective-USDC migration, expanded the game catalog and described role-separated key work. 3.0 — 2026-07-27: moved the public paper to dungeon.games and revised earlier chain, product and infrastructure descriptions.

This paper describes an evolving utility platform. Future work can change or be deferred. It is not a guaranteed investment return, financial advice, a price quote or a promise that a game, service or bridged asset is always available.