MortalOS: Evidence That Software Can Die

Try the 90-second proof

• English: https://mortal-os.com/
• 한국어: https://mortal-os.com/ko/
• No account, API key, model call, or local build is required.

Open the site in Browser A and choose Create in Browser A. Open the generated private link or QR in a clean Browser B. Authorize the handoff in both browsers, close A, then choose Continue in Browser B. The same organism_id advances from sequence 1 to sequence 2 even though neither private key ever moved.

Inspiration

Long-running software can outlive tabs, devices, keys, and operators. Persistence alone cannot answer the harder question: is a successor still the same digital entity, was continuation authorized, and what evidence would justify saying that it died?

MortalOS turns those questions into a falsifiable protocol and a live browser proof.

What it does

MortalOS creates one state-bearing digital organism whose custody can move from Browser A to Browser B.

Each browser generates its own non-extractable key. A and B authorize one canonical custody handoff. A can then disappear while B continues the same identity and advances its state. If A disappears before the handoff is complete, the organism stalls instead of silently inventing authority.

The advanced evidence workbench also demonstrates:

• replay and resurrection rejection;
• signed fork and equivocation detection;
• every complementary two-of-three endpoint loss and deterministic repair;
• canonical evidence export and replay; and
• JavaScript/Python byte-identical state and R1 operation records.

The authority boundary

The UI, browser storage, relay, Cloudflare, event order, and GPT never decide validity. They may store, transport, display, or challenge evidence.

The deterministic kernel alone validates canonical bytes, signatures, recognized lineage, custody, state transitions, forks, mortality completeness, and resource ceilings. Importing evidence grants observation, not signing authority. Private keys never leave their browser profiles.

This produces four honest evidence layers:

• L1 — deterministic protocol: canonical bytes and local verdicts;
• L2 — isolated browser continuity: A creates, B joins, A closes, B continues;
• L3 — hosted relay and failure tests: relay availability without relay authority;
• L4 — independent physical or administrative domains: future work, not claimed here.

Why GPT-5.6 is optional

The main proof makes zero model calls. Production GPT scenarios are intentionally disabled for cost safety and require no OpenAI or Turnstile secret.

GPT-5.6 was used as a bounded adversarial witness in a 25-case evaluation and remains available as an advanced development path. It can propose an attack and predict an outcome, but it cannot provide a key, signature, accepted context, recognized head, or verdict. In the fixed evaluation, schema and mutation selection succeeded 25/25 while exact status/rejection-code prediction matched the deterministic kernel 0/25. That contrast is the lesson: a strong model can help attack consensus logic, but it must not become consensus.

How we built it

The portable JavaScript core uses duplicate-aware UTF-8/I-JSON parsing, RFC 8785 canonicalization, SHA-256 domain separation, and strict RFC 8032 Ed25519 verification. R1 defines canonical operation/result bytes shared with Python. A deterministic state engine binds transitions to identity and lineage.

The browser participant uses non-extractable Web Crypto keys and consent-gated storage. A Cloudflare Durable Object relay stores and forwards public canonical messages, applies one shared rate policy, expires idle rooms, and never emits a validity verdict.

The release pipeline is fail-closed: immutable independent review, exact-head Policy and Verify, expected-head merge, exact-main source verification, relay migration, Pages upload, per-file digest/MIME/security-header checks, and live English/Korean multi-browser acceptance.

Validation

• 20/20 persistent two-profile A→B handoffs with A's browser process closed each time;
• B-only continuation of the same identity from sequence 1 to 2;
• 38–39 relay operations in a measured 12-second two-browser window with zero local 429 responses;
• exact 300th-request acceptance and canonical 301st-request 429 boundary;
• every complementary two-of-three endpoint loss and repair;
• 10,000 fixed property cases and 10,000 serialized adversarial rejections;
• actual Chromium parity with the committed portable corpus;
• JavaScript/Python byte equality for state and R1 records;
• core coverage 94.70% line, 92.31% branch, 95.22% function;
• dependency audit with zero vulnerabilities;
• English and Korean public paths; and
• exact-main Verify and Deploy PASS at 03fc3ab07ea086642027deebe282a90d804c4991.

How Codex and GPT-5.6 were used

Codex helped turn the original “software can live and die” idea into explicit protocol invariants, implement the kernel and browser experience, red-team false-death and rate-limit cases, automate two-profile Chromium acceptance, and build immutable review and exact-source deployment evidence.

GPT-5.6 helped generate bounded adversarial mutations and expose why fluent model output is unsafe as a validity oracle. The human retained the North Star, threat assumptions, honest non-claims, cost boundary, and final release decisions.

Challenges and lessons

The hardest problem was preventing false certainty. A closed browser is not global death. Three logical keys in one process are not three physical failure domains. A relay sequence is not consensus. A model explanation is not proof.

The release pipeline caught those mistakes in practice: browser installation order, source-versus-public environment leakage, insufficient Cloudflare token scope, a Workers-only Pages config key, and Cloudflare's canonical localized-index redirect all failed closed before final acceptance.

Honest scope and next step

MortalOS is not yet an ownerless operating system, a globally decentralized network, or proof of physical erasure. It is a small, reproducible lifecycle and state kernel with a real cross-browser custody transfer.

Next: run the same protocol across independently operated native endpoints and administrative domains, without changing who decides validity.

Built With

• cloudflare-pages
• cloudflare-pages-functions
• codex
• gpt-5.6
• javascript
• node.js
• openai-responses-api
• playwright
• python
• webcrypto