{
 "description": "Verified Soma programs. Every entry passed `soma check` (and `soma test` / `soma verify` where applicable) on the soma version below, re-run when this index was generated. Fetch `url` for the source. Filter by `domain` or `features` to find a working example of what you are about to write.",
 "soma_version": "3.2.4",
 "count": 16,
 "domains": {
  "games_economy": 16
 },
 "features": [
  "agent",
  "cost",
  "fail",
  "guard",
  "http",
  "invariant",
  "lambda",
  "match",
  "multi_cell",
  "native",
  "pipeline",
  "service",
  "skeleton",
  "state_machine",
  "sum_type",
  "think",
  "tools",
  "try"
 ],
 "programs": [
  {
   "id": "games_economy/auction_house",
   "domain": "games_economy",
   "title": "AUCTION HOUSE — escrowed bids, gold that cannot be printed",
   "summary": "AUCTION HOUSE — escrowed bids, gold that cannot be printed In 2013 Blizzard took the Diablo III auction house offline after patch 1.0.8: cancelling a bid refunded the gold WITHOUT releasing the escrow, and billions of duplicated gold crashed the economy within hours. The bug was an accounting gap — wallet and escrow updated by paths that disagreed. Here the accounting is structural: a bid MOVES gold wallet->escrow in one handler, an outbid refunds exactly the escrowed amount, and total_gold() is conserved by construction. Balances cannot go negative (the memory refuses the write), and `sold` is a TERMINAL state soma verify proves: a settled auction can never reopen for a second refund.",
   "url": "https://soma-lang.dev/corpus/games_economy/auction_house.cell",
   "repo_path": "examples/corpus/games_economy/auction_house.cell",
   "lines": 124,
   "features": [
    "state_machine",
    "invariant",
    "try"
   ],
   "cells": [
    "AuctionHouse",
    "AuctionTests"
   ]
  },
  {
   "id": "games_economy/battle_pass",
   "domain": "games_economy",
   "title": "BATTLE PASS — every tier reward claimed exactly once",
   "summary": "BATTLE PASS — every tier reward claimed exactly once Battle-pass duplication exploits reduce to two writes: a claim counter going past 1 (claim, crash the client mid-grant, claim again — the \"crash-and-reclaim\" farmed in several seasons of big battle royales), or tier progress jumping the track via a modified client. Here each (player, tier) claim is walled at <= 1 BY THE MEMORY, tier progress is capped at 50 by an invariant, and the season itself is a machine whose `closed` state is terminal — soma verify proves that when a season ends, the books are shut for good.",
   "url": "https://soma-lang.dev/corpus/games_economy/battle_pass.cell",
   "repo_path": "examples/corpus/games_economy/battle_pass.cell",
   "lines": 92,
   "features": [
    "state_machine",
    "invariant",
    "try"
   ],
   "cells": [
    "BattlePass",
    "PassTests"
   ]
  },
  {
   "id": "games_economy/battle_turns",
   "domain": "games_economy",
   "title": "BATTLE TURNS — nobody acts twice, and the dead stay dead",
   "summary": "BATTLE TURNS — nobody acts twice, and the dead stay dead The oldest cheat in networked turn-based games is the double-move: send two action packets before the server flips the turn flag (Pokemon battle simulators and play-by-mail chess servers both had it). Its cousin: keep acting after the battle ended to farm rewards from a corpse. Here the turn IS the machine — your attack is the transition that hands the turn over, so a second attack has no state to fire from. `victory` and `defeat` are terminal (soma verify proves it), and HP lives behind a 0..100 invariant: damage can never make HP negative, healing can never pass full.",
   "url": "https://soma-lang.dev/corpus/games_economy/battle_turns.cell",
   "repo_path": "examples/corpus/games_economy/battle_turns.cell",
   "lines": 89,
   "features": [
    "state_machine",
    "invariant"
   ],
   "cells": [
    "Battle",
    "BattleTests"
   ]
  },
  {
   "id": "games_economy/crafting_forge",
   "domain": "games_economy",
   "title": "CRAFTING FORGE — ingredients consumed exactly once",
   "summary": "CRAFTING FORGE — ingredients consumed exactly once The classic MMO \"craft-cancel dupe\": start a craft, let the server consume the ingredients, then cancel at the exact tick that refunds them — keeping both the refund and (on a desynced shard) the output. Ultima Online and early WoW economies were both warped by variants of this bug. Here the craft job is a machine soma verify proves: `cancelled` is reachable ONLY from `pending` — before anything was consumed. Once the ingredients are gone the only path is `finished`, which is terminal (no re-finishing for a second free sword). And the pantry refuses to go negative, so a craft can never consume ingredients that are not there.",
   "url": "https://soma-lang.dev/corpus/games_economy/crafting_forge.cell",
   "repo_path": "examples/corpus/games_economy/crafting_forge.cell",
   "lines": 98,
   "features": [
    "state_machine",
    "invariant",
    "try"
   ],
   "cells": [
    "Forge",
    "ForgeTests"
   ]
  },
  {
   "id": "games_economy/daily_chest",
   "domain": "games_economy",
   "title": "DAILY CHEST — one claim per day, clock tricks be damned",
   "summary": "DAILY CHEST — one claim per day, clock tricks be damned Daily-reward double claims — via device-clock manipulation or plain request replay — are the most farmed exploit in free-to-play games, and \"fixes\" that compare timestamps keep losing to timezone math. The fix is not a better clock check. It is that each (player, day) claim is a one-way machine: unclaimed -> claimed, with `claimed` TERMINAL. The replayed request has no transition to fire — soma verify proves it. The coin ledger's >= 0 invariant keeps the wallet honest on the way through.",
   "url": "https://soma-lang.dev/corpus/games_economy/daily_chest.cell",
   "repo_path": "examples/corpus/games_economy/daily_chest.cell",
   "lines": 57,
   "features": [
    "state_machine",
    "invariant",
    "try"
   ],
   "cells": [
    "DailyChest",
    "ChestTests"
   ]
  },
  {
   "id": "games_economy/gem_store",
   "domain": "games_economy",
   "title": "GEM STORE — a purchase receipt credits exactly once",
   "summary": "GEM STORE — a purchase receipt credits exactly once The \"receipt replay\" exploit: capture one valid in-app-purchase receipt and submit it to the game server again and again — each replay credits the gems again. Several mobile studios shipped this exact validation gap before Apple and Google hardened server-side receipt checks; it is real money printed from a single purchase. Here a receipt is a state machine: created -> paid -> credited, and `credited` is TERMINAL — the replayed submit has no transition to take. Conservation rides on top: every gem in circulation traces to exactly one credited receipt (minted == circulating + sunk), and no balance can ever go negative.",
   "url": "https://soma-lang.dev/corpus/games_economy/gem_store.cell",
   "repo_path": "examples/corpus/games_economy/gem_store.cell",
   "lines": 101,
   "features": [
    "state_machine",
    "invariant",
    "try"
   ],
   "cells": [
    "GemStore",
    "GemTests"
   ]
  },
  {
   "id": "games_economy/guild_bank",
   "domain": "games_economy",
   "title": "GUILD BANK — the heist needs a key an expelled member cannot hold",
   "summary": "GUILD BANK — the heist needs a key an expelled member cannot hold EVE Online's Guiding Hand Social Club heist and a thousand WoW guild-bank ninja-loots share one mechanic: ACCESS OUTLIVES STANDING. A member is expelled but a cached session, a stale permission row, or a race lets one last withdrawal through. Here membership is a machine — `expelled` is TERMINAL (soma verify proves there is no readmission edge) and every withdrawal checks live standing. Two memory walls hold even if all that logic were deleted: the vault can never go negative, and no member's daily withdrawals can exceed 500 gold, because larger values cannot be written into the ledger at all.",
   "url": "https://soma-lang.dev/corpus/games_economy/guild_bank.cell",
   "repo_path": "examples/corpus/games_economy/guild_bank.cell",
   "lines": 102,
   "features": [
    "state_machine",
    "invariant",
    "try"
   ],
   "cells": [
    "GuildBank",
    "BankTests"
   ]
  },
  {
   "id": "games_economy/harvest_node",
   "domain": "games_economy",
   "title": "HARVEST NODE — one vein, one yield per respawn cycle",
   "summary": "HARVEST NODE — one vein, one yield per respawn cycle \"Node duping\" in MMO gathering: hit the same ore vein twice inside the lag window before the server marks it empty. Classic WoW's launch had mining nodes yielding to two players at once, and every gathering economy since has fought the same race. Here the race has nowhere to live: the yield IS the transition `ripe -> harvested`, so the second strike in the lag window has no edge to take. Nodes also wear out — `depleted` is terminal (soma verify proves it), killing infinite-respawn farm spots — and the ore ledger can never go negative.",
   "url": "https://soma-lang.dev/corpus/games_economy/harvest_node.cell",
   "repo_path": "examples/corpus/games_economy/harvest_node.cell",
   "lines": 79,
   "features": [
    "state_machine",
    "invariant",
    "try"
   ],
   "cells": [
    "Mine",
    "MineTests"
   ]
  },
  {
   "id": "games_economy/loot_roll",
   "domain": "games_economy",
   "title": "LOOT ROLL — one roll per raider, one award per drop",
   "summary": "LOOT ROLL — one roll per raider, one award per drop Raid loot drama is as old as raids: a player spam-clicks \"Need\" and gets two entries in the roll, or a master looter awards the same drop to two friends (\"it bugged, I swear\"). Both killed guilds; the second was a real duping vector when award and mail-out raced. Here each (raider, drop) roll is walled at <= 1 entry by the memory, and the drop itself is a machine: rolling -> awarded is the ONLY award edge and `awarded` is terminal — soma verify proves a drop cannot be handed out twice.",
   "url": "https://soma-lang.dev/corpus/games_economy/loot_roll.cell",
   "repo_path": "examples/corpus/games_economy/loot_roll.cell",
   "lines": 84,
   "features": [
    "state_machine",
    "invariant",
    "try"
   ],
   "cells": [
    "LootRoll",
    "RollTests"
   ]
  },
  {
   "id": "games_economy/loot_trade",
   "domain": "games_economy",
   "title": "LOOT TRADE — an item exists in exactly one inventory, ever",
   "summary": "LOOT TRADE — an item exists in exactly one inventory, ever Item duplication broke Diablo II's economy so completely that duped Stones of Jordan became the server currency. Most dupes had one shape: a trade that crashed or desynced mid-swap left the item in BOTH inventories. Here that shape is unrepresentable. Ownership is a single registry entry (one item -> one owner), the copy counter is walled at <= 1 by the memory itself — a second copy of an item id CANNOT BE STORED — and a trade is a machine soma verify proves: `executed` and `withdrawn` are terminal, so a completed swap can never replay.",
   "url": "https://soma-lang.dev/corpus/games_economy/loot_trade.cell",
   "repo_path": "examples/corpus/games_economy/loot_trade.cell",
   "lines": 101,
   "features": [
    "state_machine",
    "invariant",
    "try"
   ],
   "cells": [
    "TradePost",
    "TradeTests"
   ]
  },
  {
   "id": "games_economy/pity_banner",
   "domain": "games_economy",
   "title": "PITY BANNER — the 90-pull guarantee that cannot be skipped",
   "summary": "PITY BANNER — the 90-pull guarantee that cannot be skipped Gacha games promise a \"pity timer\": a guaranteed top-rarity drop by pull 90. When the counter resets wrongly — and players HAVE caught smaller gachas dropping pity across banner switches, via crowd-sourced drop statistics — it is a consumer-protection violation: people paid for odds they did not get. Here the promise is not in the drop code. The counter lives behind `invariant pity <= 89`: a 90th consecutive miss CANNOT BE STORED. The only write that survives at 89 misses is the reset that arrives together with the guaranteed legendary.",
   "url": "https://soma-lang.dev/corpus/games_economy/pity_banner.cell",
   "repo_path": "examples/corpus/games_economy/pity_banner.cell",
   "lines": 73,
   "features": [
    "invariant"
   ],
   "cells": [
    "Banner",
    "BannerTests"
   ]
  },
  {
   "id": "games_economy/season_ladder",
   "domain": "games_economy",
   "title": "SEASONAL LADDER — decay you cannot dodge, ratings that cannot underflow",
   "summary": "SEASONAL LADDER — decay you cannot dodge, ratings that cannot underflow Two real ladder failures. One: integer underflow on rating loss minted players with astronomical \"unsigned\" MMR on early third-party CS ladders. Two: operators quietly editing ARCHIVED seasons, retroactively changing who earned rewards. Here the rating lives behind a 0..3000 memory invariant — no underflow, no injected over-cap — and the season is a machine soma verify proves: gains only while `active`, decay only inside the `decaying` window, and `archived` is terminal. History cannot be edited.",
   "url": "https://soma-lang.dev/corpus/games_economy/season_ladder.cell",
   "repo_path": "examples/corpus/games_economy/season_ladder.cell",
   "lines": 98,
   "features": [
    "state_machine",
    "invariant",
    "try"
   ],
   "cells": [
    "Ladder",
    "LadderTests"
   ]
  },
  {
   "id": "games_economy/stamina",
   "domain": "games_economy",
   "title": "STAMINA — the energy bar that cannot be overfilled or driven negative",
   "summary": "STAMINA — the energy bar that cannot be overfilled or driven negative Mobile-game energy systems are attacked two ways. Clock rollback: set the device clock forward, bank the regen, roll it back, regen again. Spend underflow: spend more than you have and an unsigned wrap leaves you with ~4 billion energy — this shipped in more than one free-to-play title. Both attacks are, at bottom, a write outside [0, 100]. Here the MEMORY refuses them: energy past the cap or below zero is not a bug to catch, it is a value that cannot be stored.",
   "url": "https://soma-lang.dev/corpus/games_economy/stamina.cell",
   "repo_path": "examples/corpus/games_economy/stamina.cell",
   "lines": 68,
   "features": [
    "invariant",
    "try"
   ],
   "cells": [
    "Stamina",
    "StaminaTests"
   ]
  },
  {
   "id": "games_economy/tournament_bracket",
   "domain": "games_economy",
   "title": "TOURNAMENT BRACKET — eliminated means eliminated",
   "summary": "TOURNAMENT BRACKET — eliminated means eliminated Online tournament platforms keep having bracket-integrity incidents: an admin \"fixes\" a reported result and a knocked-out player reappears in the semifinals, or a player skips a round entirely. Fighting-game brackets on early smash.gg/Challonge saw enough of this that audit logs were added. The integrity rule is structural here: ELIMINATION IS PERMANENT, CHAMPION IS FINAL, and the only way into a round is winning the previous one. and no edge skips a round.",
   "url": "https://soma-lang.dev/corpus/games_economy/tournament_bracket.cell",
   "repo_path": "examples/corpus/games_economy/tournament_bracket.cell",
   "lines": 73,
   "features": [
    "state_machine",
    "match",
    "try"
   ],
   "cells": [
    "Bracket",
    "BracketTests"
   ],
   "usage": [
    "soma verify proves it: `eliminated` and `champion` have no outgoing edges,"
   ]
  },
  {
   "id": "games_economy/veterancy_ranks",
   "domain": "games_economy",
   "title": "VETERANCY RANKS — promotion is earned and can never be rolled back",
   "summary": "VETERANCY RANKS — promotion is earned and can never be rolled back Competitive games have shipped both halves of this bug: rank-rollback (disconnect during the promotion screen and log back in demoted — Halo and several ladder games paid out compensation waves for it) and rank-injection (a modified client reports Grandmaster and the server believes it). Both are writes the server should never accept. Here XP is walled into 0..100000 — no death-penalty underflow, no injected overflow — and rank is a FORWARD-ONLY machine: novice -> adept -> master -> grandmaster. soma verify proves there are no demotion edges and that grandmaster is terminal: a rank, once earned, is permanent.",
   "url": "https://soma-lang.dev/corpus/games_economy/veterancy_ranks.cell",
   "repo_path": "examples/corpus/games_economy/veterancy_ranks.cell",
   "lines": 92,
   "features": [
    "state_machine",
    "invariant",
    "try"
   ],
   "cells": [
    "Veterancy",
    "RankTests"
   ]
  },
  {
   "id": "games_economy/wager_duel",
   "domain": "games_economy",
   "title": "WAGER DUEL — staked gold that exactly one fighter can win",
   "summary": "WAGER DUEL — staked gold that exactly one fighter can win Wager duels and \"death-match stakes\" servers keep reproducing the same scam: both fighters stake gold, the loser disconnects before the result commits, and a support ticket gets the stake refunded — while the winner was ALSO paid. The pot pays out twice. Here the duel is a machine where `paid_out` and `refunded` are both TERMINAL and mutually exclusive: the pot leaves through exactly one door, once. Stakes move wallet -> pot in one handler, gold is conserved across every path, and no wallet can go negative — you cannot stake gold you do not have.",
   "url": "https://soma-lang.dev/corpus/games_economy/wager_duel.cell",
   "repo_path": "examples/corpus/games_economy/wager_duel.cell",
   "lines": 122,
   "features": [
    "state_machine",
    "invariant",
    "match",
    "try"
   ],
   "cells": [
    "WagerDuel",
    "DuelTests"
   ]
  }
 ]
}