The OS family
odinOS genericised into a template, so the communities ODIN pairs with get one too — and a portal connecting them.
odinOS was built for ODIN. Then its shell was separated from its contents, so the same thing could be built for the communities ODIN's pools pair against.
Engine and pack#
The template splits in two:
- The engine — window manager, boot sequence, mobile handling, the portal. Structural, identical everywhere.
- The pack — assets, copy, apps, data sources, identity. Specific to one community.
Each OS is a pack; the engine underneath is untouched. Engine improvements flow to every OS at once, and pack work can't break the shell.
odinOS itself doesn't run on the kit. It's frozen at its own version — the kit was extracted from it. The same Engine Principle one level up: the working thing keeps working, and the generalisation happens beside it.
The OSes#
Same engine, different pack, each for a token ODIN's pools already pair against — and each with its own laws about what it will and won't say.
| OS | Community | Something it establishes |
|---|---|---|
| odinOS | ODIN | The original — depth, LF, the sixteen pools |
| dbiOS | Don't Buy Inu | Games with true odds and no house edge |
| cryptoOS | $crypto | Solana and Ethereum both; the shell wears the market, the numbers don't |
| tsukaOS | Dejitaru Tsuka | Built on current philosophy, deliberately no origin story |
| btcOS | Bitcoin | Block zero, no contract address; derive rather than fetch |
Each pack has its own copy law
Enforced in code, not a style guide:
tsukaOS: the community's words and the chain's numbers never share a panel. A quotation and a figure in the same frame implies the first endorses the second.
cryptoOS: a picture names its mint. Otherwise a picture is an assertion about provenance nobody made.
dbiOS: true odds, no house. A game that teaches probability while quietly taking a cut teaches the wrong lesson.
btcOS: derive, don't fetch. Bitcoin's supply is computable from consensus rules; fetching it from an API adds a dependency where mathematics would do.
The pattern: the constraint comes first, the design accommodates it. Same discipline as ODIN's own copy rules — every one prevents a specific way of misleading someone.
The portal#
Every OS built from the kit ships a portal — a ◎ that opens THE NEXUS, from which the other OSes are reachable. The roster is defined per-pack, and one rule took a ruling to settle:
No gate ever carries a figure.
A gate is a door, not a dashboard. A number on a gate turns "here is another community" into a comparison, and a comparison between communities of different sizes, ages and purposes is a ranking nobody asked for.
A gate with a destination is awake. A gate without one stays honestly dormant.
Why do this#
ODIN's pools pair against community tokens because those communities are part of the mechanism, not an audience for it. A community with a genuinely good surface for understanding its own network is a stronger community.
Practically: the judgement that makes a good surface — what to show, what to refuse to show, when a number would mislead — currently gets transmitted one conversation at a time. A template that encodes those constraints structurally transmits them instead.