# DINARII — Genesis Document ## The Monetary Consequence Layer of CIVICVS-ROMAN ### Version: 2.0 — Canonical ### Date: 2026-05-06 ### Status: Approved genesis. Not an implementation commitment. ### Repository path: docs/dinarii/DINARII-GENESIS-0002.md ### Supersedes: DINARII-GENESIS-0001.md --- ## 0. The Governing Sentence ``` The coin must be real enough to discipline behavior. The grant must be equal enough to begin fairly. The weather must be honest enough to matter. ``` Roman-visible form: ``` Every colonist receives the same land. What they build on it is their own. The harvest depends on the year. ``` --- ## 1. What Dinarii Is Dinarii is the monetary consequence layer of the CIVICVS-ROMAN simulator. It exists because a Roman market simulator cannot model consequence with make-believe wealth. A purse that cannot be exhausted teaches nothing. A permit that costs nothing governs nothing. Labor unpaid is not labor hired. A treasury without scarcity is not a state. Dinarii is therefore not an ornamental reward system. It is not a play-to-earn product. It is not an investment vehicle. It is not a promise of profit. It is the mechanism by which monetary pressure enters the simulation — grounded in real value, bounded by design, transparent by architecture, and Roman-visible at every interface the participant touches. --- ## 2. The Three-Layer Foundation The CIVICVS stack restores three forms of friction that compound: ``` TESSERA — distance is real terrain, route cost, elevation, biome, H3 substrate OTIVM — obligation is real markets, labor, permits, taxation, transport, accounts, information delay, commercial pressure Dinarii — value is unstable monetary consequence, scarcity, settlement pressure, weather, the treasury that governs what the state can do ``` These are not independent decorations. A merchant navigating TESSERA terrain carries goods whose value is denominated in Dinarii that fluctuate while he travels. By the time he arrives, the price has moved. The road made the price old. --- ## 3. The Hardware Foundation ### 3.1 The CVSTOS Device CIVICVS participants are provisioned through a CVSTOS device — an ESP32-S3 hardware wallet in a 3D-printed cradle that anchors identity to physical location through a six-element convergence: ``` Placekey — geographic location identifier H3 cell — hexagonal grid encoding of coordinates IP address — network endpoint at provisioning time Timestamp — position in the append-only attestation sequence Ed25519 keypair — device public key, generated on hardware RFC CID — SHA-256 of the governing RFC, published to IPFS ``` This convergence is arithmetic applied to public facts about physical reality. No institution can own, falsify, or revoke it. The binding between device and location is prior to any legal or commercial claim. The CVSTOS device is the participant's title deed. It is not a wallet in the crypto exchange sense. It is a location witness that speaks for a Placekey, not for an individual. Every provisioning event is recorded in a hardware-witnessed, append-only attestation sequence and published to IPFS as an immutable CID. Physical possession is the prerequisite for the highest trust operations. This cannot be replicated remotely. ### 3.2 Hardware Sale as the Monetary Foundation The CVSTOS device is sold. The sale price covers two things: ``` Manufacturing cost + operational infrastructure cost → project sustains itself without extracting from participants Remainder → allocated to the AERARIVM — the Roman treasury → denominated in BAT → held in a project wallet → distributed to participants as grants at container formation ``` This structure means participants never buy crypto. They buy hardware. Hardware sales are commerce. The monetary consequence they receive is a grant — their share of what they already paid for, returned in the form the simulator requires. No profit promise. No yield. No appreciation guarantee. The coin opens the seal. It does not promise a fuller purse. --- ## 4. The AERARIVM — The Roman Treasury ### 4.1 What It Is The AERARIVM SATVRNII — the Roman treasury — is the project's BAT wallet, funded by hardware sales, governed by the simulation's needs. It is not the project's revenue fund. Operational costs are extracted before the BAT allocation is made. What enters the AERARIVM is what the simulation is permitted to use. The AERARIVM is real. Its balance is verifiable. Its disbursements are recorded. When it is low, the state is genuinely constrained — roads are not repaired, guards are unpaid, permits are delayed. This is not flavor text. It is a real BAT balance that ANNALES can read. ### 4.2 The 80/20 Division At container formation: ``` 80% of AERARIVM balance → distributed equally as participant grants → one grant per provisioned CVSTOS device → all grants equal within a container → converted to simulator denarii at argentarius rate 20% of AERARIVM balance → reserved for state operations → funds permits, road repair, guard payment, public works, treasury obligations, state responses to shocks → written by CT 1103 (aggregation container) → read by CT 1105 (game server) to determine state capacity ``` The 80/20 split is a governance decision. It may be revised by the project owner with documented justification. It is not a technical constraint. ### 4.3 The Grant Is Not Equal Forever — Only at Entry Every participant in a container receives the same grant at provisioning. What they build on it is their own. A container that forms when BAT is strong starts with more denarii per participant than one that forms when BAT is weak. This is monetary weather entering the simulation at the first moment. It is historically defensible — Roman colonists received different land grants depending on the wealth of the founding expedition, the generosity of the sponsor, and the state of the treasury at the time. Lucky Romans and complaining Romans are both authentic Romans. The simulation is honest from the first moment. --- ## 5. The Argentarius — The Money Changer ### 5.1 The Institution The *argentarius* — the Roman money changer — is the interface between external monetary reality and the simulator's internal Roman-visible world. He sits at his *mensa*. He accepts BAT from the AERARIVM at the prevailing rate. He issues simulator denarii. He records every conversion in his *codex accepti et expensi*. He takes his fee, which is explicit, standard, and part of the record. His *fama* — his published audit record — is open to inspection. The argentarius does not care what rail funded the treasury. He cares whether the coin is good, the weight is honest, and the books balance. ### 5.2 The Conversion Event The conversion happens once per participant, at provisioning: ``` 1. CVSTOS device completes convergence event → founding document published to IPFS → attestation sequence records the provisioning 2. Argentarius reads treasury BAT balance → calculates grant: (AERARIVM * 0.80) / 128 → applies current argentarius rate (BAT → denarii) → records conversion in codex 3. Codex entry is JSON, written to CT 1103 database → immutable record of: participant key, container ID, BAT amount, denarii amount, rate applied, timestamp, CVSTOS attestation CID 4. CT 1105 receives provisioning signal → seeds player account with denarii grant → player enters the simulator 5. CVSTOS attestation sequence records the grant event → the grant is hardware-witnessed → verifiable without CIVICVS infrastructure → the participant holds proof in their device and custody USB drive ``` ### 5.3 Roman-Visible Language The infrastructure knows BAT. The simulator speaks Latin. ``` Preferred: The purse is full at the start of the year. The treasury was generous when the colony was founded. The coin bought more grain before noon. The laborers will not take yesterday's promise. Never in Roman-facing output: Your BAT grant has been converted. The token balance is insufficient. Your wallet requires top-up. ``` The modern rail remains beneath the Roman ontology. --- ## 6. Monetary Weather ### 6.1 The Core Claim Crypto volatility is not merely a technical risk. In this simulator it is a designed feature — a modern proxy for ancient value uncertainty. A Roman trader did not act inside a world of universal, instantly visible, institutionally guaranteed price. He acted under: ``` old information seasonal pressure bad roads spoilage local scarcity political attention rumor coin quality credit pressure transport delay trust state demands witnesses ``` Dinarii does not erase this uncertainty. Dinarii exposes participants to it in bounded form. ### 6.2 What Monetary Weather Produces Participants experience questions such as: ``` Should I pay labor now or wait? Should I hold coin or buy grain? Should I trust yesterday's rate? Should I move goods before news arrives? Should I settle debt before the treasury changes terms? Should I accept barter when coin is unstable? Should I preserve reputation at monetary loss? Should I hoard and risk civic suspicion? ``` These are Roman commercial questions. They are also the behavioral signals that the simulation is designed to record. ANNALES reads the records these decisions produce. The Market prices goods accordingly. The data warehouse fills with authentic behavioral evidence. ### 6.3 Container-Specific Monetary Conditions Containers that form at different times under different BAT prices experience different monetary conditions from the first moment. This is not a bug. It is a comparative simulation feature. Different containers can experience different monetary weather. Promotion criteria should consider not just what a participant achieved but what conditions they achieved it under. A merchant who built a solvent trading operation in a lean container demonstrates more than one who did the same in a rich one. The ANNALES assessment reflects this. The attestation sequence records it. --- ## 7. The 128-Participant Container ### 7.1 Why 128 128 is a design limit, not a technical one. It is large enough for specialization, trade, rivalry, scarcity, reputation, fraud, alliances, labor markets, route control, public works, and state pressure. It is small enough for memory, accountability, recognizable actors, local history, manual review, and social consequence. 128 CVSTOS devices sold = one container provisioned. The container size is determined by hardware sales, not by server configuration. This is the correct alignment — the simulation's social scale is governed by the physical reality of who has bought in. ### 7.2 What a Container Includes ``` 128 active participants with equal starting grants Bounded terrain region in TESSERA Resource access governed by occ_flag data Local routes with real cost structures State office presence Labor availability responding to wage, reputation, season Permits required for extraction and activity Storage with real capacity constraints Public works requiring treasury funding Tax flows to the AERARIVM reserve Local treasury governed by the 20% reserve Obligation records in OTIVM player databases Dispute records readable by ANNALES Reputation state visible to ANNALES and other participants Promotion gate governed by Roman-world viability criteria ``` ### 7.3 State Treasury Mechanics The state treasury draws from the AERARIVM reserve: ``` Permit fees → treasury (inflow) Tax receipts → treasury (inflow) Fines → treasury (inflow) Road repair → treasury (outflow) Guard payment → treasury (outflow) Public works → treasury (outflow) Clerk administration → treasury (outflow) ``` When the treasury is empty, state action is constrained: roads are not repaired, guards are unpaid, permits are disputed, public works stop, state trust weakens. The treasury is a working account, not flavor text. The AERARIVM balance is publicly verifiable — any participant with their custody USB drive and IPFS access can confirm the founding grant and the reserve allocation. The state cannot lie about its accounts. Neither can the participant. --- ## 8. Promotion — What Passes the Gate Promotion from one container level to the next does not reward raw wealth alone. A rich purse with rotten books does not pass the gate. ANNALES reads the behavioral record. The promotion assessment considers: ``` Credible books — RATIO, TABVLA records coherent and witnessed Solvency — DEBITVM resolved, no outstanding MORA pressure Tax compliance — vectigal paid, no edictvm violations State confidence — low DOLVS exposure, no FVRTVM findings Labor reliability — workers paid, obligations honored Route development — new routes opened, existing routes maintained Food and storage stability — supply chains functioning Public works contribution — treasury obligations met Dispute resolution — PACTVM honored, conflicts resolved Shock survival — container survived monetary weather events Low fraud — ANNALES found no systematic deception ``` Capital may help. Capital cannot substitute for trust, records, labor, and public order. A participant who survived a lean container with clean books and solvent accounts demonstrates more than one who spent freely in a rich one. The gate measures Roman-world viability. --- ## 9. Risk Posture ### 9.1 What This Is Not Dinarii must not posture as any of the following: ``` Investment product Play-to-earn platform Yield system Exchange Broker Bank Money transmitter Gambling product Employment marketplace Official account-resale market ``` The project operates a simulator. It sells hardware. It distributes grants from a treasury funded by those sales. It does not promise profit, yield, appreciation, or cash-out. ### 9.2 Custody Boundary The project minimizes custody of participant value: ``` Preferred: Hardware sale funds treasury Treasury holds BAT in project wallet Grant allocated at provisioning, recorded in attestation Participant operates in simulator denarii No ongoing custody of participant funds Higher risk (avoid): Project holds pooled participant crypto Project transfers crypto between participants Project guarantees balances Project redeems simulator state for money Project brokers participant-to-participant value ``` ### 9.3 Account Value Developed accounts may accumulate: ``` Reputation Permits Routes Warehouse access Labor relationships State favor Settled books Counterparty trust Local knowledge Resource claims ``` This value does not defeat the mission. It proves the simulation creates meaningful economic state. The project does not price accounts, broker account sales, or guarantee resale value. If account control changes occur, they behave as Roman succession: assets may move, standing may not, obligations follow the books. A name is not a purse. ### 9.4 Legal Review Triggers Legal review is required before: ``` Any participant cash-out mechanism Official account resale support Project custody of participant balances beyond treasury Participant-to-participant settlement operated by the project Labor payments inside gameplay Profit-oriented marketing Custom token issuance Jurisdiction expansion beyond initial deployment Minor participation with real value Large transaction sizes KYC/AML-sensitive activity ``` Before these points: small-stake, non-promotional, minimal-custody. --- ## 10. The CVSTOS Connection — Trust All the Way Down The CVSTOS attestation sequence is the trust anchor for every monetary event in the simulation: ``` Hardware provisioning → convergence event → founding document → IPFS CID Grant allocation → recorded in attestation → IPFS CID Every significant simulator event → potentially anchored through CVSTOS ``` A participant who disputes their grant can verify it with their custody USB drive and any IPFS gateway. No CIVICVS infrastructure needs to be running. The document is self-verifying against public infrastructure alone. This is Roman commercial practice expressed in modern cryptographic architecture. The argentarius's codex is content-addressed, hardware-signed, append-only, and anchored to physical reality. A disputed conversion can be verified by anyone. No CA, no registry, no institutional intermediary in the critical path. The citizen is the protected party. The infrastructure serves the homeowner, not the institution. --- ## 11. The SVCCINUM Thread The amber a Roman merchant holds in OTIVM may have originated in Maglemoisian forests approximately 8000 BCE — traceable to a specific H3 cell in TESSERA where a CIVICVS constructor gathered or traded it. When the participant who holds that amber also holds a CVSTOS device provisioned at a specific physical location, and that location's founding document is anchored in the attestation sequence, and that sequence records the grant that funded the merchant's starting purse — — the chain from 8000 BCE to the participant's physical address is complete. TESSERA holds the origin. OTIVM holds the commerce. CVSTOS holds the identity. Dinarii holds the value. ANNALES reads it all. This is what the data warehouse is. This is why the simulation is worth building. Do not lose this thread. --- ## 12. The Stack — Complete ``` TESSERA — distance is real H3 substrate, terrain, route cost, occ_flag, epoch transitions DESCENSUS — the filtering rule epoch boundary, what survives the crossing OTIVM — obligation is real commercial mechanics, behavioral sub-trace, exchange records ANNALES — the city remembers Oracle reads records, activates tokens, assesses standing Dinarii — value is unstable AERARIVM, argentarius, grants, monetary weather CVSTOS — the guardian hardware identity, attestation, trust anchor SIMULATOR — 128 participants, runs once, forward only the instrument the entire stack was built toward ``` Three forms of friction, compounding: ``` TESSERA: distance is real. OTIVM: obligation is real. Dinarii: value is unstable. ``` The data warehouse is the product. The simulation is the instrument that fills it. The instrument can be replicated. Rome is the first instantiation. --- ## 13. What This Document Does Not Commit To - A launch date or development timeline - The exact BAT/denarii argentarius rate formula - The specific argentarius fee structure - The exact promotion criteria weights - A technical architecture for CT 1103 aggregation - A commercial model or licensing arrangement - A specific set of participant roles beyond examples named - The exact 80/20 treasury split as permanent (governance decision) These are open. The genesis is the frame. The frame is stable. Everything within it is subject to design work that has not yet begun. --- *DINARII — Genesis Document v2.0* *2026-05-06* *TheRON — single contributor.* *AI assistants implement, document, flag — do not direct.* *A decision recorded here is not revisited without new argument* *presented to the project owner.* *The purse is small, but the books are real.* *The coin has a face, but not a fixed weight in every hand.* *Every colonist receives the same land.* *What they build on it is their own.* *The harvest depends on the year.*