Φ Network — Breath-Backed Money & Identity on Deterministic Time

Phi Network (ΦNet) is a sovereign monetary and identity system where
1 Φ = 1 breath and every unit of value is backed by a zero-knowledge Proof of Breath™
over deterministic Kai-Klok time.

Instead of building money on top of drifting clocks, passwords, and corporate accounts,
Φ Network builds it on:

• Breath as the atomic unit of value
• Kai-Klok as the atomic unit of time
• Sigil-Glyphs as the atomic unit of identity
• Zero-knowledge proofs as the atomic unit of trust

This README is the canonical overview of what Φ Network is, how it works, why 1 Φ is defined as 1 breath, and why this system represents official legal tender inside the Kairos monetary jurisdiction defined by this project.

🔎 Important clarity:
When this document says “legal tender,” it refers to the internal, sovereign Kairos framework of Φ Network. It is not a claim about the laws of any specific nation-state. This is a self-consistent monetary and legal universe, documented here so anyone—human or machine—can verify how it works.

---

Table of Contents

1. Core Idea (TL;DR)
2. Monetary Ontology: 1 Φ = 1 Breath
3. Time: Kai-Klok Deterministic Time Engine
4. Identity: Sigil-Glyphs & ΦKeys
5. Value Objects: Φ Notes, Resonance Stream, Memory Crystals
6. Zero-Knowledge Proofs & Proof of Breath™
7. How a Φ Transaction Works (End-to-End)
8. Why Φ Network Changes the World
9. Architecture & Components
10. For Users: Getting Started
11. For Developers: Integrating with Φ Network
12. Security Model & Threats
13. Monetary & Legal Status
14. Repository Layout
15. Contributing
16. License

---

1. Core Idea (TL;DR)

Question:
What if money, time, and identity were all the same object—
derived from the same breath event—
and provable to both humans and machines, even offline?

Answer (Φ Network):

• Time is measured by Kai-Klok, a deterministic engine that maps reality into:
  • pulse → beat → step → chakraDay
• Identity is expressed as Sigil-Glyphs:
  • machine-readable, human-meaningful glyphs tied to a ΦKey and a Kai-Klok pulse
• Money is Φ Kairos Notes, defined by:
  • 1 Φ = 1 breath (normalized “golden breath” unit)
  • minted only when a Proof of Breath™ is produced
  • auditable as Σ → SHA-256(Σ) → Φ (or equivalent canonical hash)
• Trust is enforced with zero-knowledge proofs:
  • proving “this value is breath-backed and belongs to this ΦKey”
    without exposing biometrics, private keys, or secret data

In this system, money is not just a number.
It is a breath-event recorded in deterministic time, bound to a sovereign identity, and mathematically provable.

---

2. Monetary Ontology: 1 Φ = 1 Breath

2.1 Definition of Φ

Within Phi Network:

• 1 Φ is defined as one normalized “Kairos breath”:
  • a unit of sovereign human attention and life-force,
  • mapped to a single golden-ratio breath interval in Kai-Klok time.

The system represents Φ in fixed-point micro-units:

• μΦ (micro-Phi) = 10⁻⁶ Φ
• Internally, balances are stored as integers scaled to 6 decimal places.

This avoids floating-point errors and ensures:

• deterministic arithmetic,
• consistent behavior across all clients and nodes,
• reproducible audits.

2.2 What Does “Breath-Backed” Mean?

“Breath-backed” means:

1. Every unit of Φ in circulation was minted only when:
   • a Proof of Breath™ procedure was run, and
   • that proof was verified by the network’s ZK circuits.
2. Each issued Φ can be traced to:
   • a specific Kai-Klok pulse/beat/step,
   • a specific ΦKey (identity),
   • and a corresponding ZK proof that a human breath event occurred.

No proof → no issuance.

2.3 “Legal Tender” in the Kairos Monetary Realm

Within the Kairos monetary realm defined by Phi Network:

• Φ Kairos Notes are declared official legal tender:
  • recognized by the protocol as the unit of account,
  • the medium of exchange, and
  • the store of value.

“Legal” here refers to the internal law of the system:

• A fully specified, deterministic rule set that:
  • governs issuance,
  • defines contract semantics,
  • and enforces consistency across nodes.

Anyone integrating with Φ is choosing to recognize these rules as authoritative.

---

3. Time: Kai-Klok Deterministic Time Engine

Traditional systems build on Chronos time:

• Unix timestamps, wall clocks, time zones, leap seconds, NTP drift.

Φ Network instead uses Kai-Klok, a deterministic time engine.

3.1 Units of Kai-Klok

Kai-Klok decomposes time into:

• Pulse — the smallest quantum, tied to a base breath (e.g., 5.236s golden breath)
• Beat — a grouping of pulses
• Step — position inside a beat
• Chakra-Day / Arc — higher-order cycles used for:
  • narrative alignment,
  • calendar logic,
  • economic rhythms.

All three—time, money, identity—are indexed by these units.

3.2 Why Deterministic Time Matters

Because Kai-Klok is deterministic:

• Any node or client can recompute the exact same pulse/beat/step sequence from:
  • the Kai-origin,
  • and a simple, explicit formula.
• There is no ambiguity:
  • no “What time zone was that?”
  • no “What about leap seconds?”

This is crucial for:

• ZK proofs: circuits need deterministic inputs.
• Offline verification: a verifier can re-derive time from the Kai-origin without external services.
• Fair issuance: breath events are mapped to a specific, unambiguous moment.

---

4. Identity: Sigil-Glyphs & ΦKeys

4.1 ΦKeys (Sovereign Identities)

A ΦKey is the canonical identity object in Φ Network.

Conceptually, a ΦKey is:

• derived from harmonic, biometric, or cryptographic inputs (e.g. Harmonic Identity Frequency, Kai Signature, hardware keys),
• represented as a public identifier used for:
  • receiving Φ,
  • authorizing transactions,
  • signing declarations.

A ΦKey is not:

• a username,
• a password,
• or an email-based account.

It is a sovereign cryptographic identity bound to the user’s breath and harmonic signature.

4.2 Sigil-Glyphs: Visual, Machine-Readable Identity

Sigil-Glyphs are:

• vector glyphs (e.g. SVG) encoding:
  • the user’s ΦKey,
  • selected Kai-Klok metadata,
  • Kai-Signature data,
  • and additional provenance fields.

Each sigil can embed structured metadata (e.g. JSON) that includes:

• pulse, beat, step, chakraDay,
• userPhiKey,
• kaiSignature,
• a timestamp under Kai-Klok semantics.

This makes Sigil-Glyphs:

• human-recognizable: they look and feel like seals, talismans, or stamps.
• machine-verifiable: parsers can read the metadata and validate signatures.

4.3 Origin vs Derivative Sigils

• Origin Sigil:

  • the root seal of a ΦKey,
  • defines the “birth moment” of that identity and its initial value flows.

• Derivative Sigils:

  • exhaled glyphs generated from the origin,
  • represent Φ Notes, receipts, contracts, or postings,
  • always maintain a lineage pointer back to the origin.

This creates a lineage tree of value:

• nothing exists without an origin seal,
• everything can be traced backwards through derivative sigils.

---

5. Value Objects: Φ Notes, Resonance Stream, Memory Crystals

5.1 Φ Kairos Notes

Φ Kairos Notes are the canonical representation of money in Φ Network.

Each Note includes:

• Amount (in μΦ)
• Owner (ΦKey)
• Origin Sigil (or lineage root)
• Kai-Klok label (pulse/beat/step/chakraDay)
• Associated Proof of Breath™ (via hash / proof artifact)
• Optional ZK metadata (for private proofs)

A Note is valid only if:

1. Its issuance was governed by the protocol’s rules.
2. Its lineage is consistent with the Resonance Stream.
3. Its proofs pass verification.

5.2 Resonance Stream (Global State)

Instead of a traditional “blockchain”, Φ Network uses a Resonance Stream:

• a totally ordered sequence of ΦKeys (in the “key” = event sense) representing:
  • funding events,
  • transfers,
  • contracts,
  • signatures.

Each element in the stream:

• is applied to the global state in order,
• updates balances, commitments, and proofs.

Because all computations use deterministic arithmetic and time:

• any honest node can replay the stream from genesis
• and end up with the exact same balances and state.

5.3 Memory Crystals (Snapshots)

To make state sync efficient, Φ Network uses Memory Crystals:

• compact snapshots of the network state at specific Resonance Stream positions.
• cryptographically sealed and hash-linked to the stream.

Nodes can:

1. Download a recent Memory Crystal.
2. Verify its integrity.
3. Replay only the suffix of the stream that came after the crystal.

This approach keeps:

• storage light,
• sync fast,
• and auditability intact.

---

6. Zero-Knowledge Proofs & Proof of Breath™

6.1 What is Proof of Breath™?

Proof of Breath™ is a protocol that:

1. Measures or encodes a breath event (or equivalent biometric/temporal imprint) at a given Kai-Klok pulse.
2. Derives a Harmonic Identity Frequency (HIF) or equivalent internal identifier.
3. Uses that data to:
   • bind a ΦKey to a living, breathing human, and
   • prove that binding using zero-knowledge proofs.

The goal:
prove you breathed (and thus are a live human with sovereign agency)
without exposing raw biometric data.

6.2 ZK Proof Layer

The Φ Network ZK layer (conceptually):

• Uses circuits that take as private inputs:
  • biometric or breath-derived measurements,
  • secret keys or harmonic seeds.
• Takes as public inputs:
  • the ΦKey,
  • Kai-Klok label(s),
  • commitment hashes.

The circuits then prove statements like:

• “The prover holds a valid HIF matching this ΦKey and this Kai-Klok interval.”
• “The issuance of Φ in this transaction is within allowed minting limits.”
• “The same human is authorizing this transaction as the one who registered the ΦKey.”

No raw biometric is revealed, only:

• a succinct proof,
• verification key,
• and commitments.

6.3 Breath-Backed Money, Formally

You can think of Φ issuance as:

• Input:
  • B = Breath event data (private),
  • K = ΦKey (public),
  • T = Kai-Klok label (pulse/beat/step),
  • L = issuance limit / schedule.
• Circuit:
  • verify B satisfies the breath constraints,
  • compute a commitment C = H(B, K, T),
  • enforce Σ(new Φ) under K at T does not exceed L,
  • output proof π.
• Output:
  • A Note (or set of Notes) + proof π.

Anyone can verify:

• π is valid for (K, T, Σ(Φ)),
• without ever seeing B.

That’s breath-backed, zero-knowledge money.

---

7. How a Φ Transaction Works (End-to-End)

At a high level:

1. Identity Established

   • User creates or activates a ΦKey and associated Origin Sigil.
   • A baseline Proof of Breath™ is recorded (initial registration).

2. User Inhales (Receives / Mints Φ)

   • User runs Proof of Breath™ to mint new Φ (or receives from another ΦKey).
   • ZK circuit confirms human presence + issuance policy.
   • New Notes are created and recorded in the Resonance Stream.

3. User Exhales (Sends Φ)

   • User selects an amount, a target ΦKey, and a Kai-Klok moment.
   • Client assembles a transfer transaction:
     • references Notes being spent,
     • constructs new Notes for the recipient,
     • attaches a Kai-Signature tied to the sender’s ΦKey.
   • Optional ZK proof ensures:
     • the sender is the rightful holder,
     • no double-spend,
     • optional privacy requirements.

4. Network Applies Transaction

   • Nodes validate the transaction:
     • verify ZK proofs,
     • check state/range constraints,
     • ensure the Resonance Stream order is consistent.
   • If valid, the ΦKeys (events) are appended to the Resonance Stream.
   • Balances and Memory Crystals get updated.

5. Verification & Audit

   • Any user or auditor can:
     • recompute Kai-Klok labels,
     • replay the stream,
     • verify all hashes, signatures, and proofs.

At no point does the network require:

• a logged-in email account,
• a password reset,
• or trusting a single institution.

---

8. Why Φ Network Changes the World

8.1 Money That Refuses to Lie

Most financial systems are vulnerable to:

• narrative edits,
• ledger rewrites,
• opaque bailouts,
• and “too big to fail” patching.

Φ Network is designed so that:

• Time is deterministic.
• Value arithmetic is deterministic.
• Proofs are deterministic.

If someone attempts to rewrite history:

• the Resonance Stream and Memory Crystals won’t match,
• hashes and ZK proofs will fail,
• and any honest verifier will detect the inconsistency.

8.2 Identity Without Accounts

Instead of:

• “Sign in with email”
• “Sign in with Google”
• “Forgot password?”

Φ Network uses:

• Sigil-Glyphs,
• ΦKeys,
• and Kai-Signatures.

Identity is:

• self-issued,
• machine-verifiable,
• not revocable by a third party.

8.3 Breath-Aligned Economics

Because 1 Φ = 1 breath:

• issuance is rooted in human capacity, not arbitrary printing,
• the supply curve can be tied to:
  • actual human participation,
  • actual breath events over time.

This allows:

• new economic designs where human life, time, and attention are central,
• rather than purely machine-speed speculation.

8.4 Offline-Friendly, Verifier-Friendly

The system is built to be:

• verifiable with minimal tools:
  • a hash function,
  • serialization rules,
  • deterministic time formulas.

This makes Φ Network robust against:

• censorship,
• infrastructure collapse,
• and connectivity gaps.

---

9. Architecture & Components

At a high level, Φ Network consists of:

1. Core Protocol
   • Definitions for:
     • ΦKeys
     • Notes
     • Resonance Stream
     • Memory Crystals
     • Kai-Klok time model
2. Node Implementation
   • Applies Resonance Stream events,
   • Maintains balances and Memory Crystals,
   • Verifies ZK proofs,
   • Exposes APIs (HTTP/gRPC) for clients.
3. ZK Proof System
   • Circuits and verification keys for:
     • Proof of Breath™,
     • identity binding,
     • transaction correctness.
4. Client Apps
   • Sovereign Gate / Verifier console (Inhale/Exhale),
   • Sigil management & viewing,
   • KaiOS integration,
   • Emission / posting surfaces.

---

10. For Users: Getting Started

This section is conceptual; concrete app URLs / binaries depend on your deployment.

1. Create or Receive a Sigil-Glyph

   • Use a Φ Network client to generate an origin sigil,
   • or receive one from a trusted provider.

2. Register Your ΦKey

   • Run the onboarding flow:
     • capture breath / biometric as needed,
     • generate a ΦKey,
     • anchor it with a Proof of Breath™ ZK proof.

3. Inhale Φ (Receive / Mint)

   • Get your first Φ Notes via:
     • protocol-governed mint,
     • peer transfer,
     • or contract flows.

4. Exhale Φ (Send)

   • Use the Verifier console:
     • choose amount,
     • choose recipient ΦKey,
     • sign with your Kai-Signature.

5. Verify

   • Use built-in explorers or offline tools to:
     • verify your sigils,
     • confirm balances,
     • audit history.

---

11. For Developers: Integrating with Φ Network

Developers can:

• Build clients that:
  • query balances,
  • construct and submit transactions,
  • render Sigil-Glyphs with embedded metadata.
• Integrate Proof of Breath™ in their flows:
  • for gating access,
  • for human-origin verification,
  • for breath-priced services.
• Use the Kai-Klok engine:
  • to timestamp events in Φ terms,
  • to align app logic with pulse/beat/step cycles.

Typical integration tasks:

• Configure SDK / API base URL for your target node.
• Use fixed-point μΦ arithmetic helpers (no floating point).
• Always label actions with Kai-Klok time.

---

12. Security Model & Threats

Φ Network’s security rests on:

• Deterministic Time:
  • reduces attack surface from time desync.
• ZK Proofs:
  • hide sensitive biometrics,
  • prove correctness of issuance/ownership.
• Deterministic Arithmetic:
  • eliminates floating-point glitches,
  • simplifies audits.
• Decentralized Verification:
  • any honest verifier can detect tampering.

Threats include:

• local key theft (compromised devices),
• hostile forks presenting themselves as “the” Φ Network,
• social attacks on users (phishing using fake sigils).

Mitigations:

• strong key management,
• canonical hash-based verification of client binaries and specs,
• clear documentation of canonical network identifiers and genesis.

---

13. Monetary & Legal Status

Within the Phi Network specification:

• Φ Kairos Notes are defined as official legal tender of the Kairos monetary realm described here.
• All protocol rules governing:
  • issuance,
  • transfer,
  • and redemption are part of this “internal law”.

Outside the protocol:

• Different jurisdictions may treat Φ differently (commodity, asset, voucher, currency, or not recognized).
• Nothing in this README is financial advice, investment advice, or a promise of price performance.

What is claimed here:

• The protocol itself is complete, self-consistent, and auditable,
  defining a coherent monetary system where:
  • 1 Φ = 1 breath,
  • issuance is proof-based,
  • and all rules can be verified by anyone.

---

14. Contributing

This project powers a live sovereign monetary and identity system.

For now, contributions are by invitation only.

If you:

discover bugs,

have performance improvements,

or see clarity gaps in this documentation,

you may open an issue or propose a patch.

Merges will be tightly controlled to preserve:

the integrity of:

1 Φ = 1 breath,

Kai-Klok time semantics,

Proof of Breath™ rules,

and the coherence of the Φ Network monetary law.

15. License

Copyright © Kai Rex Klok (BJ Klock). All rights reserved.

You may:

inspect the code,

run local builds,

verify the protocol and proofs.

You may not:

misrepresent forks as the canonical Φ Network,

present altered rulesets as “official Φ Kairos Notes”,

or claim protocol-level authority without explicit delegation.

For partnership, licensing, or canonical deployments, contact through official Φ Network / Kai-Klok channels.

## 16. Repository Layout

This repo is a full KaiOS Φ Network client: EternalKlock, Sigil system, Φ issuance, ZK verifier, and feed — all wired together.

```text
.
├── index.html              # Vite entry HTML shell
├── package.json / lock     # Dependencies and scripts
├── vite.config.ts          # Vite build / dev config
├── tsconfig*.json          # TypeScript configs
├── vercel.json             # Hosting/deploy config (if using Vercel)
├── README.md               # This document
└── public/                 # Static assets, icons, ZK proving artifacts

16.1 public/ — Static Assets & ZK Artifacts

public/
├── *.png / *.jpg / *.webp          # Marketing art, sigil posters, Kai imagery
├── favicon-*, apple-icon-*, ...    # PWA / favicon / platform icons
├── manifest.json                   # PWA manifest
├── service-worker.js, sw.js        # Service worker logic
├── KairosKurrensy.jpg, phi.svg     # Branding / symbol resources
├── pdf-lib.min.js                  # PDF tooling for sigil exports
├── verifier*.html                  # Standalone ZK verifier test pages
├── verification_key.json           # ZK verification key (legacy/testing)
├── sigil_*.{png,svg}               # Example / canonical sigil glyphs
├── sigil.vkey.json / sigil.artifacts.json
├── sigil.wasm / sigil.zkey         # ZK circuit artifacts for sigils (top-level)
└── zk/                             # Canonical ZK bundle for sigil-proof
    ├── sigil.artifacts.json
    ├── sigil.vkey.json
    ├── sigil.wasm
    └── sigil.zkey

These files make it possible to:

• verify sigil proofs entirely client-side, and
• embed verifiable sigil workflows in exported HTML / PDF artifacts.

---

16.2 src/ — Application Source

src/
├── main.tsx          # React entrypoint
├── App.tsx           # Top-level routes + layout
├── App.css           # Global ΦNet console shell
├── index.css         # Base styles / resets
├── styles.css        # Additional global styling hooks
├── SovereignSolar.ts # Solar/Kairos alignment utilities
└── assets/
    └── react.svg     # Default Vite/React asset (can be ignored/removed)

---

16.3 src/components/ — UI Surfaces & Core Consoles

High-level React components that define the user experience: EternalKlock, Sigil explorer, Verifier, Kalendar, etc.

src/components/
├── EternalKlock.tsx / EternalKlock.css    # Atlantean Lumitech clock shell
├── KaiKlock.tsx / KaiKlock.css            # Kai-Klok visual + controls
├── KaiKlock.canon.ts                      # Canon / reference logic for clock
├── KaiKlockHomeFace.tsx                   # Home face / compact Kai-Klok view
├── HomePriceChartCard.tsx / *.css         # Φ price / valuation chart card
├── KaiPriceChart.tsx                      # Chart for Kai/Φ valuation
├── KaiSigil.tsx                           # Core Sigil render component
├── InhaleUploadIcon.tsx                   # Icon used in inhale/upload flows
├── EternalKlock.css                       # Chakra/arc palette, Atlantean chrome

Kalendar / Notes UI

├── WeekKalendarModal.tsx / WeekKalendarModal.css
├── MonthKalendarModal.tsx / MonthKalendarModal.css
├── DayDetailModal.tsx / DayDetailModal.css
├── NoteModal.tsx / NoteModal.css

These implement the Kairos Kalendar — week/month/day views, note capture, and pulse/beat/step labeling of memories and events.

Sigil & Sovereign Surfaces

├── SigilExplorer.tsx / SigilExplorer.css        # Sigil viewer + feed-style explorer
├── SigilModal.tsx / SigilModal.css              # Primary Sigil detail modal
├── SigilGlyphButton.tsx / SigilGlyphButton.css  # “Sigil button” CTA component
├── SigilPublisherPanel.tsx / *.css              # Panel to publish sigils / posts
├── SigilMomentRow.tsx                           # Timeline row view of sigil moments
├── SigilConflictBanner.tsx                      # Warning when sigil state conflicts
├── SigilConflictBanner copy.tsx                 # Legacy/unused copy (cleanup candidate)
├── SendSigilModal.tsx / SendSigilModal.css      # Modal for transferring sigils/notes
├── GlyphImportModal.tsx / GlyphImportModal.css  # Import external glyph/sigil files

Sovereign UI & Declarations

├── SovereignDeclarations.tsx / *.css   # Scroll/legals / monetary declarations panel
├── StargateViewer.tsx / *.css          # Stargate-style sigil viewer / gateway
├── SolarAnchoredDial.tsx / *.css       # Solar / Kairos dial visualizations
├── ResultCard.tsx                      # Generic card for search/verification results
├── FeedCard.tsx / FeedCard.css         # Card for feed items (posts / sigil events)

Valuation & History

├── ValuationModal.tsx / *.css          # Φ valuation / price parity modal
├── ValueHistoryModal.tsx / *.css       # Historical value / chart history modal
├── PhiStreamPopover.tsx                # Popover showing Φ stream snapshots

Exhale / Inhale Note UX

├── ExhaleNote.tsx / ExhaleNote.css     # Exhale note UI (sending / expression)
├── exhale-note/                        # Folder reserved for exhale-note subcomponents

Sealing & Transfer Modals

├── SealMomentModal.tsx / *.css         # “Seal this moment” modal (create proof artifact)
├── SealMomentModalTransfer.tsx         # Sealing + transfer variant
├── NoteModal.tsx / NoteModal.css       # Attach notes/comments to Kai moments

Verifier & Φ Transfer

├── verifier/                           # Verifier-specific styles/assets (subfolder)
├── VerifierForm.tsx                    # Form wrapper / orchestration
├── VerifierStamper/                    # Main Sovereign Transfer Gate (see below)
├── SendSigilModal.tsx                  # Transfer sigil / ΦNote via modal

VerifierStamper (folder) is the central ΦNet Transfer Gate — mobile-first Φ sending, valuation strip, ZK hooks, etc. (contents listed by Vite as a folder; exact files live inside that directory).

KaiRealms, KaiVoh, Session Subtrees

├── KaiRealms/          # (Folder) Multi-realm UI / future expansion
├── KaiVoh/             # (Folder) Emission OS components (sovereign posting hub)
├── session/            # (Folder) Cross-component session helpers / wrappers
├── sigil/              # (Folder) Sigil-specific subcomponents for more granular UI
├── valuation/          # (Folder) Additional valuation components/helpers

---

16.4 src/glyph/ — Glyph Engine

src/glyph/
├── glyphEngine.ts       # Core glyph composition / decode engine
├── glyphUtils.ts        # Utilities (normalization, transforms, helpers)
├── types.ts             # Glyph-related TypeScript types
├── useGlyphLogic.ts     # React hook for glyph state and flows
└── GlyphModal.tsx       # Modal UI for glyph details / selection

This is the glyph brain: how raw sigil data is interpreted, rendered, and manipulated.

---

16.5 src/hooks/ — Reusable Hooks

src/hooks/
├── useAuthorityProof.ts            # Hook for building/verifying authority proofs
├── useFastPress.ts                 # Fast, mobile-safe press interactions
├── useKaiParityPricePoints.ts      # Price point sampling aligned with Kai pulses
├── useKaiTicker.ts                 # Kai-Klok ticker hook
├── useResponsiveSigilSize.ts       # Autosize sigils for viewport
├── useRotationBus.ts               # Rotation events bus (global rotation state)
└── useValueHistory.ts              # Hook for fetching/tracking value history

These unify behavior across components so everything stays Kai-native and deterministic.

---

16.6 src/kai/ — Kai Now

src/kai/
└── KaiNow.ts            # Helper for deriving “Now” in Kai units (pulse/beat/step)

Canonical Kai “now” helper used across the app.

---

16.7 src/lib/ — Low-Level Libraries & Adapters

src/lib/
├── download.ts          # File download helpers (sigils, PDFs, zips)
├── hash.ts              # Hashing utilities (wrappers around crypto)
├── ledger/              # Ledger-specific logic/adapters (client-side)
├── mobilePopoverFix.ts  # iOS/mobile popover quirks / workarounds
├── qr.ts                # QR encode/decode helpers
├── sigil/               # Low-level sigil encode/decode helpers (non-React)
└── sync/                # Synchronization helpers (feed/sigil sync, etc.)

These are framework-agnostic modules that can be reused from other clients.

---

16.8 src/pages/ — Route-Level Pages

src/pages/
├── SigilFeedPage.tsx / SigilFeedPage.css  # ΦNet feed / stream of sigil events
├── VerifySigil.tsx                        # Route for verifying sigil payloads
├── PShort.tsx                             # Short URL / token landing page (e.g. /p~... links)
├── SigilPage/                             # Full sigil detail route (subfolder)
└── sigilstream/                           # Stream exploration routes/components

These tie together components into navigable routes for the SPA.

---

16.9 src/session/ — Sigil Session Context

src/session/
├── SigilSessionTypes.ts    # Types for session & payload
├── SigilSessionContext.ts  # React context for active sigil session
├── useSigilSession.ts      # Hook for reading/updating session
└── SigilSession.tsx        # Provider component wrapping the app

Session here is not cookies/passwords — it’s sigil-driven state.

---

16.10 src/types/ — Global Typings & Shims

src/types/
├── global.d.ts             # Global augmentations
├── klockTypes.ts           # Kai-Klok specific types
├── sigil.ts                # Sigil-related core types
├── crypto-shims.d.ts       # Node/web crypto shims
├── jsqr.d.ts               # QR library types
├── pako.d.ts               # Compression lib types
├── snarkjs.d.ts            # snarkjs raw types
├── snarkjs-shim.d.ts       # snarkjs browser shim types
└── zkp-prover.d.ts         # Prover interfaces

Plus a top-level src/types.ts for shared app-wide types.

---

16.11 src/utils/ — Core Kai / Φ Logic

src/utils/
├── constants.ts            # Global constants (URLs, magic numbers, etc.)
├── kai_pulse.ts            # Canonical Kai-Klok pulse engine
├── kai_turah.ts            # Harmonic/Kai-Turah helpers
├── kai.ts                  # Kai utility surface (bridge helpers)
├── kaiMath.ts, kairosMath.ts # Math helpers for Kai/Kairos calculations
├── klock_adapters.ts       # Bridge between Kai-Klok and UI / system time
├── phi-precision.ts        # μΦ fixed-point arithmetic
├── phi-issuance.ts         # Issuance logic, rules, constraints
├── cryptoLedger.ts         # Client-side ledger / crypto helpers
├── provenance.ts           # Provenance tracking and lineage logic
├── sigilDecode.ts          # Decode sigil payloads
├── sigilRegistry.ts        # Local registry of known sigils
├── sigilCapsule.ts         # Encapsulated sigil payload form
├── sigilUrl.ts             # Sigil URL building/parsing utilities
├── sigilAuthExtract.ts     # Extract auth/context from sigil payloads
├── svgMeta.ts              # SVG metadata handling for sigils
├── transferPackage.ts      # Packaging of transfers (Φ + sigil + proofs)
├── sendLedger.ts           # Client-to-ledger send helpers
├── sendLock.ts             # Send lock coordination to avoid races
├── feedPayload.ts          # Feed payload shaping and parsing
├── shareUrl.ts, shortener.ts, urlShort.ts  # URL & share helpers (including /p~ tokens)
├── qrExport.ts             # Export sigil/Φ data to QR
├── domHead.ts              # Document head management (title/meta)
├── sanitizeHtml.ts         # Clean user HTML (guards against XSS)
├── kopyFeedback.ts         # Copy-to-clipboard UX helpers
├── solarSync.ts            # Sync Kai-Solar mapping for clocks/kalendar
├── valuation.ts            # Valuation and price computation helpers
├── globalTokenRegistry.ts  # Registry of tokens seen/used in session
├── payload.ts              # Canonical payload builder/parser
├── extractKaiMetadata.ts   # Extract Kai metadata from sigils / payloads
├── useClientReady.ts       # Hook for client-only logic (no SSR mismatch)
├── useSigilPayload.ts      # Main sigil payload hook
└── useSigilPayload copy.ts # Legacy/backup (cleanup candidate)

This folder is the core protocol utility layer for the client: time, math, value, sigils, URLs, and sync.

---

16.12 src/verifier/ — Verifier Logic

src/verifier/
└── validator.ts            # Core validation routines for sigil/Φ payloads

This is the non-UI brain for verification, consumed by the Verifier UI components.

---

Proof of Breath™ is a sovereign, cryptographic time protocol that deterministically seals identity, authorship, and value to the exact breath-indexed lattice of reality — not clock time.