Skip to content
View Phinetwork's full-sized avatar

Block or report Phinetwork

Block user

Prevent this user from interacting with your repositories and sending you notifications. Learn more about blocking users.

You must be logged in to block users.

Maximum 250 characters. Please don't include any personal information such as legal names or email addresses. Markdown supported. This note will be visible to only you.
Report abuse

Contact GitHub support about this user’s behavior. Learn more about reporting abuse.

Report abuse
PHINetwork/README.md

Φ 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:
    • pulsebeatstepchakraDay
  • 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.

  1. 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.

  1. 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.

Pinned Loading

  1. PHI_NETWORK PHI_NETWORK Public

    Forked from kojibai/PHI_NETWORK

    The official ΦNet Sovereign Gate — the verification, identity, and value terminal running on phi.network

    TypeScript 1