docs: add Dinarii genesis v2 — hardware foundation, AERARIVM, argentarius

2026-05-06 14:53:05 -04:00
parent 915f0a285e
commit 65d0935353
1 changed files with 597 additions and 0 deletions
--- a/docs/DINARII-GENESIS-0002.md
+++ 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.*