ChronoSeal Architecture

ChronoSeal is a Unix-native browser attestation daemon. It validates session continuity by combining cryptographic signatures, hash-chain progression, deterministic VM execution, and a shared Synthetic Gene Mutation Engine.

System Diagram

The following diagram shows the relationship between browser clients, the daemon process, and the shared protocol library:

Workspace Components

The codebase is structured as a Rust workspace containing three runtime crates and static frontend assets:

1. shared/ Crate

The determinism boundary of ChronoSeal. Any execution logic that must agree precisely between the browser WASM runtime and server verification belongs here. Its responsibilities include:

  • Wire protocol struct formats for request and response models.
  • Blake3 hash-chain progression functions.
  • Synthetic gene model definitions and commitments.
  • Mutation program bytecode generator, interpreter, and execution tracer.

2. server/ Crate

Compiles into the chronoseal daemon binary. It manages the server runtime, HTTP API routes, database backends, and verification logic. Key responsibilities:

  • CLI command parsing and flag defaults.
  • Axum-based web router and health endpoints.
  • Verification pipeline (signature verification, timestamp drift checks, rate limit validations).
  • Pluggable storage adapters (SQLite memory/disk, Valkey).
  • Background cleanup loop for session purges.

3. wasm/ Crate

Compiles into the browser WebAssembly package (using wasm-pack) used by the frontend. Its key functions include:

  • Secure client-side Ed25519 keypair generation and verification.
  • Message signing for canonical heartbeat payloads.
  • Client-side VM program execution and stack history logging.
  • Previewing, committing, and discarding synthetic gene mutations.

4. frontend/ Directory

Contains static JavaScript (heartbeat.js, app.js) and assets served to browsers to orchestrate background attestation calls without blocking UI rendering.

Session State Model

The daemon stores a single SessionRecord in the active database per session, structured as follows:

Field Core Description
session_id Random 32-byte session lookup key.
public_key Registered Ed25519 public key. Used to verify all heartbeats.
salt Current server salt required to verify the next heartbeat.
last_hash Current accepted Blake3 hash head. Prevents out-of-order repeats.
gene Committed synthetic gene byte buffer.
pending_mutation The mutation program compiled by the server for the next heartbeat step.
pending_mutation_step Mismatches between this and request steps cause silent rejection.
⚠️
State Invariant: The server-side session state advances ONLY after a heartbeat passes all pipeline validations. Failed heartbeats never alter the stored salt, hash, or gene parameters, preventing desynchronization exploits.

Verification Pipeline

Heartbeat verification follows a strict chronological order. If any check fails, execution immediately halts, returning the silent rejection response. The pipeline is:

  1. Load the session record using the submitted session_id.
  2. Assert that the session exists and has not expired (now < expires_at).
  3. Verify the Ed25519 signature against the reconstructed canonical JSON payload.
  4. Assert the request's prev_hash matches the server-stored last_hash.
  5. Compare request step with pending_mutation_step.
  6. Apply the stored pending_mutation to a cloned gene buffer.
  7. Assert the computed gene commitment matches the request's gene_commitment.
  8. Assert that the timestamp drift matches liveness bounds (within 30 seconds).
  9. Assert that mouse activity entropy is present and speed falls within thresholds.
  10. Assert screen aspect ratio, device pixel ratio, and concurrency parameters match bounds.
  11. Advance the session's hash head, rotate the salt, compile the next mutation program, and persist.
Last Updated: June 2026 (v1.0.2)
/
▲