Liquimon: Battle-Forged Evolution on a Fixed-Supply Chain

Introduction

Creature-collector games endure because they pair a simple loop — collect, train, battle, evolve — with deep strategic texture from type matchups and team composition. Bringing that loop fully on-chain is attractive: creatures become provably scarce, ownership is real, rules are transparent and immutable, and the game can outlive any single operator.

But most on-chain games quietly reintroduce the worst incentives of free-to-play. Power is sold. Progress is a function of spend. New tokens are minted as rewards, diluting holders and forcing perpetual sinks to stay afloat. The result is an economy that depends on continuous new deposits — and collapses without them.

Liquimon takes the opposite position. There is no emission. There is no way to buy power directly. The strongest, scarcest creatures exist only because someone earned them in the Arena, repeatedly, against real opponents, with real stakes. We call this Battle-Forged Evolution, and it is the organizing principle of the whole system.

1.1  The core claim

Evolution experience (XP) is non-transferable, non-purchasable, and produced by exactly one event: a settled battle that you won. XP is then consumed to evolve a creature into a stronger species. Because winning requires either type advantage, stat advantage, or favorable variance — and because the pool of $LMON is fixed — the supply of highly-evolved creatures is naturally throttled by player skill and risk appetite, not by a faucet.

Design goals

Every mechanism in Liquimon was chosen against five goals:

1. Earned, not bought. The scarce resource that gates power — evolution XP — must be impossible to purchase and impossible to transfer. It can only be produced by winning.
2. Fixed and honest supply. The token is capped forever, with no mint, no owner, and no upgradeability. A holder can verify the supply can never change by reading the bytecode.
3. Zero-sum, not inflationary. Rewards are funded by opponents' stakes, not by emissions. The game can run indefinitely without diluting anyone.
4. Strategic depth from transparent math. The six-type chart is balanced (every type has exactly two strengths and two weaknesses) and lives on-chain as a cheap, auditable lookup.
5. Fully on-chain and trust-minimized. Creatures, stats, matchups, battles, and settlement all execute in contracts. Battle settlement is permissionless — anyone can finalize a battle, so no operator can withhold results.

System overview

Liquimon is implemented as one token contract plus four game contracts. Two shared helpers — a TypeChart library and an IERC20 interface — are bundled inside the game files and are not standalone contracts.

Imports flow in a single direction — the token imports the four game files; each game contract references $LMON only through the IERC20 interface — so there are no circular dependencies. The token itself uses none of the imported logic; importing simply keeps the whole protocol in one compilation unit.

The $LMON token

$LMON is an ordinary ERC-20 with deliberately minimal surface area. Its properties are fixed at deployment and can never be altered.

4.1  Why fixed supply matters here

A capped token is what makes the zero-sum design honest. If the protocol could mint $LMON as battle rewards, "earned" evolution would be subsidized by dilution — economically identical to the pay-to-win loops Liquimon is built to avoid. Because supply is fixed, every $LMON a winner receives was first staked by a loser. The game cannot print its way out of a downturn, which keeps the token's role purely utilitarian.

4.2  Utility

$LMON has exactly three uses inside the game: it is spent to recruit creatures at the Academy, staked to enter battles in the Arena, and won from opponents on victory. Evolution itself costs no $LMON — it costs XP, which cannot be bought. This separation is intentional: money buys you entry and attempts, never power.

The six-type system

Every creature has exactly one immutable element, fixed by its species. There are six, indexed 0–5:

EMBER (0) · TIDE (1) · BLOOM (2) · SPARK (3) · GUST (4) · TERRA (5)

5.1  Balanced matchups

The chart is fully balanced: each type is super-effective against exactly two others and resisted by exactly two others. No type is strictly dominant, and there are no "dead" types. An attack lands at one of three multipliers — ×2.0 when super-effective, ×1.0 when neutral, ×0.5 when resisted.

Written out, the super-effective relationships are: EMBER beats BLOOM and SPARK; TIDE beats EMBER and GUST; BLOOM beats TIDE and TERRA; SPARK beats TIDE and GUST; GUST beats BLOOM and TERRA; TERRA beats EMBER and SPARK.

5.2  On-chain encoding

The relationships are stored as a single bitmask constant inside the TypeChart library. A matchup lookup sets a bit index from the attacker and defender indices and tests it, so resolving any matchup is a pure, branch-light, gas-cheap operation with no storage reads. Because an element is a property of the species and a creature's species only changes on evolution (to another fixed-element form), a creature's type is effectively permanent.

// pure lookup — no storage, no external calls
function multiplier(uint8 att, uint8 def) internal pure returns (uint16) {
    if (superEffective(att, def)) return 200;  // x2.0
    if (superEffective(def, att)) return 50;   // x0.5
    return 100;                               // x1.0
}

Creatures & species

Liquimon separates the template from the instance.

6.1  Species (templates)

A species defines a creature archetype: its element, base stats, display name, and which species it evolves into plus the XP that evolution costs. Species are registered by the deploying admin and define the entire roster. Stats are derived purely from species — there is no level scaling and no per-creature stat drift — so two creatures of the same species are mechanically identical until one evolves.

6.2  Creatures (instances)

A creature is an owned record in the Registry: its species, its owner, and its accumulated XP. Creatures are internal Registry records rather than ERC-721 tokens; ownership and transfer are tracked by the Registry directly. New creatures can only be created by the Academy, and XP can only be added by the Arena — both enforced by role checks.

Recruiting

New creatures enter circulation through the Academy. A trainer approves the Academy to spend $LMON, then calls recruit(species). The Academy pulls the species' price in $LMON, forwards it to the Treasury, and instructs the Registry to mint a fresh creature of that species to the caller. Prices are set per-species by the admin.

// trainer flow
lmon.approve(academy, price);
academy.recruit(speciesId);   // pays Treasury, mints creature to msg.sender

Recruiting is the only $LMON cost of acquiring a creature, and it buys a base-form creature with no XP and no evolution. From there, all progression is earned.

Battle resolution

The Arena is where the game's only XP is produced. Battles are staked, one-versus-one, and settled permissionlessly.

7.1  Challenge lifecycle

1. Create. A challenger commits a creature, locks a $LMON stake, and optionally restricts the opponent's element (or accepts any). The challenge opens.
2. Accept. Within the accept window, a second trainer matches the stake and commits a creature. The battle locks, and both stakes are escrowed by the Arena.
3. Settle. After a short block delay, anyone can settle. The contract derives randomness, computes both creatures' effective power, picks a winner probabilistically, pays out, and awards XP.
4. Cancel / expire. An unaccepted challenge can be cancelled to refund the challenger; stale challenges time out.

7.2  Effective power

Each creature's effective power against its specific opponent is computed from its element multiplier, its power and the opponent's defense, plus a flat speed edge:

Here multiplier is the attacker's type multiplier against the defender (200 / 100 / 50), and defense is the defender's defense stat. The trailing + 1 guarantees a strictly positive value, so every creature always has some chance.

7.3  Probabilistic outcome

Effective powers are combined into a win probability. With effective powers effA and effB:

A favored creature is likely — not guaranteed — to win, which keeps type advantage meaningful while preserving upset potential. A creature with a 2× type advantage and comparable stats wins the large majority of the time; an even matchup is close to a coin flip.

7.4  Randomness

The settlement roll is seeded from the hash of the settle block, with a fallback to prevrandao if the committed block has aged out of the 256-block window the EVM keeps available. The mandatory delay between locking and settling prevents either party from knowing the outcome at commit time.

7.5  Settlement & fees

On settlement the winner receives the combined pot minus a protocol fee (default 5%, hard-capped at 20%), which is routed to the Treasury. The winning creature is credited XP. The whole operation conserves $LMON exactly: pot in equals payout plus fee.

Battle-Forged Evolution

This is the mechanism the rest of the system exists to protect.

8.1  XP is a battle-only resource

Experience is awarded only to the winning creature of a settled battle — a base of XP_PER_WIN (100), with a +50% clutch bonus (150 total) when the winner triumphed from a type disadvantage. XP is attached to the creature, is never transferable, and can never be bought. There is no faucet, no daily reward, no airdrop of XP. If a creature has XP, it won battles for it.

8.2  Evolution spends XP

When a creature has accumulated at least its species' evolveXp, its owner may evolve it. Evolution consumes exactly that XP and changes the creature's species to the designated evolved form — typically a stronger, scarcer archetype with higher stats. Element is preserved across the line.

// once xp >= species.evolveXp
registry.evolve(creatureId);  // burns the XP, swaps species -> evolvesTo

8.3  A scarcity gradient earned by skill

Because XP only flows from victories, and victories require advantage or favorable variance against opponents who are also risking $LMON, the population of evolved creatures is gated by aggregate player skill and risk appetite rather than by spending. The clutch bonus deliberately rewards skilled play into bad matchups, nudging the metagame toward bold, well-read battling rather than safe farming. The result is an organic rarity curve: many base creatures, fewer evolved ones, and the rarest forms concentrated among the trainers who consistently win.

Economic analysis

9.1  Conservation

$LMON is conserved at every step. Recruiting moves tokens from a trainer to the Treasury. A battle moves both stakes into escrow, then out to the winner and (a fee) the Treasury. No code path mints or burns $LMON. The sum of all balances — trainers, Academy, Arena escrow, Treasury — is invariant at exactly 8,888 tokens.

9.2  No emissions, no dilution

Conventional play-to-earn games emit a reward token to attract players, then fight inflation with sinks. Liquimon emits nothing. Battle rewards are funded entirely by the opposing stake, so a winner's gain is a loser's loss — a true zero-sum transfer net of the Treasury fee. There is no dilution to defend against and no structural sell pressure from emissions.

9.3  The Treasury as recirculation

The Treasury is a sink-and-faucet, not a printer. It accrues recruit payments and battle fees and can disburse $LMON back into the ecosystem (e.g. to fund events, prizes, or liquidity programs) at the admin's discretion. Crucially, it can only ever move existing tokens; it cannot create them. Over time it concentrates a slice of activity, which can be recirculated to keep the game liquid without ever touching supply.

9.4  Equilibrium intuition

Because recruiting has a cost and battling is zero-sum with a small fee, casual churn slowly moves $LMON toward winners and the Treasury. This is by design: the token rewards skill and participation, not passive holding, and the fixed cap means the game's health is measured in activity rather than issuance.

Parameters

The launch configuration. Several are adjustable by the admin within hard-coded safety bounds; the token's supply and immutability are not adjustable by anyone.

Security considerations

10.1  Supply guarantees

The token has no mint, no burn, no owner, and no proxy. These guarantees are verifiable directly from the deployed bytecode — a holder need not trust the team to confirm that 8,888 is permanent.

10.2  Randomness

Battle settlement uses block-derived randomness (block hash, with a prevrandao fallback). This is appropriate for the stakes the game targets but is influenceable by a block proposer who is also a participant at sufficiently high value. The seed and resolution logic are isolated, leaving a clean path to integrate a verifiable randomness function (VRF) if higher-value play warrants it.

10.3  Permissionless settlement

Anyone can settle a locked battle after the delay. This removes the operator from the critical path: results cannot be withheld, censored, or front-run by a privileged settler, because there is no privileged settler.

10.4  Reentrancy & value movement

Contracts that move $LMON — the Treasury, Academy, and Arena — guard external entry points and follow checks-effects-interactions so state is finalized before transfers. The Registry performs no external token calls, so it carries no reentrancy surface.

10.5  Authorization model

Privileged actions are narrowly scoped: only the Academy may mint creatures, only the Arena may add XP, and only the admin may register species, set evolutions, set prices, and tune the fee within its cap. These roles are wired once at deployment.

Future work

The contracts are designed to be stable and immutable, so evolution of the game happens by adding species, tuning admin parameters, and building optional surfaces around the core — not by changing the rules underneath players. Directions under consideration, none of which alter the fixed supply or the earned-XP principle, include: verifiable randomness for high-stakes battles; richer multi-creature or seasonal formats layered on top of the Arena; expanded rosters and evolution lines; and community programs funded from the recirculating Treasury. Anything described here is directional, not a commitment or a timeline.

Disclaimer

Liquimon is an experimental, fully on-chain game. $LMON is a utility token for in-game actions — not an investment, a security, or a promise of returns. Nothing in this paper is financial, legal, or tax advice. Interacting with the contracts carries risk, including the total loss of staked tokens. Battle outcomes are probabilistic. On-chain randomness has known limitations described in §10. Review the open-source code, understand the mechanics, and verify all contract addresses before you transact. The Telegram link is a placeholder until launch and will be published from official channels.

Liquimon Whitepaper · v1.0 · This document describes intended mechanics and is subject to change before deployment.