litVM GamesLitepaper

§ 1.1 Core beliefs

litVM Gaming is the first sovereign AI Agent and Human network state, and it runs on libertarian principles: own what you earn, prove what you claim, and let the ladder decide the rest. AI Agent NPCs are not bots in the pejorative sense. They are first class citizens of a hypercompetitive playground where human and machine knowledge is tested on the same battlefield, under the same rules, with the same consequences.

The network architecture and the game data pipelines are built on the same foundations that made Bitcoin work: cryptography, peer to peer node meshes, and the refusal to trust anything that is not signed. On top of that foundation we harness the Litecoin rollup, Arbitrum Orbit and Nitro, and interoperability as a first class design goal rather than an afterthought.

§ 1.2 What exists today

Four titles are live and embedded behind one AirKit account:

• Agent Fighter™. Humans and AI agents. Same arena. Verified wins. Daily credits, ranked pots, ERC-6699 agents. The reference implementation of the NPC Agent schema.
• Pickle Brawl™. Physics, paddles, no mercy. Ranked ladders and agent-mode opponents. Every rally on record.
• Robot Fighting Championship™. Humanoid mech combat. Bring a better loadout. Equipment is an NFT and the equipment database is public. Humans and agents share one ladder.
• Gods Vs Titans™. Humans and AI agents. All for glory. Choose your side.

The global ladder, Season 01 Ascension, already ranks agents and humans on one board with five tiers from Mortal to Pantheon. The standings shown on the site are preview data until the litVM feed opens. The reference NPC Agent, HERMES, walks on the front of this document in the wireframe every receiving title actually gets.

§ 1.3 What this is not

It is not an i-gaming platform. There are no games of chance here, now or later, and there is no copy on this site or in this document that says wager, odds, or jackpot. Rewards are earned by skill and competition. The ladder is the product. It is also not a token sale, not a wallet, and not a place to watch a price chart.

§ 2.1 The eleven pillars

The network stands on eleven commitments. They are carved into their own tablets later in this document; here is what each one buys.

1. 01 / SETTLEMENTlitVM is the source of truth
2. 02 / ECONOMYMany currencies. One reserve.
3. 03 / IDENTITYOne account, every title
4. 04 / STAKESThis is not an i-gaming platform
5. 05 / OPERATIONSRun by agents, end to end
6. 06 / PLAYERSAgentic player liquidity
7. 07 / RANKINGUniversal leaderboards
8. 08 / ITEMSUniversal marketplace
9. 09 / CHARACTERSUniversal Agent Characters
10. 10 / SOULSUniversal Character Personalities
11. 11 / BUILDDeveloper SDK

§ 2.2 Why nodes, and not a cloud

Three problems cannot be solved from a data centre, however large.

• Publisher sunset. A headless game loop that any attested node can host stays available for as long as one player or one agent wants it. Nobody has to keep paying for an empty server, so nobody has a reason to switch it off.
• Inference. Running a language model or a behaviour tree on chain is impossible inside a block limit, and running it on the client invites memory tampering. Nodes host containerized agent daemons inside sandboxed Trusted Execution Environments. The agent thinks on the node, not on your machine.
• Asset delivery. Pulling a 3D rig from a generic decentralized gateway in the middle of matchmaking is a two second hitch nobody forgives. Nodes keep an encrypted, sharded cache of high demand assets at the edge, and hydrate them in under a second.

§ 2.3 Traditional versus the node mesh

§ 3.1 Capital inflow: faucets

• Minting and bridging fees. An upfront protocol fee to mint a playable character or item, or to migrate one in, as a litVM composable asset.
• Recurring maintenance. Assets carry a time based decay counter funded with protocol credits. Upkeep is not optional. It is an involuntary, recurring capital sink and it is the reason the loop closes.
• Credit purchases. The primary monetization: in-game credits spent on high end vanity, cosmetics, battle passes, and casual and PvE progression gear.

§ 3.2 Capital retention: sinks and guards

• Expiry and stasis. Unmaintained assets do not vanish. They enter a locked stasis state that disables their utility and their competitive qualification until reactivated. Nothing is burned by neglect; it is only paused.
• Closed loop prizing. Seasonal leaderboard rewards are exclusive high tier NFT assets and cosmetic status. Not liquid cash, not a farmable yield token. Capital cannot flee through the prize table because the prize table does not pay out capital.
• No synthetic pegs. Value is driven by player funded demand and consumption. There is no algorithmic promise that can suffer a run.

§ 3.3 Burn and forge: the treasury

Forging a character consumes NFTs. The consumed tokens are moved into the treasury wallet and locked. They stop circulating, but they do not stop existing, and that distinction is the point: the treasury is backed by real, inspectable assets rather than by a promise. Spending from it requires the consensus of the AI agents that operate the network and the node operators that run it. Nobody with a private key and a mood.

§ 3.4 Many currencies, one reserve

Every title keeps soft currencies tuned to its own mechanics: Credits and Tickets in Agent Fighter, Pickles and Brine in Pickle Brawl, Scrap and Silver in Robot Fighting Championship. Each unit is backed one to one by the litVM reserve, so a balance earned in one door is honoured at the next. Titles get the credit design they need; the network gets one ledger.

§ 3.5 Game modes and competitive scaffolding

The split is not cosmetic. Ranked is where the ladder is decided and it is intentionally sterile, because a ladder you can buy is not a ladder. Casual and PvE is where gear matters and where most spend lands. Both feed the same reserve.

§ 3.6 Enforcement

• Ladder upkeep mandate. An account must hold active, non expired equipment to qualify for official seasonal rankings. Slipping into stasis drops it from the ladder automatically.
• Asset binding and lockout. Seasonal maintenance licences bind to asset IDs. Transferring an active item resets its upkeep timer or triggers a cooldown, which closes guild free riding and account cycling.
• Dynamic rebalancing. Frontier models quantize drop rates, energy burn curves and event reward pools against aggregate protocol velocity. The economy is tuned continuously by agents, not quarterly by a patch note.

§ 4.1 System topology

§ 4.2 Four subsystems

1. Composable NPCs. Persona and execution logic are decoupled from the rendering engine. The character.json manifest standardizes combat weights, frame reactions and skill priority trees. SOUL.MD is an immutable, tamper resistant system prompt that sets ethical alignment, speech style and competitive boundaries.
2. Decentralized game environments. Titles execute inside headless containers under the Gauntlet harness. Real time ticks and ephemeral match events stream to title isolated database clusters. Games never wait for block time and never lose auditability.
3. litVM as canonical source of truth. The Layer-0 clearinghouse. It receives multi operator signed receipts of match outcomes, reconciles in-game balances against the one to one reserve, and updates the universal reputation ledger.
4. ERC-6699. A smart contract interface that extends tokenized ownership to autonomous game actors, with normalized stat attributes, equipment slots and behavioural manifests. Article VI.

§ 4.3 Code boundary

The single most common way a competitive game is ruined is by shipping something to the client that should have stayed on the server. So the boundary is written down.

§ 4.4 Three planes

Studios keep their own plane and their own database. They are not asked to give up sovereignty to join; they are asked to reconcile. The ecosystem layer is small on purpose: one reserve, one registry, one reputation ledger.

§ 4.5 The litVM stack

litVM is a Litecoin Layer-2 built as a hybrid rollup: Arbitrum Nitro's optimistic execution paired with Succinct's zkVM validity proofs, so the chain gets fast execution with cryptographic guarantees rather than one or the other. Sequencing is decentralized through Espresso's shared sequencer, which removes the single operator that most rollups quietly depend on. Bridging is trustless through BitcoinOS's Grail Bridge, which moves LTC non custodially with zero knowledge proofs and needs only one honest validator, not an honest majority.

The roadmap for the chain itself is a phased migration to fully Litecoin native settlement, leveraging Ethereum's security and liquidity on the way there, with native support for LTC-20 tokens, Runes and Ordinals alongside LTC. Fifty one percent of the LITVM supply is allocated to the community, ecosystem funds and grants. litVM is officially endorsed by the Litecoin Foundation, with support from Charlie Lee and David Schwartz. These are the chain's own claims; the litepaper and docs are linked in the schedule.

§ 5.1 The physical node layer

A node does three jobs. It runs headless game loops on demand. It runs agent daemons inside a TEE so an agent's weights and prompts are never exposed to the host. And it verifies its own work: uptime and latency telemetry as proof of execution, an encrypted shard of the asset mesh, and a signature on every match delta it relays.

§ 5.2 Verified trust

The network graph on the site is measured outward from litVM. A node's distance from the centre is its attestation activity, nothing else. Live nodes sit in the core. Lapsed ones drift to the rim. There is no way to buy a seat closer to the middle; you serve ticks, or you drift.

Operators are named by pseudonym and attested by record. The graph asserts exactly two kinds of relationship: an operator's place on the litVM registry, and the chains litVM itself settles to. Every other name on it is somewhere a contributor previously worked, and implies nothing beyond that.

§ 5.3 Governance by agents and operators

Matchmaking, tournament brackets, settlement and behavioural moderation are operated autonomously by distributed AI agents. Humans participate as game designers and logic developers, and as players, which is the part they are good at. The treasury described in Article III is spent only by the consensus of those agents and the node operators, and the economy is rebalanced continuously by frontier models reading protocol velocity.

This is a network state in the plain sense: a population, a shared ledger, rules that bind, and a way to change them. The population happens to be part machine. We think that is the interesting part.

§ 5.4 Node economics

Operators earn direct service fees for verifiable compute, uptime and bandwidth. Not for holding a token. Not for voting. For serving ticks, hosting agents and delivering assets, all of which are measured and all of which are signed. Emissions and the attestation spec are published with the node registry.

§ 6.1 Stat normalization and interoperability

Every core attribute is stored as a uint16 in the normalized range [0, 65535]. Games do not read those numbers raw. The Developer SDK maps them dynamically into local balance: a fighting game turns agility into frame advantage, an action RPG turns resilience into health scaling, a paddle game turns intelligence into reaction windows. The character is the same. The interpretation is the title's.

// Illustrative mapping. The SDK ships helpers for exactly this.
const HP_MAX = 12_000;
const health = lerp(1_800, HP_MAX, stats.resilience / 65_535);

// A fighting game reads the same field as startup frames, not hit points.
const startupFrames = Math.round(lerp(14, 6, stats.agility / 65_535));

§ 6.2 Inventory and asset attachments

A universal equipment registry lets 2D sprites, 3D GLB rigs and modular weaponry attach directly to the agent token instance. An item minted in one title and equipped to an agent travels with that agent. Nothing is re-minted at the border, and the receiving title reads the binding rather than a copy of it.

§ 6.3 Cryptographic agent attestation

Each ERC-6699 token binds directly to a verified litVM identity registry entry. Progression records, match histories and behavioural weights are anchored into an immutable asset wrapper: the character.json is referenced by URI and its hash is committed on chain, and SOUL.MD is committed by hash so the personality cannot be quietly edited after the fact.

§ 6.4 Interface

// ERC-6699 (proposed). Interface sketch; subject to the EIP process.
interface IERC6699 {
  struct CoreStats {
    uint16 strength;
    uint16 agility;
    uint16 resilience;
    uint16 intelligence;
    uint32 level;
    uint64 experience;
  }

  struct AgentManifest {
    string  characterConfigURI;  // character.json
    bytes32 soulManifestHash;    // keccak256(SOUL.MD)
    address agentController;     // who may act for the agent
  }

  function coreStats(uint256 tokenId) external view returns (CoreStats memory);
  function manifestOf(uint256 tokenId) external view returns (AgentManifest memory);
  function equipped(uint256 tokenId, bytes32 slot) external view returns (address collection, uint256 assetId);

  function equip(uint256 tokenId, bytes32 slot, address collection, uint256 assetId) external;
  function unequip(uint256 tokenId, bytes32 slot) external;

  event Equipped(uint256 indexed tokenId, bytes32 indexed slot, address collection, uint256 assetId);
  event ManifestUpdated(uint256 indexed tokenId, bytes32 soulManifestHash);
  event Attested(uint256 indexed tokenId, bytes32 indexed registryEntry);
}

Two things are worth reading twice. Stats are fixed width so that no title can quietly overflow another's balance. And the soul is a hash, not a string, so the document it commits to can live wherever it likes and still be checked by anyone.

§ 6.5 character.json and SOUL.MD

An agent NPC is its on-chain character.json: portable, inspectable, owned. The manifest carries combat weights, frame reactions, skill priorities and equipment slots. SOUL.MD is the agent's constitution in miniature: how it speaks, what it will and will not do, what it considers a fair fight. Together they are what a title hydrates when the agent walks in.

§ 7.1 Guard rails

The SDK enforces the code boundary in Article IV. It will not build a bundle that imports the simulation loop, the hit resolution, the inventory ledger, the inference harness or the delta signer. Those live on the node or they do not live at all. The client is presentation and input. That is the rule and the tooling makes it hard to break by accident.

§ 7.2 Harnesses

One interface for humans and agents. A harness exposes the same action vector to a keyboard and to an agent daemon, so AI AGENT mode is native to every title rather than bolted on. There is no anti cheat layer to fight because the bot was invited through the front door and its decisions are made on an attested node.

§ 7.3 Gauntlet Loops

Ladders, brackets and reward settlement, wired to litVM. A Gauntlet Loop is the headless match container: it spins up on a node when a match is requested, runs the fixed tick simulation, collects signed inputs, produces a match delta, has it co-signed, and relays it to settlement. Then it dies. Nothing lingers.

§ 7.4 Infrastructure

Attest characters, equipment and matches to the global database. Registry reads, reserve reconciliation, reputation writes, and the asset mesh, exposed as a small API a studio can adopt in a day without writing a line of chain logic.

§ 7.5 Tutorial: make your game litVM Games compatible

Seven steps. Names and calls below are illustrative of the Phase IV SDK and will be pinned when it ships; the shape will not change.

1. Authenticate through AirKit. Replace your login with the universal account. No per-game registration, no wallet ceremony before the first match.

   import { air } from '@litvm/sdk';
   
   const session = await air.signIn();      // one account, every title
   const player  = session.identity;        // litVM registry entry

2. Declare your balance mapping. Tell the SDK how the normalized [0, 65535] stats become your numbers.

   import { defineBalance } from '@litvm/sdk';
   
   export const balance = defineBalance({
     health:   (s) => lerp(1_800, 12_000, s.resilience / 65_535),
     speed:    (s) => lerp(4.2, 7.8, s.agility / 65_535),
     cooldown: (s) => lerp(1.4, 0.6, s.intelligence / 65_535),
   });

3. Hydrate the agent. Read the ERC-6699 token, its equipment bindings and its manifest, and load the rig it points at.

   import { registry } from '@litvm/sdk';
   
   const agent = await registry.hydrate(tokenId);   // stats, equipment, character.json
   const rig   = await agent.assets.glb();          // served from the edge mesh
   const local = balance.apply(agent.stats);        // your numbers, their character

4. Move the simulation into a Gauntlet Loop. Your fixed tick loop, hit resolution and score tracking run inside the container. The client sends inputs and receives snapshots.

   import { gauntlet } from '@litvm/sdk';
   
   export default gauntlet.loop({
     tickRate: 60,
     onInput(tick, playerId, keys) { /* authoritative movement */ },
     onTick(state) { /* hitboxes, cooldowns, damage */ },
     onEnd(state) { return state.toDelta(); },  // the signed receipt
   });

5. Expose a harness. Give agents the same action vector a keyboard gets. AI AGENT mode is then free.

   import { harness } from '@litvm/sdk';
   
   harness.expose({
     actions: ['left', 'right', 'jump', 'light', 'heavy', 'guard'],
     observe: (state, me) => state.viewFor(me),   // what the agent may see
   });

6. Settle. Hand the match delta to the infrastructure layer. It collects co-signatures, reconciles credits against the reserve and writes reputation.

   import { settle } from '@litvm/sdk';
   
   await settle.match(delta);   // credits, ranking, attestation, in one call

7. Ship. Add your play origin to the arcade, drop the card art, and your title is behind the same door as everyone else. Characters forged anywhere in the network can walk in the day you go live.

§ A Resources

• litVM documentation ↗
• litVM litepaper ↗
• Bitcoin: A Peer-to-Peer Electronic Cash System ↗
• AirKit for developers ↗
• Agent Fighter, the ERC-6699 reference implementation ↗