Docs · Donut Strategy

Overview

What this project is, which parts of it are real, and how to read the rest of these chapters without mistaking a design assumption for a fact.

Donut Strategy: Galactic Stock Fleet is a game concept. A commander crews a fleet of hulls, spends $DONUT as fuel to launch expeditions into four sectors modelled on real equity behaviour, and reads back what a month of that would produce. This site is the working artefact of that concept: a marketing surface, a document of record, a simulator that runs the model live rather than quoting figures somebody typed into a slide, and — at /play — a small playable version of the loop, where expeditions run for real hours and the state behind them is kept on a server.

These docs are the deep reference. They exist so that a contributor can rebuild the engine from the formulas, check every constant against the value the code actually holds, and see exactly which claims rest on research that has been checked and which rest on somebody else's word. Where the marketing pages summarise, this document states.

What is not real

Nothing described here is deployed, audited, funded or agreed. No token exists, no contract is live, no pool exists, and no NFT has been minted. Targeting a chain is a design decision, not a deployment. The launchpad named in the design exists as a business and has no agreement of any kind with this project. Every number in these chapters is output from a model whose constants are still being balanced — simulation, never forecast, and never a return anyone should expect.

What is real

The code is real: the engine in src/lib/economy.ts, the constants it reads, and the simulator that runs them in the browser. So is the played game — /play stores real rows in a real database, and chapter 03 says which ones, because a reader should learn that from the documentation rather than deduce it. The research in src/lib/chain.ts is real, was carried out on 2026-09-07, and each item carries the status it earned. This document is generated from all of it, so it cannot quietly disagree with any of it. None of that makes the fuel a token: it comes from a faucet the game runs, and nothing a commander accumulates is an asset or convertible to one.

How to read these chapters

—Every figure printed here is imported from src/lib or produced by calling the engine. If a value looks wrong, the constant is wrong — not the sentence.
—Formulas carry a reference — F1 through F10 — and appear in the order the engine evaluates them. Chapter 04 states each one in words and as an expression, then works two examples end to end.
—Researched claims carry a verification status. Verified means read from a primary source or checked directly. Reported means somebody stated it and nobody has independently checked it. Unresolved means it could not be established, and is shown as unknown rather than assumed false.
—A status is never upgraded to make a sentence read better. If a chapter needs a claim it cannot support, the chapter says so instead.
—Chapter 12 states the rules this project's copy must hold to. A contributor writing new surfaces should read it before writing anything.

Document

Versionv0.1 — DRAFT

RevisionREV 12

Research date2026-09-07

Litepaper sections12

Issued atgdonut.com

Quickstart

Install, run, build, and know what a clone actually needs — including the database and the signing secret the played game does not work without.

The site is a Next.js App Router project on React 19 and Tailwind v4. Most of it is arithmetic in process: the landing document, the fleet and sector references, the litepaper, the simulator and these chapters compute every figure they print from the files under src/lib, fetch nothing and store nothing. Those pages do run offline.

The played game does not, and it is the reason this chapter has an environment table. /play keeps commander state on a server — Postgres in the deployment, a JSON file under .data/ on a laptop — reached through the route handlers under /api/play, and every figure a commander sees is decided there rather than in the browser. Playing writes to that server. Chapter 03 sets out exactly what is written and which of it is public.

Commands

Read from the scripts block in package.json. Node 20 or newer. The build type-checks, so a type error is a failed build rather than a surprise in production.
Command	What it does
npm install	Installs dependencies. Node 20 or newer.
npm run dev	Development server with hot reload, on the default Next.js port. With no database URL set it writes to .data/ and says so on the first line of the log.
npm run build	Production build. Type errors fail the build.
npm start	Serves the production build. Without a Postgres URL or PLAY_SECRET the reference pages still serve and every play route faults; /api/play/health says which one is missing.
npm run lint	ESLint across the project, using the flat config in eslint.config.mjs.
npx tsc --noEmit	Type check on its own, without a build.

Environment

What the deployment reads, as the code actually reads it. The first two are required in production: without them the played game faults on every request rather than quietly running on something that would lose every fleet. The rest change what a surface will show, never what it stores.
Variable	Needed	What it does
DATABASE_URL	Production	The Postgres connection string. Four other names are accepted and read in this order — POSTGRES_URL, POSTGRES_PRISMA_URL, POSTGRES_URL_NON_POOLING, NEON_DATABASE_URL — because a host injects a different one depending on how the database was attached. Absent in development means the JSON file store under .data/. Absent in production is a refusal, not a fallback.
PLAY_SECRET	Production	One key, five jobs: it signs the session cookie, seeds the expedition roll, derives the world day's flags, derives the commander plate and digests recovery codes. Unset in development it falls back to a constant that ships in the source and protects nothing; unset in production the game refuses to start. Rotating it retires every session, every plate and every recovery code at once.
STATS_TOKEN	Optional	The ?key= that opens /stats and /api/stats. Compared in constant time. Unset, development may read them and production answers 404 — an unconfigured production is a mistake, and the safe reading of a mistake is that nobody was meant to look.
STATS_PUBLIC	Optional	Set to true, the aggregate numbers are open to anybody with no key. They stay aggregates: no commander, no plate, no id, and no figure describing fewer than five commanders.
NEXT_PUBLIC_SITE_URL	Optional	The origin absolute share links are built on when the caller cannot supply one from the request's own headers. Falling back further: the browser's location, then the project domain — so a preview deployment shares preview links rather than production ones.

FIG. 2.1What the deployment reads, as the code actually reads it. The first two are required in production: without them the played game faults on every request rather than quietly running on something that would lose every fleet. The rest change what a surface will show, never what it stores.

The production guard, and why it refuses rather than degrades

With no Postgres URL under any of the names it checks, the store falls back to a JSON file in development and throws in production. That is deliberate: a serverless filesystem is read-only apart from a temporary directory that does not survive between invocations, so a production fallback would not degrade gracefully — it would hand every player a 500 and lose every fleet, for a reason nothing in the log would name. PLAY_SECRET throws on the same principle: with the development constant, which ships in this repository, anybody could mint another commander's cookie and compute whether a launch is lost before paying for it. /api/play/health exists so the two failures can be told apart from outside, and it reports the variable NAME it found rather than the URL, the host, the credentials or the secret.

Where things live

The top level of the tree, in the order a contributor meets it. Everything under src/server, and the one module in src/lib carrying a SERVER ONLY banner, must never be imported from a client component.
Path	Contents
src/app	Routes. One directory per page, plus the route handlers under src/app/api, layout.tsx and globals.css.
src/app/api	The route handlers: /api/play/* is the game, /api/card/* renders the share sheets, /api/stats serves the aggregate numbers.
src/app/globals.css	The whole design system: tokens, type primitives, plates, ledger tables, hatches, buttons, motion.
src/lib	Data and arithmetic. No JSX, no React and no browser APIs, with two exceptions that declare themselves in their first lines: share.ts reads the public site-URL variable, and handle.ts reaches the server layer for the signing key.
src/server	The played game's server half: the rules, the shared day, the flight orders, the session cookie, recovery, the aggregate metrics and the store. Everything that reads a secret or writes a row is here.
src/server/schema.sql	The database, written out canonically and commented. It is the file to read to find out what is stored.
src/components/ui	The primitive kit every page composes from.
src/components/marks	Drawn marks — ship silhouettes, captain patches, sector hatches, the bite meter.
src/components/<feature>	Feature components, one directory per area of the product.
.data	Where the development file store writes. Gitignored, local, one Node process, and never used in production.

Adding a page

01Put the content and any arithmetic in src/lib. A component that computes a figure is a bug in this codebase.
02Build the page as a Server Component. Add "use client" only to the leaf that genuinely needs state or an effect.
03Anything that reads PLAY_SECRET, a database URL or the store belongs under src/server, behind a route handler or a server component. Those modules open with a SERVER ONLY banner and must never be imported from a client component.
04Compose from src/components/ui rather than restyling a div. If a primitive is missing, add it to the kit instead of inlining it once.
05Register the route in src/lib/nav.ts with the next plate index, so the header rail and the stacked menu both pick it up.
06If the page stores anything, say so where a reader will see it, and add the row to the table in chapter 03. A surface that writes without saying so is the one defect this project cannot absorb.
07Run the type check and the linter before committing. Both are expected to pass clean.

Architecture

11 page routes and 15 route handlers over four layers — lib, server, components, routes — a single rule holding them apart, and a plain account of what playing writes to the server.

The system is a four-layer stack. The lib layer holds the domain: types, constants, the modelled engine, the played game's rules, the researched facts, the copy and the formatting. The server layer holds what a browser may not — the signing secret, the shared day, the store, and every write. The component layer renders what it is handed. The route layer composes components into a page, or, under src/app/api, is a handler that reads a request, calls the server layer and answers with JSON or an image. Only the server layer touches the database, and it is reached from route handlers and server components alone.

The rule that keeps this honest

A component never computes a figure and never types one. It reads from src/lib, or from what the server answered, and formats through src/lib/format.ts. The moment a percentage is typed into JSX, two surfaces can disagree about the same number and the site becomes untrustworthy in a way no reader can detect. This is the one architectural rule that is not negotiable — and on the play board it is also the security property, since a figure computed in the browser is a figure the browser can edit.

Page routes

Every route that renders HTML — 11 of them, counted from the table rather than typed into a sentence that could drift away from it. Four arrived with the played game: /play is the game itself, /today is the public day report, /c/<plate> is one commander's public standing, and /stats is private by default.
Route	File	What it carries
/	src/app/page.tsx	The landing document: lore, the loop, the split, and the standing disclaimer.
/play	src/app/play/page.tsx	The played game. The first nav item and the only page behind a session: it renders a thin shell, and every action on the board goes to a handler below that writes.
/fleet	src/app/fleet/page.tsx	Hulls and captains, with the spec tables and the synergy matrix.
/nebulae	src/app/nebulae/page.tsx	The four sectors, the session clock, the oracle rules and the raid drop table.
/simulator	src/app/simulator/page.tsx	The fleet simulator, run entirely in the browser. It stores nothing and asks the server for nothing.
/burn	src/app/burn/page.tsx	The supply side: the split bar, the deflation table and the dead address.
/litepaper	src/app/litepaper/page.tsx	The document of record, 12 sections.
/docs	src/app/docs/page.tsx	This reference. Renders the chapters in src/lib/docs.ts and computes nothing.
/today	src/app/today/page.tsx	The public day report: one world day summed across every commander, naming nobody. What the day card unfurls back into.
/c/[handle]	src/app/c/[handle]/page.tsx	One commander's public standing, by derived plate. Reads no cookie and mints no identity.
/stats	src/app/stats/page.tsx	Aggregate retention for whoever runs this. Private by default: without the key it answers 404 rather than announcing itself.

FIG. 3.1Every route that renders HTML — 11 of them, counted from the table rather than typed into a sentence that could drift away from it. Four arrived with the played game: /play is the game itself, /today is the public day report, /c/<plate> is one commander's public standing, and /stats is private by default.

Route handlers

The 15 handlers under src/app/api. Every play handler acting for a commander takes their id from the signed cookie and never from the request body, and every one of them decides the figures itself: a body may name a choice — which hull, which sector, which captain — and never a price, a tier, a risk or an outcome.
Handler	File	What it does
GET /api/play/state	src/app/api/play/state/route.ts	The whole board, and the only endpoint that mints an identity. Settles everything that landed while the commander was away.
POST /api/play/claim	src/app/api/play/claim/route.ts	The daily fuel allowance. Takes no body: the amount and the interval are the server's.
POST /api/play/hull	src/app/api/play/hull/route.ts	Commission one hull. The body names a class; the price is read server-side.
POST /api/play/launch	src/app/api/play/launch/route.ts	Dispatch one hull. Three choices — hull, sector, captain. Fuel, risk, flight time and refit are the server's.
POST /api/play/refit	src/app/api/play/refit/route.ts	Buy the next refit tier for one hull. A request cannot name a tier, a price or an effect.
GET, POST /api/play/orders	src/app/api/play/orders/route.ts	Today's 3 flight orders, and the claim on a finished one. The board is the world day's and is identical for everyone.
GET /api/play/leaderboard	src/app/api/play/leaderboard/route.ts	The burn ranking. Public, names commanders by derived plate, and does not mint an identity for whoever reads it.
GET, POST /api/play/recovery	src/app/api/play/recovery/route.ts	Whether this commander holds a recovery code, and minting one. The code is printed once and never stored.
POST /api/play/restore	src/app/api/play/restore/route.ts	Re-attach a browser to a fleet from a code. Every attempt is counted before the code is looked at, and one refusal covers every failure.
GET /api/play/health	src/app/api/play/health/route.ts	Which store the running build chose and which variable name it read it from. Never the URL, the host, the credentials or the secret.
GET /api/card/site	src/app/api/card/site/route.tsx	What the domain unfurls into. Static, carries the terms rather than a pitch.
GET /api/card/day	src/app/api/card/day/route.tsx	The day report as a sheet. The one artefact this project can post daily without writing anything.
GET /api/card/commander/[handle]	src/app/api/card/commander/[handle]/route.tsx	A commander's standing as a picture — exactly the figures the burn ranking already publishes, and no more.
GET /api/card/expedition/[id]	src/app/api/card/expedition/[id]/route.tsx	One settled docket as a picture, so the artefact the game produces can leave the browser that produced it.
GET /api/stats	src/app/api/stats/route.ts	The aggregate snapshot as JSON, behind the same 404 gate as /stats.

FIG. 3.2The 15 handlers under src/app/api. Every play handler acting for a commander takes their id from the signed cookie and never from the request body, and every one of them decides the figures itself: a body may name a choice — which hull, which sector, which captain — and never a price, a tier, a risk or an outcome.

Playing writes to a server

Everything on the reference side of this site is computed in the process that renders it and stored nowhere; a reader of those pages leaves no trace on any database. /play is not like that, and a reader should learn it here rather than infer it. A visitor who launches is handed a commander id in one signed httpOnly cookie, and a row is written for that id: the fleet, the fuel balance, every expedition and its outcome, the running burn total, the day's order progress, and one coarse last-seen stamp. There is no email, no password, no wallet, no address and no personal data anywhere in it — and nothing stored is a token, an asset or convertible to one, since the fuel it counts comes from a faucet the game runs itself.

What playing writes, and what of it is public

One row per thing the store holds, from src/server/schema.sql. Public means a stranger can read it without a session: the burn ranking and /c/<plate> publish it, the day report sums it across everybody, or the aggregate sheet counts it. Anything marked No is readable only by the browser holding that commander's cookie.
Stored	Written when	Public
Commander id	The first request that mints an identity — a state read, a claim, a launch. A UUID in one httpOnly signed cookie, so the browser holds it and cannot choose it.	No
Fleet	Every hull commissioned or refitted, as JSON on the commander's row.	Count only
Fuel balance	Every allowance claim, launch and purchase.	No
Expeditions	One row per launch, written at departure and updated once at settlement with its outcome. An outcome is never rewritten.	By plate
Burn total, launches, losses	Settlement. The burn total is the number the public ranking sorts on and the number that unlocks captains.	Yes
Flight-order progress	Settlement, and the claim on a finished order. The orders themselves are not stored — they are drawn from the day.	No
Last seen	A state read, and at most once an hour per commander. One integer, and the whole of what this database records about visiting.	Aggregate only
Recovery digest	Only if a commander asks for a way back. HMAC(PLAY_SECRET, code) — the code itself is never stored, so nothing here can be turned back into one.	No
Restore attempts	Every attempt to restore a fleet from a code, counted against the browser making it before the code is looked at.	No

FIG. 3.3One row per thing the store holds, from src/server/schema.sql. Public means a stranger can read it without a session: the burn ranking and /c/<plate> publish it, the day report sums it across everybody, or the aggregate sheet counts it. Anything marked No is readable only by the browser holding that commander's cookie.

What is public is public under a derived plate

The two surfaces that name a commander name them the same way: HMAC(PLAY_SECRET, "plate:<id>") truncated to six hex characters and printed as CMD-XXXXXX. The derivation is one-way — a plate can be computed from a commander id, and an id can never be recovered from a plate — and it carries no session value, which is what makes it safe on an image anybody can paste anywhere. The burn ranking prints it for the top of the board. /c/<plate> is a page about one commander showing the same figures the ranking already publishes, plus the last several settled dockets; it reads no cookie and mints no identity, so a visitor arriving there is a reader and does not become a player by looking. /today sums a world day across every commander and names nobody. /stats is aggregate, private by default, and withholds any figure describing fewer than five commanders. Rotating PLAY_SECRET rotates every plate along with every session.

The lib layer

Every module under src/lib. None of them imports React, and two declare in their first lines the one thing they do beyond arithmetic: share.ts reads the public site-URL variable and the browser's own location so a preview deployment shares preview links, and handle.ts reaches the server layer for the signing key the commander plate is derived under.
Module	Responsibility
src/lib/types.ts	Domain shapes. Every number reaching the screen originates in one of these types.
src/lib/constants.ts	Design constants. The single place a tunable figure of the modelled game is allowed to live.
src/lib/economy.ts	The engine: the ten formulas, the fleet simulation, the burn projection and the presets. Answers what a month would produce, on average.
src/lib/play.ts	The played game's rules and its own dials: one expedition resolved once, integer centi-DONUT money, the faucet, hull prices, refit tiers and the flight orders. Pure — it holds no state and reads no secret.
src/lib/ships.ts	The three hull specs and their lookup.
src/lib/captains.ts	The three captain specs, plus the uncrewed baseline.
src/lib/nebulae.ts	The four sector specs and the hatch class map.
src/lib/oracle.ts	Session state in the session's own zone, the oracle rules and the sample tape.
src/lib/chain.ts	Researched chain and market-structure facts, each carrying a verification status.
src/lib/copy.ts	Shared site copy, the microcopy strings and the standing disclaimer.
src/lib/litepaper.ts	The document of record, as section data.
src/lib/docs.ts	These chapters.
src/lib/share.ts	Share links and share text, and the note that every composed line ends with. Pure, and imported by client components, so it may not touch a secret, the store or a commander id.
src/lib/handle.ts	SERVER ONLY. The commander plate: one derivation, used by the ranking, the cards and the public page alike.
src/lib/format.ts	Every figure on screen passes through here before it is printed.
src/lib/nav.ts	The primary navigation list and the external links.
src/lib/devnet.ts	A local development chain, described honestly as a thing we alone operate. Nothing in the deployed site renders it today.

FIG. 3.4Every module under src/lib. None of them imports React, and two declare in their first lines the one thing they do beyond arithmetic: share.ts reads the public site-URL variable and the browser's own location so a preview deployment shares preview links, and handle.ts reaches the server layer for the signing key the commander plate is derived under.

The server layer

Everything that reads a secret, writes a row, or decides an outcome. Each module opens with a SERVER ONLY banner naming what it reads, so an import from the wrong side of the boundary is visible at the top of the file rather than three levels down a call.
Module	Responsibility
src/server/session.ts	Who is flying: the signed httpOnly cookie, the commander id inside it, and the HMAC every other derived value in the game is built on.
src/server/game.ts	The rules applied to stored state: claim, buy, launch, refit, settle. Every figure a commander sees is decided here, never in the browser.
src/server/world.ts	The shared day. Whether the session closed green and whether Hyper-Boost armed are properties of the date, derived from a keyed hash rather than fetched from a market.
src/server/orders.ts	The day's 3 flight orders and a commander's progress against them. The board is the world's; the progress is the commander's.
src/server/recovery.ts	The way back to a fleet: a code minted, shown once, and stored only as a digest. No email, no password, nothing that turns a session into a person.
src/server/metrics.ts	Aggregate retention, and the gate on it. No identifier reaches this module, and no figure describing fewer than five commanders leaves it.
src/server/store	The persistence contract and its two implementations, plus the codec every value crosses on the way in and out.
src/server/schema.sql	The database written out canonically. postgres.ts issues the same statements at startup, so a deploy needs no migration step.

FIG. 3.5Everything that reads a secret, writes a row, or decides an outcome. Each module opens with a SERVER ONLY banner naming what it reads, so an import from the wrong side of the boundary is visible at the top of the file rather than three levels down a call.

One store interface, two implementations

src/server/store defines a single persistence contract and implements it twice: Postgres for the deployment and a JSON file under .data/ for a laptop. Nothing above that layer knows which one it is talking to, so moving from a laptop to a host is setting one environment variable. The file store writes atomically and serialises its writes, because a dev server runs requests concurrently and two overlapping saves would otherwise race — but it is a development store, it assumes one Node process owns the directory, and production refuses it outright rather than running on it. Everything crossing the boundary in either direction goes through the codec, so a value that is not an exact integer, a known hull, a known sector or a known captain is rejected at the edge rather than stored and believed later.

The component layers

Directories under src/components, and the one sentence that governs all of them: they lay out what they are handed. The play directory is the newest and the strictest about it, because what it is handed came from the server.
Directory	Contents
src/components/ui	Primitives: Plate, SectionHeading, PlateCaption, StatTile, Badge, ActionButton, LeaderRow, Stepper, SegmentedControl, ScrollRegion, CopyableAddress.
src/components/marks	Drawn marks: ShipMark, CaptainPatch, BiteMeter, SectorHatch. Pattern and rule, never colour alone.
src/components/site	The frame: header, footer, tape rail, theme script.
src/components/chain	StatusBadge — the one place a verification status becomes a colour.
src/components/play	The flight desk: the board, the roster, the launch rail, the orders panel, the receipt feed, the ranking and the recovery panel. It renders the server's answer and computes no figure of its own.
src/components/share	ShareRow — the link, the text and the card behind one docket or one day.
src/components/ships, captains, nebulae, burn, simulator, litepaper, docs	Feature components. They lay out what lib hands them.

FIG. 3.6Directories under src/components, and the one sentence that governs all of them: they lay out what they are handed. The play directory is the newest and the strictest about it, because what it is handed came from the server.

Client boundaries

—The simulator is one substantial client component tree: it holds fleet state, re-runs the engine on every change and prints the docket. It stores nothing and asks the server for nothing.
—The play board is the other. It holds no figures of its own: it fetches the whole board from /api/play/state, posts a choice, and re-renders from what the server answered. Nothing about a balance, a fleet or an outcome is computed in the browser.
—The header is a client component because it owns the theme toggle and the stacked menu; the theme itself is written to the document element before paint by a small inline script, so the first frame is never the wrong colour.
—Navigation rails with scroll-spy — the litepaper contents and the docs rail — are client components wrapping an IntersectionObserver. They mark the active section and do nothing else.
—Everything else renders on the server. The reference pages have nothing to await and are static in practice; /play, /today, /c/<plate>, /stats and every handler that reads the store are declared dynamic, because a cached answer there would be a wrong one. The site card is the exception and is declared static, since it carries the terms rather than any figure.

The model

Every formula in the engine, stated in words and as an expression, in the order it is evaluated — then two examples worked end to end by calling the engine itself.

The engine runs in expected-value mode. There is no randomness anywhere in it, so the same fleet always prints the same docket, and every figure below is an average across many launches rather than the outcome of any single one. A commander does not experience an average.

F1Supply index

supplyIndex = clamp(float ÷ 350,000,000, 0.05, 1.00)

The circulating float divided by the initial float, clamped at both ends. It starts at 1.00 and falls as fuel is burned. Every fuel bill is multiplied by it, so a shrinking float makes launching cheaper — the loop that makes flying the deflation mechanism rather than a side effect of one. The floor stops a heavily burned float from driving fuel cost to nothing.

F2Fuel per launch

fuel = fuelBase × (1 + volatility × surchargeCoeff) × captainFuel × supplyIndex

The hull's base fuel, surcharged by the sector's volatility at the hull's own coefficient, adjusted by the captain, then scaled by the supply index. Volatility is charged here and again in F4, which is the central honesty of the map: a violent sector costs more to enter and returns less of what it produces. The Bull's discount is conditional on a green close, so the engine weights it by the scenario's green-day frequency rather than applying it in full — under the flat scenario that is 0.50 of the headline discount.

F3The fixed split

burned = fuel × 0.70 · dividendPool = fuel × 0.20 · treasury = fuel − burned − dividendPool

Every payment of fuel splits 70% to the dead address, 20% to the dividend pool and 10% to the treasury. The split is fixed by design: no hull, captain, sector or flight window changes it. The treasury slice is computed as the remainder rather than as a third multiplication, so the three parts always sum to exactly the fuel paid.

F4Pirate risk

pFail = min(0.49, max(volatility × 0.38 × defenseFactor × afterHoursRisk, afterHoursFloor))

The probability an expedition is lost. Sector volatility is the driver; the captain's defence factor scales it — the Bear halves it — and flying after the bell multiplies it by 1.35. Outside the session a floor of 12.0% applies, and in a quiet sector that floor binds long before the multiplier does: an unescorted launch in SPY Galaxy fails 3.0% of the time during the session and 12.0% of the time after it. Everything is clamped at 49.0%, and nothing on the board reaches that clamp: the worst case in the game is an unescorted launch into MSTR Void after the bell, which the after-hours multiplier takes to 48.7% — a hair under it.

F5Salvage and survival

survival = 1 − (1 − 0.20) × pFail

A lost expedition is not a total loss: 20.0% of its cargo comes back as salvage. So the expected haircut on everything harvested is 80.0 percent of the failure probability, not the failure probability itself. In the Void, an unescorted session failure rate of 36.1% costs 28.9% of the haul rather than all of it.

F6Bonuses and aura coverage

bonus = 1 + rewardBonus × greenFrequency + 0.20 × auraCoverage

Additive, deliberately, so that stacked modifiers cannot compound into nonsense. The captain's reward bonus is weighted by the green-day frequency because only the Bull's is conditional. Aura coverage is a fraction rather than a flag: each Dreadnought lifts 8 other hulls, the slots are allocated to the lines that gain most from them, and a line of twenty hulls handed eight slots is covered 0.40 and draws 0.20 times that. A fleet can never draw more aura than it bought, and a flagship flown beside too few hulls is running idle slots — the simulator says so in words when it happens.

F7Reward per launch

rewardUnits = sessionLaunches × survivalSession × boostFactor + afterHoursLaunches × survivalRaid
fragmentsUsd = fragmentBaseUsd × fragmentMod × yieldMultiplier × bonus × rewardUnits
longTokens = longBase × cruiserGap × yieldMultiplier × bonus × rewardUnits

Both reward streams run through the same chain: a base value, the hull's own modifier, the sector's yield multiplier, the bonus term, and the survival-weighted count of launches. Hyper-Boost enters as boostFactor and only in NVDA Sector, pro-rated across the number of qualifying sessions in the month: a full month of qualifying closes would pay 2×, and a month with none pays 1. The cruiserGap term applies to the Arbitrage Cruiser alone and equals 1 plus volatility times 0.60, the only place in the model where a payout rises with chaos — 1.57 in the Void against 1.05 in the index. The Harvester earns no $LONG at all.

F8Launches per month

cycle = flightHours + refitHours
sessionOnly: floor((136.5 ÷ cycle) × sessionFactor)
allHours:    floor((24 ÷ cycle) × uptime × 30)

Cycle time, not wallet balance, is the real constraint on a fleet. A session-only fleet divides the 136.5 session hours in a month by the cycle and keeps 90.0% of it, on the assumption that nobody works the whole bell. A round-the-clock fleet divides the day by the cycle and keeps the commander's uptime, between 10% and 60%. The Quant AI Pilot replaces uptime with its automation floor of 77.5% and removes the session-only penalty, which is the whole of what it buys. Of an all-hours fleet's launches, 81.0% land outside the session — a derived consequence of 6.5 session hours on 21 of 30 days, not a setting anyone chose.

F9Parts and tickets

engineParts = enginePartChance × (sessionLaunches × (1 − pFailSession) + afterHoursLaunches × 3 × (1 − pFailRaid))
plasmaCannons = engineParts × 0.50
crafted = floor(min(engineParts ÷ 8, plasmaCannons ÷ 4))
granted = min(floor(flagshipLaunches ÷ 8), flagships × 2)
tickets = min(crafted + granted, 12)

Parts drop from completed launches only, so the drop stream is weighted by one minus the failure probability rather than by the survival factor — salvage returns cargo, not parts. The raid table pays 3×. Because Plasma Cannons drop at exactly 0.50 of the Engine Part rate and the recipe asks for 8 and 4, the two streams are matched by construction and neither is ever the bottleneck. Tickets are capped at 12 a month however they were obtained, so a large fleet converts salvage into access at a bounded rate.

F10Recapture

fuelUsd = fuelDonut × $0.0025
returnUsd = fragmentsUsd + longTokens × $0.008 + dividendClaim × $0.0025
recapture = returnUsd ÷ fuelUsd

The one summary figure, and the one most easily misread. It is the ratio of a modelled return to a modelled cost at reference prices that have no market behind them. Below 1 the month cost more than it returned. Above 1.25 the simulator flags the configuration as unproven, because the reward faucet is funded by a treasury slice of only 10% and nothing has been balanced to sustain that rate. The dividend claim is modelled at parity — a commander's own contribution returned to them — which is the flattering case and is stated as such in chapter 08.

The two examples below are not written out by hand. They are produced by calling the same functions the simulator calls, with the fleet and settings named in each column heading, so the figures on this page cannot drift away from the engine that generated them.

Two worked examples

Both fleets fly the all-hours window at 55% uptime under the flat scenario, with no qualifying Hyper-Boost sessions and the float at its initial value. Example A is one Donut Harvester in SPY Galaxy with no captain. Example B is one Arbitrage Cruiser in MSTR Void under The Bear. Simulation output, not a forecast.
Quantity	A — Harvester / SPY / no captain	B — Cruiser / MSTR / Bear
Hull	DS-H1	DS-C2
Sector	SPY Galaxy	MSTR Void
Captain	No captain	The Bear
Volatility	0.08	0.95
Cycle time	10 h	4 h
Launches / month	39	99
— during session	7	19
— after the bell	32	80
Fuel per launch, $DONUT	20.40	46.04
Fuel per month	796 $DONUT	4,558 $DONUT
Pirate failure, session	3.0%	18.1%
Pirate failure, after hours	12.0%	24.4%
Survival factor, session	0.98	0.86
Expected losses	4.1	22.9
Stock fragments	$1.42	$1.40
$LONG earned	0 $LONG	1,065 $LONG
Engine Parts	0.00	11.83
Plasma Cannons	0.00	5.91
Burned to the dead address	557 $DONUT	3,191 $DONUT
Dividend pool	159 $DONUT	912 $DONUT
Treasury	80 $DONUT	456 $DONUT
Fuel cost	$1.99	$11.39
Modelled return	$1.81	$12.20
Net	−$0.18	$0.81
Recapture ratio	0.91×	1.07×

FIG. 4.1Both fleets fly the all-hours window at 55% uptime under the flat scenario, with no qualifying Hyper-Boost sessions and the float at its initial value. Example A is one Donut Harvester in SPY Galaxy with no captain. Example B is one Arbitrage Cruiser in MSTR Void under The Bear. Simulation output, not a forecast.

Reading the two examples

The Harvester is the floor of the game and behaves like it: cheap fuel, a quiet sector, a failure rate the floor dominates after the bell, and no $LONG at all. The Cruiser is the opposite trade — 1.35 times the base fuel, a sector charging 11.88 times the volatility on both the fuel bill and the failure rate, and a payout that rises with exactly the chaos that is trying to kill it. The Bear pays 12.0% more fuel to halve the failure rate, moving an unescorted 36.1% to 18.1%. Neither example is advice about how to build a fleet; they are here so the arithmetic can be checked line by line.

F2 and F8 evaluated across the board

Fuel per launch for an uncrewed hull at the initial float under the flat scenario, in $DONUT, one column per sector — and the launch count the same hull sustains in a month. The automation column replaces the commander's uptime with the Quant AI Pilot's floor. Both are produced by calling the engine's own functions.
Hull	SPY	NVDA	TSLA	MSTR	Session only	All hours, 55%	All hours, automated
DS-H1 Donut Harvester	20.40	22.75	23.60	24.75	12	39	55
DS-C2 Arbitrage Cruiser	28.19	35.17	37.69	41.11	30	99	139
DS-D3 Wall Street Dreadnought	153.00	170.63	177.00	185.63	4	13	18

FIG. 4.2Fuel per launch for an uncrewed hull at the initial float under the flat scenario, in $DONUT, one column per sector — and the launch count the same hull sustains in a month. The automation column replaces the commander's uptime with the Quant AI Pilot's floor. Both are produced by calling the engine's own functions.

The preset fleets, run through the same engine

The four presets shipped in the simulator, each run at 55% uptime on the all-hours window under the flat scenario with no qualifying Hyper-Boost sessions. Recapture is a simulation ratio at reference prices, not a return.
Preset	Composition	Hulls	Launches	Fuel	Modelled return	Recapture
Starter Haul	4 × DS-H1 SPY	4	156	3,182 $DONUT	$7.26	0.91×
Yield Farmer	6 × DS-H1 SPY · 2 × DS-C2 TSLA · 1 × DS-D3 SPY	9	445	13,868 $DONUT	$36.93	1.07×
Void Runner	6 × DS-C2 MSTR · 2 × DS-H1 MSTR	8	672	29,510 $DONUT	$78.44	1.06×
Whale Flagship	2 × DS-D3 MSTR · 10 × DS-H1 NVDA · 6 × DS-C2 NVDA	18	1,020	34,747 $DONUT	$95.39	1.10×

FIG. 4.3The four presets shipped in the simulator, each run at 55% uptime on the all-hours window under the flat scenario with no qualifying Hyper-Boost sessions. Recapture is a simulation ratio at reference prices, not a return.

Constants reference

Every export in src/lib/constants.ts, its current value read from the module itself, what it controls, and where the played game's own dials live instead.

Constants are the only place a tunable figure of the modelled game is allowed to live. Nothing in the engine, the components or the copy may carry a number of its own; when a value below changes, every surface that quotes it changes with it — including this table, which is generated from the imports rather than transcribed.

PROJECT

nameDonut Strategy

subtitleGalactic Stock Fleet

domaingdonut.com

x@donutstrategy

launchpadlong.xyz

versionv0.1 — DRAFT

revisionREV 12

Design constants

Values are read from src/lib/constants.ts at build time. Percentages, multipliers and token counts are formatted through src/lib/format.ts, which is also the only formatter any component may use.
Export	Value	What it controls
FUEL_SPLIT	70% / 20% / 10%	The fixed split every launch's fuel is divided on: burned, dividend pool, treasury.
DEAD_ADDRESS	0x0000…dEaD	Where the burned slice is sent. No key exists for it.
DONUT_REF_PRICE	$0.0025	Reference price used only to express in-game $DONUT in USD. Not a quote.
LONG_REF_PRICE	$0.008	Reference price used only to express earned $LONG in USD. Not a quote.
TOTAL_SUPPLY	1,000,000,000	Design supply of $DONUT, in tokens.
INITIAL_FLOAT	350,000,000	Starting circulating float, and the denominator of the supply index.
PIRATE_COEFF	0.38	Turns sector volatility into a failure probability.
PFAIL_CLAMP	49.0%	Hard ceiling on failure probability. Nothing on the board reaches it: the worst case in the game is an unescorted after-hours launch into MSTR Void, at 48.7%.
AFTER_HOURS_RISK	1.35×	Multiplier on failure probability outside the session.
AFTER_HOURS_PFAIL_FLOOR	12.0%	Minimum failure probability after the bell, whatever the sector.
SALVAGE_FACTOR	20.0%	Fraction of cargo a lost expedition still returns.
RAID_DROP_MULTIPLIER	3×	Multiplier on the rare-part drop table after the bell.
PLASMA_TO_ENGINE_RATIO	0.50	Plasma Cannons drop at this fraction of the Engine Part rate.
AURA_SLOTS_PER_FLAGSHIP	8	How many other hulls one Dreadnought lifts.
AURA_BONUS	20.0%	Reward lift applied to the covered share of a line.
HYPER_BOOST_MULTIPLIER	2×	What Hyper-Boost does to fragments and $LONG on a qualifying session.
HYPER_BOOST_THRESHOLD_PCT	3.00%	The close that arms Hyper-Boost in NVDA Sector.
TRADING_DAYS_PER_MONTH	21	Sessions in a modelled month.
CALENDAR_DAYS_PER_MONTH	30	Days in a modelled month, used by the all-hours launch rate.
SESSION_HOURS_PER_DAY	6.5 h	Length of the US regular session.
SESSION_HOURS_PER_MONTH	136.5 h	Session hours available in a modelled month.
AFTER_HOURS_SHARE	81.0%	Derived, not a slider: the share of round-the-clock launches landing outside the session.
SESSION_UPTIME_FACTOR	90.0%	How much of the session window an unautomated commander is assumed to work.
DEFAULT_UPTIME	55.0%	Starting position of the uptime control.
MIN_UPTIME	10.0%	Lower bound of the uptime control.
MAX_UPTIME	60.0%	Upper bound of the uptime control.
GREEN_DAY_FREQUENCY	0.75 / 0.50 / 0.25	Assumed share of green closes per scenario: green, flat, red. Drives the Bull's weighted payout.
TICKET_RECIPE	8 + 4	Engine Parts plus Plasma Cannons that craft one Launchpad Ticket.
FLAGSHIP_TICKET_EVERY	8	Completed flagship expeditions per granted ticket.
FLAGSHIP_TICKET_CAP	2	Granted tickets per flagship per month.
TICKET_CAP_PER_MONTH	12	Total tickets a commander can hold per month, however obtained.
SESSION_TZ	America/New_York	The time zone the session clock is computed in.
SESSION_TZ_LABEL	ET	The short label printed beside session times.
SESSION_WINDOW	09:30–16:00	Open and close of the regular session, as wall clock in that zone.
SESSION_OPEN_MINUTES	570	The open, in minutes past local midnight.
SESSION_CLOSE_MINUTES	960	The close, in minutes past local midnight.
UPTIME_PRESETS	15% / 30% / 45% / 60%	Tick labels on the uptime control: Casual, Steady, Committed, Obsessive.

FIG. 5.1Values are read from src/lib/constants.ts at build time. Percentages, multipliers and token counts are formatted through src/lib/format.ts, which is also the only formatter any component may use.

Two of these are not free parameters

AFTER_HOURS_SHARE is derived rather than chosen: it falls out of the session length and the trading calendar, and currently prints 81.0%. SESSION_HOURS_PER_DAY is the length of the US regular session and is fixed at 6.5 hours by the market, not by this design. Editing either to make a docket look better would be editing the world rather than the game.

The played game keeps its dials somewhere else, and deliberately

Everything above is a constant of the model — the thing the simulator and these chapters evaluate. The played game at /play has a second, smaller set of its own in src/lib/play.ts: the starter grant, the daily fuel allowance, the hull prices, the burn totals that unlock each captain, the 3 refit tiers and the 3 flight orders a day. They are separate because they are answering a different question — what one commander can do this afternoon, not what a fleet averages over a month — and mixing them would let a change made to keep a game playable quietly move a figure this document presents as design. The shared rules, the split, the pirate clamp and the salvage factor are read from the table above by both.

The reference prices are conveniences

$0.0025 per $DONUT and $0.008 per $LONG exist so in-game quantities can be expressed in a familiar unit. There is no market behind either figure, no token exists to price, and neither number should be read as a valuation, a target or an expectation.

Fleet reference

The three hulls, the three captains and the four sectors, as complete tables generated from the specs the engine reads.

Three hulls are specified and they are deliberately not balanced against each other in isolation. The Harvester is the floor, the Cruiser converts disorder into $LONG, and the Dreadnought is on purpose the worst raw earner in the game — it repays its fuel bill only by lifting the hulls around it. Mixed fleets beat monocultures in the model because launch cost scales with tank size while the aura bonus is a flat percentage applied to whatever sits beneath it.

Hull specifications

Every column is read from src/lib/ships.ts. Cycle is flight plus refit and is the figure that actually limits a fleet.
Hull	Role	Fuel base	Flight	Refit	Cycle	Fragment base	$LONG base	Fragment mod	Surcharge	Engine part	Best fit
DS-H1 Donut Harvester	Miner / Hauler	20.00	8 h	2 h	10 h	$0.036	0.0	1.25	0.25	0.0%	SPY
DS-C2 Arbitrage Cruiser	Fast Frigate	27.00	3 h	1 h	4 h	$0.012	5.8	1.00	0.55	6.0%	TSLA
DS-D3 Wall Street Dreadnought	Flagship	150.00	24 h	6 h	30 h	$0.200	12.0	1.00	0.25	4.0%	MSTR

FIG. 6.1Every column is read from src/lib/ships.ts. Cycle is flight plus refit and is the figure that actually limits a fleet.

Hull perks

The perk as written in src/lib/ships.ts — the design statement, in the words a player is shown. The figures implementing it are in the specification table above and in F6 and F7; the flagship's ticket grant is the one half that rests on an integration nobody has agreed to, and its own text says so.
Code	Hull	Perk as specified
DS-H1	Donut Harvester	Dividend Hauler — +25% on the RWA stock-fragment component of every completed expedition. Earns no $LONG.
DS-C2	Arbitrage Cruiser	Arbitrage Gap Engine — $LONG earned scales with sector volatility (×1 + volatility × 0.60). The only hull whose payout rises with chaos.
DS-D3	Wall Street Dreadnought	Flagship Aura — +20% yield to eight other hulls in the fleet, and one long.xyz IDO ticket per eight of its own completed expeditions. The launchpad exists; no agreement or allocation with it does, so that second half is designed and not delivered.

A captain sits above the hull and changes how the whole line behaves: fuel draw, pirate exposure, sustained launch rate and reward. Two of the three are defensive or logistical rather than multiplicative, which is intentional — a roster where every captain raised yield would collapse into one dominant pick.

Captain specifications

Read from src/lib/captains.ts, with the uncrewed baseline printed as the fourth row. A defence factor below 1 lowers failure probability; a fuel multiplier above 1 is a tax.
Captain	Rarity	Reward bonus	Fuel ×	Defence ×	Automation	Condition
CPT-01 The Bull	Legendary	30.0%	0.85	1.00	—	Only on sessions that close green
CPT-02 The Bear	Epic	0.0%	1.12	0.50	—	Always active; earns its keep in down markets
CPT-03 Quant AI Pilot	Rare	0.0%	1.08	1.00	77.5%	Always active; buys time, not performance
No captain	—	0.0%	1.00	1.00	—	Fly the hull unattended

FIG. 6.2Read from src/lib/captains.ts, with the uncrewed baseline printed as the fourth row. A defence factor below 1 lowers failure probability; a fuel multiplier above 1 is a tax.

Captain effects

Read from src/lib/captains.ts, with the uncrewed baseline as the fourth row. The effect is the sentence a player is shown; the multipliers implementing it are in the specification table above, and the Bull's carries its condition here as it must everywhere.
Code	Captain	Effect as specified
CPT-01	The Bull	+30% fleet reward and −15% fuel burn on any session the real US market closes green. On red sessions it contributes nothing but opinions.
CPT-02	The Bear	+50% defense — halves pirate failure probability on every expedition. Costs 12% more fuel and adds nothing to yield.
CPT-03	Quant AI Pilot	Automation module — refuels and repeats the last expedition for twelve hours while you are offline, raising sustained launch rate. Costs 8% more fuel and adds nothing to yield.
—	No captain	No modifiers. Baseline fuel, baseline risk, baseline reward.

The Bull is conditional and the interface must always say so

The Bull pays 30.0% reward and a 15.0% fuel discount only on sessions the real market closes green. The engine weights both by the scenario's green-day frequency, so under the flat scenario the expected reward bonus is 15.0% and the expected fuel discount 7.5%. An unconditional headline figure would be a lie, and no surface of this project is permitted to print one.

Four sectors carry the whole map, each mirroring a real equity's behaviour without using its branding, logo or colours. Two numbers define a region — a yield multiplier applied to everything harvested there, and a volatility value between 0 and 1 that drives the fuel surcharge, the pirate risk and the dispersion at once. Sectors are identified on every surface by hatch pattern and plate code, so they survive greyscale, dark mode and an 8px legend swatch.

Sector specifications

Yield and volatility are read from src/lib/nebulae.ts. The three failure columns are computed by calling the engine's pirate-risk function for an uncrewed hull and for one under the Bear, so they cannot drift from F4.
Sector	Ticker	Underlying	Yield ×	Volatility	Fail, session	Fail, raid	Fail, Bear	Hatch
SPY Galaxy	SPY	S&P 500 index basket	0.88	0.08	3.0%	12.0%	1.5%	spy
NVDA Sector	NVDA	Semiconductor compute	1.05	0.55	20.9%	28.2%	10.5%	nvda
TSLA Nebula	TSLA	Electric vehicle equity	1.15	0.72	27.4%	36.9%	13.7%	tsla
MSTR Void	MSTR	Leveraged treasury equity	1.45	0.95	36.1%	48.7%	18.1%	mstr

FIG. 6.3Yield and volatility are read from src/lib/nebulae.ts. The three failure columns are computed by calling the engine's pirate-risk function for an uncrewed hull and for one under the Bear, so they cannot drift from F4.

Sector character

Read from src/lib/nebulae.ts. Character is a risk label and a fragment type — how a region reads. The two numbers that actually drive the model, yield and volatility, are in the table above, and nothing in this one enters an equation.
Ticker	Risk label	Fragment type	As described
SPY	Low — Index Drift	Broad-basket fragments	A slow, wide, almost boring spiral of five hundred blended light-sources. Nothing here moves fast enough to kill you, which is exactly why the survivors retire in it.
NVDA	High — Hyper-Boost Band	Compute fragments	Silicon reefs that glow when the fabs run hot. The only region carrying Hyper-Boost: when the underlying closes three percent up or better, everything harvested here doubles.
TSLA	High — Whipsaw	Drive-unit fragments	Violently bimodal: gorgeous one epoch, debris field the next. It moves before anyone has finished reading the news, and the Arbitrage Cruiser was drawn for exactly this weather.
MSTR	Extreme — Leveraged Singularity	Reserve fragments	A leveraged accretion disc that holds one enormous position and declines to explain it. Highest yield multiplier on the board, and the highest chance your hull does not come back.

Why the safe sector is only safe during the session

In SPY Galaxy an uncrewed launch fails 3.0% of the time during the session and 12.0% of the time after the bell, because the after-hours floor binds long before the multiplier does. In MSTR Void the multiplier binds instead and takes an unescorted launch to 48.7% after the bell — a hair under the 49.0% clamp, which nothing on the board reaches. Sector choice is a directional call made deliberately, not a cosmetic preference.

Session and oracle

The US regular session in its own time zone, how session state is computed, the four oracle rules, and the fact that no live price feed exists.

Expeditions are designed to resolve against the real US regular session: 09:30–16:00 ET, 21 sessions in a modelled month, 6.5 hours a session and 136.5 session hours in a 30-day month. Weekends are closed. The clock is computed in the market's own zone rather than a viewer's, so the session opens and closes at the same wall-clock time for everyone reading this, wherever they are.

Session window

Time zoneAmerica/New_York

LabelET

Opens09:30 ET

Closes16:00 ET

Open, minutes past midnight570

Close, minutes past midnight960

Session length6.5 h

Sessions per month21

Session hours per month136.5 h

Share of launches after the bell81.0%

sessionStateAt takes a Date and returns the state of the session at that instant. It formats the instant into the session's zone with Intl.DateTimeFormat, reads hour, minute, second and weekday from the formatted parts, and reduces the clock to minutes past local midnight. That single number is then compared against the open and close constants. Nothing about the viewer's own clock or locale enters the calculation, and daylight saving is handled by the zone database rather than by an offset anyone has to maintain.

The four states

Each state also returns the wall clock in the session zone and the milliseconds until the next change, which is what the countdown on the sectors page renders.
State	When	What it means for a launch
open	Weekday, at or after 09:30 and before 16:00	Oracle modifiers apply. Failure probability carries no after-hours multiplier.
before-open	Weekday, before 09:30	Pre-session. Launches resolve under after-hours rules and the clock counts down to the open.
after-close	Weekday, at or after 16:00	After-Hours Raids. The clock counts down to the next open.
weekend	Saturday or Sunday in the session zone	No session at all. After-Hours Raids run for the whole two days.

FIG. 7.1Each state also returns the wall clock in the session zone and the milliseconds until the next change, which is what the countdown on the sectors page renders.

Oracle rules

Read from src/lib/oracle.ts. Two of the four are conditional on the close, one on the clock, and none of them are live today.
Rule	Trigger	Scope	Effect
NVDA Hyper-Boost	NVDA closes +3.00% or better	NVDA Sector only	Ships in NVDA Sector double both stock fragments and $LONG for that session. Nowhere else on the map carries this modifier.
Green Close	The session closes up	Fleets crewed by The Bull	The Bull pays +30% fleet reward and −15% fuel burn. On a red close it pays nothing, which is the whole trade.
After-Hours Raids	Outside 09:30–16:00 ET, and all weekend	Every sector	Pirate failure rises 1.35× with a 12% floor, and the rare-part table pays 3× the session rate. Engine Parts and Plasma Cannons drop from any completed launch; the raid is where that table is worth flying. The rule is modelled on the market it borrows from: a tokenized-equity pool holds no oracle, and the arbitrage that keeps it near the share price runs through authorised participants who work weekdays, so nothing corrects the pool between Friday's close and Monday's open.
Red Close	The session closes down	Every sector	The Bull's bonus does not arm at all. The Bear halves failure probability on every expedition regardless of the close, and a red month is the one that pays for its 12% fuel premium.

FIG. 7.2Read from src/lib/oracle.ts. Two of the four are conditional on the close, one on the clock, and none of them are live today.

There is no live price feed

No market data source is wired up. The ticker rail across the top of the site runs a small table of illustrative sample rows and prints SAMPLE FEED beside them wherever they appear. Inventing live quotes is the one thing a finance-shaped product cannot do, so this one does not do it. The rules in the table above are specified behaviour, not observed behaviour of a system reading a market.

What the played game resolves against instead

The game at /play still has to answer two of these questions before it can settle an expedition: did the session close green, and did Hyper-Boost arm. It derives both rather than fetching them. The day's flags come out of a keyed hash of the date in src/server/world.ts, so every commander whose hull lands in the same session gets the same modifiers, nobody can reroll one by reloading, and no part of it claims to describe a real market — a weekend carries neither flag, because there is no close to be green. That is a substitute for a feed, chosen so the game can run without fabricating a quote. It is not a feed, it is not a measurement, and no figure it produces says anything about what any real stock did.

The sample tape

Design placeholders held in src/lib/oracle.ts. Not quotes, not delayed quotes, and not derived from any feed.
Ticker	Sector	Sample price	Sample change
NVDA	NVDA Sector	184.22	+3.41%
TSLA	TSLA Nebula	402.87	−1.94%
MSTR	MSTR Void	331.05	+5.12%
SPY	SPY Galaxy	612.44	+0.28%

FIG. 7.3Design placeholders held in src/lib/oracle.ts. Not quotes, not delayed quotes, and not derived from any feed.

The weekend is the exploit. The after-hours rules are not flavour: they imitate a documented failure in the market this design borrows from.

Why the hours after the bell are dangerous

01An automated market maker holds no opinion about what a tokenized share is worth. It prices from its own reserves and nothing else — there is no oracle in the pool.
02The peg to the real equity is held by arbitrage: when the token drifts above the share price, someone mints new tokens from the issuer and sells them into the pool. That path runs through an authorised participant, and authorised participants work weekdays.
03So between the closing bell on Friday and the open on Monday, the correcting force is simply absent. The pool can be pushed anywhere and nothing pulls it back.

The precedent, as reported

In August 2026 a memecoin cornered roughly 53% of the floating supply of one tokenized US healthcare stock and drove the wrapper to $132.64 while the underlying had closed at $28.84 on Friday. It resolved only when the sole authorised participant minted about 4,000 fresh tokens after the market reopened. Reported by trade press with internally consistent dates. We have not reconstructed the pool history on chain. It is carried here as reported rather than verified, and no part of this design depends on it being exactly as described.

The game already charged a risk premium for flying after the bell. It turns out the premium is not invented: pirate failure rising 1.35× outside the session, with a floor that no captain can talk their way under, is the closest honest analogue of a market where the corrective mechanism has gone home for the weekend.

Burn engine

The fixed split, where the burned slice goes, what each of the other two slices funds, and the assumption doing the work behind the dividend claim.

Fuel is spent, not parked. Launching debits $DONUT up front and the debit is never refunded, whatever the expedition returns. That payment splits on a fixed schedule — 70% burned, 20% to the dividend pool, 10% to the treasury — and the schedule does not vary by hull, captain, sector, flight window or scenario. It is the project's headline rule and the one number a reader should be able to recite.

The fixed split

Read from FUEL_SPLIT. The treasury slice is computed as the remainder so the three parts always sum to the fuel paid.
Slice	Share	Destination	What it funds
Burned	70%	0x0000…dEaD	Destroyed. It leaves the float permanently, which lowers the supply index and makes the next launch cheaper.
Dividend pool	20%	Pool contract	Shared across every locked hull in the game. The simulator models a commander's claim at parity with their contribution.
Treasury	10%	Treasury	Funds the reward faucet — fragments, $LONG grants and salvage. It is small by construction, which is why an unusually high recapture ratio is flagged as unproven rather than celebrated.

FIG. 8.1Read from FUEL_SPLIT. The treasury slice is computed as the remainder so the three parts always sum to the fuel paid.

Dead address

Address

0x000000000000000000000000000000000000dEaD

Printed as0x0000…dEaD

Key holder

None — the address is unspendable by construction

Explorer

https://robinhoodchain.blockscout.com

The burn is what closes the loop. Fuel destroyed leaves the circulating float, which lowers the supply index in F1, which lowers the fuel cost of the next launch in F2. A commander who flies is simultaneously the largest cost centre in the game and its deflation mechanism. The projection on the burn page runs that loop forward twelve months with the float decrementing as it goes, which is why the monthly burn falls even when the fleet does not change — and the float is floored at 5% of its initial value so the model cannot run itself to zero.

The parity assumption behind the dividend claim

The 20% pool is shared across every locked hull in the game, so a commander's claim on it depends on what everybody else does. The simulator resolves this by modelling the claim at parity: it returns a commander's own contribution to the pool as their claim on it, on the explicit assumption that the rest of the field flies at a similar intensity. That assumption is doing real work in the recapture ratio and should be read as the flattering case. A commander who flies harder than the field claims less than they contributed; one who flies less claims more. There is no mechanism in this design that guarantees parity, and none is being promised.

The faucet is small by construction

The reward side is funded by the 10% treasury slice. A deflationary fuel loop that lowers launch cost as the float shrinks can accelerate faster than that slice can fund, which is why the simulator flags any configuration recapturing more than 1.25× as unproven rather than as a result. This is an open balance problem, stated in chapter 15, not a solved one.

Rewards, parts and tickets

What a completed expedition pays, how salvage becomes a ticket, what the flagship grants, and an honest account of what the after-hours multiplier does and does not mean.

A completed expedition pays in three currencies and two objects. Stock fragments are the dividend-shaped component and are denominated in USD. $LONG is the game's own reward unit, earned by every hull except the Harvester — issued by the game, and not the token of the launchpad named below or of any other third party, with no allocation of anybody else's token implied, agreed or held. Engine Parts and Plasma Cannons are rare salvage. Fragments and $LONG are the reason to fly at all; parts are the reason to fly at three in the morning.

The ticket recipe

Engine Parts per ticket8

Plasma Cannons per ticket4

Plasma drop rate0.50 × the Engine Part rate

Flagship grant

1 ticket per 8 completed flagship expeditions

Flagship grant cap2 per flagship per month

Total cap12 per commander per month

Raid drop multiplier3×

Engine Part chance, Cruiser6.0%

Engine Part chance, Dreadnought4.0%

Engine Part chance, Harvester0.0%

The raid table pays 3×, which is not the same as being the only source

Parts drop from any completed launch, during the session as well as after it. What the raid does is multiply the drop rate by 3 — and charge for it, since failure probability outside the session is multiplied by 1.35 with a floor of 12.0% and a failed launch drops nothing at all. A session-only fleet still earns parts and can still craft tickets; it simply does so more slowly. Describing the night as the only way to obtain salvage would overstate the mechanic, and the 81.0% of all-hours launches landing after the bell is a consequence of the calendar rather than a reward for staying up.

The intended endpoint for salvage is a launchpad ticket. Under the planned long.xyz integration a ticket is designed to grant front-of-line access to IDOs of new tokenized stocks and stock-paired tokens, and the Dreadnought is specified to carry a guaranteed grant on top of anything crafted. That is the mechanic as designed.

The integration is intended, not built and not agreed

A launchpad operating on this chain that quotes newly created tokens in tokenized stock tokens rather than in a stablecoin or the gas asset. Stock-paired launches have been live there since roughly mid-July 2026, and comparable pools carry real daily volume. That is the launchpad's own position in the market, reported rather than independently checked. No agreement, allocation or conversation exists between this project and it. Naming it here is a design intention and nothing more, and both halves of that sentence travel together wherever it appears.

In the played game a ticket is a counter

/play issues Launchpad Tickets on exactly the recipe above — full sets crafted from spare Engine Parts and Plasma Cannons, with the parts a hull still needs for its next refit tier held back so the recipe cannot craft a fleet's upgrades away underneath it — and then does nothing with them. Launchpad Tickets have no redemption. They count sets crafted and nothing else. There is no redemption, no queue, no allocation and nothing to convert one into, and the board says so beside the count rather than leaving a commander to find out. The flagship grant described above is design, not played code: today the game grants tickets by crafting alone.

What we could not establish about the launchpad

—We found no primary documentation: no published fee schedule, no contract addresses, no audit.
—Liquidity figures quoted by aggregators value both legs of a pool, including the new token at a mark derived from that same pool, so headline numbers overstate tradeable depth substantially.
—No agreement, allocation, or conversation exists between this project and that launchpad. Naming it here is a design intention and nothing more.

If the integration never happens

—Tickets and $LONG would need a different sink, since front-of-line IDO access is the only terminal reward the design currently specifies for them.
—The Dreadnought would lose one of its two justifications and would have to be rebalanced around Flagship Aura alone.
—The night economy would lose its endpoint, and the after-hours risk premium would be charging for a reward that no longer resolves into anything.
—The roadmap treats this phase as contingent for exactly that reason, rather than as scheduled work.

Chain

The chain this design targets, what was actually observed on its public RPC, and the researched facts about the chain and about tokenized equities — each carrying the status it earned.

Targeting is not deploying

Donut Strategy has deployed nothing on this chain or any other. No token exists, no contract is live, no pool exists, and none of the arithmetic in these chapters has touched a block. Choosing a chain is a design decision that obliges this document to describe the chain honestly, including the parts that are inconvenient.

Chain identity

NameRobinhood Chain

Chain ID4,663

Testnet chain ID46,630

StackArbitrum Orbit (Nitro)

Settles toEthereum

Gas tokenETH

Announced2025-06-30

Public testnet2026-02-10

Public mainnet2026-07-01

RPC

https://rpc.mainnet.chain.robinhood.com

Explorer

https://robinhoodchain.blockscout.com

Documentationhttps://docs.robinhood.com/chain

The identity above was not taken on trust. On 2026-09-07 the public RPC was queried directly and the responses below are what came back. They are the reason the chain rows in the next table read as verified rather than reported.

What the RPC actually answered

eth_chainId0x1237 (4,663)

web3_clientVersionnitro/v3.11.4-rc.3

eth_blockNumber56,806,983 — producing blocks

eth_getCode, filter precompile0x0000…0074 — code present

Probed on2026-09-07

Chain facts

Robinhood Chain as researched on 2026-09-07. Verified means read from a primary source or checked against the chain. Reported means stated by the operator or reported consistently, and not independently checked. Unresolved means it could not be established and is treated as unknown rather than false.
Item	Finding	Status
Status	Public mainnet since 2026-07-01Announced 2025-06-30, public testnet 2026-02-10. The RPC answers on chain ID 4663.	Verified
Architecture	Arbitrum Orbit (Nitro) L2, settling to EthereumEthereum blob data availability. Gas is paid in ETH, not a chain token.	Verified
Deployment	PermissionlessThe operator's own documentation states anyone may deploy contracts, and canonical CREATE2 infrastructure is already on chain. A third-party contract creation simulates without an allowlist rejection.	Verified
Decentralisation	L2BEAT Stage 0The lowest of the three stages. It means the operator retains powers a mature rollup would have given up.	Verified
Transaction filtering	Present at the protocol levelArbOS 61 carries a filtered-transactions precompile. An authorised filterer can register a transaction hash and the state transition function will force that transaction to fail — including transactions force-included from Ethereum.	Verified
Who holds the filtering role	Not establishedWe could not determine who may filter, under what policy, or whether the power has ever been used. Anyone deploying here should assume it exists and is usable.	Unresolved

FIG. 10.1Robinhood Chain as researched on 2026-09-07. Verified means read from a primary source or checked against the chain. Reported means stated by the operator or reported consistently, and not independently checked. Unresolved means it could not be established and is treated as unknown rather than false.

The filtering role is unresolved and stays unresolved

The transaction-filtering precompile is verified: the mechanism exists at the protocol level and can force a registered transaction to fail, including one force-included from the settlement layer. Who may use it, under what policy, and whether it has ever been used could not be established. That row is unresolved and is shown as unknown rather than assumed benign. Anything built here should assume the capability exists and is usable.

Tokenized equity facts

Tokenized equities as researched on 2026-09-07. The transfer model is reported and not verified: nobody has read the deployed bytecode, so free transferability is not treated as an established fact anywhere on this site.
Item	Finding	Status
Transfer model	Deny-list, not allow-listAcross the major issuers, KYC gates primary mint and redemption rather than transfer. Documentation and reporting agree on this; we have not read the deployed bytecode ourselves, and until someone does it should not be treated as settled.	Reported, not checked
Legal wrapper	Debt securities or derivatives, never real sharesIssuers wrap equity exposure as tracker certificates, structured notes or OTC derivatives. A token holder owns a claim on an issuer, not stock.	Verified
Mint and redeem window	Weekdays only, through authorised participantsThis is the single most important fact for the game's design: the supply of a tokenized equity cannot change while the underlying market is shut.	Verified
US persons	Excluded by every major issuerThis is the awkward fact at the centre of a US-facing design. Tokenized equities are offered under exemptions that specifically exclude US persons, and the exclusion is enforced at the front end and in the offering terms rather than in the contract. A US audience can read this design; it is not who the underlying instruments are sold to.	Verified
Third-party equity-referencing tokens	Effectively closed to retail in the USA token issued by a third party that references someone else's equity is treated as a linked security or a security-based swap, which cannot be sold to ordinary retail without registration and an exchange. This is the single reason $DONUT is fuel and references nothing.	Reported, not checked

FIG. 10.2Tokenized equities as researched on 2026-09-07. The transfer model is reported and not verified: nobody has read the deployed bytecode, so free transferability is not treated as an established fact anywhere on this site.

One of those rows is load-bearing for the whole design. The mint and redeem window for a tokenized equity runs on weekdays through authorised participants, so the supply of the wrapper cannot change while the underlying market is shut. That is the mechanism chapter 07 imitates, and it is verified rather than assumed.

Liquidity and pair selection

Which tokenized equity a launch pool should be quoted in, the four candidates compared on the two axes that matter, and the recommendation stated plainly.

Quoting a pool in an equity rather than a stablecoin is the whole point of launching on a chain where tokenized stocks are the native unit of account. It is also a decision with consequences that arrive whether or not anything happens to the token itself: a pool quote is not a neutral unit. Whatever the quote asset does, the pair does in the opposite direction.

The four candidates

Read from src/lib/chain.ts. Imported volatility is what the quote leg contributes to the pair's chart; corner resistance is how hard the wrapper would be to squeeze over a weekend while mint and redeem are shut.
Ticker	Wrapper	Imported volatility	Corner resistance	Narrative	Verdict
SPY	S&P 500 index wrapper	lowest	strongest	The index. No single company's earnings day moves the quote.	Recommended for the launch pool. It still delivers a stock-quoted pair, but the chart reads as the token's own story rather than one issuer's week, and it is the hardest of the four to squeeze while mint and redeem are shut.
NVDA	Semiconductor compute	high	moderate	The most-watched ticker on the board and the busiest stock-quoted pools in practice.	The attention case. Costs you a quote that can move several percent on a single session, and every one of those moves lands on your pair whether or not it has anything to do with the token.
TSLA	Electric vehicle equity	high (bimodal)	weak	Moves early and often, rarely quietly.	Hardest to defend as a quote asset. You import the volatility without the index's depth or the flagship's story.
MSTR	Leveraged treasury equity	highest	weakest	The joke the project is named after. A treasury company quoting a treasury-themed game is the sharpest identity available.	The best narrative and the worst market structure. Highest imported volatility on the board and the thinnest wrapper to defend over a weekend. Worth a small second pool for the identity; a poor choice for the pool that has to hold.

FIG. 11.1Read from src/lib/chain.ts. Imported volatility is what the quote leg contributes to the pair's chart; corner resistance is how hard the wrapper would be to squeeze over a weekend while mint and redeem are shut.

Recommended quote asset for the launch pool

SPY

Recommended for the launch pool. It still delivers a stock-quoted pair, but the chart reads as the token's own story rather than one issuer's week, and it is the hardest of the four to squeeze while mint and redeem are shut.

The reasoning, in three parts

01A pool quote is not a neutral unit of account. Whatever the quote asset does, the pair does in the opposite direction, so choosing a volatile equity means the token's chart tells someone else's story on any day the underlying moves.
02The weekend failure documented elsewhere in this design applies to the quote leg as much as to any other tokenized equity. Mint and redeem run on weekdays, so between Friday's close and Monday's open a thin wrapper can be pushed a long way with nothing to pull it back. Depth is the only defence, and the index wrapper has the most of it.
03Quoting in an equity rather than a stablecoin is the whole point of launching here, so the answer is not to retreat to a stable quote. The answer is to pick the equity that behaves most like one.

The tradeoff, and the case for a second MSTR pool

The cost of this choice is the joke. Quoting Donut Strategy against MicroStrategy is a better line than quoting it against an index fund, and launch-day attention is a real asset. If the identity matters more than the structure, a small MSTR pool alongside the main SPY pool buys the story without putting the primary book on the thinnest quote available.

Not a prediction and not advice

This is liquidity engineering, not a view about prices. Nothing here predicts what any asset will do, and no configuration makes a launch safe.

Two practical cautions belong beside the recommendation. Headline liquidity figures quoted by aggregators value both legs of a pool, including the new token at a mark derived from that same pool, so they overstate tradeable depth substantially — depth on the quote side is the number that matters here. And the weekend gap described in chapter 07 applies to the quote leg exactly as it applies to any other tokenized equity: between the Friday close and the Monday open there is no correcting force, and depth is the only defence available.

Integrity rules

The claims this project may make, the claims it may not, and the reasoning behind each — written as rules a contributor has to follow, not as a disclaimer at the bottom of a page.

The regulatory line this design sits on is binary rather than a spectrum, and it decides what every surface of the site is allowed to say. It is written down here so that nobody has to reconstruct it from the copy.

The distinction that decides everything

Referencing an equity

A token whose own value is defined by an equity is treated as a financial instrument almost everywhere that has looked at it — a linked security or a swap in the United States, a MiFID instrument rather than a crypto-asset in the European Union. Selling one to the retail public is, in practice, closed off without registration.

Merely pairing against one

A token that does not reference an equity at all, and merely happens to trade against a tokenized one in a liquidity pool, has not been addressed by any regulator we could find. That silence is genuinely unsettled ground, not permission.

Design consequence

$DONUT is fuel. It is spent to launch expeditions and it makes no claim on any share, index or stream of earnings. That is a deliberate design constraint, and every surface of this project is written to hold it.

Silence is not permission

The pairing case has not been addressed by any regulator we could find. That is genuinely unsettled ground, and unsettled ground is a reason for care rather than a licence. A contributor should not read the absence of a rule as the presence of an allowance.

Rules a contributor must follow

01$DONUT is fuel. It is spent to launch expeditions and references no equity, index or stream of earnings. Never write a sentence implying it tracks, is backed by, or derives value from a stock.
02Nothing is deployed, audited, funded or agreed. Naming a target chain is a design decision, not a deployment, and no surface may imply otherwise.
03Simulator output is simulation. It is never a forecast, never a yield, never a return, and never something a reader should expect. Say so wherever a figure appears.
04The launchpad exists as a business and has no agreement with this project. Both halves of that sentence travel together, every time, including in long.xyz copy that would read better without the second half.
05$LONG is the game's own reward unit and is never identified with the launchpad's token or with any other third party's. Wherever it is defined, the sentence says who issues it and states that no allocation of anybody else's token is implied, agreed or held — a reward the game issues is the only thing a hull can be said to earn.
06Conditional modifiers are printed with their condition attached. An unconditional headline for the Bull's bonus would be a lie even though the number itself is correct.
07Verification statuses are respected and never upgraded. A reported claim is attributed and hedged; an unresolved one is shown as unknown, not as false and not as fine.
08In-game fuel is issued by the game from a faucet it runs itself. It is not a token, not an asset, and not convertible to one, and no ranking, docket, card or share line may carry a fuel figure without carrying that with it — least of all the ones that travel further than the page explaining them.
09Tickets have no redemption today. A ticket counts sets crafted; front-of-line access is the intended endpoint under an integration that does not exist, and the count is never printed as though it were a claim on anything.
10Playing stores things, and the site says so plainly. A surface that would let a reader believe their fleet lives only in their browser is a defect; chapter 03 states what is written and which of it is public, and a new surface that writes anything adds its row there.
11Every figure comes from src/lib, or on the play board from what the server answered. A number typed into a component is a defect regardless of whether it happens to be correct today, and a figure computed in the browser is one the browser can edit.
12No promised returns, no launch dates, no countdowns, and no claims about a team, a backer, a listing or a user base that does not exist.
13Tokenized equities are regulated instruments and the rules differ by country. Where the copy touches real exposure, it points the reader at someone licensed where they live rather than answering.

The standing disclaimer

Donut Strategy: Galactic Stock Fleet is a game concept in development. Nothing described here is live, deployed, audited, or funded, and there is no team, backer, listing, or user base being claimed. Every number on this page — yields, burn totals, dividend fragments, $LONG accrual — is output from a simulator running on design assumptions we are still changing. Those are simulation results, not forecasts, and not returns anyone should expect. The long.xyz integration is an intended one; no agreement is in place, and $LONG is this game's own reward unit rather than that venue's token — no allocation of anybody else's token is implied, agreed or held. Nothing here is investment advice. Tokenized equities are regulated financial instruments and the rules around them differ by country, so if you are thinking about real exposure, talk to someone licensed where you live.

Design system

The tokens, the three typefaces and the sizes they are allowed at, the utility classes in globals.css, the layer contract, and how the theme resolves in three states.

The visual system is printed matter rather than screen glow: a warm unbleached tape ground, hairline ledger rules, an engraved display serif and a teleprinter mono. Depth comes from rules and a deliberate two-colour misregistration, never from shadow, blur or gradient. Nothing is centred, corners are square everywhere except the button, and no figure is ever set in a proportional face.

Colour tokens

Defined once on :root and redefined for the dark palette. Components reference the token, never a literal colour, so a palette change is a one-file edit.
Token	Role
--tape	Page ground. The warm unbleached paper the whole site is printed on.
--stock	Plate fill. One step away from the ground, so a sheet reads as a sheet without a border alone.
--rule	Hairline rules, table borders, plate edges.
--rule-soft	Interior column rules, where a full-strength rule would fence the numbers in.
--ink	Body text and the 2px section rules.
--graphite	Secondary text, labels, captions.
--sodium	The single accent: active states, hover rules, focus rings, the misregistered offset.
--verdigris	Verified status, and positive figures where a sign alone is not enough.
--minium	Unresolved status, warnings, negative figures.
--sodium-wash, --verdigris-wash, --minium-wash	12% mixes of the three signal colours, for row highlights.
--hairline	The rule width, so every hairline in the system moves together.
--rail-h	Height of the tape rail, which the sticky header and every scroll offset are computed from.

FIG. 13.1Defined once on :root and redefined for the dark palette. Components reference the token, never a literal colour, so a palette change is a one-file edit.

Sodium carries small type, so it has to clear contrast on both grounds

The accent colour sets 10 and 12px type all over the product — labels, plate indices, active nav rows. Its light value is chosen to clear WCAG AA against both the tape and the stock grounds, and the dark value is chosen the same way. Any replacement accent has to be checked against both grounds at those sizes before it lands.

Type

Three faces, each with a job and a size rule. The rules exist because the display serif is a smoothing lottery at small sizes and tabular numerals are unreadable in a proportional face.
Class	Face	Where it is allowed
.t-display	Bodoni Moda, 700, uppercase	Headings at 24px and above only. Never in repeating UI, never in a table, never in a row that appears more than once on a page.
.t-plate	Archivo, 700, 88% width, uppercase	Every repeating label: table row headers, nav items, segment labels, badge-adjacent plate text. This is what repeating UI uses instead of the display face.
.t-label	IBM Plex Mono, 10.5px, graphite	Eyebrows, plate indices, caption slugs, field labels.
.num	IBM Plex Mono, tabular numerals	Every numeral on the site without exception, so columns align and two dockets are visibly comparable.
.prose-tape	Body face at a 66ch measure	Running prose. The measure is the whole class.

FIG. 13.2Three faces, each with a job and a size rule. The rules exist because the display serif is a smoothing lottery at small sizes and tabular numerals are unreadable in a proportional face.

Utility and component classes

Declared in src/app/globals.css inside @layer components. This is the whole kit: a class not in this table is not part of the system, and a new one belongs in that layer for the reason the note below states.
Class	What it does
.plate	The base sheet: stock fill, 1px rule border, radius 0, no padding of its own.
.plate-key	Adds the misregistered sodium offset border. Key plates only — it is the one depth device in the system.
.rule-t / .rule-b / .rule-l / .rule-r	A hairline on one edge.
.rule-heavy	The 2px ink top rule that marks a section or a stat tile.
.leader	A dot-leader ledger row: label, dotted fill, right-hanging numeral.
table.ledger	The ledger table: 2px ink header rule, hairline row rules, right-aligned tabular numerals, left-aligned first column, sodium left rule on hover.
.hatch-nvda / .hatch-tsla / .hatch-mstr / .hatch-spy	The four sector patterns, drawn in currentColor so they survive greyscale and dark mode.
.stamp	The rotated 2px-bordered stamp used for status marks.
.docket	The perforated docket mask: two sprocket strips plus the body, unioned rather than intersected.
.tear	The torn edge under a docket.
.btn / .btn-primary	The only rounded surface in the system, and the only place a radius above 0 is permitted.
.scroll-tape	Square scrollbars in the palette, for the horizontal overflow containers tables live in.
.odometer / .odometer-drum	A figure that has just changed, on the play board: the drum steps once and a 2px sodium rule is struck under it. The strike exists only while the settle is on — nothing in this system is parked invisible waiting for a cue.
.prog	Determinate progress, ruled instead of rounded: a hairline baseline carrying hard segments, sodium over the filled part, cut by the same repeating mask the docket sprockets use. No pill, no cap, no radius, no gradient.
.tape-rail / .tape-run / .tape-halted	The ticker rail's scroll, and the two ways it stops: hovering the rail, or a halted flag on it.
.stamp-land / .docket-print	The two mechanical motions in the product — a stamp landing, a docket printing in steps. Both are short, and both are dropped entirely under prefers-reduced-motion, which leaves the finished mark rather than a half-drawn one.

The @layer components contract

Everything from the type primitives down to the buttons is declared inside @layer components. This is not cosmetic: unlayered, .t-label would outrank a Tailwind utility on the same element and every colour utility would silently do nothing, and an anchor rendered as .btn-primary would inherit the page ink and paint ink on ink. The base anchor reset is layered for the same reason. A new primitive belongs in that layer or it will start winning arguments it should lose.

Theme resolution, in three states

01No stamp on the document element: the palette follows prefers-color-scheme, so a visitor who has expressed no preference gets their system's.
02data-theme="dark": the dark tokens are redefined unconditionally and win regardless of the system setting.
03data-theme="light": the dark media block is guarded with :root:not([data-theme="light"]), so an explicit light choice survives a dark system setting.
04The stamp is written to the document element by a small inline script before first paint, and read back through an external store rather than an effect, so the header toggle and the DOM never disagree and the first frame is never the wrong colour.

Standing constraints

—Radius 0 everywhere except .btn.
—No shadow, no blur, no gradient — the sector hatches and the split bar are the two exceptions, and both are patterns rather than depth.
—No emoji anywhere, in any surface, including alt text.
—Nothing centred. Everything hangs off the hard left rule.
—Numerals right-aligned and set in .num.
—Sectors are hatch patterns plus a plate code, never colour alone.
—Everything visible at rest. No scroll-triggered reveals, and motion is mechanical and short where it exists at all.

Glossary

Every term of art used across the project, alphabetised, with the figure it refers to where it has one.

Terms are defined here once and used consistently everywhere else. Where a definition carries a figure, the figure is imported rather than restated, so a term cannot come to mean something the engine disagrees with.

44 terms, sorted alphabetically ignoring leading symbols.
Term	Definition
After-Hours Raid	A launch resolving outside 09:30–16:00 ET or at the weekend. Failure probability is multiplied by 1.35 with a floor of 12.0%, and the rare-part table pays 3×.
Aura coverage	The fraction of a fleet line sitting inside a Flagship Aura. A line of hulls handed fewer slots than it has hulls draws the 20.0% bonus pro rata, never in full.
Authorised participant	The party permitted to mint and redeem a tokenized equity with its issuer. They work weekdays, which is why the weekend has no correcting force.
Bonus term	One plus the captain's weighted reward bonus plus the pro-rated aura bonus. Additive, so stacked modifiers do not compound.
Circulating float	$DONUT in circulation. It starts at 350,000,000 and is the denominator of the supply index.
Commander plate	The six hex characters a commander is named by in public, printed CMD-XXXXXX. It is a one-way derivation of their id under the game's signing key: a plate can be computed from an id and an id can never be recovered from a plate, so a ranking can say who is ahead of you without handing out who they are.
Cycle time	Flight hours plus refit hours. The real constraint on a fleet's throughput — not the wallet balance.
Daily allowance	The faucet: a fixed grant claimable once a real day, and the largest of the three ways the game issues fuel — the others being the starter tank and a claimed flight order. Every one of them is issued by the game; none of it can be bought, sold or brought in from outside, and it is not a token, an asset or convertible to one.
Dead address	0x0000…dEaD. Nobody holds a key for it, so anything sent there is destroyed rather than held.
Dispersion	The honest band drawn around a simulated result, derived from fleet-weighted sector volatility. Not a confidence interval and not a forecast.
Dividend pool	The 20% slice of every fuel payment, shared across locked hulls. The simulator models a claim at parity with the contribution.
Docket	The printed output of one simulated month. Expected-value mode has no randomness, so the same fleet always prints the same docket.
$DONUT	The fuel token. It is spent to launch expeditions and makes no claim on any share, index or stream of earnings.
Engine Part	Rare salvage. Drops at the hull's own chance per completed launch, 3× after the bell. 8 are needed for one ticket.
Expedition	One launch of one hull into one sector. The atom of the game: fuel is debited up front and never refunded.
Filtered-transactions precompile	A protocol-level facility on the target chain by which an authorised party can force a registered transaction to fail, including one force-included from the settlement layer.
Flagship Aura	The Dreadnought's perk: 20.0% reward to 8 other hulls in the same fleet, allocated to the lines that gain most.
Flight order	One of 3 tasks drawn for the world day in the played game. The board is a property of the day rather than of the commander: every commander sees the same three, nobody can reroll them, and only progress against them is private.
Flight window	Whether a fleet flies during the session only, or around the clock. It changes the character of a fleet, not just its throughput.
Fragment	The dividend-shaped reward component, denominated in USD. A simulation output, not a distribution and not income.
Green-day frequency	The assumed share of sessions closing up, per scenario: 0.75, 0.50, 0.25. An assumption, not a measured base rate.
Hatch	The pattern identifying a sector. Sectors are pattern plus plate code and never colour alone, so they survive greyscale and an 8px swatch.
Hyper-Boost	The NVDA Sector modifier: on a session closing 3.00% or better, fragments and $LONG harvested there pay 2×.
Launchpad Ticket	Crafted from 8 Engine Parts and 4 Plasma Cannons, or granted by a flagship. Intended to grant front-of-line IDO access under an integration that does not exist yet. In the played game it is a count of sets crafted and has no redemption of any kind.
$LONG	The game's own reward unit, earned by every hull except the Harvester. It is issued by the game and is not the launchpad's token, or any other third party's: no allocation of anybody else's token is implied, agreed or held. Referenced here as a reward unit in a design, not as an asset anyone holds.
Oracle	The rule set that reads the real session and decides which conditional modifiers fired. No live price feed is wired up today.
Pirate failure	The probability an expedition is lost. Volatility times 0.38 times the captain's defence factor times the after-hours multiplier, clamped at 49.0%.
Plasma Cannon	Rare salvage dropping at 0.50 of the Engine Part rate, so the two streams are matched to the recipe by construction.
Recapture ratio	Modelled return divided by fuel cost, both in USD at reference prices. Below one, the month cost more than it returned. It is a ratio inside a simulation, not a yield.
Recovery code	The whole of the way back to a fleet once the cookie is gone. It is minted once, shown once and never stored: the database holds only a digest of it, so nobody — the operator included — can recover a commander's code, and rotating the signing key retires every code along with every session.
Refit	The hours a hull is unavailable after a flight, before it can launch again.
Refit tier	One of 3 upgrades a hull can be fitted with in the played game, bought with salvage rather than fuel. The tier is recorded on the expedition at departure, so a refit bought while a hull is out cannot enrich the flight that left before it was fitted.
Salvage	The 20.0% of cargo a lost expedition still returns. It is why the survival factor is a haircut rather than a wipeout.
Sector	One of the four harvest regions. Two numbers define it: a yield multiplier and a volatility value between 0 and 1.
Session	The US regular session, 09:30–16:00 ET, 21 of them in a modelled month.
Stage 0	The lowest of L2BEAT's three decentralisation stages. It means the operator retains powers a mature rollup would have given up.
Supply eaten	How burned fuel is labelled on a public standing and on a share card. It is fuel a commander destroyed inside a game whose fuel comes from a faucet — not a burn of anything that exists outside it, and the card says so on its face.
Supply index	Float divided by the initial float, clamped to 0.05–1.00. Burning lowers it, which lowers fuel cost.
Survival factor	The expected fraction of cargo that comes home. Expected value across many launches; any single expedition either lands or does not.
Tape	The ticker rail across the top of the site. It runs sample rows and prints SAMPLE FEED alongside them.
Uptime	The share of the theoretical launch ceiling a commander actually keeps, between 10% and 60%. A human input, and the default is generous.
Verification status	Verified, reported or unresolved. Applied to every researched claim, and never upgraded to make a sentence read better.
World day	The shared day the played game resolves against: its date in the session's own zone, whether the close was green, and whether Hyper-Boost armed. Derived from a keyed hash of the date rather than read from a market, so two commanders landing in the same session get the same modifiers and neither can shop for a better one by reloading. It is a substitute for a feed, not a description of one.
Yield multiplier	The sector's flat multiplier on everything harvested there. Compensation for volatility charged twice, on the fuel bill and on the failure rate.

FIG. 14.144 terms, sorted alphabetically ignoring leading symbols.

Open questions

What is genuinely unresolved — in the research, in the model, and in the design — stated as questions rather than quietly settled in the project's favour.

A reference document is only useful if it is as clear about its holes as about its contents. Everything below is open. None of it is presented as a risk that has been managed, and none of it is a rhetorical caveat: each item would change something concrete if it were resolved one way rather than another.

Unresolved and reported research

Carried straight from src/lib/chain.ts with their own statuses. Nothing here has been upgraded for this chapter.
Item	Finding	Status
Who holds the filtering role	Not establishedWe could not determine who may filter, under what policy, or whether the power has ever been used. Anyone deploying here should assume it exists and is usable.	Unresolved
Transfer model	Deny-list, not allow-listAcross the major issuers, KYC gates primary mint and redemption rather than transfer. Documentation and reporting agree on this; we have not read the deployed bytecode ourselves, and until someone does it should not be treated as settled.	Reported, not checked
Third-party equity-referencing tokens	Effectively closed to retail in the USA token issued by a third party that references someone else's equity is treated as a linked security or a security-based swap, which cannot be sold to ordinary retail without registration and an exchange. This is the single reason $DONUT is fuel and references nothing.	Reported, not checked

FIG. 15.1Carried straight from src/lib/chain.ts with their own statuses. Nothing here has been upgraded for this chapter.

Nobody has read the tokenized-equity bytecode

The transfer model of the deployed equity-token contracts is reported, not verified. Documentation and reporting agree that KYC gates primary mint and redemption rather than secondary transfer, but no one has read the deployed bytecode, so free transferability is an unchecked property. Any mechanic that assumes those tokens move freely is resting on something nobody has looked at, and this project does not print it as a fact anywhere.

Who holds the chain's transaction-filtering role

The precompile is verified to exist and to be able to force a registered transaction to fail, including one force-included from the settlement layer. Who may register a hash, under what policy, with what oversight, and whether the power has ever been exercised are all unestablished. The conservative assumption is the working one: the capability exists, it is usable, and a transaction can be made to fail irrespective of what a game contract would otherwise do.

Open questions in the model and the design

These are balance and design problems the concept is still being worked against, not defects with fixes waiting to be applied.
Question	Where it stands
Can a 10% treasury slice fund the reward faucet at the rates the model produces?	Not established. The simulator flags recapture above 1.25× as unproven precisely because nothing has been balanced to sustain it, and several ordinary fleet configurations reach that flag.
Does the dividend-pool parity assumption survive contact with a real field of players?	Unknown, and it is the flattering case. Parity returns a commander's own contribution as their claim; no mechanism guarantees it, and the recapture ratio leans on it.
Are the green-day frequencies of 0.75, 0.50 and 0.25 anywhere near real base rates?	They are scenario assumptions, never measured. Replaying the oracle rules against historical session data is scheduled work that has not been done.
Is a default uptime of 55% a reasonable human input?	It is generous, and it is the single input with the largest effect on a docket. The control spans 10% to 60% for that reason.
Where does the oracle get its data, and under what licence?	Unresolved. No feed is wired up, no vendor has been chosen, and market data licensing is a real constraint on any design that resolves rewards against real closes. The played game sidesteps the question rather than answering it: it derives the day's flags from a keyed hash of the date, which is honest about describing nothing, and is not a route to a design that resolves against the real market.
What happens to tickets and $LONG if the launchpad integration never exists?	Open. The design has no second sink for either, and the flagship would need rebalancing around Flagship Aura alone.
Can every commander's public page still be resolved as the board grows?	No, and the code says so where it happens. A plate is one-way, so it has to be matched rather than decoded, and the only listing the store exposes is the burn ranking — which is read up to a fixed ceiling. A commander below that ceiling cannot be resolved from their plate and their page reports that it cannot find them. The honest fix is a lookup by plate in the store itself; until then this is a known limit rather than a rare bug.
Does concentrating rare-part supply in the riskiest hours produce a game anybody wants to play?	Untested. The night is where the 3× table lives and also where failure probability is highest; whether that reads as a real choice or as a tax on sleep is not yet known.
Will any of this be built?	Genuinely open. Today the project is a design document, a simulator, a small played game keeping its own state in its own database, and a set of numbers still being balanced. Nothing is deployed on any chain, audited or funded, no launch date is being promised, and a concept in this state may simply not be built.

FIG. 15.2These are balance and design problems the concept is still being worked against, not defects with fixes waiting to be applied.

The docs state the system. The simulator runs it, the litepaper argues it, and the burn page shows the same arithmetic from the supply side.

Run the simulator Litepaper Burn engine Fleet and captains