From 65d09353530720f080fa97e5c20748f79e0260a7 Mon Sep 17 00:00:00 2001 From: TheRON Date: Wed, 6 May 2026 14:53:05 -0400 Subject: [PATCH] =?UTF-8?q?docs:=20add=20Dinarii=20genesis=20v2=20?= =?UTF-8?q?=E2=80=94=20hardware=20foundation,=20AERARIVM,=20argentarius?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/DINARII-GENESIS-0002.md | 597 +++++++++++++++++++++++++++++++++++ 1 file changed, 597 insertions(+) create mode 100644 docs/DINARII-GENESIS-0002.md diff --git a/docs/DINARII-GENESIS-0002.md b/docs/DINARII-GENESIS-0002.md new file mode 100644 index 0000000..9ca16bc --- /dev/null +++ b/docs/DINARII-GENESIS-0002.md @@ -0,0 +1,597 @@ +# 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.*