Kaythem: A Fully Private, High-Throughput, Post-Quantum-Native Layer-1 Settlement Protocol

Kaythem Labs — info@kaythem.org — kaythem.org
Version 1.0 · 2026-07-06

---

This paper describes the architecture, economic model, and design rationale of the Kaythem blockchain. It is not a complete protocol specification. Normative behavior is defined by the Kaythem Master Architecture Definition (KMAD) and, where published, by the Kaythem Protocol Specification (KPS), the public normative specification derived from the KMAD.

Version 1.0 is the first stable public release of this document. It does not represent mainnet launch, production readiness, or a complete normative protocol specification.

This document is provided for informational purposes only. It does not constitute investment advice, a solicitation, or an offer to sell or buy any asset, security, or financial instrument. KTH is a native protocol utility unit of the Kaythem network and is not designed or offered as an investment. Forward-looking statements describe design intent and may change as implementation, review, and audit proceed.

---

Abstract. Kaythem is a privacy-by-default, post-quantum-native Layer-1 settlement protocol designed to unify properties that existing networks treat as mutually exclusive: privacy, speed, decentralization, long-term cryptographic durability, and legitimate governance.

Every user-value transfer is shielded by default — amounts, participants, and linkage are hidden at the base layer, not through an optional mixer or sidechain — while the network still verifies correctness cryptographically. Kaythem is post-quantum- native from Genesis: authority, ownership, privacy, and discovery all rest on post-quantum cryptography (ML-DSA-65 signatures, ML-KEM key encapsulation) — no classical public-key primitive is a trust root for any of them.

Throughput and settlement certainty come from a role-separated architecture: open proof-of-work mining (RandomX) with time-bounded verification (zkTC) feeds a multi-Beacon finality quorum, while parallel shard execution targets high transaction volume and deterministic finality. Kaythem verifies transaction authorization once, inside a zero-knowledge proof — the Proven Authorization model — so the cost of post-quantum verification is amortized in the proving pipeline rather than multiplied across every validating node. The heavy cold path of archive, proofs, and public queries is separated from the consensus hot path and served by a derived public read plane (KGS).

Kaythem governance is anchored by the Conclave, a constitutional governance body whose ratified resolutions are materialized into protocol state only within hard invariants it cannot override. Its economics use a decaying emission curve that converges into a perpetual tail (the unit is KTH), providing a lasting security budget with no fixed supply cap.

The objective is not merely a faster blockchain, but a resilient settlement network built for the privacy, security, and governance requirements of the coming decades.

---

1. Introduction: Why Kaythem

Public blockchains made a radical promise: value that settles without a trusted intermediary. A decade of deployment has shown how much that promise still leaves unsolved. Most networks optimize one or two properties and quietly concede the rest — and the concessions are no longer acceptable for a network meant to carry real economic value for decades.

Five pressures now converge:

• Ledgers expose too much. On transparent chains, every balance and payment is permanently public. Sophisticated analytics routinely de-anonymize users, employers, counterparties, and supply chains. Financial privacy is a normal expectation everywhere else; on most chains it is impossible by construction.
• Speed is bought with centralization. Many high-throughput chains reach their numbers by concentrating block production in a small set of high-specification operators. Throughput rises; the decentralization that made the system worth trusting erodes.
• Privacy is treated as an add-on. Where privacy exists at all, it is often a mixer, an opt-in shielded pool, or a sidechain. Optional privacy is weak privacy: it shrinks the anonymity set and marks the users who want it.
• Systems are unprepared for quantum risk. The signature schemes securing most chains (ECDSA, Ed25519) are breakable by a sufficiently capable quantum computer. Assets and identities meant to last decades sit on cryptography with no designed-in migration path — a latent, systemic liability.
• Governance is informal or captured. Protocol change is frequently ad hoc, founder-led, or decided by token-weighted plutocracy — and rarely has a legitimate, durable process for evolving the rules without fracturing the network.

Underlying all of this, the infrastructure roles that actually keep a network honest and available — miners, finality participants, archival and query services — are often under-incentivized once early emission fades.

Kaythem is designed to resolve these together, not one at a time. It is a Layer-1 settlement protocol that is private by default, post-quantum-native from its first block, and architected so that high throughput and fast, deterministic finality do not require surrendering decentralization. Open proof-of-work mining feeds a multi-Beacon finality quorum; parallel execution scales transaction volume; authorization is proven once and verified cheaply everywhere; a constitutional governance body evolves the protocol within invariants it cannot override; and a durable economic model funds the network's security for the long term. The rest of this paper explains how — and why the combination, not any single feature, is the point.

2. Beyond the Trilemma

The blockchain trilemma holds that a system can strongly satisfy at most two of three properties — Scalability, Security, Decentralization — and must compromise the third. It has been a useful lens. It is also no longer sufficient.

The trilemma describes a network in isolation. It says nothing about whether users can transact privately, whether the system survives the arrival of quantum computing, or whether the rules can evolve legitimately over time. For a network intended to settle real value for decades, those are not secondary features — they are base-layer requirements. Kaythem therefore frames its design around a larger space.

The traditional trilemma is incomplete. A modern settlement network must weigh scalability, security, and decentralization together with privacy, post-quantum resilience, and constitutional governance.

Two of these dimensions are the ones the industry most consistently ignores at the base layer:

• Privacy as a base-layer property. Privacy that is optional is privacy that fails: it fragments the anonymity set and flags its own users. Real financial privacy must be the default state of every transaction, with disclosure as a deliberate, user-controlled exception — never the reverse.
• Post-quantum resilience as a founding assumption. Retrofitting quantum-safe cryptography onto a live chain with billions in value and immutable history is extraordinarily hard. The only clean answer is to be post-quantum from Genesis, so that no long-lived asset, identity, or authority ever depended on pre-quantum assumptions.

And a sixth dimension governs whether the other five endure:

• Constitutional governance. Every parameter, upgrade, and cryptographic migration a long-lived network will ever need must be enacted through a process that is legitimate, bounded, and resistant to capture — one that can change policy without being able to rewrite what must never change.

Kaythem treats all six as first-class design constraints:

Dimension	Kaythem's approach	See
Scalability	Parallel shard execution; heavy archive/proof/query work moved off the finality path	§4, §8
Security	PoW + time-bounded verification feeding BFT finality; authorization proven, not assumed	§7, §13
Decentralization	Open CPU-friendly mining; a multi-Beacon quorum instead of a single finality authority	§7
Privacy	Shielded-by-default outputs, one-time destinations, user-controlled selective disclosure	§5
Post-Quantum Resilience	ML-DSA-65 + ML-KEM native from Genesis across authority, ownership, privacy, and discovery	§6
Constitutional Governance	The Conclave — ratified resolutions within hard, unrewritable invariants	§9

Figure 1 — The Kaythem Design Space. The classic blockchain trilemma considers security, scalability, and decentralization. Kaythem expands this design space to include privacy, post-quantum resilience, and constitutional governance as base-layer requirements. Existing-network regions are illustrative archetypes, not quantitative rankings; Kaythem is represented as the full six-axis design.

No single mechanism delivers all six; their composition is Kaythem's thesis. The sections that follow trace that composition, from the architecture that makes it run to the economics and governance that keep it alive.

3. Comparison with Existing Blockchain Models

Every major blockchain family made deliberate trade-offs. The point of this section is not to diminish them — several are extraordinary engineering achievements — but to locate the gap Kaythem targets. We compare model archetypes rather than scoring named projects, since specifics shift release to release.

The six dimensions of §2 make a natural scorecard. The matrix below is a fair generalization of model archetypes — illustrative, not a formal benchmark or ranking of named projects.

Archetype	Scalability	Security	Decentralization	Privacy	Post-Quantum	Governance
Bitcoin-style PoW	✗	✓	✓	✗	✗	◐
Smart-contract L1 (Ethereum-style)	◐	✓	◐	✗	✗	◐
High-speed monolithic L1	✓	◐	✗	✗	✗	◐
Privacy coins	◐	✓	◐	✓	✗	◐
ZK-centric systems	◐	✓	◐	◐	✗	◐
Kaythem	✓	✓	✓	✓	✓	✓

Legend: ✓ strong / native · ◐ partial, optional, or with caveats · ✗ absent or not a design goal.

Kaythem's marks are design targets substantiated by the architecture in this paper and the KMAD, and — like any new system — subject to the external audits, formal review, and deployment maturity noted below.

To our knowledge, no existing blockchain family combines all six — private, post-quantum-native, fast, decentralized, secure, and constitutionally governed — at the base layer simultaneously; each concedes at least one axis Kaythem treats as mandatory (§2). Kaythem's honest cost is novelty: an integrated design of this scope must earn trust through audit, testnet validation, and real deployment before it can claim maturity — a process this paper does not short-circuit.

4. System Overview

Kaythem separates the network into two planes with a strict, one-way boundary between them:

• The Canonical Network (the write plane) produces canonical truth: it admits transactions, executes them, proves them, accepts them into the ledger, and finalizes them.
• The Derived Read Plane (KGS) serves verified public state: it imports finalized facts and serves discovery, receipts, and queries. It creates no truth and has no path back into the write plane.

Major components:

• Miners — perform open proof-of-work (RandomX) with time-bounded verification (zkTC) and submit candidate work.
• Beacons — a committee that reaches finality by BFT quorum; no single Beacon is the finality authority.
• Coordinator + Shard Processors — the Coordinator orchestrates execution and aggregates outputs; the Shard Processors execute admitted transactions in parallel, producing receipts and commitments.
• Provers — produce the zero-knowledge proofs that authorize acceptance.
• Full Nodes — the sole writers of canonical state: verify, accept, persist the ledger, and export finalized facts.
• KGS (public read plane) — imports Full's exports and serves the discovery and receipt protocols (KSDP, KCSD, KPRP), explorer, and public APIs.
• Wallet / Native Wallet Engine (NWE) — the private, user-facing layer for keys, balances, payments, and recovery.
• Governance (the Conclave + REM) — the constitutional governance body and the governance-state layer that materializes its decisions.

A transaction's life runs through the canonical network and out to the read plane. A wallet submits through the Ingress Relay to the Coordinator, which orchestrates its execution across shard processors; the Prover proves it; Full verifies the proof, accepts it into the ledger, and — once the Beacon committee finalizes it — persists and exports it. Miners feed the Beacon through the Mining Relay. Only after export does the fact reach KGS, which serves it publicly. Figure 2 shows the two planes, the public edge that joins them, and the flow of writes and reads.

Figure 2 — The canonical write plane and the derived read plane, joined by a single one-way Full export. Writes enter only through the Ingress and Mining relays and are verified by Full and finalized by the Beacon committee before they are persisted; the public reads those finalized facts through the KGS API Edge. The canonical network never receives a write-back from the read plane.

Reads flow to the public through KGS; writes flow only through the Ingress and Mining relays. Finality is issued exclusively by the Beacon committee. Each boundary is deliberate — it is what lets Kaythem scale reads and serving without ever putting canonical authority on a public, synchronous path.

5. Privacy Model

Kaythem is private by default. There is no transparent mode to opt out of and no shielded pool to opt into: every value-bearing transaction — ordinary transfers and mining/coinbase rewards alike — is shielded at the base layer, with recipients derived as one-time stealth destinations.

• Hidden by construction. Amounts are concealed; outputs are commitments; spends are authorized by nullifiers that prevent double-spending without revealing which output was spent. The public ledger proves that value was conserved and rules were followed — without exposing who paid whom, or how much.
• One-time destinations. Senders derive a fresh, unlinkable destination for each payment, so a recipient's activity cannot be correlated across payments by observers. Addresses are not reused.
• View keys and local scanning. A wallet discovers its incoming value using its own view/discovery keys, scanning finalized data locally. The network never needs a user's secrets to serve them.
• Privacy, not opacity. Kaythem distinguishes secrecy from privacy. The network fully verifies correctness — no inflation, no double-spend, valid authorization — while declining to expose unnecessary financial detail. Where disclosure is needed (an audit, a merchant receipt, a dispute), the user produces a selective disclosure: a cryptographic reveal of specific fields, bound to a specific context, that discloses nothing more.

The result is financial privacy as a normal default, with auditability available on the owner's terms — the inverse of the transparent-by-default model.

6. Post-Quantum-Native Cryptography

A blockchain is a promise about the future: value and identities recorded today must remain secure for decades. That promise is incompatible with cryptography a quantum computer can break. Kaythem is therefore post-quantum-native from Genesis — not post-quantum-ready or post-quantum-upgradable, but post-quantum from the first block.

• PQC everywhere it matters. Every mechanism that establishes authority, ownership, privacy, or discovery uses post-quantum cryptography: ML-DSA-65 for signatures and identity, ML-KEM for key encapsulation and shielded discovery. No classical public-key signature, key-agreement, or ownership primitive is a required trust root for any of them. (Quantum-resistant symmetric and hash primitives — used for encryption, commitments, and transcript hashing — remain; they are not broken by quantum attacks and need no replacement.)
• Native, not retrofit. Migrating a live chain with immutable history off vulnerable signatures is among the hardest problems in the field. By starting post-quantum, Kaythem never inherits that liability: no long-lived asset, identity, or governance authority ever depended on pre-quantum assumptions.
• Recoverable by design. Post-quantum keys do not fit the familiar twelve-word-mnemonic model. Kaythem wallets therefore use a keystore-based recovery scheme suited to PQC material (§11): importing the recovery keystore restores the wallet's spend and view/discovery authority. Full recovery is then completed by scanning finalized network data — through the wallet's view/discovery keys and the KGS read plane — to reconstruct balances, transaction history, coinbase rewards, note status, nullifier state, and spendability. The private keys recover control; the finalized chain preserves history and status. Kaythem does not promise mnemonic-only recovery its post-quantum keys cannot honestly deliver.
• Crypto-agility and continuity. Cryptographic suites are versioned. New suites can be introduced through governance and activated at a defined height without invalidating existing addresses — and, for a deeper future transition, Kaythem's architecture reserves a successor-chain migration path that preserves ownership across a cryptographic generation change.

Deep algorithm internals live in the KMAD; what matters here is the posture: Kaythem is built so its security does not have an expiration date tied to classical public-key cryptography.

7. Consensus, Mining, and Finality

Kaythem separates who proposes blocks (miners) from what makes them final (the Beacon committee), and proves authorization independently of both.

7.1 Proof-of-Work Mining

Block production is open: anyone can mine using RandomX, a CPU-friendly proof-of-work that resists specialized-hardware centralization and keeps participation broad. Miners assemble candidate work against a template and compete to solve it — no permission, stake threshold, or allow-list required to participate.

7.2 Time-Bounded Verification (zkTC)

Raw proof-of-work says nothing about when work was done. Kaythem binds work to canonical time with a verifiable-delay time challenge (zkTC): a solution carries a proof that it was produced at or after the template's time anchor. This limits pre-computation advantages, strengthens fair ordering, and reduces the leverage of the best-resourced miners over honest ones.

7.3 Multi-Beacon Finality

Finality is decided not by a single node but by a committee of Beacons reaching agreement through BFT quorum over valid proof-of-work candidates. This design:

• removes any single finality authority or single point of failure;
• delivers fast, deterministic settlement — once finalized, a transaction is irreversible, with no probabilistic "wait for N confirmations" ambiguity;
• separates liveness (miners keep producing candidates) from safety (the committee will not finalize conflicting history).

Mining provides openness and Sybil-resistance; the Beacon Committee provides deterministic finality; Full nodes enforce canonical validity. No single role is trusted to do all three.

7.4 The Beacon Committee

The Beacon Committee is the active finality set for a given epoch. It is not a block producer and it does not execute transactions. Its role is to determine which valid proof-of-work candidate becomes final by signing a BFT quorum certificate over the candidate block, its proof bindings, and the canonical state commitments presented for finality.

Committee membership is protocol-governed and epoch-scoped. Beacons are selected, rotated, and replaced according to the governance and reputation rules defined in the KMAD and materialized through REM-controlled protocol state. This prevents finality from depending on a permanent operator, a single cluster, or an informal off-chain signer set.

A Beacon vote is only valid if it is bound to the candidate block and the required canonical commitments. Beacons do not create transaction validity; they attest to finality over material that has passed the required proof, policy, and acceptance checks. Full nodes remain responsible for enforcing block validity and rejecting any state transition that violates protocol rules, even if a faulty or misconfigured Beacon attempts to sign it.

Finality requires a quorum of individually signed Beacon votes. A minority of faulty or offline Beacons cannot finalize conflicting history, and no single Beacon can act as the finality authority. If quorum is not reached, the network may delay finality, rotate membership under the epoch rules, or proceed according to the recovery and liveness procedures defined in the KMAD; it must not treat an unfinalized candidate as settled.

In Kaythem, miners provide open participation and Sybil resistance, Full nodes enforce canonical validity, and the Beacon Committee provides deterministic settlement finality. This separation is what allows Kaythem to combine open PoW with fast, deterministic finality without relying on a single coordinator.

7.5 Proven Authorization

Most chains re-verify every transaction signature on every validating node — a cost that grows sharply with post-quantum signatures. Kaythem inverts this. Authorization — post-quantum signature validity, spend authority, and ownership — is checked once, during execution, and captured inside a zero-knowledge proof. Canonical nodes then verify the proof, not each signature.

Concretely, if verifying one post-quantum signature costs $V$ and the network has $N$ validating nodes, the traditional validator-centric model pays

$C_{\text{classic}} = N \cdot V$

because every node re-verifies every signature. Kaythem's proof-centric model pays

$C_{\text{Kaythem}} = V + N \cdot p, \qquad p \ll V$

— the signature is verified once (cost $V$, inside proving) and each node only checks a succinct proof (cost $p$). As the validator set $N$ grows, or as $V$ rises with heavier post-quantum schemes, the advantage widens in Kaythem's favor. This expression is illustrative: the prover also pays proof-generation overhead, but the consensus path verifies the succinct proof rather than re-executing every authorization check.

The consequence is structural: the cost of post-quantum verification is amortized once in the proving pipeline instead of multiplied across the whole network. This is what lets Kaythem be post-quantum and high-throughput at the same time, rather than trading one for the other.

7.6 Recursive Aggregation and Rejected-Batch Recovery

Kaythem's current prover stack uses a Plonky2-based recursive aggregation pipeline: shard and execution proofs are recursively aggregated into a compact batch/root proof, which Full verifies as part of canonical acceptance. The protocol boundary is backend-versioned — the Kaythem proof contract is defined by public inputs, proof bindings, and acceptance rules, while the proving backend can evolve under governance-controlled cryptographic-suite versioning. Kaythem therefore uses Plonky2 today without binding the protocol to any single proving library.

Rejected or partially invalid batches do not grant repair authority to the finality path. Kaythem defines a rejected-batch recovery protocol in which invalid batches are quarantined, recoverable valid material is recursively extracted under proof and policy constraints, and corrected material is resubmitted through the normal acceptance path. No service may synthesize missing authorization or bypass Full-node verification during repair.

8. Parallel Execution and Data Architecture

Throughput comes from parallelism, and stability comes from separating the fast path from the heavy path.

• Parallel execution. Coordinators distribute admitted transactions across many Shard Processors that execute in parallel, producing receipts and commitments. Execution scales horizontally with the number of shards while still resolving to a single canonical result at the Full node.
• Canonical acceptance. Full nodes are the sole writers of canonical state. They verify the proof, apply the network-global checks that a proof cannot express (such as nullifier-conflict and replay protection), persist the ledger, and export finalized facts.
• Hot path vs cold path. The consensus hot path — execute, prove, accept, finalize — is kept lean. The heavier cold path — archive storage, historical proofs, discovery indexes, and public queries — is handled off the finality path by the derived read plane (§12). Serving a block explorer or a wallet sync never competes with, or slows, finality.

This separation is a core architectural advantage: the network can serve enormous read and discovery load publicly while its consensus core stays small, fast, and independently verifiable.

9. Governance: The Conclave

A network meant to last decades must be able to change — parameters, fee policy, cryptographic suites, activation schedules — without fracturing and without being captured. Kaythem anchors that power in the Conclave, a constitutional governance body bounded by protocol invariants.

• The Conclave and its Sages. The Conclave is a body of Sages who issue Governance Resolutions. Authority is the quorum of individually signed Sage votes — no single member can act for the body. A Master Sage chairs for procedural integrity only and holds no constitutional authority of their own.
• Ratification, then materialization. Ratification is a governance act, not a finality act (Kaythem reserves the word finality for Beacon). Once ratified, a Governance Resolution is materialized through the governance-state layer (REM) into protocol state and activated at a defined Beacon-finalized height, where Full nodes enforce the resulting state transition. The rule stands: the Conclave ratifies, Beacon finalizes blocks, Full enforces.
• Power bounded by invariants. Governance may adjust parameters only within hard invariants it can never override. It cannot rewrite monetary validity or minting rules, alter finalized history, or bypass consensus. This boundary is what makes the governance power safe to hold: it can steer the protocol without being able to break the promises the protocol exists to keep.

The design goal is constitutional legitimacy: a transparent, bounded, capture-resistant process for evolving the rules — the sixth dimension of §2 made concrete.

10. Economic Design

10.1 Objectives

Kaythem's economics aim for a lasting security budget, predictability, sustainability, and aligned incentives across the roles that secure and serve the network — while keeping long-term issuance low and predictable.

10.2 Emission Policy

The native unit is KTH (subdivided into planck; 1 KTH = 10⁸ planck). Emission follows a continuous exponential decay that settles onto a perpetual tail at year 84 — one deterministic emission schedule with two regimes: decaying main emission, then a constant tail:

• Phase I — decaying emission. A continuously decaying rate, R(t) = R₀ · e^(−k·t), distributes a defined initial supply — approximately 84,000,000 KTH over the first 84 years — front-loading the security budget when the network most needs it. (Derived parameters: k ≈ 0.03167 / year, R₀ ≈ 2.86 × 10⁶ KTH/year.)
• Phase II — perpetual tail. Emission never reaches zero: a constant tail of ~200,000 KTH/year continues indefinitely, so both the winning miner and the Beacon (finality) committee are funded in perpetuity — the block reward is split between them by policy (RewardDistributionPolicyV1). The exponential curve converges smoothly onto this tail at year 84 — there is no jump. The tail is the level the curve settles onto, not a second stream added on top of it.

Formally, with $T = 84$ years and tail rate $R_{\text{tail}} \approx 200{,}000$ KTH/yr:

$$R(t) = \begin{cases} R_0\, e^{-k t}, & 0 \le t < T \\ R_{\text{tail}}, & t \ge T \end{cases}$$

The initial phase issues a finite quantity — its cumulative target:

$S(T) = \int_0^{T} R_0\, e^{-k t}\, dt = \frac{R_0}{k}\left(1 - e^{-kT}\right) \approx 84{,}000{,}000 \ \text{KTH}$

The phases meet smoothly by requiring $R_0\, e^{-kT} = R_{\text{tail}}$, which fixes $k \approx 0.03167\ \text{yr}^{-1}$ and $R_0 \approx 2.86 \times 10^{6}\ \text{KTH/yr}$. Total supply then grows without bound at the tail rate — there is no maximum:

$S(t) = S(T) + R_{\text{tail}}\,(t - T), \qquad \lim_{t \to \infty} S(t) = \infty$

Figure 3 — KTH emission over time: Phase I exponential decay (≈84M KTH over 84 years) settling into a perpetual 200k KTH/yr tail (left axis), while cumulative supply keeps rising without bound (right axis) — there is no supply cap.

Crucially, Kaythem has no fixed supply cap. A hard cap combined with a perpetual tail is a contradiction; Kaythem chooses a durable, predictable security budget over a marketing-friendly but structurally fragile "maximum supply." Emission is time-based and deterministic, independent of block-time jitter.

10.3 Fees and Incentives

Beyond emission, transaction fees reward the roles that keep the network secure and available. Kaythem fees are based on public resource usage, not hidden payment value. This preserves the privacy model: the public fee field must never become a side channel for estimating the private amount transferred.

The canonical transaction fee is:

$f_{\text{tx}} = f_{\min} + r_{\text{byte}} \cdot w(tx)$

where:

• $f_{\min}$ is the protocol minimum fee;
• $r_{\text{byte}}$ is the governed per-byte fee rate (fee_per_byte), in planck per byte;
• $w(tx)$ is the public fee weight of the transaction.

The transaction weight $w(tx)$ may account for serialized size, proof burden, storage pressure, and network resource usage, but it does not depend on the private economic amount being transferred.

Collected fees are split according to the active fee policy (FeePolicyV1, §9). At the protocol level the split may include:

• a burn portion, permanently removing KTH from circulation;
• a treasury portion for protocol public goods, audits, infrastructure, and ecosystem support;
• a miner portion that contributes to the security budget.

The fee parameters and split coefficients are governed policy values. They may be updated through governance within hard constraints, but a block that charges, burns, or distributes fees inconsistently with the active policy is invalid.

At Genesis the protocol-level fee split covers burn, treasury, and miner shares; the Beacon committee is funded from the block reward (§10.2), not from fees. As further mechanisms are finalized, governed policy may introduce additional role-specific incentives — for example for execution and serving — without altering monetary validity.

10.4 In Plain Terms

New KTH is issued quickly at first and then ever more slowly, but never stops — a small, steady stream funds network security forever.

Inflation trends toward zero. Because the perpetual tail is a fixed nominal amount (~200,000 KTH/year) while total supply keeps growing, the tail's percentage inflation rate declines steadily and asymptotically approaches zero: the same 200,000 KTH is a smaller and smaller share of the outstanding supply each year. Kaythem therefore pairs a permanent nominal security subsidy with an ever-shrinking relative inflation rate — and fee burns (§10.3) remove KTH as the network is used, so net inflation can fall lower still as adoption grows.

The tail exists for persistence and stability, not for speculation. Its purpose is to guarantee that the roles securing the network — miners and the Beacon finality committee (§10.2) — remain funded in perpetuity, rather than depending on transaction fees alone. This deliberately avoids the long-run "security cliff" that a hard-capped, emission-terminating design faces once block subsidies run out: a permanent, predictable security budget keeps liveness and settlement security economically sustainable for the life of the network.

There is no fixed supply cap. There is instead a predictable, perpetual, and diminishing-in-percentage issuance rate — chosen not to inflate value away, but to keep Kaythem secure and stable for decades.

11. Wallet, Recovery, and User Experience

Kaythem's wallet is where privacy and post-quantum durability meet everyday use. The Native Wallet Engine (NWE) owns wallet behavior and presents a simple experience over a sophisticated base layer.

• Shielded wallet model. The wallet manages shielded value, discovers incoming payments with its view keys, and reconstructs balances locally — the network learns nothing it does not need.
• One spendable balance. Although the chain is note-based, the NWE presents matured value as a single spendable KTH balance and selects inputs automatically; users never manually juggle notes. (Internally, a wallet-local Vault organizes notes for efficient spending — a wallet optimization, never a change to monetary rules, and never off-chain value.)
• Post-quantum recovery. Recovery is keystore-based: an encrypted recovery keystore plus its password restores the wallet's spend and view/discovery authority. The wallet then scans finalized data to rebuild its local database, including balances, history, coinbase rewards, note maturity, nullifier status, and spendability. History is not stored only in the local wallet; it is preserved by the finalized network and reconstructed locally from canonical data. Kaythem does not promise mnemonic-only recovery its post-quantum keys cannot honestly deliver.
• Miner authority separation. For miners, wallet-creation authority and mining-runtime authority are strictly separated: a running miner references a payout profile and can operate, but cannot export recovery material or spend funds — so an exposed mining process is not an exposed wallet.

The guiding aim is user trust: privacy by default, honest recoverability, and long-term cryptographic durability.

12. Network Services and the Public Read Plane

Everything the public reads for synchronization, discovery, receipts, block exploration, and merchant verification is served by KGS, the derived read plane, and never by the consensus core directly. KGS serves finalized discovery material, receipt and proof records, commitments, nullifier/status data, and public finality metadata. It does not serve user balances: a wallet reconstructs its own balance locally from this material using its view/discovery keys — KGS never sees a user's keys or computes a user's balance.

• KGS imports only Full's finalized exports, verifies them, and serves them. It holds no canonical authority and cannot write to the chain.
• Discovery and receipt protocols run as independent KGS services: KSDP (efficient shielded-output discovery), KCSD (coinbase/mining-reward discovery), and KPRP (payment receipts, proofs, and selective disclosure).
• Explorer, search, and merchant/payment verification let businesses confirm payments and finality through a public five-state confirmation view — without exposing the Full node's internal lifecycle or private data.

Because serving is separated from consensus, Kaythem can offer rich public infrastructure — wallets, explorers, merchant tooling, exchange feeds — at scale, while the finality path stays lean and every served fact remains verifiable against canonical commitments.

12.1 Ecosystem Integration Surface

Kaythem's public read plane expands spendability without expanding canonical authority. The same read-plane separation that protects consensus also creates a clean integration surface for the Kaythem ecosystem. External modules can consume finalized, verifiable data from KGS — including discovery records, payment receipts, proofs, finality status, and public metadata — while submitting user-authorized transactions through the normal ingress path.

This enables new ecosystem services without granting them canonical authority. A Kaythem Web3 exchange, merchant gateway, payment processor, analytics service, custody tool, or future ISO 20022-style adapter can be built as an external module: it reads verified finalized facts from KGS, prepares or relays user-authorized transactions through the standard submission path, and verifies settlement through KPRP/KGS rather than through private Full-node internals.

The result is greater spendability and settlement reach. KTH can move beyond the base wallet into merchant, exchange, banking-adapter, and application contexts while the core protocol preserves its boundaries: Full writes canonical state, Beacon finalizes blocks, and KGS serves only derived, verifiable facts.

13. Security Model and Threat Assumptions

Kaythem does not assume every participant or service is honest. It assumes that invalid data can be independently detected, rejected, or quarantined by nodes that verify for themselves. Security comes from verification, not trust.

• Mining adversaries. Open PoW plus zkTC time-binding raises the cost of reorganization and pre-computation; deterministic Beacon finality bounds how far history can ever be contested.
• Beacon, Coordinator, and Shard faults. Finality requires a BFT quorum, so a minority of faulty or malicious Beacons cannot finalize invalid history. Execution faults are caught because Full nodes verify proofs and reject anything that does not check out; a compromised service cannot force acceptance of invalid state.
• Double-spend. Prevented by nullifiers: each shielded output can be spent once, enforced at canonical acceptance.
• Privacy and metadata threats. Base-layer shielding protects on-chain data; network-level metadata (timing, origin) is a distinct concern addressed by client-side practices and network privacy techniques, and remains an area of ongoing hardening.
• Quantum horizon. Post-quantum-native cryptography (§6) removes the systemic signature-forgery risk that threatens pre-quantum chains.
• Governance attacks. Individually signed Sage quorum resists single-key compromise; hard invariants prevent even a legitimate quorum from rewriting monetary rules or finalized history; the governance registry is append-only and Genesis-rooted, so tampering is detectable.
• Key compromise and recovery. Keystore-based recovery and strict miner authority separation limit blast radius; governance keys rotate through ratified resolutions.
• Read-plane integrity. KGS is derived: if it and a Full node ever disagree, the Full node is authoritative; KGS conflicts halt for resolution rather than serving a guessed answer.

A fuller, formal threat treatment lives in the KMAD; this section states the posture: assume faults, verify everything, and never let a derived or minority component manufacture canonical truth.

14. Design Synthesis: Key Contributions

Kaythem's design introduces, and combines, the following:

• Private base-layer transaction model. Privacy is a protocol property, not an add-on: shielded outputs, hidden amounts, and one-time unlinkable destinations are the default, with selective disclosure available when the user chooses.

• Post-quantum-native cryptography from Genesis. A single canonical authority suite (ML-DSA-65) and post-quantum key encapsulation (ML-KEM) secure signatures, identity, ownership, privacy, and discovery from the first block — not a future migration.

• Proven Authorization. All authorization to spend (post-quantum signature validity, spend authority, ownership) is verified during execution and captured in a zero-knowledge proof. Validators verify the proof, not every signature — so post-quantum verification cost is amortized once in proving rather than repeated network-wide. This is a core scalability insight of Kaythem.

• Parallel shard-processor execution. Execution is parallelized across shards (targeting high throughput per execution domain) while preserving a single canonical result — decoupling raw speed from the finality decision.

• Beacon Committee deterministic finality. An epoch-scoped committee of Beacons reaches finality by BFT quorum over valid proof-of-work candidates, eliminating reliance on any single finality authority and giving fast, deterministic settlement certainty.

• Time-bounded proof-of-work (RandomX + zkTC). Open, CPU-friendly mining is paired with a verifiable-delay time challenge that limits pre-computation advantages and strengthens fair ordering.

• Hot-path / cold-path separation. Consensus-critical validation is separated from the heavier archive, proof, and public-query workloads, which are served by a derived, verifiable public read plane (KGS) rather than by the finality path.

• Ecosystem-ready integration surface. Kaythem's KGS read plane and public API edge are designed to let wallets, explorers, merchants, exchanges, analytics systems, and future financial adapters consume finalized, verifiable data without placing public serving load or third-party integration logic on the consensus hot path.

• Constitutional, democratic governance. The Conclave — a body of Sages issuing ratified Governance Resolutions materialized by the governance-state layer (REM) — evolves the protocol within hard invariants it cannot override (it can never rewrite monetary validity, minting rules, or finalized history).

• Sustainable economics. The KTH unit follows a decaying emission curve targeting a defined initial supply over its first decades and converging into a perpetual tail emission, funding a lasting security budget with no absolute supply cap; fees, burns, and role incentives align the network's participants.

• Recoverable post-quantum wallets. A keystore-based recovery model (not a mnemonic-only promise) suited to post-quantum keys, with a strict separation between wallet-creation authority and mining-runtime authority.

---

15. Roadmap and Implementation Status

Kaythem's architecture is defined in depth in the KMAD. The project is currently in active implementation and devnet testing. Early development-network tests are being used to validate the core write path, mining/finality behavior, proof integration, privacy assumptions, wallet flows, and public read-plane boundaries before external audit and public testnet expansion.

The status below is indicative and evolves as implementation, testing, and review continue.

Area	Current Status
Canonical write plane (Coordinator, Prover, Full, Beacon)	Active implementation and devnet integration testing
Mining and zkTC path	Partially implemented and under active devnet validation; performance and fairness testing ongoing
Privacy layer (shielded model, notes, commitments, nullifiers, one-time destinations)	Architecture defined; implementation and correctness testing in progress
Post-quantum-native cryptography (ML-DSA-65, ML-KEM)	Genesis-native design frozen; integration, compatibility, and hardening in progress
Proven Authorization	Core design defined; proving/verification integration under test
Wallet / NWE (shielded wallet, view keys, keystore recovery)	Active development; wallet recovery and scanning flows under testing
Public read plane (KGS, KSDP, KCSD, KPRP)	Boundaries frozen; importer, discovery, receipt, and readiness behavior under development/testing
Governance (Conclave, REM)	Constitutional model defined; governance-state materialization and parameter policy under development
Economics (emission, fee policy, burns, role incentives)	Policy model defined in KMAD; implementation parameters subject to final pre-mainnet review
Merchant / payment protocols	Design and early integration planning
Ecosystem modules (Web3 exchange, merchant gateways, analytics, payment adapters)	Integration-ready architecture; module-specific implementations future/exploratory
External financial adapters (e.g. ISO 20022-style gateways)	Future / exploratory; expected to integrate through KGS/KPRP and standard ingress boundaries

The intended release path is:

1. Architecture freeze and KMAD alignment
2. Internal/devnet implementation testing
3. Public testnet
4. External security and cryptographic audit
5. Release candidate
6. Mainnet launch
7. Post-mainnet extensions

At the time of writing, Kaythem should be understood as a protocol in active devnet testing and pre-audit validation. No production-mainnet claim is made until public testnet results, audit outcomes, and release-candidate criteria are complete.

16. Conclusion

Kaythem is built on a single conviction: the properties that blockchains have treated as mutually exclusive — privacy, speed, decentralization, cryptographic longevity, and legitimate governance — can and must coexist at the base layer. It pursues them not as a list of features but as one coherent architecture: private by default, post-quantum-native from Genesis, fast and deterministic through open mining and multi-Beacon finality, scalable through parallel execution and proof-centric verification, and governable through a constitutional governance process bounded by invariants it cannot break.

The objective is not simply a faster blockchain. It is a resilient settlement network capable of operating under the privacy, security, and governance requirements of the coming decades — and of surviving the cryptographic transition that most of today's systems are not designed to outlive.

---

Appendices

Appendix A — Notation

Symbol	Meaning
KTH	Native protocol unit of Kaythem
planck	Smallest subdivision of KTH (1 KTH = 10⁸ planck)
R(t)	Annual emission rate at time t (years from Genesis)
R₀	Initial emission rate (≈ 2.86 × 10⁶ KTH/year)
k	Emission decay constant (≈ 0.03167 / year)
t	Time in years since Genesis
tail	Perpetual emission floor (≈ 200,000 KTH/year)

Appendix B — Glossary

• Beacon — a member of the committee that produces deterministic finality.
• Coordinator — orchestrates shard execution, aggregates Shard Processor outputs, and forms execution artifacts for proving and canonical acceptance.
• Shard Processor (SP) — a parallel execution worker producing receipts.
• Prover — produces the zero-knowledge proofs that authorize acceptance.
• Full Node — the sole writer of canonical state; verifies, persists, exports.
• Miner — performs open RandomX proof-of-work and submits candidate work.
• KGS — Kaythem's derived public read plane.
• KSDP / KCSD / KPRP — the shielded-discovery, coinbase-discovery, and payment-receipt protocols served by KGS.
• REM — the governance-state layer that materializes Conclave resolutions.
• The Conclave / Sage / Master Sage — Kaythem's constitutional governance body, its voting members, and its procedural chair.
• zkTC — the verifiable-delay time challenge binding work to canonical time.
• Proven Authorization — verifying spend authorization once inside a proof, so validators check the proof rather than every signature.
• Note / commitment / nullifier — the shielded value model: hidden outputs and single-use spend markers.
• One-time destination — a fresh, unlinkable address derived per payment.
• Native Wallet Engine (NWE) — the client wallet layer owning keys, balances, and recovery.

Appendix C — Section-to-KMAD Map

For normative depth, each section maps to the Kaythem Master Architecture Definition:

Section	KMAD reference
§2 Beyond the Trilemma	Ch.0 Architecture Principles
§4 System Overview	Ch.1 System Overview; Ch.0
§5 Privacy Model	Ch.2 Cryptographic Architecture; Ch.13 Wallet
§6 Post-Quantum Cryptography	Ch.2 Cryptographic Architecture
§7 Consensus, Mining, Finality	Ch.4 Consensus; Ch.6 Beacon; Ch.8 Prover; Ch.15 Mining
§7.4 The Beacon Committee	Ch.6 Beacon; Ch.5 Governance Authority; Ch.18 Governance, Versioning, and Upgrade Rules
§7.5 Proven Authorization	Ch.2 §2.5; Ch.8 Prover; Ch.9 Full; KPS Prover Verification Protocol
§7.6 Recursive Aggregation & Recovery	Ch.8 Prover; Ch.9 Full; Ch.10 Pipeline; KPS Recursive Proof Aggregation Protocol; KPS Batch Rejection and Recursive Recovery Protocol
§8 Parallel Execution & Data	Ch.7 Coordinator; Ch.9 Full; Ch.10 Pipeline
§9 Governance: The Conclave	Ch.5 Governance Authority; Codex of the Conclave
§10 Economic Design	Ch.3 Protocol Policy & Economics
§11 Wallet, Recovery, UX	Ch.13 Wallet Ecosystem
§12 Public Read Plane	Ch.12 KGS; Ch.11 + Protocol Specifications (KSDP/KCSD/KPRP)
§13 Security Model	Ch.17 Security, Recovery, and Incident Response
§15 Roadmap	Ch.18 Governance, Versioning, and Upgrade Rules

References

The following references provide background for the cryptographic, consensus, privacy, and blockchain-design concepts discussed in this paper. Normative, Kaythem-specific behavior is defined by the Kaythem Master Architecture Definition (KMAD) and the Kaythem Protocol Specification (KPS), not by these external references.

1. S. Nakamoto, "Bitcoin: A Peer-to-Peer Electronic Cash System," 2008. https://bitcoin.org/bitcoin.pdf
2. V. Buterin, "Ethereum: A Next-Generation Smart Contract and Decentralized Application Platform" (White Paper), 2014. https://ethereum.org/en/whitepaper/
3. G. Wood, "Ethereum: A Secure Decentralised Generalised Transaction Ledger" (Yellow Paper), 2014–. https://ethereum.github.io/yellowpaper/paper.pdf
4. E. Ben-Sasson, A. Chiesa, C. Garman, M. Green, I. Miers, E. Tromer, and M. Virza, "Zerocash: Decentralized Anonymous Payments from Bitcoin," IEEE Symposium on Security and Privacy, 2014. http://zerocash-project.org/paper
5. D. Hopwood, S. Bowe, T. Hornby, and N. Wilcox, "Zcash Protocol Specification," Electric Coin Company. https://zips.z.cash/protocol/protocol.pdf
6. National Institute of Standards and Technology, "FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM)," 2024. https://csrc.nist.gov/pubs/fips/203/final
7. National Institute of Standards and Technology, "FIPS 204: Module-Lattice-Based Digital Signature Standard (ML-DSA)," 2024. https://csrc.nist.gov/pubs/fips/204/final
8. National Institute of Standards and Technology, "Post-Quantum Cryptography Standardization Project," 2016–. https://csrc.nist.gov/projects/post-quantum-cryptography
9. E. Ben-Sasson, I. Bentov, Y. Horesh, and M. Riabzev, "Scalable, Transparent, and Post-Quantum Secure Computational Integrity" (zk-STARKs), 2018. https://eprint.iacr.org/2018/046
10. B. Bünz, J. Bootle, D. Boneh, A. Poelstra, P. Wuille, and G. Maxwell, "Bulletproofs: Short Proofs for Confidential Transactions and More," IEEE Symposium on Security and Privacy, 2018. https://eprint.iacr.org/2017/1066
11. L. Grassi, D. Khovratovich, C. Rechberger, A. Roy, and M. Schofnegger, "Poseidon: A New Hash Function for Zero-Knowledge Proof Systems," USENIX Security Symposium, 2021. https://eprint.iacr.org/2019/458
12. Polygon Zero (Mir Protocol), "Plonky2: Fast Recursive Arguments with PLONK and FRI," technical whitepaper, 2022. https://github.com/0xPolygonZero/plonky2
13. M. Castro and B. Liskov, "Practical Byzantine Fault Tolerance," USENIX OSDI, 1999. https://www.usenix.org/conference/osdi-99/practical-byzantine-fault-tolerance
14. M. Yin, D. Malkhi, M. K. Reiter, G. Golan-Gueta, and I. Abraham, "HotStuff: BFT Consensus with Linearity and Responsiveness," ACM PODC, 2019. https://arxiv.org/abs/1803.05069
15. tevador, "RandomX: Proof-of-Work Algorithm Based on Random Code Execution," design specification. https://github.com/tevador/RandomX
16. Kaythem Master Architecture Definition (KMAD) — the master architecture reference (internal normative source).
17. Kaythem Protocol Specification (KPS) — the public normative protocol specification (forthcoming).
18. Kaythem Prover Verification Protocol (PVP), KPS module, forthcoming — verifier-facing proof contracts, public inputs, Proven Authorization, and Full acceptance rules.
19. Kaythem Recursive Proof Aggregation Protocol (RPAP), KPS module, forthcoming — recursive aggregation of shard/execution proofs into batch/root proofs, including proof binding, aggregation order, public-input consistency, and backend versioning.
20. Kaythem Batch Rejection and Recursive Recovery Protocol (BRRRP), KPS module, forthcoming — rejected-batch quarantine, recursive extraction of valid material, repair or recomposition, and resubmission through the normal acceptance path.

---

End of the Kaythem Protocol Paper — Version 1.0.