TheRON/otivm
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
TheRON
2026-05-06 14:53:05 -04:00
parent 915f0a285e
commit 65d0935353
1 changed files with 597 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

597
docs/DINARII-GENESIS-0002.md Normal file
View File

@@ -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.*