PvE Over PvP: Launching the Reserve Currency for Your Fully On-Chain Game (FOCG)

The Web3 gaming market is nursing a collective hangover. For years, the play-to-earn (P2E) paradigm leaned on hyper-PvP, zero-sum economic models: early adopters farmed tokens, late adopters held the bag, and player-versus-player (PvP) market dynamics turned every game economy into a hyper-inflationary battleground. When the music stopped, players left, liquidity drained, and games collapsed under the weight of their own token dumping.

A shift is underway in decentralized gaming. Independent developers are moving away from player-vs-player capital extraction and toward Player-vs-Environment (PvE) mechanics, where the reserve currency is fuel consumed and burned by players fighting on-chain entities, boss contracts, and environmental constraints — not a speculative asset to be flipped on a peer.

This guide covers how indie developers can use frfr.fun to launch a reserve currency for a Fully On-Chain Game (FOCG), build deflationary PvE burn loops, and structure a sustainable game economy on Base. It also covers something the last version of this guide glossed over: a major infrastructure shift that hit the FOCG space in spring 2026, and what it actually means for anyone building on this stack today.

1. What Are Fully On-Chain Games (FOCG), and Where Does MUD Fit?

A "Web3-enabled game" and a Fully On-Chain Game (FOCG) are not the same thing. Traditional Web3 games use the blockchain as a database for ownership assets: game logic runs on a centralized server, while character skins and tokens live on-chain as ERC-721 or ERC-20 contracts. Turn off the server, and the NFTs become inert collectibles with no game left to play.

An FOCG works differently:

The state is the blockchain. Game state, logic, rules, and assets exist entirely inside open-source smart contracts.
Persistence isn't optional. As long as the underlying chain exists, the world stays alive and playable — even if the original team disappears.
Rules are enforced by code, not admins. If a contract says entering a dungeon costs 100 tokens, no database tweak can override that.

┌─────────────────────────────────────────────────────────────────────────┐
│                    TRADITIONAL WEB3 GAME ARCHITECTURE                    │
├─────────────────────────────────────────────────────────────────────────┤
│  Game Client (Unity/Unreal)  ──>  Centralized Server                     │
│                                           │ (Pushes ownership only)      │
│                                           ▼                              │
│                                 ERC-721 / ERC-20 Tokens                  │
└─────────────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────────────┐
│                    FULLY ON-CHAIN GAME (MUD FRAMEWORK)                   │
├─────────────────────────────────────────────────────────────────────────┤
│  Client (MUD Indexer/Store)  <──>  MUD World Contract (Base L2)          │
│                                           │ (Executes all logic)         │
│                                           ▼                              │
│                                  On-Chain Game State                    │
│                        (Entities, Systems, Components, Burns)            │
└─────────────────────────────────────────────────────────────────────────┘

The MUD Framework, in Plain Terms

Building an FOCG from scratch on the EVM used to mean solving storage costs, state-sync bugs, and indexing infrastructure yourself, on top of the actual game design. MUD, an open-source framework originally released by Lattice in 2022, standardized this by bringing an Entity Component System (ECS) pattern to Solidity:

Entities — abstract IDs (a player, a monster, an item).
Components — data tables attached to entities (Health, Attack Power, Position).
Systems — contract logic that mutates components (a CombatSystem.sol that resolves damage when a player attacks a monster).

MUD's own documentation describes it as a framework that reduces the complexity of building Ethereum applications by handling data storage, upgrades, delegations, and frontend data-sync out of the box, with an automatic indexer so teams don't have to hand-write event listeners. It reached a stable, production-recommended v2 after an OpenZeppelin security audit, and games including Sky Strife, Biomes, Primodium, and CCP Games' Project Awakening were built on it.

A Critical Update: Lattice Wound Down in April 2026

This is the update that changes how you should read the rest of this guide, so it's worth stating plainly rather than burying it in a footnote.

On April 15, 2026, Lattice — the studio behind MUD — announced on X that it was winding down operations after five years. The company said it had never found a sustainable business model for the Autonomous Worlds vision it was built around, and that it spent its final runway on one last project, an autonomous world called DUST, which validated the underlying thesis but didn't reach the scale needed to sustain the business. Lattice stated explicitly that it did not believe raising further venture capital was the right path forward.

The practical consequences:

Redstone, Lattice's own game-specific L2 (an OP Stack Plasma chain), shut down on May 15, 2026 at 23:59 UTC (some outlets reported the cutover completing early on May 16 UTC depending on time zone). Anyone with funds in Redstone contracts — including Uniswap-style LP positions — was told those funds would not be recoverable after shutdown; only externally-owned-account (EOA) balances remain withdrawable via an L1 contract.
MUD itself has been fully open-sourced, is feature-complete, MIT-licensed, and remains OpenZeppelin-audited. It does not require Redstone, and never did — MUD is EVM-chain-agnostic and runs on Base, Ethereum mainnet, or any other EVM-compatible chain today, exactly as this guide originally assumed.
Quarry (Lattice's low-latency confirmation layer, marketed at roughly 7ms) and Dozer (a high-performance MUD indexer) were also open-sourced, meaning teams can self-host equivalents of what Lattice used to run as a service.
DUST, Lattice's own flagship game, migrated to a new "DUST Chain" hosted by Conduit and supported by the Optimism Foundation, and continues under the 0xPARC research umbrella rather than Lattice.

What this means if you're building an FOCG today: the technical premise of this guide — deploy MUD Systems directly on Base — still holds, and arguably holds better now, since Base was never dependent on Lattice's Redstone chain in the first place. What you no longer have is a venture-backed team actively fielding feature requests, running managed low-latency infrastructure, or maintaining Discord support at the level Lattice previously provided. Treat MUD going forward the way you'd treat any mature, audited, but no-longer-centrally-stewarded open-source dependency: pin a specific audited version, budget for the possibility that you (or the community) will need to maintain forks, and don't assume commercial-grade support exists.

It's also worth knowing MUD isn't the only FOCG engine. Dojo, a similarly ECS-inspired framework built for Starknet using Cairo rather than Solidity, emerged from teams inspired by MUD's design and remains actively developed independently of Lattice's wind-down — a relevant fallback or comparison point if you want a second data point on the framework landscape before committing.

2. The PvE Shift: Why Fighting Bosses Beats Fighting Each Other

The rest of this section is a conceptual economic argument about game design, not a claim about any specific measured outcome — treat the diagrams below as an illustrative model, not empirical data from a live game.

Early Web3 games fell into a predictable spiral because their economics were built on PvP financial competition:

Player A farms game tokens.
Player A dumps those tokens on an AMM.
Player B buys the tokens to upgrade their stats.
Player A extracts value; Player B absorbs the risk.

PVP ZERO-SUM PARADIGM:
[Player A Farms Tokens] ──> [Dumps on AMM] ──> [Player B Buys Bag] (Value Extracted)

PVE DEFLATIONARY PARADIGM (illustrative model):
[Player A Buys Tokens] ──> [Pays Contract Fee to Fight Boss] ──> [Tokens Burned On-Chain]

PvE shifts the target from another player's wallet to a smart contract. In an FOCG PvE model, players buy the base reserve currency to equip gear, buy stamina, or pay dungeon-entry fees. Game contracts burn a share of those tokens or route them to an ecosystem pool on each meaningful action, reducing circulating supply while awarding non-tradable status or access. The economic loop shifts from extraction toward utility consumption — players pay for challenge and progression rather than each other's exit liquidity.

3. Why frfr.fun as a Reserve-Currency Launchpad — With the Caveats Made Explicit

To launch a PvE ecosystem, the reserve currency needs to be liquid, cheap to trade, and predictable in value. A few things here are verifiable platform characteristics; a few are frfr.fun's own stated figures that haven't been independently audited from outside data, and the two categories are labeled separately below.

Verifiable / established platform characteristics:

frfr.fun is a USDC-settled, fair-launch token platform built on Base, with bonding-curve graduation into deeper liquidity venues such as Aerodrome and Uniswap V4 — this is consistent across frfr.fun's own published materials.
Settling in USDC on Base means a game designer pricing a health potion at "1.00 unit of the game token" doesn't have to reprice mechanics every time a volatile gas or settlement asset swings 20% overnight.
Base, as an OP Stack L2, offers sub-cent gas fees and fast confirmation times relative to Ethereum mainnet — a general, well-established property of the network, not specific to frfr.fun.

Platform self-description — verify current numbers before publishing anything that depends on the exact percentages:

frfr.fun describes a 6% creator fee and up to a 14% referrer fee on trading volume, per its own site. These figures are the platform's own claims about its mechanics, not something independently verifiable from outside data, and — like any fee schedule on any launchpad — they are the kind of thing platforms adjust over time (competitors including Pump.fun have reworked creator-fee mechanics more than once in the past year). Check frfr.fun's live documentation for current numbers before you build them into a pitch deck or a smart contract's economic assumptions.

┌─────────────────────────────────────────────────────────┐
│      frfr.fun PLATFORM CHARACTERISTICS (as described)    │
├───────────────────────────┬─────────────────────────────┤
│ Native Network             │ Base (Ethereum L2)          │
├───────────────────────────┼─────────────────────────────┤
│ Settlement Asset           │ USDC                        │
├───────────────────────────┼─────────────────────────────┤
│ Creator Yield (self-desc.) │ 6% of trading volume        │
├───────────────────────────┼─────────────────────────────┤
│ Referrer Bounty (self-desc.)│ 14% of trading volume      │
└───────────────────────────┴─────────────────────────────┘

For a game developer, the 6% creator-yield claim matters because it's pitched as an ongoing revenue stream that could help fund indexer hosting, art, and community management as players trade the currency — but treat it as a marketing claim about the mechanism, not a guaranteed income projection, until you've confirmed the live terms yourself.

The referrer-fee model is a real, common pattern in this space more broadly (guild- or creator-driven referral links routing a cut of trading fees to whoever brought in the player), but the specific 14% figure is, again, frfr.fun's own stated number rather than something this guide independently verified.

4. Architectural Blueprint: Wiring a MUD System to a frfr.fun Token

This code is an illustrative example, not audited or production-ready. It is meant to communicate the shape of the integration, not to be deployed as-is. Any real deployment needs a professional smart-contract audit — burn mechanics that move user funds are exactly the kind of logic where a subtle bug becomes an exploit.

One correction from the earlier draft of this piece: the original example transferred tokens from the contract to itself as a way of "retaining" the treasury share. That line does nothing useful (a contract sending tokens to its own address is a no-op that just burns gas) and was removed below. If tokens should stay in the contract as treasury, no transfer call is needed at all — they're already there after the transferFrom in step one; you'd typically just track the treasury balance in accounting state rather than moving anything.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

import { System } from "@latticexyz/world/src/System.sol";
import { IERC20 } from "@openzeppelin/contracts/token/ERC20/IERC20.sol";

contract BossBattleSystem is System {
    // Address of the game's reserve currency launched on frfr.fun
    address public immutable GAME_TOKEN;
    address public constant BURN_ADDRESS = 0x000000000000000000000000000000000000dEaD;

    uint256 public treasuryBalance;

    constructor(address _gameToken) {
        GAME_TOKEN = _gameToken;
    }

    /**
     * @notice Allows a player to engage an on-chain Boss contract.
     * @param bossId The entity ID of the MUD Boss monster.
     * @param entryFee The amount of reserve currency required to fight.
     */
    function attackBoss(bytes32 bossId, uint256 entryFee) external {
        address player = _msgSender();

        // 1. Pull the entry fee from the player into this System
        require(
            IERC20(GAME_TOKEN).transferFrom(player, address(this), entryFee),
            "Payment failed"
        );

        // 2. Deflationary split: burn 80%, retain 20% as treasury (accounted, not transferred)
        uint256 burnAmount = (entryFee * 80) / 100;
        uint256 treasuryAmount = entryFee - burnAmount;

        IERC20(GAME_TOKEN).transfer(BURN_ADDRESS, burnAmount);
        treasuryBalance += treasuryAmount; // tokens already sit in this contract

        // 3. Execute MUD game logic (illustrative — modify components)
        // e.g., HealthTable.set(bossId, currentHealth - playerDamage);
    }
}

The Economic Flow

Token acquisition — the player buys the reserve currency (say, $GOLD) on frfr.fun using USDC on Base.
Allowance approval — the player approves the MUD World contract to spend $GOLD.
In-game state change — the player triggers attackBoss from the client.
Atomic execution — the transaction verifies stats, burns the majority of the entry fee, updates the boss's health component in the MUD store, and logs the outcome, all within a single Base block.

5. Tokenomics for On-Chain PvE Economies

These are design principles, not a specific measured case study — treat them as a framework to adapt, not a proven formula.

Hardcap the initial supply on frfr.fun. Avoid inflationary mint functions; new supply should enter circulation only through market acquisition or clearly defined liquidity mechanisms.
Layer multiple burn sinks so players have several environmental reasons to spend tokens:

┌─────────────────────────────────────────────────────────┐
│                GAME TOKEN BURN SINKS (illustrative)      │
├───────────────────────────┬─────────────────────────────┤
│ Boss Raid Entry            │ 80% Burn / 20% Treasury     │
├───────────────────────────┼─────────────────────────────┤
│ Equipment Repairs          │ 100% Burn                   │
├───────────────────────────┼─────────────────────────────┤
│ Recipe Crafting            │ 50% Burn / 50% Pool         │
├───────────────────────────┼─────────────────────────────┤
│ Guild Territory Taxes      │ 100% Distributed to Guilds  │
└───────────────────────────┴─────────────────────────────┘

Scale difficulty to supply. As persistent burns shrink circulating supply, design MUD Systems that adjust boss difficulty and entry fees so the dollar-denominated cost to play stays welcoming for new users rather than spiraling with token scarcity.

6. How to Actually Launch: An Updated Step-by-Step Walkthrough

Develop your MUD core architecture. Define entities, components, and systems for your combat, harvesting, or crafting loop, and test on a local MUD dev environment. Pin a specific, audited MUD release rather than tracking main, since there's no longer a company cutting stable releases on a predictable cadence.
Deploy your reserve currency on frfr.fun. Connect a wallet on Base, deploy the token, and set up project documentation and social links. Confirm the platform's current fee terms directly on frfr.fun rather than relying on any older marketing copy (yours or anyone else's).
Connect MUD Systems to the token contract. Deploy your MUD World and Systems to Base directly — you do not need Redstone, Quarry, or any Lattice-hosted service; MUD has always run on any EVM chain, Base included. If you want Quarry-style low-latency confirmations, you'd now need to self-host the open-sourced version rather than use it as a managed service.
Build the client and Web3 gateway. Integrate a MUD indexer (self-hosted, since Lattice's own Dozer/Quarry are now open-source rather than managed products) with your frontend, and add swap components so players can acquire the reserve currency with USDC without leaving your app.
Set expectations about the current on-chain gaming landscape on Base. Independent trackers such as NFT Plazas describe Base's gaming ecosystem as active but still without an AAA-scale title as of early 2026 — activity is concentrated in lighter-weight, socially driven games rather than deep persistent worlds. That's not a reason not to build; it does mean you're an early mover in a genuinely uncrowded lane on this specific chain, and you should size expectations (and marketing claims) accordingly.
Activate referral distribution, if frfr.fun's live terms still support it, so guilds and content creators have a direct incentive to bring in players.

7. Risk and Regulatory Considerations

This section is general information, not legal or financial advice — a securities lawyer should review any specific token design and marketing plan before launch.

Token classification. On March 17, 2026, the SEC and CFTC jointly issued Interpretive Release Nos. 33-11412 and 34-105020, establishing a five-category taxonomy for crypto assets: digital securities, digital commodities, stablecoins, digital tools, and digital collectibles. Three of the five categories (digital commodities, digital collectibles, digital tools) sit outside SEC jurisdiction by default; digital securities remain fully regulated; stablecoins fall under the GENIUS Act framework. Critically, the release keeps the Howey test as the governing standard and makes classification fact-specific: it depends on the token's economic substance, how it's marketed, and what the issuer promises — not on labels like "utility token" or "game currency." A PvE burn-sink game token designed purely as an in-game consumable, with no promised managerial upside or fee-sharing to holders, is the kind of asset this framework is most likely to treat as a non-security digital tool or collectible — but a launch marketed around ongoing developer effort, roadmap-linked value accrual, or creator/referrer fee-sharing tied to trading volume starts to look more like the kind of arrangement that can still create an investment contract even where the underlying token itself isn't a security. Get this reviewed rather than assuming "it's just a game token" settles the question.

Stablecoin layer. The USDC settlement layer itself sits under the GENIUS Act (signed into law July 18, 2025), which governs permitted payment stablecoin issuers; its implementing rulemaking deadline falls in mid-to-late 2026.

Broader market-structure legislation is still pending, not settled. The CLARITY Act — which would resolve SEC/CFTC jurisdictional lines more durably than the March interpretive release alone — passed the House in July 2025 and advanced out of the Senate Banking Committee 15-9 on May 14, 2026, but missed the White House's informal early-July 2026 target and remained stalled as of this writing (July 11, 2026), with disputes over an ethics provision covering government officials' crypto holdings, AML language, and stablecoin-yield treatment. Analysts have flagged the Senate's return from recess on July 13 and the chamber's August recess as the last realistic window for 2026 passage; if it slips, the current regulatory picture (the March interpretive release, plus GENIUS) is what a launch has to work within for a while longer. Build with the assumption that the rules could still shift materially during your game's lifecycle.

Infrastructure/vendor risk. Lattice's wind-down is a useful cautionary data point in its own right: even a well-regarded, venture-funded infrastructure team building genuinely used tooling can shut down after five years without reaching commercial sustainability. MUD's open-source, audited nature meant that shutdown didn't strand existing MUD-based games the way a closed-source, hosted-only dependency would have — a point in favor of choosing open, chain-agnostic infrastructure generally, and a reason to think about what happens to your own game if any single vendor in your stack (including frfr.fun) changed terms or ceased operating.

Funding climate. Broader blockchain-gaming venture funding contracted sharply through 2025 by most industry trackers' counts, even as player and wallet activity metrics stayed comparatively strong — a reminder that "the market is active" and "capital is available" are two different claims, and indie developers relying on a launchpad-funded treasury rather than VC backing should model for a genuinely lean runway.

Standard PvP/dump risk hasn't disappeared. PvE burn mechanics reduce supply pressure from in-game consumption, but they don't eliminate ordinary secondary-market volatility, sniping, or bot activity around a bonding-curve launch. Treat "PvE tokenomics" as a mitigation, not an immunity.

Smart contract risk. Any code moving user funds — burns, treasury splits, boss-entry logic — needs a real audit before mainnet. The illustrative example above is unaudited by design and should not be treated as launch-ready.

Corrections and Transparency Log

Added: A dedicated subsection on Lattice's April 15, 2026 wind-down announcement and Redstone's May 15–16, 2026 shutdown, since this materially affects the risk and support picture for anyone building on MUD, even though it doesn't invalidate the core Base-deployment approach.
Corrected: The original Solidity example transferred tokens from the contract to itself as a "retain for treasury" step. That line was a functional no-op (self-transfer) and has been replaced with internal accounting (treasuryBalance += treasuryAmount) instead.
Reframed: frfr.fun's stated 6% creator fee and 14% referrer fee are now explicitly labeled as the platform's own self-description rather than presented as settled fact, with a recommendation to check current live terms before publishing or building against exact percentages.
Added: Reference to Dojo (Starknet/Cairo) as an actively maintained alternative FOCG framework, for context on the broader landscape beyond MUD.
Added: A regulatory section covering the March 17, 2026 SEC/CFTC five-category token taxonomy, the GENIUS Act's stablecoin framework, and the CLARITY Act's stalled status as of July 11, 2026 — none of which existed in this form when the original draft was written.
Added: A caveat that Base does not currently host an AAA-scale on-chain game per independent trackers as of early 2026, to keep expectations calibrated for developers using this guide as a competitive-landscape reference.
Labeled as hypothetical/illustrative throughout: the tokenomics burn-sink tables, the economic-flow diagrams, and the Solidity example — none of these describe a specific live, audited, or measured game economy.
Not independently verified in this piece: any specific third-party statistics on individual Base game user counts (e.g., particular project UAW figures) circulating on industry-tracker sites; these are omitted or heavily hedged above because tracker methodology varies widely and figures update quickly.
Last fact-checked: July 11, 2026. Given how fast the CLARITY Act timeline and the broader L2/infrastructure consolidation trend (of which Redstone's shutdown was one part) are moving, verify the regulatory and infrastructure sections again before publishing if any meaningful time has passed since this date.