NEXUS COMPASS — 2026-08-17¶

Sovereign Blockchain · HD Keyring · Stealth Payments · Vestal Protocol · ZK-STARK Stack¶

Status: 🔵 DESIGNED — conceptual architecture, no code built yet
Session focus: Privacy-first OS-native blockchain, rotating keys, creator monetization, pruning consensus, full ZK sovereignty stack
Connects to: NeXiuM · DivaChain · Ghost Gate · Proof-of-Witness · nexus-keyring (NEW) · Vestal Protocol (DEFINED) · veedo · winterfell · starknet-privacy · OpenZKP

1. The CA De-Anonymization Problem¶

What was discovered¶

The NeXuS CA (step-certificates, local step-ca) was identified as a potential de-anonymization vector. The concern: if public metadata from a cert is observed by an external party, it fingerprints the node operator.

What leaks from a TLS cert¶

Data point	Risk
`O=NeXuS CA, CN=NeXuS CA Intermediate CA` in issuer	Identifies operator as NeXuS
SAN `192.168.1.15`	Reveals LAN IP — node-specific
Root fingerprint `99f174...`	Correlates all certs from same CA
Key linkability	Same key across sessions = same node

What does NOT leak (current setup)¶

CA listens on 127.0.0.1:9000 only — no external exposure
Private CA — zero CT log submissions
No OCSP requests to external servers

The rule derived¶

For .onion and .i2p services: no TLS certs needed at all. Tor and I2P have self-authenticating naming — adding TLS adds a fingerprint where none existed. TLS certs are for LAN-to-LAN node communication only.

2. The Anonymity Set Solution — Uniform Public Metadata¶

The concept¶

All NeXuS nodes present identical public metadata — same org name, same cert template, same SAN pattern. An observer can identify a node as a NeXuS node but cannot identify which NeXuS node or whose node.

This is the same principle as Tor Browser — all users present identical fingerprints. The fingerprint identifies the crowd, not the individual.

Standardized cert template (NeXuS Node Standard)¶

Subject:   O=NeXuS Network, CN=nexus-node   ← same for ALL nodes
SANs:      localhost, 127.0.0.1, local.host.local  ← NO real IPs
Issuer:    O=NeXuS CA, CN=NeXuS CA Intermediate CA ← shared root
Algorithm: ECDSA P-256
Duration:  24h (rotates daily)
Key:       UNIQUE per node, ROTATES per epoch

What's shared vs unique¶

Layer	Standardized (public)	Unique (private)
Root CA	Same cert ships in every .sfs	—
Cert template	Subject, SANs, duration, algorithm	Private key per node
Response headers	Same server header (or none)	—
Node behavior	Same port layout, same API shape	Config, content

.sfs connection¶

The NeXuS root CA ships inside nexus-base.sfs. Every node booting from it inherits the same public identity. On first boot a script generates the node's unique private key, signs a cert from the shared CA using the locked template. No deviation allowed.

3. HD Key Rotation — nexus-keyring¶

The core design¶

Inspired by virtual credit card one-time-use numbers and HD (Hierarchical Deterministic) wallets. The master key never leaves the machine. From it, the node continuously derives ephemeral child keys that rotate automatically.

password + local_random_seed
         ↓ HKDF / PBKDF2 (200,000 rounds)
    master_secret  ← never transmitted, never leaves disk, encrypted at rest
         ↓ derive(unix_epoch // rotation_interval)
    child_key_001  → TLS cert valid 24h
    child_key_002  → TLS cert valid 24h  (rotates in, 001 discarded)
    child_key_003  → ...

Key derivation detail¶

seed_file  = /dev/urandom 32 bytes   ← stored encrypted (age)
master     = HKDF(PBKDF2(password, seed_file, 200000), "nexus-v1")
child_key  = HKDF(master, str(epoch // rotation_seconds), "nexus-cert-v1")

Neither half alone is useful: - Seed without password → useless - Password without seed → useless - Together → unlock derivation chain

Privacy properties achieved¶

Property	Mechanism
Unlinkability	Two certs from same node have different public keys — cannot correlate
Forward secrecy	Old keys discarded — past sessions not decryptable if current key compromised
Shared anonymity set	Issuer = NeXuS CA — observer knows it's a NeXuS node, not whose
Recovery	`password + seed file` → re-derive current epoch key
No online master	Master never hits the network — only derived children do

Precedents¶

Tor relays: onion service keys rotate on schedule
Signal: pre-keys rotate after use
BIP32 HD wallets: master seed → child keys, master never transmitted

nexus-keyring tool design (not yet built)¶

nexus-keyring init
  ├── generates random_seed (256 bits, age-encrypted to password)
  ├── derives master_secret → stays in kernel keyring (keyctl)
  └── writes seed file to ~/.config/nexus/keyring/seed.enc

nexus-keyring rotate
  ├── derives child_key = HKDF(master, current_epoch)
  ├── generates CSR, sends to local step-ca
  ├── atomic swap: write new cert.pem + key.pem
  └── SIGHUP to web server → zero-downtime cert reload

nexus-keyring daemon
  └── OpenRC service, auto-rotates on schedule, fully silent

Session decrypt (the time machine property)¶

The master never rotates. Child keys are derived deterministically from master + epoch. To decrypt a session from 6 months ago: derive the key for that epoch, decrypt. The master is the time machine. This is the property the user described as "go back to a previous session and be able to decrypt."

Rotation interval recommendation¶

LAN nodes (rarely externally observed): 24h
Higher-exposure nodes: 6h or 1h
step-ca issues certs in milliseconds — rotation cost is negligible

4. Stealth Addresses — Creator Monetization Without Identity¶

The problem¶

A creator publishes a recipe book (or any content). They want to continue receiving payment indefinitely without ever being identified. Payments must be: - Unlinkable (each payment goes to a different address) - Uncorrelatable (no observer can link payments to the same recipient) - Claimable by the creator at any time (even months later) - Uncorrelatable to the creator's identity

The solution: stealth addresses (Monero's model)¶

The creator holds a stealth meta-address — a pair of public keys:

scan_pub   ← used to find incoming payments (can be shared with auditor)
spend_pub  ← used to claim payments (never shared)

The stealth meta-address is embedded in the content at creation time, signed by the creator's key. The signature proves the address belongs to the original author without revealing who that author is.

Payment flow¶

1. Buyer sees content with embedded stealth_meta_address
2. Buyer's client generates ephemeral key r
3. one_time_address = hash(r × scan_pub) × G + spend_pub
4. Payment sent to one_time_address (looks random to all observers)
5. r embedded in transaction (public, meaningless without scan_priv)

Creator scanning (can happen at any time, even years later)¶

for each transaction:
    check: hash(scan_priv × r) × G + spend_pub == this address?
    if yes → this payment is mine
    derive spend_key = hash(scan_priv × r) + spend_priv
    claim the payment

What an observer sees¶

A payment to a random-looking address
Cannot link to creator identity
Cannot link to other payments from the same content
Cannot link to other payments to the same creator
Creator could be dead — their estate scans with master key to claim 10 years of royalties

Perpetual royalties — the content carries the rule¶

recipe_book.nxs
  ├── content (encrypted)
  ├── stealth_meta_address = (scan_pub, spend_pub)
  ├── royalty_rate = 0.15
  └── creator_sig  ← proves address belongs to original signer
                     without revealing who the signer is

The royalty rule travels with the asset. Every compliant NeXuS node serving or relaying the content routes the royalty cut to the stealth address. Non-compliant nodes violate protocol and are treated accordingly by the network.

Scan efficiency at scale¶

Monero solves bulk scanning via view tags — a 1-byte hint attached to each transaction. Lets the scanner skip 99%+ of transactions without full computation. NeXiuM inherits this.

5. Why Global Smart Contract VMs Are Incompatible With NeXuS¶

The fundamental conflict¶

Requirement	Global smart contract chain	NeXuS values
State	Everyone holds a copy	Local-first, sovereign
Execution	Every node runs every tx	Private, need-to-know
Visibility	All transactions public	Stealth
Network dependency	Must be online	Self-sufficient
Storage	Terabytes of history forever	Minimal, prunable
Consensus	Global agreement on everything	Async, local-first

Monero was the chosen payment rail — correctly. But Monero has no smart contract VM, by design. RGB (client-side contracts) was previously considered but is Bitcoin-native and adds complexity. The re-evaluation landed here:

A global VM is the wrong tool entirely. NeXuS doesn't need to follow anyone's architecture.

6. The NeXuS-Native Blockchain — OS-Integrated, State-Only, Prune-After-Consensus¶

The unprecedented insight¶

No blockchain exists that is part of an OS. No OS has a blockchain as a native primitive. Every blockchain runs on an OS. NeXuS flips this: the blockchain IS part of the OS. The node is not an app. State sync is like syncing the clock — it just happens at the OS level.

This is a genuine architectural first.

The pruning insight¶

Traditional blockchains keep full history because history is the proof of current state.

NeXuS inverts this: consensus on current state IS the proof. History is scaffolding.

Once all nodes agree on "who has what" and that agreement is cryptographically signed — the transactions that produced that state are no longer needed. You needed the scaffolding to build the floor. Once you're standing on it, the scaffolding comes down.

The block structure¶

Block N:
  ├── state_root      = merkle_hash(all current balances + capabilities)
  ├── delta           = compressed diff from block N-1 state
  ├── consensus_sigs  = signatures from participating nodes
  ├── timestamp
  ├── prev_state_root = links to block N-1 (proves continuity)
  └── zk_proof        = proves this state transition is valid
                        without revealing individual transactions

Block N transactions: PRUNABLE after block N is finalized and dispute window passes

Consensus flow (before each block)¶

1. Collect all transactions since block N-1
2. Each node computes resulting state (who has what)
3. Nodes exchange state_root hashes
4. If supermajority agree on same state_root → block finalized
5. ZK proof generated: "state N is valid transition from state N-1"
6. Transactions that produced this state → scheduled for pruning
7. After dispute_window expires → transactions deleted
8. Only state_root + delta + zk_proof survive

ZK proofs — the mechanism that makes pruning safe¶

ZK proof: "state_root_N is a valid transition from state_root_N-1"
         ← verifiable in milliseconds by any node
         ← reveals nothing about individual transactions
         ← cryptographically proves history without storing history

New node joining the network: 1. Downloads current state snapshot (who has what right now) 2. Downloads ZK proof chain (proves this state is valid) 3. Fully verified and operational in seconds 4. Does not need a single historical transaction 5. Does not need to replay years of blockchain history

Storage comparison¶

Chain	Storage	New node sync	History
Bitcoin	~600GB	Days	Forever
Ethereum	~1TB+	Days–weeks	Forever
NeXuS	Current state + dispute window only	Seconds	Pruned after consensus

The dispute window¶

The only history retained is the dispute window — long enough for any participant to challenge a fraudulent state transition. Suggested: 72 hours to 7 days depending on the application. After the window: every transaction is gone. Only the ZK proof of the finalized state survives.

Precedents (partial implementations, never OS-integrated)¶

Mimblewimble (Grin, Beam) — transaction cut-through: intermediate txs disappear, chain shrinks
Nano — each account has its own chain, only current balance matters
Ethereum stateless clients — clients with no history, only state proofs (still global VM)
Celestia — separates data availability, execution, consensus (still external to OS)

None are OS-integrated. None achieve full prune-after-consensus. NeXuS combines all insights and goes further.

"Who has what" is broader than money¶

When the blockchain is IN the OS, "who has what" means: - Balances (NeXiuM) - Capabilities (file permissions, access grants) - Content licenses (recipe book ownership) - Node identities (public key → node mapping) - Reputation scores (Proof-of-Witness)

The state is holistic. The blockchain is not a separate financial layer — it IS the OS permission and identity system.

Smart contracts in this model¶

Contracts are not global programs running on every node. They are state transition rules enforced locally by the OS: - The contract is a kernel policy, not a blockchain program - The OS is the VM - Parties agree on rules; the OS enforces them locally - Consensus is only about the resulting state, not the execution details

7. The NeXuS Blockchain Architecture Stack — Full Picture¶

┌──────────────────────────────────────────────────────────────────────┐
│                          NeXuS OS Layer                               │
│                                                                        │
│  ┌──────────────┐  ┌─────────────────┐  ┌──────────────────────────┐ │
│  │ nexus-keyring│  │  nexus-state    │  │   nexus-stark            │ │
│  │ HD keys      │  │  who has what   │  │   stwo Circle STARK      │ │
│  │ master→child │  │  note+nullifier │  │   M31 field, SIMD        │ │
│  │ cert rotation│  │  Poseidon trie  │  │   stwo-circuits DSL      │ │
│  └──────────────┘  └─────────────────┘  │   recursive proof tree   │ │
│                                          │   ensure-verifier-no_std │ │
│                                          └──────────────────────────┘ │
│                                                                        │
│  ┌──────────────────────────────────────────────────────────────┐     │
│  │                      Consensus Layer                          │     │
│  │  60s heartbeat (Vestal) → state_root exchange → supermajority│     │
│  │  → block finalized → recursive proof tree folds N→1          │     │
│  │  → root proof stored in nexus-fact-store → txs pruned        │     │
│  └──────────────────────────────────────────────────────────────┘     │
│                                                                        │
│  ┌──────────────────────────────────────────────────────────────┐     │
│  │              NeXiuM Privacy Payment Layer                     │     │
│  │  Notes · Nullifiers · Channels · Viewing Keys (scan_key)     │     │
│  │  ECDH + Poseidon encryption · stealth meta-address            │     │
│  │  InvokeExternal → anonymous royalty / service calls           │     │
│  │  Discovery service → view-tag scan, no full chain needed      │     │
│  └──────────────────────────────────────────────────────────────┘     │
│                                                                        │
│  ┌──────────────────────────────────────────────────────────────┐     │
│  │              Creator Economy Layer                            │     │
│  │  Dynamic bonding curve → price discovery token launch         │     │
│  │  Piecewise constant product · up to 20 price ranges           │     │
│  │  Dynamic fees · rate limiter (Ghost Gate anti-bot)            │     │
│  │  Graduation threshold → token enters Styx Colosseum           │     │
│  │  Locked LP → InvokeExternal → stealth address → forever       │     │
│  └──────────────────────────────────────────────────────────────┘     │
│                                                                        │
│  ┌──────────────────────────────────────────────────────────────┐     │
│  │              Vestal Protocol Layer                            │     │
│  │  60s heartbeat · 48h earn/vest · Loyalty Function V(t)       │     │
│  │  Springboard Economics (NeXuS Inversion) · Streak 1x→5x      │     │
│  │  nexus-vdf (VeeDo MiMC) → Black Box VRF → Obol lottery       │     │
│  │  PLUTUS Vault (Ring 02) · Styx Colosseum creature economy    │     │
│  └──────────────────────────────────────────────────────────────┘     │
│                                                                        │
│  ┌──────────────────────────────────────────────────────────────┐     │
│  │           Content / Identity Layer                            │     │
│  │  stealth_meta_address embedded in content · signed            │     │
│  │  royalty rule travels with the asset — not the creator        │     │
│  │  creator permanently anonymous at every payment step          │     │
│  └──────────────────────────────────────────────────────────────┘     │
│                                                                        │
│  ┌──────────────────────────────────────────────────────────────┐     │
│  │              Ghost Gate                                       │     │
│  │  enforcement — no node leaks beyond standard template         │     │
│  │  rate limiter enforcement at token launch level               │     │
│  └──────────────────────────────────────────────────────────────┘     │
└──────────────────────────────────────────────────────────────────────┘

Proving engine:  stwo (M31 Circle STARK) via ~/git/proving monorepo
Toolchain:       Hare + QBE + musl (Phase 3) / Rust bridge (Phase 1-2)
Unified hash:    Poseidon throughout — state, notes, nullifiers, circuits

8. The Vestal Protocol — Loyalty Baked Into Math¶

STATUS: ✅ DEFINED
Sources: ~/Pictures/nexus/The_Vestal_Protocol_Reward_Tiers.png · ~/manuals/vestal-protocol.md
Name origin: Vestal Virgins of ancient Rome kept the sacred city fire burning 24/7. A node that breaks uptime lets the NeXuS flame die.
Philosophy: Showing up is the work, and unbroken service is the proof of contribution.

What it solves¶

The network needs reliable nodes. Reliability must be incentivized mathematically, not socially. The Vestal Protocol is the Proof-of-Uptime participation and reward layer — earns nodes NeXiuM for staying online, punishes inconsistency harshly, redistributes forfeited wealth to loyal survivors, rewards long-term loyalty exponentially.

1. The Heartbeat — 60-Second Proof of Life¶

Nodes sign and submit a cryptographic heartbeat to the DIVA ledger every 60 seconds. Gap > 5 minutes → flagged Offline instantly.

This IS the consensus participation signal. The heartbeat cadence aligns with block finalization — nodes signing heartbeats are the nodes whose state_root signatures count toward consensus.

2. The 48-Hour Earn / Vest Cycle¶

Hour 0–24  — EARNING WINDOW
  Continuous unbroken uptime earns 1 Vestal Credit
  Credit is LOCKED — cannot be spent or moved

Hour 24–48 — VESTING WINDOW
  Credit vests gradually (see Loyalty Function below)
  Go offline at Hour 47 → V = 0, streak resets to zero

Hour 48    — SETTLEMENT
  Credit 100% vested → locked permanently into PLUTUS Vault (Ring 02)
  Spendable NeXiuM. Yours forever. Safe to go offline now.

3. The Loyalty Function — The Math¶

         ┌ 0                          if t < 24h
V(t) =   ┤ C × ((t − 24) / 24)       if 24h ≤ t < 48h
         └ C                          if t ≥ 48h

Where V(t) = vested credit at time t, C = total earned credit, t = continuous unbroken uptime in hours.

Time	Vested
t = 24h	0% — seed planted, nothing vested yet
t = 36h	50% — halfway through vesting
t = 48h	100% — fully vested, locked into PLUTUS Vault
Disconnect at t = 47h	0% — unvested credit fully forfeited, streak reset

4. Springboard Economics — The NeXuS Inversion¶

When a node forfeits unvested credits, those credits do not disappear. They are immediately redistributed into the epoch pool for surviving nodes.

The NeXuS Inversion: Other nodes leaving the network makes staying more valuable for loyal nodes who remain. During network stress, nodes that hold the line inherit the accumulated wealth of those who left. No death spiral — loyal nodes are paid by disloyal nodes.

This is the slashing mechanism: Byzantine nodes don't just lose their reward, they fund the honest ones.

5. Streak Multipliers and Milestones¶

Continuous Streak	Multiplier	Vesting Window	Status / Perks
1–29 days	1×	48h	Standard Node — base earning rate
30 days	2× (14-day window)	6-day vest	Vestal Badge minted on personal chain
90 days	3× (continuous)	5-day vest	Senior Vestal — The Torch is Lit
180 days	4× (continuous)	4-day vest	The Black Box opens — VRF lottery fires
365 days	5× (continuous)	3-day vest	Vestal Guardian — 2nd Black Box fires

Legendary: Vestal Guardian (365d) + all 5 Styx Colosseum seasons completed → Eternal Flame badge (ultra-rare, non-transferable)

6. The Black Box — VRF Lottery¶

Triggered at 180-day and 365-day milestones. Verifiably random, mathematically proven:

VRF_proof = sign(node_pubkey + streak_hash + block_height)

No party controls the outcome. No party can predict or manipulate it.

Obol Payout Tiers¶

Probability	Payout
40%	Ember — 50 Obol bonus
30%	200 Obol bonus
15%	500 Obol + 30-day 2× multiplier boost
8%	2,000 Obol bonus
5%	5,000 Obol + rare badge
2%	THE MOTHER LODE — massive Obol bounty + permanent Oracle Badge + permanent 1.5× yield multiplier forever

Badge Vault Drops (non-transferable, probability-curved)¶

Asphodel (15%)
The Obol (8%)
Sibyl's Mark (5%)
Hydra Scale (3%)
The Deep (2%)
Poseidon's Trident (1%)
Oracle (0.5%)

7. The PLUTUS Vault (Ring 02)¶

The secure storage ring where fully vested Vestal Credits become spendable NeXiuM. Ring 02 = the second security ring of the NeXuS key architecture. Credits locked here are permanent — they survive node restart, streak reset, or going offline after vesting completes.

Staked Obol credits can increase node priority in the network. Obol is also the currency of the Styx Colosseum — creature breeding, battling, seasonal mechanics (full Colosseum spec pending).

8. Greek Mythology Theme — The Economy Naming Layer¶

The entire economy carries a Greek underworld framework: - Obol — coin placed in the mouth of the dead to pay Charon for passage across the Styx - Styx Colosseum — the river Styx; arena for creature arcs across 5 seasons - Asphodel — the fields of Asphodel (neutral afterlife for ordinary souls) - Sibyl's Mark — the Sibyl of Cumae, oracle and prophet - The Deep — Tartarus - Poseidon's Trident — god of seas and earthquakes - Oracle — Delphi; rarest badge, permanent yield multiplier - PLUTUS — Greek god of wealth (the Vault name) - Eternal Flame — the Vestal fire itself

9. Architecture Connections¶

Vestal Protocol component	Blockchain / NeXuS role
60-second heartbeat	Consensus participation signal
Forfeiture to epoch pool	Slashing — Byzantine nodes fund honest nodes
Epoch pool	Settlement pool before block finalization
Vesting window	Dispute window analog — commit before spending
VRF proof	ZK-STARK-compatible unpredictable randomness
Streak multipliers	Long-term stability incentive for the network
PLUTUS Vault (Ring 02)	Vested NeXiuM storage security ring
Obol	Sub-currency for node priority + Colosseum economy

10. The Flame Connection¶

The Vestal Protocol IS the Flame metaphor made mathematical. The network's life force only burns as long as nodes keep it alive. Vestal Virgins didn't get days off. Neither do NeXuS nodes earning their multipliers.

9. ZK-STARKs — Why and Which¶

Why STARKs over SNARKs — The Quantum Decision¶

	ZK-SNARKs	ZK-STARKs
Trusted setup	Required — if any participant cheats, the whole system is permanently compromised	None — trustless by design
Quantum resistance	No — elliptic curve based; Shor's algorithm breaks it	Yes — hash-based; Grover's algorithm only halves security (fixable by doubling hash size)
Proof size	~200 bytes	~50–200KB
Verification	Fast	Fast
Sovereignty fit	Poor — external trust baked into cryptography	Perfect — no external dependencies

STARKs were specifically hardened against quantum computing by moving to larger field sizes and hash output sizes (targeting 256-bit security) to pre-empt Grover's algorithm. SNARKs cannot be patched for quantum — the elliptic curve foundation collapses under Shor's.

The NeXuS permanent record (STARK proofs of finalized state) must be verifiable in 50 years. STARKs survive quantum advancement. SNARKs do not.

The trusted setup is the dealbreaker: SNARKs require a ceremony where if even one participant had quantum capability at the time, the entire proof system is silently broken forever. NeXuS cannot accept that. STARKs have no ceremony.

10. The ~/git/ ZK Stack — Full Sovereign Proving Arsenal¶

All repositories already pulled into ~/git/. Not random — together they form the complete NeXuS ZK sovereignty stack.

~/git/proving                ← StarkWare unified proving monorepo (THE ENGINE)
~/git/stwo-cairo             ← Circle STARK prover/verifier for Cairo CPU (production)
~/git/starknet-privacy       ← Complete privacy protocol blueprint
~/git/veedo                  ← STARK-based VDF — Black Box randomness
~/git/dynamic-bonding-curve  ← Creator token launch + graduation economics
~/git/winterfell             ← Research STARK reference (simpler AIR study)
~/git/OpenZKP                ← Lightweight STARK verifier reference

Unified hash: Poseidon¶

All layers use Poseidon — a ZK-friendly, domain-separated hash function. Arithmetization-friendly (low constraint count in STARK circuits). Used throughout: state tree, note encryption, nullifiers, VDF constants, circuit hashing. One hash function across the entire stack = coherent and auditable.

The hierarchy¶

proving (monorepo)     ← production engine — use this
  ├── stwo             ← core Circle STARK (M31 field, SIMD)
  ├── stwo-circuits    ← circuit DSL (write NeXuS logic here)
  ├── stwo-cairo       ← Cairo CPU AIR (reference for writing NeXuS AIR)
  ├── proving-utils    ← recursive tree, privacy prove CLI, orchestration
  └── stwo-air-infra   ← AIR code generation toolchain

starknet-privacy       ← privacy model — note/nullifier/channel/InvokeExternal
veedo                  ← VDF math — Black Box delay function
dynamic-bonding-curve  ← creator economy — token launch + graduation
winterfell             ← study reference only
OpenZKP                ← lightweight verifier reference

11. VeeDo — STARK-based VDF (The Black Box Engine)¶

Repo: ~/git/veedo
Source: StarkWare
What it proves: "I ran this delay function for N iterations correctly" — nothing more, nothing less.

MiMC Delay Function¶

prime = 0x30000003000000010000000000000001  # 126-bit field
pow   = (2 * prime - 1) / 3               # cube root exponent

# Each iteration: cube → MDS matrix mix → add constants
# Repeat 335 million times → 3.5 minutes, unavoidable even with infinite parallelism

Prover inversion trick¶

The prover runs the INVERSE function (cube root → computationally cheap in the field) to generate the trace. The verifier checks the FORWARD direction. This asymmetry is why the delay is real — forward is hard, inverse is easy, verification is fast.

MDS Matrix (deployed values — use these, NOT the Sage reference values)¶

MM_MAT00 = 0x109bbc181e07a285856e0d8bde02619
MM_MAT01 = 0x1eb8859b1b789cd8a80927a32fdf41f7
MM_MAT10 = 0xdc8eaac802c8f9cb9dff6ed0728012d
MM_MAT11 = 0x2c18506f35eab63b58143a34181c89e

VeeDo's role in NeXuS¶

Use	Mechanism
Black Box VRF (180d, 365d)	`seed = node_pubkey + streak_hash + block_height` → VDF → unforgeable randomness
Block randomness beacon	Previous block hash → VDF during dispute window → next block's canonical randomness
Anti-grinding	3.5-minute delay prevents grinding lottery outcomes regardless of hardware

Key limitation: VeeDo only proves VDF computation. It is NOT the general state transition prover. That is proving/crates/stwo.

12. stwo-cairo + proving — The Production Engine¶

Repos: ~/git/stwo-cairo (stable snapshot) · ~/git/proving (active development — use this)
Source: StarkWare — Apache 2.0
Status: Production. Runs StarkWare's SHARP infrastructure securing Starknet today. Not research.

Circle STARKs — Why M31 Changes Everything for NeXuS¶

M31 = 2^31 - 1  ← Mersenne prime, fits in one 32-bit machine word

Reduction mod M31:
  result = (a * b >> 31) + (a * b & 0x7fffffff)
  ← 3–4 CPU instructions vs complex 256-bit Montgomery reduction
  ← E6520 SSE4.2: pack 4 × M31 per SIMD register = 4× throughput
  ← SIMD-native, rayon-parallelised — scales on commodity hardware

The field was chosen because M31 arithmetic vectorises cleanly on real CPUs. The E6520 compute concern from earlier largely disappears with Circle STARKs.

Extension Field Tower¶

M31   → 31-bit base field (hardware speed)
CM31  → M31[i], i²=-1 (complex Mersenne, quadratic extension)
QM31  → CM31[j], j²=i (quaternion Mersenne, degree-4 extension)

QM31 security: 4 × 31 = 124 bits — from 32-bit operations

Strong security without 256-bit arithmetic. Perfect for constrained nodes.

The Five Crate Groups in `proving/`¶

Group	Key crates	NeXuS use
stwo (core)	`stwo`, `constraint-framework`, `air-utils`	M31 Circle STARK engine — the mathematical foundation
stwo-cairo	`cairo-air`, `prover`, `adapter`	Reference for writing NeXuS AIR components
stwo-circuits	`circuits`, `circuit_prover`, `circuit_verifier`, `circuit_multiverifier`	Circuit DSL — write NeXuS state machine here
proving-utils	`stwo_run_and_prove_recursive_tree`, `privacy_prove`, `privacy_circuit_verify`, `leaf_prover`	Recursive proof tree + privacy prove CLI
stwo-air-infra	`air_infra`, `air_code_gen`, `airs`	AIR DSL → generated Rust code

The Recursive Proof Tree — Prune-After-Consensus Made Concrete¶

N block proofs (leaf proofs, one per NeXuS block)
  ↓ binary folding via circuit_multiverifier
  ↓ each pair: prove both children with one multiverifier circuit
  ↓ ceil(log2(N)) layers — balanced, predictable
  ↓ 1 root proof

100 blocks → 7 fold layers → 1 root proof
1000 blocks → 10 fold layers → 1 root proof

All leaf proofs → PRUNED
All transactions → PRUNED
NeXuS stores: current state + root proof chain only
Storage shrinks over time through aggregation.

All proofs share a canonical circuit shape (common padding target) — the multiverifier is homogeneous, auditable, predictable. Internal folds: M31 channel (fast). Root: Blake2s (anchored, externally verifiable).

stwo-circuits DSL — Simpler than Raw AIR¶

Instead of hand-crafting algebraic constraint polynomials, write circuits. The DSL handles translation to AIR constraints automatically. NeXuS state machine, Vestal Protocol rules, note/nullifier logic → written as circuits, not polynomial math. Massive simplification over raw Winterfell AIRs.

ensure-verifier-no_std — Bare-Metal Verifier¶

No runtime. No allocator. No std. Pure math. Every NeXuS node — even the most constrained — carries the verifier binary in the .sfs image. Prover nodes do the heavy work. All others: verify in milliseconds.

Wasm Support¶

Both wasm32 and wasm64 targets verified in CI. Browser-based or embedded verifier nodes — zero install, load the wasm binary. Aligns with the .sfs lightweight node vision.

The NeXuS AIRs to Write¶

nexus-state-circuit.rs   ← state transition constraints (stwo-circuits DSL)
nexus-vestal-circuit.rs  ← heartbeat + streak validity
nexus-vdf-air.rs         ← MiMC VDF (from VeeDo, adapted for stwo)

These are the NeXuS-specific components. Everything else is borrowed from the proving monorepo directly.

What NeXuS Replaces (plumbing only — no architecture changes)¶

StarkWare component	NeXuS equivalent
Starknet settlement	NeXuS state root (prune-after-consensus)
Cairo language	stwo-circuits DSL
STRK fees	Obol / NeXiuM
SHARP centralized prover	Prover nodes — proof verifies itself, operator irrelevant
On-chain fact registry	nexus-fact-store (local)
Ethereum L1 anchor	NeXuS root proof chain

13. Winterfell — Research Reference (Superseded by stwo)¶

Repo: ~/git/winterfell
Source: Facebook/Novi/Polygon research — MIT license
What it does: STARK prover AND verifier for arbitrary computations defined as AIRs.

What Winterfell gives NeXuS¶

Full prover + verifier — not just verification, full proof generation
AIR-based — describe your computation once, prove it indefinitely
Generic over fields and hash functions — configure for Poseidon
Multi-threaded proof generation — scales with hardware
WebAssembly support — lightweight nodes verify in a browser
No trusted setup
Quantum resistant

The AIR pattern¶

Define: NexusStateAIR — "a valid block transition looks like this"
Prove:  Winterfell proves "this block satisfies the NexusStateAIR"
Store:  STARK proof in nexus-fact-store (permanent, compact)
Prune:  All transactions that produced this state → deleted after dispute window
Verify: Any node, any time, milliseconds, no history needed

Important caveat — not perfect zero-knowledge¶

Winterfell provides succinct proofs but NOT perfect zero-knowledge for secret inputs. This is NOT a problem for NeXuS because: - State transition proofs: state IS the public input — PZK not needed - VDF proofs: no secret inputs — PZK not needed - Payment privacy: handled by the note/nullifier/ECDH layer (starknet-privacy model) — not by Winterfell

The two concerns are handled by separate layers. They do not overlap.

NeXuS AIRs to write (the actual NeXuS-specific work)¶

nexus-state-air.ha    ← state transition constraints
nexus-vestal-air.ha   ← heartbeat + streak validity
nexus-vdf-air.ha      ← MiMC VDF (from VeeDo, Winterfell-native)

13. starknet-privacy — The Complete Privacy Blueprint¶

Repo: ~/git/starknet-privacy
Source: StarkWare (official)
What it is: A complete, production-grade, formally verified private transfer protocol.

Everything is portable — nothing is a blocker¶

starknet-privacy component	NeXuS implementation
Proving service (off-chain)	Prover nodes running Winterfell — trustless by proof, not by operator
Starknet on-chain verification	nexus-fact-store — local verified fact storage
STRK fee token	Obol / NeXiuM
Cairo contract	Winterfell AIR + Hare
L1 settlement	NeXuS state root (prune-after-consensus)
Discovery service	Local node discovery — no chain scan needed
Notes / nullifiers / channels	NeXiuM native primitives
Viewing key	scan_key in nexus-keyring
InvokeExternal anonymizer	Anonymous royalty / service invocation
Lean formal verification	NeXuS long-term verification target
Poseidon hash	Unified ZK hash across the whole stack

The proving service is trustless by design — the proof verifies itself, the operator doesn't matter. StarkWare runs a centralized prover as a convenience. NeXuS runs provers on capable nodes using Winterfell. Architecture identical, operator sovereign.

The Note / Nullifier / Channel Model¶

This replaces account-based balances with a privacy-preserving UTXO-like model:

Channel → Subchannel → Note (encrypted, ECDH + Poseidon)
                       ↓ spent
                    Nullifier (proves note is spent without revealing WHICH note)

Why notes instead of balances? - Account balances are linkable — same address receives and sends, observable - Notes are unlinkable — each note is a fresh encrypted value, nullifier breaks the link - Spent notes → nullifiers → compact, prunable set - Only the owner with the viewing key can discover their own notes

The Viewing Key (scan_key)¶

Maps directly to the stealth address design from earlier in this session: - viewing_key = scan_key — finds incoming notes without spending key - Owner runs discovery service scan: for each encrypted note, try to decrypt with viewing_key - Successful decryption = this note belongs to me - View tags (1-byte hint per note) let scanner skip 99% of notes without full decryption

Phase-ordered action model¶

0 SetViewingKey → 1 OpenChannel → 2 OpenSubchannel → 3 Deposit
→ 4 UseNote → 5 CreateEncNote → 6 Withdraw → 7 InvokeExternal

InvokeExternal = the anonymizer: call any external NeXuS service (royalty contract, staking, marketplace) from inside a private transaction without revealing the caller. Recipe book royalties flow through InvokeExternal. Creator identity: never exposed.

Cryptographic primitives¶

Poseidon with domain-separation tags — all hashes
ECDH with ephemeral keys — note encryption (channel keys, addresses, amounts, tokens, private keys all encrypted)
Nullifier = hash(viewing_key, note_id) — spend proof without linkage

Lean Formal Verification¶

lean/ directory uses Mathlib4 — the most comprehensive mathematical proof library. Security properties are mathematically proven, not just tested. This is the gold standard for critical cryptographic code. Long-term NeXuS goal: Lean proofs for all core ZK primitives.

14. Dynamic Bonding Curve — Creator Economy + Styx Colosseum Gateway¶

Repo: ~/git/dynamic-bonding-curve
Source: Meteora (Solana ecosystem)
Platform context: bags.fm and similar platforms are built on this protocol — creator/music token launches using customizable bonding curves. The .fm domain suggests music/creative content focus.
Sovereignty note: Solana/Anchor-specific plumbing. The math and economic design are fully portable to NeXuS.

What a Dynamic Bonding Curve Is¶

A price-discovery launch mechanism where the token price follows a mathematical curve as supply is bought. Early supporters buy in cheap. Price rises with demand. The market sets the value.

bonding_curve = piecewise constant product across up to 20 price ranges

Each range: x * y = l²  (liquidity l, price range [pa, pb])
Overall:    bonding_curve = function([l_i, pa_i, pb_i] for i in ranges)

Creator configures: starting price, curve shape, fee structure
Market determines: actual price at any moment

The Graduation Mechanism — Entry to the Styx Colosseum¶

When accumulated liquidity hits migration_quote_threshold:

Virtual launch pool → GRADUATES → full AMM pool
  ↓
Locked LP created for creator + partner
  ↓
Creator earns trading fees FOREVER from locked LP
  ↓
For NeXuS: locked LP fees → InvokeExternal → stealth address → private collection
Creator identity: never revealed at any step

Graduation IS the mechanism by which content tokens enter the Styx Colosseum. Content that proves enough demand via the bonding curve earns its place in the open trading economy. The creator's locked LP becomes the perpetual royalty stream.

Replacing the Fixed Royalty Rate¶

Earlier design: creator embeds royalty_rate = 0.15 (fixed 15%) in content.

With bonding curves: the market sets the royalty through price discovery. Creator is paid by math, not by trust. Early supporters are rewarded for early belief. Popularity compounds.

Fee Architecture (portable to NeXuS)¶

Each trade generates fees split:
  ├── Protocol fee (NeXuS network)
  ├── Partner fee (platform — bags.fm equivalent)
  ├── Creator fee (via stealth address, anonymous)
  └── Referral fee (optional — trading bots, front-ends)

After graduation:
  ├── Creator locked LP → perpetual fee stream
  └── Partner locked LP → platform perpetual fee stream

Dynamic Fee + Rate Limiter — Anti-Bot Protection¶

fee_scheduler  ← fee rises during high-activity windows (launch sniping prevention)
rate_limiter   ← limits velocity of trades (bot throttling)
dynamic_fee    ← adjusts based on market volatility

For NeXuS: the rate limiter maps to Ghost Gate enforcement at the token level — bots cannot front-run creator launches.

NeXuS Implementation (Solana plumbing replaced)¶

Meteora component	NeXuS equivalent
SPL Token / Token2022	NeXiuM token primitive
Meteora DAMM v2	NeXuS native AMM (graduated pool)
SOL/USDC quote token	Obol / NeXiuM as quote
Anchor program	stwo-circuits DSL contract
Jup lock (vesting)	PLUTUS Vault (Ring 02) — locked LP equivalent
On-chain config	nexus-fact-store

The Complete Creator Monetization Stack¶

1. Creator launches content token via bonding curve
   └── price discovery — early supporters rewarded

2. Trading fees → stealth address → creator (anonymous, continuous)

3. Threshold hit → token graduates
   └── locked LP created in Styx Colosseum

4. Creator locked LP → perpetual fee stream
   └── InvokeExternal → stealth address → private collection forever

5. Creator identity: never revealed at any step in this pipeline

Bonus: token graduation IS the Styx Colosseum entry rite
       creatures, seasonal arcs, Obol economy — all flow from here

15. OpenZKP — Lightweight Verifier Reference¶

Repo: ~/git/OpenZKP
Source: 0xProject — pure Rust
Role: Simpler STARK implementation, useful for lightweight verifier-only nodes and as a reference.

Limitations: hard-coded field and hash function, no high-level language, no security audit. Use Winterfell for the prover. Use OpenZKP as a reference for understanding the core FRI + STARK verification loop without Winterfell's full complexity.

15. Implementation Phasing — Honest Sane/Simple/Sustainable Assessment¶

The architecture is sound. The implementation path must be honest about complexity.

Phase 1 (now — Alpine/Hare-ready primitives)
  ├── nexus-keyring    ← HD key derivation, cert rotation (no ZK needed)
  ├── nexus-vestal     ← heartbeat signing, streak tracking (no ZK needed)
  └── nexus-vdf        ← MiMC VDF port from Sage (Python first, Hare next)

Phase 2 (ZK bridge — stwo in Rust, from ~/git/proving)
  ├── nexus-stark      ← stwo Circle STARK + stwo-circuits DSL + NeXuS circuits
  ├── nexus-notes      ← note/nullifier/channel model (starknet-privacy design)
  ├── nexus-discovery  ← viewing key scan, view-tag optimised
  ├── nexus-fact-store ← local verified fact registry (replaces FactRegistry.sol)
  └── nexus-bonding    ← dynamic bonding curve (creator token launch + graduation)
  Note: Rust + LLVM — not fully sovereign toolchain but proving math is sovereign.
        stwo's M31 arithmetic is SIMD-native — E6520 concern resolved.

Phase 3 (full sovereignty — Hare/QBE)
  └── Port stwo M31 field arithmetic + FRI + Merkle trees to Hare
      M31 reduction: 4 instructions — trivial to port
      Helios microkernel-ready when Alpine transitions
      no_std verifier already exists — porting that is Phase 3 day 1

The E6520 compute reality — resolved by M31¶

Circle STARKs on M31 use 32-bit arithmetic + SIMD. E6520 has SSE4.2 = 4× M31 ops per instruction.
VDF still requires designated prover nodes (335M iterations). State transition proofs: significantly faster than classical STARKs on the same hardware.
Prover nodes do heavy work. All others: verify in milliseconds via no_std verifier. Anyone can prove — no PoW waste.

16. Open Questions / Next Steps¶

Item	Priority	Notes
✅ Vestal Protocol defined	DONE	Full spec in section 8 — source infographic + ~/manuals/vestal-protocol.md
✅ Vestal Protocol defined	DONE	Full spec §8 — ~/Pictures/nexus/The_Vestal_Protocol_Reward_Tiers.png + ~/manuals/vestal-protocol.md
✅ ZK proof engine selected	DONE	stwo (M31 Circle STARK) from ~/git/proving — production, not research
✅ ZK hash function selected	DONE	Poseidon — unified throughout all layers
✅ Quantum resistance confirmed	DONE	STARKs hash-based — survive Grover; SNARKs rejected (trusted setup + elliptic curve)
✅ PZK gap resolved	DONE	stwo proves validity; ECDH+Poseidon+nullifiers hide content — separate layers
✅ E6520 compute concern resolved	DONE	M31 Circle STARKs use 32-bit SIMD — 4× throughput on SSE4.2; prover nodes for VDF
✅ Creator royalty model finalized	DONE	Dynamic bonding curve + graduation + locked LP replaces fixed 15% royalty rate
✅ Styx Colosseum entry mechanism	DONE	Graduation from bonding curve IS the Colosseum entry rite
Name the consensus model	HIGH	"Settle-and-prune" descriptive but not formal — needs a name
nexus-keyring	HIGH	Design complete — build Phase 1; Python prototype → Hare production
nexus-vdf	HIGH	Port delay_function.sage → verify against MDS matrix deployed values
nexus-circuits	HIGH	Write NeXuS AIRs using stwo-circuits DSL: state, vestal, vdf
nexus-bonding	HIGH	Dynamic bonding curve native — piecewise constant product, NeXiuM quote token
nexus-notes	MED	Note/nullifier/channel model from starknet-privacy
nexus-discovery	MED	View-tag scan, no full chain needed
nexus-fact-store	MED	Local verified fact registry — root proofs stored here
Dispute window duration	MED	72h? 7 days? Application-dependent?
nexus-bonding graduation	MED	Define NeXuS DAMM equivalent for graduated token pools
Royalty → InvokeExternal spec	MED	Locked LP fees → anonymous stealth address collection
Lean formal verification	LOW	Long-term — formally prove NeXuS ZK primitives
Styx Colosseum full spec	LOW	Creature breeding/battling/seasonal mechanics — pending
bags.fm integration study	LOW	Understand bags.fm platform specifics for NeXuS creator UX patterns

17. Key Principles Reaffirmed This Session¶

No blockchain follows an OS. NeXuS doesn't follow blockchain. — The OS IS the node. The node IS the OS.
History is scaffolding. — Once consensus is achieved on current state, transactions are provably unnecessary.
Public metadata is a crowd, not an identity. — Uniform public metadata across all nodes makes fingerprinting impossible.
The master never travels. — Only derived children hit the network. The master is the time machine.
The royalty rule travels with the asset, not the creator. — Stealth addresses decouple payment from identity permanently.
A global VM is the wrong tool. — The OS is the VM. Contracts are kernel policies.
The proof verifies itself — the operator doesn't matter. — A proving service can be run by anyone. Trustlessness comes from the math, not the operator.
NeXuS inherits best ideas, not constraints. — Every existing protocol has Starknet fees, Ethereum settlement, centralized assumptions. NeXuS takes the cryptographic design and discards the chain-specific plumbing.
One hash function throughout. — Poseidon across state tree, note encryption, VDF constants, nullifiers, circuits. No mixing of hash assumptions.
Validity and privacy are separate layers. — STARKs prove the ledger is honest. ECDH + Poseidon + nullifiers hide what's in it. Neither layer bleeds into the other.
The market sets the royalty, not the creator. — Dynamic bonding curves replace fixed rates. Price discovery is more honest than an arbitrary percentage. Creator is paid by math.
Graduation is the proof of worth. — Content that earns its way through the bonding curve threshold has proven demand. The Styx Colosseum is not open to all — it is earned.
Storage shrinks over time, not grows. — Recursive proof trees fold N block proofs into 1 root proof. The permanent record compresses with aggregation. Every other chain grows forever. NeXuS grows smaller.

Referenced Repositories¶

Repo	Role	Location
proving	Production proving monorepo — stwo (M31 Circle STARK), stwo-circuits DSL, recursive tree, privacy prove, AIR infra	`~/git/proving`
starknet-privacy	Complete privacy blueprint — notes, nullifiers, channels, viewing keys, InvokeExternal, Lean proofs	`~/git/starknet-privacy`
dynamic-bonding-curve	Creator economy — piecewise bonding curve launch, graduation, locked LP, dynamic fees	`~/git/dynamic-bonding-curve`
veedo	VDF — Black Box randomness, block beacon (MiMC delay function)	`~/git/veedo`
stwo-cairo	Circle STARK prover/verifier for Cairo CPU (stable snapshot, superseded by proving)	`~/git/stwo-cairo`
winterfell	Research STARK reference — study AIR design (not production)	`~/git/winterfell`
OpenZKP	Lightweight STARK verifier reference	`~/git/OpenZKP`

Report generated: 2026-08-17
Updated: 2026-08-17 — Final picture: proving monorepo + dynamic bonding curve + full architecture
Vestal Protocol: DEFINED — §8. Sources: ~/Pictures/nexus/The_Vestal_Protocol_Reward_Tiers.png · ~/manuals/vestal-protocol.md
ZK Stack: stwo (M31 Circle STARK, production) + starknet-privacy (note/nullifier model) + veedo (VDF) + Poseidon (unified hash)
Creator Economy: dynamic bonding curve + graduation → Styx Colosseum + locked LP → anonymous perpetual royalties