The MMORPP Manifesto: When Mining Becomes the Game

Release status: DCENT_Pool is being prepared for public release. Follow or inspect the DCENT_Pool GitHub destination for release status. Do not assume the complete pool, game, dashboard, or self-hosting documentation is public until it appears there.

Most online worlds ask players to pretend that a button press is labour.

Click the ore. Wait for the bar. Receive the metal. Repeat until a number becomes large enough to open the next door.

There is nothing wrong with that abstraction. Entire genres have turned it into art. Persistent MMOs teach us to coordinate through guilds and roles. Long-horizon skill games make slow accumulation satisfying. Tabletop campaigns make a shared history feel more important than any single victory. Idle games prove that anticipation and return can be as meaningful as constant input.

DCENT_Pool begins with a different question:

What if the action economy of an online world were bounded by work that happened outside the fiction—and that work was Bitcoin mining?

D-Central calls the answer an MMORPP: a Massively Multiplayer Online Role-Playing Pool.

An MMORPP is not simply an MMORPG with Bitcoin rewards attached. It is not a token economy wearing fantasy art. It is not a phone game that calls a tap “mining.” The pool is the action engine. Compatible Bitcoin miners receive current work, perform SHA-256 hashing, and submit shares. Validated accepted work can then become effort inside a persistent role-playing world.

The player chooses what the hero is trying to do. The miner supplies the effort. Bitcoin supplies the clock.

Development note: DCENT_Pool is still under active development. This article explains the product doctrine, not a promise that every described system is available on the hosted realm today. Check the DCENT_Pool product page for current deployment status.

Not a mining simulator

Many games use the language of mining. Virtual rigs generate virtual hashrate. Clicking a button yields a token. A mobile game may distribute small Bitcoin rewards through another service. Those can be enjoyable games, but the mining is a metaphor.

DCENT_Pool starts on the other side of that line. The machine is a real SHA-256 miner working on a real Bitcoin mining job. The pool validates its submissions. A share demonstrates that the miner found a header hash below the pool’s share target. On rare occasions, a result may also satisfy the much harder Bitcoin network target and become a candidate block.

The game does not simulate that work. It interprets measured pool work as an input to a fictional world.

That distinction is why “physically grounded” matters. Progress is not free computation generated by a game server while everyone is asleep. The player’s hardware must be operating. It consumes electricity, creates heat, needs a network connection, receives current work, and submits valid results. If the miner is off, disconnected, or working on stale data, the game should not pretend otherwise.

This is also why the idea needs unusually strict truth in its interface. Fantasy can make the world memorable. It cannot turn rejected work into accepted work, a pool share into a Bitcoin block, or an uncertain reward into a promise.

The three-plane rule

Every MMORPP screen should make three different realities legible.

1. The Bitcoin plane

This is the external protocol reality: block headers, network difficulty, candidate blocks, node validation, confirmations, coinbase outputs, and the chain selected by Bitcoin nodes.

Game rules cannot change these facts. Slaying a dragon cannot improve the next hash. Joining a guild cannot make Bitcoin owe anyone a reward. A title, level, or item cannot turn an invalid block into a valid one.

2. The pool-accounting plane

This is where jobs, worker sessions, share targets, vardiff, accepted and rejected shares, work attribution, fees, and payout policy live.

Shares are essential here, but they require careful language. An accepted share proves work at the pool’s easier target. It measures contribution; it is not a partially completed block and does not mean a network-valid result is getting closer. The anatomy of a Bitcoin share explains that boundary in detail.

3. The fictional-world plane

This is where accepted work may become Hero Effort, movement, construction, scouting, damage, healing, influence, or research under a documented ruleset.

These units are fiction. They are not satoshis. They are not a game token, a security, a claim on a future block, or a multiplier on Bitcoin probability. Their purpose is to make real participation visible, social, and narratively meaningful.

The rule is simple: the fantasy may translate the evidence, but it may never falsify the evidence.

Bitcoin is the world clock

Traditional online games control their calendars. A studio schedules a boss for Friday at 8 p.m., resets a season on Tuesday, or shortens a construction timer during an event.

An MMORPP can use a clock it does not own: Bitcoin block height.

Each newly adopted Bitcoin block can advance the world by one tick. Travel may take a number of blocks. Construction may settle at a future height. A siege may remain open for a block-denominated response window. A monster may migrate after a documented number of canonical ticks.

That gives the world an external heartbeat—but not a precise wall-clock schedule.

The Bitcoin network adds blocks at irregular intervals. Roughly ten minutes is a long-run network target, not an appointment. Two blocks can arrive close together. Another can take much longer. There is no honest countdown to the next one.

This unpredictability is not a flaw for the world design. It creates anticipation without letting the developer sell time skips. But the interface must always show block-denominated rules as primary and wall-clock equivalents as approximate hints.

For example:

Arrival at height 965,410 — 6 blocks remaining (roughly one hour at the target average; actual time varies).

Not:

Your hero arrives in exactly 60 minutes.

The difference is more than pedantry. It teaches the player something true about Bitcoin every time they look at the map.

The player declares intent; proof of work supplies force

A machine can hash continuously, but role-playing requires choice. The important design problem is separating intent from effort.

Intent can be declared through a supported interface: explore north, defend a settlement, contribute to a bridge, attack a local monster, or prepare for a guild objective. That command does not manufacture progress. It directs where subsequently validated effort should be applied.

The loop is:

The player chooses an intention.
The pool gives the miner current Bitcoin work.
The miner hashes and submits results.
The pool validates each submission.
Accepted work is normalized under a published game rule.
The world applies that effort to the chosen action.
Bitcoin blocks advance block-timed transitions.
The chronicle records what changed and why.

The result resembles an idle game from the player’s perspective: choose a direction, leave, and return to discover what happened. Underneath, however, it is not an imaginary offline multiplier. A physical machine kept doing measurable work.

Why idle-game players may understand this first

Idle games are often misunderstood as games with nothing to do. The best of them are games about deciding what should happen during absence.

Players optimize a system, commit to a plan, and step away. When they return, accumulated results reveal whether that plan worked. The emotional rhythm is preparation, anticipation, discovery, and adjustment.

An MMORPP can share that rhythm:

choose a role or objective;
configure a compatible miner safely;
let accepted work accumulate toward a fictional action;
return after several Bitcoin blocks;
read a chronicle of movement, threats, allies, and world changes;
redirect the next period of effort.

But one sentence must accompany every idle-game comparison:

The player may be away; the miner is not “offline.” It must remain powered, cooled, connected, and maintained, and no Bitcoin return is guaranteed.

That constraint may actually be the creative heart of the design. In a conventional idle game, the resource curve exists because a designer typed a formula. Here, the input reflects hardware capability, uptime, pool difficulty, network conditions, and valid work. The game designer must respond to reality rather than erase it.

What guilds mean when contribution is measured

Guilds are powerful because they transform individual repetition into collective memory. A difficult encounter becomes “the night we held the gate,” not merely a line in a personal log.

Proof-of-work input can give those stories an inspectable foundation. A guild objective can name the accepted effort applied, the ruleset used, the blocks during which the event occurred, and the outcome produced.

That does not automatically make the design fair.

Hashrate is unequal by nature. An industrial miner can perform far more work than a small desktop miner. Pretending otherwise would betray the physical premise. A good MMORPP must instead create meaningful forms of participation at different scales: scouting thresholds, timing decisions, logistics, persistent defence, route selection, information, coordination, and contribution floors where appropriate.

The design challenge is not to make every miner equally powerful. It is to keep raw power from becoming the only interesting decision.

That is familiar territory to MMO players. Parties already use different roles because a group of pure damage dealers is not always the strongest team. DCENT_Pool can borrow that systems lesson without copying any particular game’s world, characters, or mechanics.

A campaign that does not need a reset

Seasonal wipes are convenient. They compress competition into a marketable window and make late arrivals feel less behind. They also teach players that their history is disposable.

The MMORPP doctrine aims at something closer to a long-running tabletop campaign or a persistent world: new chapters without erasing old ones.

Roads can decay instead of vanishing. A defeated threat can leave a ruin. A settlement can change hands while retaining its earlier chronicle. Seasonal rankings can reset as a view over history without deleting the history itself.

This is an ambition, not magic. Databases can fail. Rules must evolve. Bitcoin can reorganize near the tip. A truthful implementation needs provisional ticks, versioned transitions, backups, migrations, and replay tests. Until those systems are proven in a release, the safe promise is continuous-history design, not literal immutability.

The rare block moment

There is an extraordinary event at the edge of the loop. The same miner producing ordinary pool shares might find a result below the Bitcoin network target.

People often reach for the word “jackpot.” It captures the emotional scale of a rare, high-variance outcome, but it imports the wrong mechanics. There is no drawing issued by DCENT_Pool every ten minutes. Miners make continuous hash attempts. The global network’s blocks arrive irregularly, averaging roughly ten minutes over time. Most of those blocks are found by miners elsewhere. Past failures do not make a DCENT_Pool block due.

The precise language is better:

A DCENT_Pool miner participates in the live Bitcoin block race. If work from an active job produces a candidate accepted into Bitcoin’s best chain, the published coinbase and fee policy determines the payout outputs.

Before launch, the product surface must prove that path end to end. It should show the active job, fee and payout policy, candidate lifecycle, block hash, confirmations, and exact outputs. The story should follow the evidence rather than outrun it.

For the underlying probability, use the solo mining calculator and read its assumptions. Expected time is a statistical mean, not a countdown.

No game token required

The easiest way to merge games and crypto is to issue another asset. The harder path is to make the game meaningful without turning every object into a market.

DCENT_Pool’s stronger thesis is that the world does not need a required game token or NFT. Hero Effort can remain fictional. A sword can be a record of a campaign achievement instead of a financial instrument. A guild can exist to coordinate people instead of pooling an investment.

Bitcoin remains Bitcoin. Mining economics remain mining economics. Fiction remains fiction.

This boundary does not remove every regulatory or consumer-protection question. Mining still involves real costs and a possible monetary payout. Any future prize, referral reward, transferable asset, pooled reward, or paid game advantage would require a fresh technical, economic, and legal review. “No token” is a design constraint, not a permission slip.

Five laws of an MMORPP

Law 1: No work, no work credit

Only work that passes the published validation rules can supply game effort. Rejected, duplicate, unauthorized, or stale submissions cannot be dressed up as success.

Law 2: A share is not a nearly finished block

Shares measure work at a pool target. They do not fill a progress bar toward a Bitcoin block, and they do not make the next hash due.

Law 3: The world may interpret Bitcoin; it may not impersonate Bitcoin

Game labels must remain visibly separate from network, payout, and confirmation facts.

Law 4: Important outcomes need a replay path

The ruleset version, accepted-work inputs, block references, and resulting transition should be inspectable. “Provably fair” is too broad; “reproducible under these rules and inputs” is testable.

Law 5: Physical play requires physical honesty

Mining consumes electricity and produces heat and noise. Hardware and network failures happen. Reward variance is severe. No gaming metaphor may hide those realities from a newcomer.

Not “the first”—a category worth defining

Games have used blockchains, mining metaphors, human computation, geolocation, and even their own proof-of-work chains before. Recent projects also combine real mining hardware with game-oriented networks. A web search cannot prove a universal “first.”

The useful claim is not that history was empty before DCENT_Pool. It is that this particular combination deserves a name:

a real Bitcoin mining pool supplies validated work;
accepted work becomes action effort in a persistent role-playing world;
Bitcoin blocks advance the shared clock;
the fiction does not become a token or distort payout truth;
and the system is built to expose evidence for the path from work to world.

That is an MMORPP.

If the category becomes useful enough that other builders adopt the term, that is stronger evidence of originality than repeating a superlative. D-Central’s job is to define the model precisely, build it honestly, publish the proof, and make the world worth entering.

Frequently asked questions

Is an MMORPP an MMORPG on the Bitcoin blockchain?

Not exactly. DCENT_Pool’s game state is not Bitcoin consensus state. Bitcoin mining work and block events act as inputs to a separately versioned multiplayer simulation. The separation protects both technical accuracy and game-design flexibility.

Is this a play-to-earn game?

No return should be promised. The game layer can interpret accepted mining work, while Bitcoin mining retains its real hardware costs and high-variance block-discovery outcome. Fictional progress is not a claim on BTC.

Does every Bitcoin block pay a DCENT_Pool player?

No. Every adopted Bitcoin block may advance the world clock, regardless of who found it. A DCENT_Pool payout path is relevant only if work from the pool produces a block that is accepted into the best chain, subject to the active fee and coinbase policy.

Can the game make my miner more likely to find a block?

No. Classes, guilds, items, and actions must not improve Bitcoin hash probability. Hashrate, valid work, difficulty, uptime, and network conditions govern the mining process.

Why would an idle-game player care?

The appeal is asynchronous intention and return: choose a goal, let a real machine supply measurable effort, and come back to a persistent chronicle. Unlike a conventional idle game, the machine must remain safely powered and connected.

Is DCENT_Pool affiliated with World of Warcraft, RuneScape, or Dungeons & Dragons?

No. Those names describe creative influences in guild play, long-horizon progression, and collaborative campaign storytelling. DCENT_Pool is an independent D-Central project and uses its own world, systems, and identity.

Continue reading

Sources and further reading

Trademark note: World of Warcraft, RuneScape, and Dungeons & Dragons are referenced nominatively as design influences. Their respective owners do not sponsor, endorse, or affiliate with DCENT_Pool or D-Central.

Related products, repair, and setup paths

Last reviewed September 2, 2026.