A cryptographic protocol for structural trust between independent deterministic cores.
Two parties. One commitment. Identical evaluation.
Timestamped, non-repudiable proof — without revealing content to the certifying authority.
These five commitments are the cryptographic foundation of the MCR protocol. Every design decision — from hash algorithm choice to relay storage limits — follows from holding all five simultaneously.
Keys are generated in the browser. Never transmitted in plaintext. Never extractable. The user owns their identity. No external authority issues credentials. ECDSA P-256 — native to Web Crypto, zero library imports. SRC: SPEC-MCR §1.4
SHA-256 over deterministic CBOR. Same inputs → same hash on every browser, every platform, every time. The commitment hash is the cryptographic anchor that cannot drift. Sorted keys, no whitespace, UTF-8. SRC: SPEC-MCR §1.3
The Foundry Relay verifies signatures and mints receipts. It never sees the payload. It cannot read what was signed. ≤250 bytes stored per receipt. Zero payload storage. The relay is a witness, not a custodian. SRC: SPEC-MCR §2
The deterministic auditor runs before any network call. HALT is emitted locally. The relay is never contacted for a divergent commitment. The divergence is caught at the source — not by the notary. SRC: SPEC-MCR §3.3
Once both signatures converge on identical commitment hashes, the receipt is permanent. The receipt ID is a public verification key. Anyone with the ID can verify convergence. No party identities beyond pubkey hashes. No payload content. SRC: SPEC-MCR §1.5
The MCR protocol certifies that two or more parties, each operating an independent deterministic core, have independently evaluated an identical commitment hash and have cryptographically attested to that evaluation. The protocol produces a timestamped, non-repudiable receipt without revealing the content of the commitment to the certifying authority.
This is not an approval workflow. It is not a digital signature wrapper. It is a structural trust protocol — the cryptographic mechanism that proves two independent parties converged on identical terms without either party needing to trust the other, the relay, or any third party.
MCR is Layer 3 of the Continuity Architecture — the protocol layer that sits between the Deterministic Core (Layer 1) and the Standard Body (Layer 4). It is the adoption mechanism. Companies don't rebuild their infrastructure to adopt the Continuity Architecture. They deploy an MCR Foundry Relay — a single Cloudflare Worker, minutes to deploy, $0/month — and open a single HTML artifact. The architecture augments existing systems with cryptographic proof that decisions were made correctly, identically, and auditably.
The cryptographic specification. Actors, commitment hash computation, signature scheme, receipt format. Every implementation must conform to this section exactly.
| Actor | Role | Key Operations |
|---|---|---|
| Party A (Initiator) | Computes commitment hash from local data. Signs it. Transmits to Party B and Relay. | CBOR encode · SHA-256 hash · ECDSA sign · ECDH encrypt for Party B |
| Party B (Responder) | Receives commitment hash. Computes local hash. Verifies identity. Signs if identical. Transmits to Relay. | ECDH decrypt · CBOR encode · SHA-256 hash · Auditor evaluation · ECDSA sign |
| Foundry Relay | Blind notary. Receives signatures and hashes. Verifies cryptography. Mints receipt. Stores ≤250 bytes. Forgets payload. | ECDSA verify · Convergence detection · Receipt minting · Ed25519 receipt signing |
| Local BAR-OS Core | Computes hash, manages keys, evaluates SIC, emits COMMIT or HALT. Runs before any network call. | Deterministic CBOR · SHA-256 hash · SIC evaluation · Auditor verdict |
The commitment hash is computed locally by every party before any network transmission. It is the invariant that both parties must produce identically for convergence to occur.
Algorithm: SHA-256 (Web Crypto API: SubtleCrypto.digest)
Canonicalization: Deterministic CBOR encoding (sorted keys, no whitespace, UTF-8). CBOR is chosen over JSON for its byte-level determinism — JSON serialization varies across JavaScript engines for key ordering, number formatting, and whitespace. CBOR eliminates these ambiguities.
Critical Invariant: The Foundry Relay never sees payload_hash decrypted. It sees only the commitmentHash and the signatures that cover it. The payload content is encrypted (ECDH + AES-GCM) before transmission and only decryptable by the counterparty.
Why CBOR not JSON: JSON.stringify does not guarantee deterministic key ordering across JavaScript engines. Object.keys().sort() is not a stable canonicalization — Unicode sort order varies. CBOR encoding with UTF-8 byte-level key sorting and no whitespace produces identical bytes on every platform, making the hash truly deterministic.
| Property | Specification | Rationale |
|---|---|---|
| Algorithm | ECDSA over P-256 (Web Crypto API native) | Native to every browser. No library imports. Sovereign key generation. |
| Key Format (Export) | SPKI for public keys; PKCS#8 for private keys | Standard interoperable formats |
| Key Format (Storage) | JWK for IndexedDB persistence | JSON-serializable, IndexedDB-compatible |
| Key Extractability | Non-extractable (extractable: false) | Private key never leaves the browser. Sovereign identity. |
| Signature Input | The raw 32-byte SHA-256 commitment hash | Fixed-size input. No canonicalization ambiguity. |
| Output Encoding | Base64URL | URL-safe, JSON-compatible, compact |
Storage budget: ≤500 bytes per receipt (v1.0-RC1, JSON + CBOR). Target: ≤250 bytes (v1.1 with raw-byte field optimization).Retention policy: Permanent for receipt metadata. Zero payload storage — the relay never had the payload and never will.
v1.0 uses HMAC-SHA256 for the relay signature — the relay signs receipts with a secret key. This means only the relay can verify its own signatures. v1.1 migrates to Ed25519 with a published relay public key, enabling any third party to independently verify receipt authenticity. The relay public key is published at /.well-known/mcr-relay.pub.
Receipt bytes are CBOR-encoded sans relay_sig. The relay signs those bytes with Ed25519. The resulting signature is appended as relay_sig. A verifier: (1) fetches the receipt, (2) strips relay_sig, (3) CBOR-encodes the remainder, (4) verifies the Ed25519 signature against the published relay public key. Zero trust in the relay required.
Depends on: Ed25519 keypair persisted in Durable Object · /.well-known/mcr-relay.pub endpoint · CBOR round-trip verified
The blind notary. Deployment target, endpoints, request/response contracts, relay logic, and code structure. The relay is the only infrastructure component in the MCR protocol.
Primary: Cloudflare Worker + Durable Object (free tier: 100k requests/day). The Durable Object provides strong consistency for convergence detection — two signatures arriving simultaneously cannot produce a race condition.
Fallback: Deno Deploy or Node.js on a $5 VPS. Reason: Edge-deployed, zero cold-start, no server maintenance. The entire relay is a single JavaScript file.
| Endpoint | Method | Purpose | Success Response | Error Responses |
|---|---|---|---|---|
/mint |
POST | Submit a signature for a commitment. Second party completes convergence. | 201 CONVERGED — receipt object 202 ACCEPTED — pending counterpart |
400 INVALID_SIGNATURE · 400 MISSING_FIELDS · 409 DIVERGENT_COMMITMENT (HALTED) · 429 RATE_LIMITED |
/verify?id=LM-... |
GET | Public verification of a receipt. Anyone with the receipt ID can verify convergence. | 200 — receipt object (JSON or CBOR) | 404 NOT_FOUND |
/wake |
POST | Notify an offline party that a commitment awaits their signature. | 202 WAKE_QUEUED | 400 MISSING_FIELDS |
/.well-known/mcr-relay.pub |
GET | Publish the relay's Ed25519 public key for third-party receipt verification (v1.1). | 200 — {"public_key":"...", "algorithm":"Ed25519"} |
— |
/krl |
GET | Key Revocation List — pubkey hashes that are no longer valid. | 200 — {"revoked_hashes":[...], "updated_at":...} |
— |
/mint HandlerThe relay performs these steps in order. No step can be skipped. No step depends on external state outside the Durable Object.
| Step | Operation | Failure Mode |
|---|---|---|
| 1. Parse | Parse JSON body. Validate required fields: commitment_hash, party_id, pubkey, signature, action_nonce, idempotency_key, participants, threshold. | 400 MISSING_FIELDS |
| 2. Verify Signature | Import ECDSA P-256 public key from SPKI. Verify signature over commitment hash bytes. | 400 INVALID_SIGNATURE · 400 INVALID_PUBKEY |
| 3. Derive Identity | Compute pubkey_hash = first 8 bytes of SHA-256(pubkey SPKI). | — |
| 4. Check Idempotency | If idempotency key was processed within IDEMPOTENCY_TTL_MS, return cached response. | — |
| 5. Journal Entry | Store {commitment_hash, pubkey_hash, received_at} in Durable Object under PENDING:nonce:pubkey_hash. | 409 PARTY_ALREADY_COMMITTED_DIFFERENT_HASH (if existing entry has different hash) |
| 6. Divergence Guard | For all participants, check if any OTHER participant has already signed with a different commitment hash. If yes → HALT. | 409 DIVERGENT_COMMITMENT (HALTED) |
| 7. Threshold Check | Count how many participants have signed with matching commitment hash. If count ≥ threshold → CONVERGE. | 202 ACCEPTED (if below threshold) |
| 8. Mint Receipt | Atomic counter increment. Generate receipt ID. Build receipt object. CBOR-encode sans relay_sig. Sign with Ed25519. Append relay_sig. Size-check (≤500 bytes). Store in KV. Return 201. | 500 RECEIPT_OVERSIZED |
The Durable Object (MintConverger) provides strong consistency for the convergence detection window. Two signatures arriving within milliseconds of each other cannot produce a race condition where both see "one signature, pending" and neither triggers convergence. The Durable Object serializes access — the second signature always sees the first.
Without the Durable Object: Two simultaneous POSTs to KV could both read "1 signature" and both return 202, requiring a polling loop or out-of-band convergence. The Durable Object eliminates this race condition at the architectural level.
Anyone with a receipt ID can verify that convergence occurred. The response includes: receipt ID, status, timestamp, commitment hash (one-way hash — original content unrecoverable), and pubkey hashes of participants. No party identities beyond pubkey hashes. No payload content. The relay never had the payload. The relay cannot decrypt the payload. The privacy guarantee is structural, not contractual.
The Foundry Relay is implemented as a Cloudflare Worker + Durable Object in v1.0-RC1. The implementation includes: ECDSA signature verification in the Worker edge layer, idempotency key deduplication, Durable Object convergence detection with race-condition elimination, Ed25519 receipt signing, CBOR + JSON dual storage, KRL endpoint, wake endpoint with HMAC-blinded hints, and automated alarm-based cleanup of stale pending entries. The specification sections above reflect the implemented logic — not aspirational design.
The client-side module that lives inside BAR-OS. Key generation, commitment computation, payload encryption, relay communication, and the deterministic auditor that runs before any network call.
mcr-client.jsThis module lives inside BAR-OS. It has no external dependencies except fetch. Every cryptographic operation uses the Web Crypto API — zero library imports.
When the client is offline, signatures are queued in an IndexedDB outbox. A Service Worker listens for sync events and drains the outbox when connectivity returns. The outbox schema: {action_nonce, url, method, headers, body, attempts, next_retry, created_at}. Exponential backoff with 5-second base delay. Maximum 3 retries before surfacing to user.
This means the MCR protocol works across connectivity gaps. A founder can seal a commitment on a plane. The signature queues locally. When they land, the Service Worker drains the outbox. The counterparty receives it. Convergence occurs. The protocol is not gated on real-time connectivity.
The MCR panel in BAR-OS renders exactly three states. No loading spinners. No indeterminate progress. The state is always one of these three.
Meaning: The deterministic auditor detected a violation before any network call. The commitment hash did not match. A SIC constraint was violated. A key was revoked. No receipt will be minted.
User sees: Red banner. Reason code (e.g., COMMITMENT_HASH_MISMATCH, SIC_VIOLATION, KEY_LOCKED). Option to view details. No network request was made.
Meaning: Party A's signature has been submitted. The relay accepted it. Waiting for Party B to evaluate the identical commitment and submit their signature.
User sees: Yellow banner. Truncated commitment hash. Copy invite link button. Status: "Awaiting Bob..."
Meaning: Both parties signed the identical commitment. The relay verified both signatures. A receipt was minted. The proof is permanent.
User sees: Green banner. Receipt ID (e.g., LM-20260620-001-a1b2c3d4). Timestamp. Download receipt button. View on Foundry link. Both pubkey hashes visible.
Before the MCR client ever calls fetch, the local deterministic auditor runs. If the verdict is anything other than COMMIT, the network call is structurally blocked.
The auditor runs eight checks in order. The first failure emits HALT and stops the chain. No partial evaluation. No network call preceded by a failed check.
| Check | Condition | HALT Code |
|---|---|---|
| Protocol Version | preimage.protocol_version must equal 1 | UNSUPPORTED_PROTOCOL_VERSION |
| Timestamp Freshness | abs(now - preimage.timestamp_unix) ≤ 300 seconds (5 min) | STALE_COMMITMENT |
| Participant Sort Order | participants array must be sorted by pubkey_hash (ascending, UTF-8 byte order) | UNSORTED_PARTICIPANTS |
| Revocation Check | No participant's pubkey_hash appears in the KRL revoked_hashes list | REVOKED_KEY |
| Counterpart Identity | Every participant's pubkey_hash must match a known identity in the local identity store | UNKNOWN_COUNTERPART |
| Key Expiry | No participant's identity has expired_at in the past or revoked_at set | EXPIRED_KEY / REVOKED_KEY |
| Local Payload Hash | Compute SHA-256 of local payload. Must match preimage.payload_hash. | PAYLOAD_HASH_MISMATCH |
| Commitment Hash Match | CBOR-encode local preimage with local payload_hash. SHA-256. Must match expected commitment hash. | COMMITMENT_HASH_MISMATCH |
If verdict !== 'COMMIT', the MCR client does not POST to the relay. The handoff is structurally blocked. The HALT is emitted locally. No network request is made. The divergence is caught at the source — not by the notary. This is the architectural guarantee that distinguishes MCR from approval workflows: the gate is enforced before any external system is contacted.
How the components compose into a complete cryptographic trust system. From sovereign key generation to receipt verification.
The MCR protocol is domain-agnostic. Vertical SIC (Shared Intent Contract) templates encode domain-specific governance rules that the deterministic auditor enforces structurally.
Every SIC is a JSON document that encodes: required signatories, exact-match fields, bounded value ranges, halt conditions, and the governance standard version it enforces. The SIC is loaded into BAR-OS. The MCR auditor evaluates every commitment against the active SIC before allowing a signature to be queued.
| Field | Purpose | Example |
|---|---|---|
| schema | Identifies the SIC type and version | "sic.medical.v1" |
| tier | Evaluation strictness: 1 = exact match, 2 = bounded, 3 = threshold | 1 |
| required_principals | Who must sign before convergence | ["attending_surgeon", "ai_proposal"] |
| exact_match_fields | Fields that must match byte-for-byte | ["dosage_mg", "medication_id", "patient_id"] |
| bounds | Allowed value ranges for named fields | {"dosage_mg": {"whitelist": [50, 75, 100]}} |
| halt_on | Conditions that trigger HALT before network call | ["hash_mismatch", "principal_missing", "bounds_violation"] |
How it works: A surgical robot proposes an action. The local BAR-OS core encodes the proposal as a CBOR preimage. The auditor checks: are both the attending surgeon and the AI proposal present as principals? Does the dosage match the whitelist exactly? Does the medication ID match? Does the patient ID match? If any check fails → HALT. No network call. No physical action. No harm.
The credibility artifact. Not a pitch deck — a working cryptographic protocol filmed in 3 minutes. Seven shots. One narrative. Filmable in one day.
Narrative: Alice, a software architect, delivers a specification to Bob, a client. Bob must approve the exact file Alice sent — not a modified version, not a summary, the identical bytes. The MCR protocol certifies that both parties evaluated the same commitment. If Bob changes even one byte, the handoff halts before any receipt is minted.
Cast: Alice = Browser Tab A · Bob = Browser Tab B (incognito) · Foundry = Cloudflare Worker
Alice opens BAR-OS. Navigates to Contracts. Selects a specification. Clicks "Propose Handoff." Screen shows "Computing commitment..." then the truncated hash. Screen shows "Sealing for Bob..." Voiceover: "Alice selects her specification. BAR-OS computes a cryptographic commitment. The file is sealed to Bob's identity. Alice cannot alter it without breaking the seal."
Alice clicks "Send to Bob." BAR-OS POSTs to /mint as Party A. Screen shows "Awaiting Bob..." Voiceover: "The commitment — not the file — is sent to the Trust Foundry. The Foundry stores a signature. It cannot read the file. It only knows Alice signed something."
Bob opens BAR-OS in incognito. Notification: "Alice sent you a commitment." Bob clicks. BAR-OS decrypts payload locally. Bob sees the file in a read-only viewer. Hash comparison shows: Local Hash = Alice's Hash = MATCH ✓. Voiceover: "Bob receives the sealed file. His BAR-OS computes the same hash independently. The match is verified locally — not by a server."
Bob clicks "Approve — Identical." BAR-OS signs the hash. POSTs to /mint as Party B. Screen shows "Minting receipt..." Voiceover: "Bob signs the identical commitment. The Foundry verifies both signatures match the same hash. A receipt is born."
Both screens show simultaneously: Green banner — CONVERGED — LM-20260620-001-a1b2c3d4. Timestamp. Both pubkey hashes. "View Foundry Proof" link. Voiceover: "Receipt LM-001. Timestamped proof that Alice and Bob agreed on identical terms. No data was stored by the Foundry. Only the proof remains."
Reset. Alice sends same file. Bob opens it. Changes one word. Saves locally. BAR-OS recomputes hash — DIFFERENT. Screen shows HALT in red. No network call made. Voiceover: "If Bob changes even one byte, his local core detects the mismatch. The handoff halts. No receipt is minted. The divergence is caught before it becomes a dispute."
Split screen: Alice's vault shows LM-001 linked to the spec. Bob's vault shows identical. Foundry verify page shows CONVERGED. Text overlay fades in: "Trust is not a service. Trust is a structure." Voiceover: "Both parties own the proof. The Foundry witnessed. No one owns the data. This is structural trust."
This demo is not marketing material. It is the primary credibility artifact for the entire Continuity Architecture. It proves — in real time, with verifiable cryptography — that the architecture works. When a CTO, compliance officer, or department head asks "how do we know this works?", the answer is: "Watch this 3-minute video. Then we can talk."
Each day produces a deliverable. Each deliverable is a dependency for subsequent days. The sprint is designed to go from specification to filmed demo in two weeks.
Write MCR v1.0 spec + commitment hash canonicalization. Deliverable: SPEC-MCR-v1.md.
Implement Foundry Relay /mint + /verify locally (Node.js). Deliverable: Working relay on localhost:8787.
Deploy Foundry Relay to Cloudflare / Deno. Deliverable: Live URL.
Implement BAR-OS mcr-client.js: keygen, hash computation, sign. Module integrated into BAR-OS.
Implement mcr-client.js: encrypt/decrypt payload. End-to-end encryption working.
Implement mcr-client.js: relay POST + receipt storage. Full handoff loop working.
Build MCR Panel UI (HALT / PENDING / CONVERGED states). UI rendered in BAR-OS viewport.
Test divergence detection (modify payload, verify HALT). Passing test: mismatch = no receipt.
Polish UI: copy invite links, receipt download, verify link. UX complete.
Film demo per shot list in Section VI. Raw footage.
Edit demo + add captions + voiceover. Final video file.
Write case study page: "MCR v1.0 — Structural Trust in 3 Minutes." Published on portfolio.
Assemble Trust Architecture Packet (PDF). Downloadable.
Outreach: Send to 20 qualified prospects. 10 conversations scheduled.
Before declaring the module production-ready, every gate must pass with exact-value assertions and evidence. No claims. No "looks good." Verifiable proof for each gate.
The MCR Foundation Client includes a self-test suite accessible via ?test=true. Ten tests verify the cryptographic invariants. Every test produces exact-value assertions — not best-effort checks.
| Gate | Test | Assertion |
|---|---|---|
| F1 | Deterministic CBOR | Same object → identical CBOR bytes. Same CBOR bytes → identical SHA-256 hash. |
| F2 | Divergent HALT | Modified commitment hash → auditor returns HALT with code COMMITMENT_HASH_MISMATCH. |
| F3 | Receipt Budget | 2-party receipt CBOR ≤ 500 bytes. 2-party receipt JSON ≤ 600 bytes. |
| F5 | Non-Extractable Key | crypto.subtle.exportKey on private key handle throws. Sovereign identity preserved. |
| F6 | Temporal Anti-Replay | Commitment with timestamp > 5 minutes old → HALT with code STALE_COMMITMENT. |
| F7 | KRL Revocation | Participant pubkey_hash in KRL revoked list → HALT with code REVOKED_KEY. |
| F7b | Sort Order Enforcement | Unsorted participants array → HALT with code UNSORTED_PARTICIPANTS. |
| F8 | ECDH End-to-End | Encrypt with recipient public key, decrypt with recipient private key → plaintext matches. |
The test suite runs automatically when ?test=true is appended to the Foundation Client URL. Tests execute in order. Output is displayed in a dedicated panel. Every test produces ✅ or ❌ with expected vs. actual values on failure. The suite has zero external dependencies — it runs fully offline.
The MCR protocol is the foundation. Once the precedent exists — a filmed, verifiable convergence between two deterministic cores — the protocol extends to every domain where structural trust is the bottleneck.
The medical_co_sign.sic.v1 template is the first. It proves the pattern. After the demo, the vertical SIC library expands to cover every regulated domain in the GABOS platform: financial_audit, legal_review, compliance_ops, manufacturing_ops, command_auth, infra_control, aerospace_ops. Each SIC encodes domain-specific governance rules into the same deterministic CBOR → SHA-256 → ECDSA sign → blind relay mint pipeline.
The MCR auditor evaluates SIC compliance before a network call. The Execution Consent Gate applies the same primitive one layer closer to the physical world: between decision and execution in any autonomous pipeline. The model proposes an action. The gate evaluates it against the governing SIC. HALT before any physical consequence. The same mechanism. The same deterministic auditor. The same blind relay. One layer closer to the point of no return.
Once multiple MCR receipts exist across more than one vertical, the Continuity Architecture standard body certifies deployments as Continuity-Compliant. MCR is the cryptographic proof layer. ASB is the quality measurement layer. GAS is the governance layer. Together they form the complete certification framework for trustworthy AI deployment in regulated industries.
"Trust is not a service. Trust is a structure."
The MCR protocol is the structural proof. Two parties. One commitment. Identical evaluation. A blind notary that witnesses convergence without ever seeing the data. A timestamped, non-repudiable receipt that anyone can verify. This is what trust looks like when it is built into the architecture rather than promised by a platform.