Skip to content

SOVN ZHTP Canonical Technical Specification v2

Jump to bottom
Hugo Perez edited this page Apr 8, 2026 · 1 revision

SOVN / ZHTP — Canonical Technical Specification (v2)

The Sovereign Network — Canonical Release

Version 2.0 — Canonical Release
Status Internal Engineering Reference
Date April 2026
Classification Confidential — Core Team Only

Note

About this wiki page

The text of this specification is reproduced verbatim from SOVN_Canonical_Spec_v2.docx. No wording, number, formula, or protocol constant has been altered.

This page adds non-normative enrichments only:

  • Mermaid diagrams (clearly marked 📐 Diagram — not normative) that visualise sequences and state machines described in the text.
  • Hyperlinks on external standards references (NIST FIPS, IETF RFCs, published papers) to the canonical upstream source.
  • A References section at the end.

In any conflict between a diagram and the text, the text is authoritative.

Table of Contents

ABSTRACT

This document is the single canonical source of truth for The Sovereign Network. It supersedes all prior specifications, working documents, and ADRs. It covers the full technical stack: BFT consensus, post-quantum cryptography, the CBE/SOV bonding curve with the 20/80/40/60 economic model, the SOVRN transformer, the Double Helix audit architecture (tension chain, Filament system, superposition states), the three-token model, and the validator set specification. Every number, formula, and protocol constant in this document is locked. Implementation must produce identical results on every node for every input.

PART I — TOKEN ARCHITECTURE

1. Three-Token Model

The Sovereign Network operates three distinct tokens. Each has a fixed role. None are interchangeable.

Token Supply Role Properties
SOV 1 Trillion (fixed) Civic Reserve Token 0% inflation. Non-tradeable. Earned only. Powers UBI, governance, welfare DAOs.
CBE 100 Billion (fixed) Corporate Utility Token Sold via bonding curve. Price determined by network activity, not by fiat. 20% of supply to Sovereign Treasury per DAO rule.
SOVRN 600 Million (fixed) Governance Token 400M genesis distribution, 120M ecosystem, 80M proofing pool. Tracks locked CBE reserve. Oracle-free graduation trigger.

1.1 DAO Treasury Rule

Every DAO operating on the network allocates 20% of its token supply to the Sovereign Treasury. This applies to CBE. Non-profit DAOs contribute 10%. This is the engine that funds the civic SOV layer.

1.2 SOV Supply

SOV has a fixed supply of 1,000,000,000,000 (one trillion) tokens. It is never minted post-genesis. It is distributed only through the Sovereign Treasury as UBI, welfare services, and governance participation rewards. It cannot be purchased directly.

PART II — CBE/SOV BONDING CURVE

2. Economic Model — The 20/80/40/60 Split

CBE is sold to bootstrap the SOV ecosystem. The bonding curve is the on-ramp: every SOV sent to buy CBE is split deterministically into three pools. The curve produces the next CBE price on every purchase. No external price discovery. No liquidity providers. The protocol is the market maker.

THE CANONICAL SPLIT

On every CBE buy, gross_sov is split as follows: 20% → Sovereign Treasury (SOV civic engine — UBI, welfare DAOs) 80% → CBE backing economy ├─ 40% of 80% = 32% of gross → LOCKED reserve (sustains bonding curve floor price) └─ 60% of 80% = 48% of gross → LIQUID (seeds AMM at graduation)

From 100 SOV gross input:
→ Sovereign Treasury: 20 SOV (20% of gross)
→ CBE backing (total): 80 SOV (80% of gross)
├─ Locked reserve: 32 SOV (40% of 80%)
└─ Liquid: 48 SOV (60% of 80%)
Total accounted: 100 SOV ✓

📐 Diagram — not normative. Visual representation of the 20/80/40/60 split described above.

flowchart LR
    A["gross_sov<br/>(100%)"] --> B{"20 / 80<br/>Split"}
    B -->|"20%"| T["Sovereign Treasury<br/>SOV civic engine<br/>UBI · Welfare DAOs"]
    B -->|"80%"| C["CBE Backing Economy"]
    C --> D{"40 / 60<br/>Split"}
    D -->|"40% of 80%<br/>= 32% of gross"| L["LOCKED Reserve<br/>Floor-price backing<br/>Mints SOVRN 1:1"]
    D -->|"60% of 80%<br/>= 48% of gross"| Q["LIQUID Pool<br/>AMM seed capital<br/>Locked at graduation"]
    style T fill:#e8f5e9,stroke:#2e7d32
    style L fill:#fff3e0,stroke:#e65100
    style Q fill:#e3f2fd,stroke:#1565c0
Loading

2.1 Solvency Property

The locked reserve grows monotonically with every buy. It is never discretionary. Sells redeem from the locked reserve, so the floor price — locked_reserve / circulating_CBE — is always real and always backed. The bonding curve cannot be rugged because the locked reserve is a protocol invariant, not a pool managed by any party.

2.2 Liquid Reserve Role

The liquid 48% is not idle. It is the AMM seed capital. At graduation it is converted into protocol-owned liquidity that is permanently locked as LP tokens. The market gains free price discovery without ever losing the liquidity base the bonding curve accumulated.

2.3 Integer Arithmetic — The Split in Code

// All values in raw units (18 decimals). SCALE = 10^18.
let to_treasury = gross_sov * 20 / 100; // 20% → Sovereign Treasury
let cbe_backing = gross_sov * 80 / 100; // 80% → CBE economy
let locked_reserve = cbe_backing * 40 / 100; // 32% of gross — locked
let liquid = cbe_backing * 60 / 100; // 48% of gross — liquid
// Remainder from truncation → assigned to locked_reserve
let remainder = gross_sov - to_treasury - locked_reserve - liquid;
locked_reserve += remainder; // protocol-defined, consensus-critical

3. Bonding Curve Mathematics

3.1 Price Function

The bonding curve uses a piecewise linear pricing model. Within each band the marginal price is:

P(S) = (slope_num × S / slope_den) + intercept_i

where S is circulating CBE supply in raw units. No floats. No oracles. Every node computes the identical price from the same genesis constants.

3.2 Five-Band Configuration

Band Start (raw CBE) End (raw CBE) slope_num slope_den Intercept (raw SOV)
0 0 10B × 10¹⁸ 1 10¹⁴ 313,345,700,000,000
1 10B × 10¹⁸ 30B × 10¹⁸ 2 10¹⁴ genesis constant
2 30B × 10¹⁸ 60B × 10¹⁸ 3 10¹⁴ genesis constant
3 60B × 10¹⁸ 85B × 10¹⁸ 4 10¹⁴ genesis constant
4 85B × 10¹⁸ 100B × 10¹⁸ 5 10¹⁴ genesis constant

CONTINUITY CONSTRAINT

Band intercepts 1–4 are derived offline: b_i = b_{i-1} + (m_{i-1} − m_i) × S_i. Computed once with arbitrary-precision arithmetic. Frozen as genesis constants. Nodes never recompute them at runtime.

📐 Diagram — not normative. Conceptual shape of the piecewise linear price function across the five bands. Slopes are monotonically increasing (1 → 5), and intercepts are chosen so P(S) is continuous at every band boundary.

flowchart LR
    B0["Band 0<br/>0 → 10B<br/>slope = 1"] --> B1["Band 1<br/>10B → 30B<br/>slope = 2"]
    B1 --> B2["Band 2<br/>30B → 60B<br/>slope = 3"]
    B2 --> B3["Band 3<br/>60B → 85B<br/>slope = 4"]
    B3 --> B4["Band 4<br/>85B → 100B<br/>slope = 5"]
    B4 --> G["MAX_SUPPLY<br/>100B × SCALE"]
    style B0 fill:#e8f5e9
    style B1 fill:#dcedc8
    style B2 fill:#fff9c4
    style B3 fill:#ffe0b2
    style B4 fill:#ffccbc
    style G fill:#f5f5f5,stroke-dasharray: 3 3
Loading

3.3 Cost Integration (Mandatory Factored Form)

C(Sa, Sb) = slope_num × (Sb-Sa) × (Sb+Sa) / slope_den / 2 + intercept × (Sb-Sa)
// (Sb² - Sa²) factored as (Sb-Sa)×(Sb+Sa) — mandatory, avoids u128 overflow at Band 4
// U256 for all intermediates. Downcast to u128 at end. Explicit overflow abort.

3.4 Inverse Quote — Mint Calculation

ΔS = (−P0 + isqrt(P0² + 2 × slope_num × c / slope_den)) × slope_den / slope_num
// c = locked_reserve credit (32% of gross_sov)
// isqrt always rounds DOWN — protocol-defined, consensus-critical
// P0 = P(S) at current supply before tx

3.5 Protocol Constants

Constant Value Notes
SCALE 1_000_000_000_000_000_000 10¹⁸ — 18 decimal places
INTERCEPT_0 313_345_700_000_000 Raw SOV/CBE at genesis price
BAND_COUNT 5 Hard constant. Not governance-adjustable without overflow re-analysis.
ISQRT_ROUND Down (floor) Protocol rule. Consensus-critical.
MAX_GROSS_SOV_PER_TX 10^24 raw SOV Required for overflow bound.
MAX_SUPPLY 100B × SCALE Hard ceiling.

PART III — SOVRN TRANSFORMER AND GRADUATION

4. The SOVRN Transformer

4.1 Purpose

The locked reserve accumulates as an opaque state variable on-chain. At graduation, it seeds the AMM. Without SOVRN, any external observer — regulator, DAO participant, AMM liquidity recipient — must trust the chain state directly. SOVRN makes the locked reserve auditable by representing it as a token supply.

SOVRN_total_supply at any block equals exactly the locked_reserve_sov accumulated from genesis. The token supply is the audit. No trusted party required.

4.2 What SOVRN Tracks

// On every finalized BuyReceipt:
locked_credit = gross_sov × 32 / 100 // 40% of 80%
SOVRN_minted = locked_credit
// Invariant (holds at every block):
SOVRN_total_supply = Σ locked_credit across all blocks from genesis
= locked_reserve_sov

AUDIT PROPERTY

Any observer can verify at any block: SOVRN_total_supply × P_ref_SOV/USD = locked CBE-backing value in USD This requires no internal chain state access. The token supply is the proof. At graduation: SOVRN is burned, locked_reserve seeds the AMM. The burn event is non-repudiable public proof that the reserve was real.

4.3 Transformer Architecture

The SOVRN transformer is an async parallel transformer that runs post-finality on committed BuyReceipt outputs. It does not block the buy transaction execution path. It cannot corrupt CBE minting. A bug in the transformer cannot affect economic state.

pub struct SovrnMintTransformer;
impl StateTransformer for SovrnMintTransformer {
fn transform(&self, block: &FinalizedBlock, state: &ReadOnlyState) -> Vec<StateWrite> {
block.receipts()
.filter_map(|r| r.as_buy_receipt())
.map(|r| StateWrite::MintSovrn {
amount: r.locked_credit, // gross_sov × 32/100
block_height: block.height,
})
.collect()
}
}

SAME-BLOCK FINALIZATION

SOVRN transformer output must be included in the same block state root as the buy transactions that generated the locked credits. If deferred to block N+1, the graduation check could fire on stale data. Same-block finalization is a protocol requirement, not an implementation preference.

4.4 Graduation Trigger

The graduation trigger is expressed purely in terms of SOVRN supply. No oracle. No USD price feed. A pure on-chain state comparison.

// Canonical graduation trigger:
fn check_graduation(state: &ReadOnlyState) -> bool {
state.sovrn_total_supply() >= GRADUATION_THRESHOLD
}
// Derivation:
// Target: locked_reserve × P_ref >= 269,000 USD
// P_ref = 0.10 USD/SOV (genesis reference price)
// locked_reserve_needed = 269,000 / 0.10 = 2,690,000 SOV display
// Since SOVRN = locked_reserve:
const GRADUATION_THRESHOLD: u128 = 2_690_000 * SCALE; // raw SOVRN units

4.5 Graduation Sequence

When SOVRN_total_supply >= GRADUATION_THRESHOLD the following sequence executes atomically:

  1. Freeze bonding curve — no further buys or sells accepted.

  2. Snapshot final CBE price and circulating supply.

  3. Burn all SOVRN. Transfer locked_reserve_sov to AMM seed pool.

  4. Seed constant-product AMM (x × y = k) with locked reserve + liquid reserve.

  5. Permanently lock LP tokens — no withdrawal ever.

  6. Activate AMM pricing. Oracle switches to post-graduation mode.

📐 Diagram — not normative. Atomic graduation sequence as described in §4.5.

sequenceDiagram
    autonumber
    participant Chain as Chain State
    participant SOVRN as SOVRN Supply
    participant Curve as Bonding Curve
    participant AMM as Constant-Product AMM
    participant LP as LP Tokens

    Chain->>SOVRN: check_graduation()
    SOVRN-->>Chain: supply ≥ 2,690,000 × SCALE
    rect rgba(255, 224, 130, 0.3)
    note over Chain,LP: Atomic — all steps execute in one transaction
    Chain->>Curve: Freeze (no buys, no sells)
    Chain->>Curve: Snapshot final price + circulating supply
    Chain->>SOVRN: Burn all SOVRN
    Chain->>AMM: Transfer locked_reserve + liquid_reserve
    AMM->>AMM: Initialise x · y = k
    AMM->>LP: Mint LP tokens
    LP->>LP: Permanently lock (no withdrawal ever)
    Chain->>Chain: Activate AMM pricing mode
    end
Loading

PART IV — BFT CONSENSUS AND VALIDATOR SET

5. Byzantine Fault Tolerant Consensus

5.1 Mathematical Invariant

BFT consensus has one theorem that cannot be overridden:

n ≥ 3f + 1 // n validators, f Byzantine tolerated
quorum = floor(2n/3) + 1 // minimum votes for finality
BFT_SUPERMAJORITY_FLOOR = 6667 bps (66.67%) // immutable protocol constant

WHY THIS IS NON-NEGOTIABLE FOR THE BONDING CURVE

The bonding curve is a stateful pricing machine. Transaction N+1's price depends on transaction N's output (circulating_supply). Two nodes that disagree on circulating_supply compute different prices, different SOVRN mint amounts, different state roots. The chain forks on economic state. BFT absolute finality prevents this. Eventual consistency (daisy chain as consensus) does not. This is not a preference. It is a mathematical requirement.

5.2 Validator Set Parameters

Parameter Value Notes
BFT_SUPERMAJORITY_FLOOR 6667 bps IMMUTABLE. Breaking this breaks the safety proof.
Genesis validators n = 3 All operator-controlled. Quorum = 3. Zero Byzantine tolerance. Recovery mode only.
Maximum validators n = 21 Ceiling for current architecture. Limited by O(n²) BFT and linear tension chain.
Block time 6 seconds 2 BFT rounds + propagation margin.
At n = 21 f = 6, quorum = 14 6 Byzantine tolerated. Halts if 8 crash simultaneously.

5.3 Why 21 Is the Ceiling

Four constraints converge at 21. Exceeding any one requires a Level 2 architectural upgrade.

  • BFT message complexity: O(n²). At n=21: 840 messages/block. At n=50: 4,900. Network consumed by consensus before economic transactions can execute.

  • Tension chain latency: linear, 150ms/hop. At n=21: 3,150ms — fits one 6-second block. At n=50: 7,500ms — audit trail falls behind the chain.

  • Sybil resistance: Byzantine threshold = 1/3 of staked value. At 21 validators, controlling 7 requires one-third of total stake — economically prohibitive at proper stake levels.

  • Quorum liveness: quorum=14 requires taking 8 validators simultaneously offline. Across geographically distributed infrastructure this demands a global event or coordinated multi-jurisdiction attack.

PART V — POST-QUANTUM CRYPTOGRAPHIC STACK

6. Cryptographic Primitives

All classical cryptography (Ed25519, X25519, Bulletproofs) is replaced. The entire stack is post-quantum. This is not optional — harvest-now-decrypt-later attacks make the threat present tense.

Primitive Algorithm Standard Usage
Signatures Dilithium5 (ML-DSA) NIST FIPS 204 All signatures: transactions, BFT votes, tension chain, node identity.
Key Encapsulation Kyber1024 (ML-KEM) NIST FIPS 203 All KEM: ZHTP handshake, Filament encryption.
Hashing Blake3 — Commitments, nonce fingerprints, tension values, Merkle trees.
AEAD (default) ChaCha20-Poly1305 RFC 8439 Session encryption.
Key Derivation HKDF-SHA3-256 RFC 5869 Session keys, Filament channel keys.
ZK Proofs [DEFERRED] — Slot reserved as [u8;32] placeholder. No production-ready post-quantum ZK primitive exists.

KEY SIZES — FIXED CONSTRAINTS

Dilithium5 signature: 4,595 bytes (vs Ed25519: 64 bytes — 72× larger) Kyber1024 ciphertext: 1,568 bytes (vs X25519: 32 bytes — 49× larger) These are security parameters, not performance bugs. They cannot be reduced without reducing post-quantum security level. BondingCurveBuyTx with Dilithium5: 4,707 bytes fixed. Always.

PART VI — DOUBLE HELIX AUDIT ARCHITECTURE

7. Two Helices — Consensus and Audit

The Double Helix architecture answers a question BFT does not: given that a block is final, can we prove — for each validator — that they saw the exact economic state of that block before the next validator signed?

Data Helix (data_helix_root) Verification Helix (verification_helix_root)
Answers What happened economically in block N? Who sequentially acknowledged it, and when?
Contains Merkle root of all transactions and receipts. Blake3 hash of the complete tension chain.
Finalized At BFT quorum (t ≈ 400ms). When last validator signs tension chain (t ≈ 3,550ms).
On-chain cost [u8; 32] in block header. [u8; 32] in block header.

7.1 Block Header

pub struct BlockHeader {
pub height: u64,
pub timestamp: u64,
pub previous_hash: [u8; 32],
pub validator: [u8; 32],
pub data_helix_root: [u8; 32], // Merkle root of txs + receipts
pub verification_helix_root: [u8; 32], // Blake3 of tension chain (post-finality)
pub state_root: [u8; 32], // supply, reserve, treasury, SOVRN
pub bft_quorum_root: [u8; 32], // Merkle root of 14 quorum sigs
}

7.2 Block N Timeline

t=0ms Leader proposes block
t=200ms BFT round 1 — parallel validator votes (21 × Dilithium5)
t=400ms BFT quorum reached — block FINAL
→ data_helix_root committed
→ state_root committed (supply, locked_reserve, liquid, treasury, SOVRN)
→ bft_quorum_root committed
t=400ms SOVRN transformer fires (async, same block)
→ reads locked_credit from all BuyReceipts
→ writes SOVRN total supply
t=400ms Tension chain begins (post-finality, off critical path)
→ 21 sequential steps × 150ms ≈ 3,150ms
t=3,550ms verification_helix_root committed
t=6,000ms Block N+1 proposed — block N audit trail complete

📐 Diagram — not normative. The Block N timeline as a Gantt chart, showing BFT finality on the critical path and the tension chain running off it.

gantt
    title Block N Lifecycle (6-second interval)
    dateFormat  X
    axisFormat  %Lms

    section Critical path
    Leader proposes block         :p, 0, 200
    BFT round 1 (21 × Dilithium5) :b, 200, 200
    FINAL — roots committed       :milestone, f, 400, 0

    section Parallel
    SOVRN transformer (async)     :s, 400, 50

    section Post-finality (off path)
    Tension chain (21 × 150ms)    :t, 400, 3150
    verification_helix_root       :milestone, v, 3550, 0

    section Next block
    Block N+1 proposed            :n, 6000, 0
Loading

8. The Tension Chain

The tension chain is a sequential, post-finality, post-quantum secure, non-repudiable validator accountability ledger. It is not consensus. It does not affect finality. It proves ordered knowledge of finalized state.

8.1 Construction

// Anchor — binds the entire chain to the finalized block
tension[0] = block_hash
// Each step:
V_i_signature = Dilithium5.sign(V_i_privkey, tension[i-1])
tension[i] = Blake3(
tension[i-1] || // [u8; 32] — chain dependency
V_i_signature || // [u8; 4595] — non-repudiable attestation
block_height.to_le() || // [u8; 8] — epoch binding
validator_index.to_le() // [u8; 8] — position binding
)
// Chain completion:
verification_helix_root = Blake3(tension[1] || tension[2] || ... || tension[21])

📐 Diagram — not normative. Sequential linking of tension values. Each validator's tension[i] cannot be computed without tension[i-1], producing a non-repudiable ordered chain anchored to the finalized block hash.

flowchart LR
    BH["block_hash<br/>(tension[0])"] --> V1["V₁ signs<br/>tension[1]"]
    V1 --> V2["V₂ signs<br/>tension[2]"]
    V2 --> V3["V₃ signs<br/>tension[3]"]
    V3 --> D["…"]
    D --> VN["V₂₁ signs<br/>tension[21]"]
    VN --> R["verification_helix_root<br/>= Blake3(tension[1] ‖ … ‖ tension[21])"]
    style BH fill:#e3f2fd,stroke:#1565c0
    style R fill:#fce4ec,stroke:#c2185b
Loading

8.2 What the Tension Chain Proves

For any validator V_i in the chain for block N:

  • V_i saw the exact finalized block — block_hash is in tension[1] and every value is derived from it. A different block invalidates the entire chain.

  • V_i processed every prior validator's output — tension[i] cannot be computed without tension[i-1], which cannot be computed without tension[i-2], back to V1.

  • V_i's participation is non-repudiable — their Dilithium5 signature is verifiable against their registered public key forever.

  • V_i saw the SOVRN supply, locked reserve, treasury balance, and price at block N — because state_root is in block_hash. No governance dispute can succeed on a claim of ignorance.

8.3 Size and Timing

Validators Raw size Approx Completion vs 6s block
3 3 × 4,643 B = 13,929 B ~14 KB 450ms < 1 block
7 7 × 4,643 B = 32,501 B ~32 KB 1,050ms < 1 block
21 21 × 4,643 B = 97,503 B ~95 KB 3,150ms < 1 block

Off-chain storage: ~95KB per block, ~1.3 GB/day at 10 blocks/minute. On-chain: 32 bytes (verification_helix_root only).

9. The Filament System

The Filament system is the transaction-level counterpart to the block-level tension chain. Where the tension chain proves validator knowledge, the Filament proves buyer commitment and enables selective, timed, cryptographic disclosure.

9.1 Blueprint-Not-Data Principle

Only the hash commitment is on-chain. The encrypted content is off-chain, content-addressed. The on-chain footprint is always 32 bytes regardless of Filament complexity.

// In BondingCurveBuyTx:
pub filament_commitment: [u8; 32], // Blake3(kyber_ct || encrypted_receipt || tx_hash)
// Zero-filled if no Filament attached
// Off-chain FilamentBlueprint contains:
// Channel 0 — BuyReceipt summary (delta_s, locked_credit, liquid_credit, new_supply, price_post)
// Channel 1 — Full band iteration trace (per-band delta_s, cost_to_fill, remaining)
// Channel 2 — gross_sov exact input
// Channel 3 — Price impact detail
// Channel 4 — Verification seed (opens the commitment)
// Each channel has an independent HKDF-derived key:
channel_key_i = HKDF(ikm: kyber_shared_secret,
salt: Blake3(tx_hash || filament_id),
info: "ZHTP-FILAMENT-CHANNEL-" || channel_id_byte)
// Revealing channel_key_0 gives zero information about channel_key_1.

9.2 The Four Superposition States

The superposition state machine governs the Filament lifecycle. Transitions are unidirectional — a ratchet that moves forward only.

State Entry Condition Exit Condition Who Can Read
Encoded Buyer creates tx, generates seed, encrypts blueprint. Transaction submitted to mempool. Sender only.
Superimposed Transaction included in BFT-finalized block. Buyer initiates reveal. Sender + receiver (via Kyber1024 decryption). Validators: commitment hash only.
Revealed Buyer publishes channel decryption key. Graduation event. Any party the buyer disclosed to. Granular by channel.
Collapsed Graduation — SOVRN burned, AMM seeded. Terminal. No further transitions. Determined by what was revealed before graduation. Unrevealed content: permanently private.

📐 Diagram — not normative. The four-state superposition ratchet. Transitions are unidirectional — the state machine cannot move backwards.

stateDiagram-v2
    [*] --> Encoded: Buyer creates tx,<br/>encrypts blueprint
    Encoded --> Superimposed: Tx included in<br/>BFT-finalized block
    Superimposed --> Revealed: Buyer publishes<br/>channel decryption key
    Revealed --> Collapsed: Graduation event<br/>(SOVRN burned)
    Superimposed --> Collapsed: Graduation without reveal<br/>(content permanently private)
    Collapsed --> [*]

    note right of Encoded
        Readable by: Sender only
    end note
    note right of Superimposed
        Readable by: Sender + receiver
        Validators see commitment hash only
    end note
    note right of Revealed
        Readable by: Whomever the
        buyer disclosed to
        (granular per channel)
    end note
    note right of Collapsed
        Terminal — no further transitions
    end note
Loading

9.3 What the Filament Proves

  • The buyer committed to the full receipt at transaction creation time — the filament_commitment on-chain is binding. It cannot be retroactively changed.

  • The locked_credit (32% of gross_sov) that fed into SOVRN minting was exactly this amount — provable to governance, regulators, or arbitrators via Channel 0 reveal.

  • The exact band segments crossed and intermediate computations are preserved — Channel 1 enables full mathematical audit of the band-crossing computation.

  • Selective disclosure: Channel 0 for governance voting weight. Channel 1 for technical audit. Channel 2 for regulatory. No reveal implies no disclosure of any channel.

9.4 The Encrypted Anchor — Kyber1024

The Filament blueprint is encrypted with the receiver's Kyber1024 public key. Validators process the transaction and include it in a block without ever reading the Filament content. This proves the economic state transition is independent of the Filament — the bonding curve executed on public inputs only.

// Sender encrypts for receiver:
kyber_ciphertext: [u8; 1568] // Kyber1024 encapsulation
// Only the receiver can decrypt:
// Requires solving Module Learning With Errors — no known classical or quantum algorithm.

10. The Audit Chain Reconstruction

Any party can reconstruct the complete accountability proof for any buy transaction using only public algorithms and publicly available data. No trusted party required.

  1. Locate the transaction — Merkle proof to data_helix_root.

  2. Verify BFT finality — 14 Dilithium5 quorum signatures over block_hash.

  3. Verify the receipt — Merkle proof, filament_commitment echo check.

  4. Verify the Filament commitment — Channel 4 opening with verification seed.

  5. Verify Filament content against public receipt — field-by-field comparison.

  6. Verify band computation — independent re-execution from disclosed inputs.

  7. Verify validator knowledge — complete tension chain verification.

📐 Diagram — not normative. The seven-step audit chain reconstruction. Every step uses public algorithms and publicly available data.

flowchart TD
    S1["1 — Locate transaction<br/>Merkle proof → data_helix_root"]
    S2["2 — Verify BFT finality<br/>14 × Dilithium5 over block_hash"]
    S3["3 — Verify receipt<br/>Merkle proof + filament_commitment echo"]
    S4["4 — Verify Filament commitment<br/>Channel 4 opening with verification seed"]
    S5["5 — Verify Filament vs public receipt<br/>field-by-field comparison"]
    S6["6 — Verify band computation<br/>independent re-execution from inputs"]
    S7["7 — Verify validator knowledge<br/>complete tension chain verification"]
    S1 --> S2 --> S3 --> S4 --> S5 --> S6 --> S7
    S7 --> OK(["Full accountability proof<br/>— no trusted party required"])
    style OK fill:#e8f5e9,stroke:#2e7d32
Loading

NON-REPUDIATION PROPERTIES

Buyer: committed to exact inputs at creation time. Cannot claim a different gross_sov, a different band, or a different price. Validators: signed over the block hash that includes the SOVRN supply, reserve, and treasury at that height. Cannot claim ignorance in governance disputes. Protocol: the bonding curve computation is independently re-executable from public band parameters and disclosed inputs. Cannot be disputed.

PART VII — TRANSACTION STRUCTS AND STATE

11. Fixed-Size Transaction Structs

Every transaction struct uses fixed-width types only. No Vec, no String, no Option, no memo. Transaction byte size is independent of amount values. This is the prerequisite for consensus-deterministic serialization.

11.1 BondingCurveBuyTx — 4,707 bytes

Field Type Bytes Description
sender [u8; 32] 32 Sender address (Dilithium5 public key hash).
gross_sov u128 16 Raw SOV sent. Always 16 bytes regardless of amount.
min_cbe u128 16 Slippage guard — minimum CBE to receive.
nonce u64 8 Replay-protection counter.
deadline u64 8 Block height expiry.
filament_commitment [u8; 32] 32 Blake3 hash of encrypted Filament blueprint. Zero-filled if no Filament.
signature [u8; 4595] 4,595 Dilithium5 — post-quantum, non-reducible.
TOTAL 4,707 Fixed. Always. Independent of amount values.

11.2 BondingCurveBuyReceipt — 96 bytes

Field Type Bytes Description
delta_s u128 16 Raw CBE minted. Identical on every node for same input.
to_treasury u128 16 Raw SOV to Sovereign Treasury (20% of gross).
locked_credit u128 16 Raw SOV to locked reserve (32% of gross). SOVRN mint input.
liquid_credit u128 16 Raw SOV to liquid pool (48% of gross). AMM seed accumulator.
new_supply u128 16 Post-transaction circulating CBE supply.
price_post u128 16 Marginal price after mint (raw SOV per raw CBE).
TOTAL 96 Fixed. Forms part of the state transition proof.

11.3 Chain State Variables

// All u128. No floats. Atomic updates — overflow or underflow aborts entire tx.
circulating_supply: u128 // raw CBE minted to date
locked_reserve_sov: u128 // 32% of all gross_sov ever sent
liquid_reserve_sov: u128 // 48% of all gross_sov ever sent
sovereign_treasury: u128 // 20% of all gross_sov ever sent
sovrn_total_supply: u128 // = locked_reserve_sov (SOVRN transformer invariant)

PART VIII — ZHTP TRANSPORT PROTOCOL

12. ZHTP UHP/2.0 Unified Handshake Protocol

ZHTP is the application-layer protocol that runs over QUIC/TCP. Every node connection begins with a three-message handshake that establishes a post-quantum authenticated session.

ClientHello → Kyber1024 encapsulation (client → server pubkey)
Dilithium5 challenge signature
nonce_fingerprint = Blake3(nonce || network_epoch || node_id)
ServerHello ← Kyber1024 ciphertext (server decapsulates, derives shared secret)
Dilithium5 challenge response
session_key = HKDF-SHA3-256(kyber_shared_secret || challenge_response)
ClientFinish→ ChaCha20-Poly1305 encrypted under session_key
Session established.

📐 Diagram — not normative. Three-message ZHTP UHP/2.0 handshake over QUIC or TCP.

sequenceDiagram
    autonumber
    participant C as Client
    participant S as Server

    C->>S: ClientHello<br/>Kyber1024 encapsulation (→ server pubkey)<br/>Dilithium5 challenge signature<br/>nonce_fingerprint = Blake3(nonce ‖ epoch ‖ node_id)
    note over S: Decapsulate → kyber_shared_secret
    S->>C: ServerHello<br/>Kyber1024 ciphertext<br/>Dilithium5 challenge response
    note over C,S: session_key = HKDF-SHA3-256(<br/>  kyber_shared_secret ‖ challenge_response)
    C->>S: ClientFinish<br/>ChaCha20-Poly1305 under session_key
    note over C,S: Session established — all subsequent<br/>traffic AEAD-encrypted
Loading

  • All subsequent traffic: ChaCha20-Poly1305 AEAD by default. AES-256-GCM if negotiated.

  • Nonce anti-replay: Blake3 fingerprints tied to network_epoch. Stale caches from previous genesis states are automatically rejected.

  • libp2p transport: Gossipsub (mempool), Kademlia DHT (peer discovery), mDNS (local network).

PART IX — SCALING ROADMAP

13. Beyond 21 Validators

21 is the correct ceiling for the current architecture. It is not arbitrary. Exceeding it requires two protocol-level upgrades that do not change the base consensus or economic model.

Upgrade What it enables What it requires
Threshold Dilithium5 One aggregate signature replaces 14 individual BFT quorum sigs. Consensus overhead drops from O(n²) to O(n). Ceiling raises to 50–100. Threshold signature scheme for Dilithium5. Not yet production-ready.
Tree Tension Chain log₂(n) depth replaces linear chain. At n=100: 7 levels × 150ms = 1,050ms. Well within block interval. Redesign of tension computation. Merged tension values at internal nodes. Accountability property preserved.
Two-Tier Validator Model Tier 1: 50–100 consensus validators. Tier 2: hundreds of attestation validators for jurisdictional coverage. New validator registry, attestation log, political finalization metric in governance module.

13.1 Level 2 Upgrade — Tree Tension Calculation

// At each internal tree node:
tension[node] = Blake3(
tension[left_child] || // [u8; 32]
tension[right_child] || // [u8; 32]
V_node_signature || // [u8; 4595] — over concat(left||right)
block_height || // [u8; 8]
node_id // [u8; 32] — validator pubkey hash
)
// verification_helix_root = tree root
// Accountability property preserved: every validator at level L
// has signed over all validators below L.

📐 Diagram — not normative. A tree tension chain for n = 8 validators. Depth is log₂(n), so at n = 100 the chain completes in 7 × 150 ms ≈ 1,050 ms — well within the 6-second block interval.

flowchart BT
    V1((V₁)) --> N12((N₁₂))
    V2((V₂)) --> N12
    V3((V₃)) --> N34((N₃₄))
    V4((V₄)) --> N34
    V5((V₅)) --> N56((N₅₆))
    V6((V₆)) --> N56
    V7((V₇)) --> N78((N₇₈))
    V8((V₈)) --> N78
    N12 --> N1234((N₁₋₄))
    N34 --> N1234
    N56 --> N5678((N₅₋₈))
    N78 --> N5678
    N1234 --> ROOT[["verification_helix_root<br/>(tree root)"]]
    N5678 --> ROOT
    style ROOT fill:#fce4ec,stroke:#c2185b
Loading

PART X — CANONICAL DEVIATIONS FROM PRIOR SPECS

14. What Changed and Why

This table documents every deviation from prior specs. All are justified on technical grounds. Implementation must follow this document, not any prior version.

Prior Spec Had This Spec Has Reason
Ed25519 signatures Dilithium5 Ed25519 broken by Shor's algorithm on quantum hardware. Harvest-now-decrypt-later attacks are present-tense.
X25519 KEM Kyber1024 X25519 elliptic curve discrete log broken by Shor's algorithm.
Bulletproofs ZK [u8;32] placeholder Bulletproofs are classical. No production-ready post-quantum ZK substitute exists. Slot reserved.
Daisy chain as consensus BFT + post-finality tension chain Daisy chain provides liveness only, not safety. Bonding curve requires absolute BFT finality.
Vec<u8> tx fields Fixed-size fields only Variable-length fields make tx byte size content-dependent. Breaks deterministic serialization.
anchor_range = 100 filament_commitment [u8;32] 100-position space provides trivially weak hiding. Replaced with full Blake3 output space (2²⁵⁶).
FrequencyHints struct Dropped entirely Electrical engineering metaphors with no computational definition. Not implementable.
GRAD tracks 80% of gross SOVRN tracks 32% (locked reserve) SOVRN audits the locked reserve specifically. The 80% contains both locked (32%) and liquid (48%). Tracking all 80% conflates the two.
Graduation threshold 2,745,966 GRADUATION_THRESHOLD = 2,690,000 SOV 2,745,966 derived before 40/60 split was specified, using wrong denominator. Correct derivation: 269,000 USD / 0.10 USD per SOV = 2,690,000.

CANONICAL STATUS

This document supersedes: SPEC.md v1, VERIFICATION.md, all prior bonding curve specs, all prior GRAD token designs, and all prior Filament specs. Implementation MUST match this document. Any deviation requires a formal ADR referencing this document as the baseline. Graduation threshold: 2,690,000 SOVRN (locked reserve at P_ref = 0.10 USD/SOV). Locked.

End of document. Version 2.0 — April 2026 — The Sovereign Network Core Team.

References

This References section is a non-normative enrichment added by the wiki. It points to the canonical upstream sources for standards and concepts cited in the specification.

Post-Quantum Cryptography

Symmetric Primitives

Byzantine Fault Tolerant Consensus

Networking & Transport

Economic Model

Related Sovereign Network Documentation

← Back to Documentation

Home

Documentation

Infrastructure

Research Notes

Testnet Policy

Policy

Clone this wiki locally