From 6eca4e9f9a5e15f49662501b1b74e30f5b1a7831 Mon Sep 17 00:00:00 2001 From: Greg Soucy Date: Thu, 21 May 2026 18:01:55 -0400 Subject: [PATCH] Rebuild runtime-core and canonical receipts protocol pages --- public/canonical-receipts.html | 54 +++++++++++++++++++++++++++++++++- public/runtime-core.html | 35 +++++++++++++++++++++- 2 files changed, 87 insertions(+), 2 deletions(-) diff --git a/public/canonical-receipts.html b/public/canonical-receipts.html index 7c5cf58..3bd1fed 100644 --- a/public/canonical-receipts.html +++ b/public/canonical-receipts.html @@ -1 +1,53 @@ -Canonical Receipts | CommandLayer
Canonical Receipts

Canonical receipts anchor trust verification.

Receipt model

A CommandLayer receipt is a structured action result with a canonical metadata.proof envelope for deterministic verification.

  • canonicalization: json.sorted_keys.v1
  • hash algorithm: SHA-256
  • signature algorithm: Ed25519
  • signature key id: vC4WbcNoq2znSCiQ
  • signer id: runtime.commandlayer.eth

Verification semantics

Tampering invalidates proof because both hash and signature checks fail.

Schema-valid alone is not verified.

+ + + + + + Canonical Receipts | CommandLayer + + + + + + + + + + +
Canonical Receipts

The proof envelope for verifiable agent actions.

A CommandLayer receipt records what an action returned and attaches metadata.proof so the result can be independently verified.

+
+

What a receipt proves

Which verb ran.
Which class/family it belongs to.
What payload/result was returned.
Which signer produced the proof.
Which canonicalization/hash/signature algorithms were used.
Whether tampering breaks verification.
+

Receipt shape

{
+  "verb": "sign",
+  "class": "trust-verification",
+  "result": {
+    "payload": {
+      "message": "hello from CommandLayer"
+    }
+  },
+  "metadata": {
+    "proof": {
+      "canonicalization": "json.sorted_keys.v1",
+      "hash": {
+        "alg": "SHA-256",
+        "value": "..."
+      },
+      "signature": {
+        "alg": "Ed25519",
+        "kid": "vC4WbcNoq2znSCiQ",
+        "value": "..."
+      },
+      "signer_id": "runtime.commandlayer.eth"
+    }
+  }
+}
+

Required proof fields

  • metadata.proof.canonicalization
  • metadata.proof.hash.alg
  • metadata.proof.hash.value
  • metadata.proof.signature.alg
  • metadata.proof.signature.kid
  • metadata.proof.signature.value
  • metadata.proof.signer_id
+

Verification lifecycle

receipt received → structure checked → canonical payload rebuilt → SHA-256 hash recomputed → hash compared → Ed25519 signature verified → signer identity/kid checked → VALID or INVALID
+

Valid vs tampered

Valid receipt

verifier_status = VALID
hash_matches = true
signature_valid = true

Valid receipt accepted.

Tampered receipt

verifier_status = INVALID
hash_matches = false
signature_valid = false

Tampered receipt rejected.

+

Schema validation vs proof verification

Schema validation checks shape. Proof verification checks truth.
A schema-valid receipt can still be invalid if the hash or signature fails.
+

Where receipts are used

+

Trust boundaries

  • Runtime signs.
  • Verifier validates.
  • MCP bridges.
  • SDK wraps.
  • Schemas describe.
  • Private keys never go through MCP or public verifier endpoints.

Production runtime endpoint: https://runtime.commandlayer.org.

+

Take the next step

+
+ + diff --git a/public/runtime-core.html b/public/runtime-core.html index b2aedc0..5f47f5b 100644 --- a/public/runtime-core.html +++ b/public/runtime-core.html @@ -1 +1,34 @@ -runtime-core | CommandLayer
runtime-core

runtime-core is the crypto truth layer.

canonicalize → hash → sign → verify

runtime-core powers deterministic proof creation and verification for runtime, verifier, and SDK integrations.

It is not a runtime, not MCP, and not a marketplace.

https://github.com/commandlayer

+ + + + + + runtime-core | CommandLayer + + + + + + + + + + +
runtime-core

The crypto truth layer for CommandLayer receipts.

runtime-core defines the canonicalization, hashing, signing, and verification primitives used to produce and validate CommandLayer receipts.

+
+

What runtime-core does

Canonicalizes receipt payloads.
Computes SHA-256 hashes.
Signs receipts with Ed25519.
Verifies Ed25519 signatures.
Checks metadata.proof integrity.
Detects tampering.
+

What runtime-core is not

Not the hosted runtime.
Not MCP.
Not the SDK.
Not a marketplace.
Not a schema registry.
Not a trust claim by itself.

runtime-core is the primitive layer. The hosted runtime uses it to sign. Verifiers use it to validate. SDKs can use it to wrap actions, but runtime-core itself is the deterministic proof engine.

+

Proof pipeline

canonicalize
hash
sign
verify
valid / invalid
  • Canonicalize with json.sorted_keys.v1.
  • Hash canonical payload with SHA-256.
  • Sign hash/proof envelope with Ed25519.
  • Verify by recomputing hash and checking signature.
  • Reject if any byte changes.
+

Canonical proof fields

metadata.proof.canonicalization = "json.sorted_keys.v1"
+metadata.proof.hash.alg = "SHA-256"
+metadata.proof.hash.value = "..."
+metadata.proof.signature.alg = "Ed25519"
+metadata.proof.signature.kid = "vC4WbcNoq2znSCiQ"
+metadata.proof.signature.value = "..."
+metadata.proof.signer_id = "runtime.commandlayer.eth"
+

Runtime-core in the stack

CLAS defines action contracts.
runtime-core defines proof primitives.
runtime executes and signs.
MCP bridges requests.
VerifyAgent/verifier validates.
SDK wraps developer actions.
+

Verification result model

  • VALID / VERIFIED means canonical hash and signature checks passed.
  • INVALID means proof failed.
  • TRANSPORT_ERROR means verifier/runtime unavailable.
  • Schema-valid alone is not verified.
+

Developer links

Runtime endpoints are available at https://runtime.commandlayer.org.

+
+ +