Universal attestation chain: typed QR codes, linked stages, domain-agnostic

[joelteply]

Vision

Forge-alloy is not just for model forging. It's a universal attestation chain for any transformation on any data. Each step is a signed, hashed link. QR codes are self-contained proofs that chain backwards to the origin.

The Chain

Each QR/alloy entry contains:

{
  "type": 0x01,                    // domain type byte
  "prev": "sha256:abc123...",      // hash of previous link (the chain)
  "input_hash": "sha256:def456",   // what came in
  "stage": { ... },                // what was done (transformation config)
  "output_hash": "sha256:789abc",  // what came out
  "signer": "ed25519:pubkey...",   // who did it
  "signature": "sig:...",          // proof they did it
  "timestamp": "2026-04-01T..."    // when
}

Walk the chain: scan any QR → follow prev hash → verify each link → reach origin.

Type Byte (domain classification)

0x01 = Model forge (prune, train, quant — current use case)
0x02 = Adapter training (LoRA, skill acquisition)
0x03 = Dataset attestation (provenance of training data)
0x04 = Compute receipt (grid transaction, GPU-hours)
0x05 = Delivery confirmation (model published/deployed)
0x06 = Evaluation result (benchmark scores)
0x07 = Vision encoder (modality addition)
0x08 = Audio encoder (modality addition)
0xFF = Custom domain (schema in payload)

The scanner reads the type byte, knows how to parse and verify the rest. Universal format, domain-specific interpretation.

Two-QR Model Card

┌────────────────────────────┐
│   Model Name               │
│                            │
│  [QR: Alloy]  [QR: Hash]  │
│  Recipe +     Model        │
│  attestation  weights      │
│                            │
│  Scan both → client-side   │
│  verification              │
└────────────────────────────┘

• Left QR: the alloy chain (recipe + signatures)
• Right QR: the model hash (verify weights match)
• Client-side JS: alloy's claimed hash == actual weights hash?

Self-Contained QR

For alloys under ~3KB (compact recipe + hashes, no loss curves):

• Entire alloy embedded IN the QR code
• No network needed to verify — scan → verify locally
• Offline-first verification

For larger alloys:

• QR contains hash + URL to fetch full alloy (HF, IPFS, local node)
• Multiple fetch sources for redundancy

Chain Examples

Model Forge

QR #1: Source (Qwen/Qwen3.5-4B, hash of base weights)
  → QR #2: Context Extend (YaRN 4x, prev=#1)
    → QR #3: Prune (30% entropy, prev=#2)
      → QR #4: LoRA Train (code domain, prev=#3)
        → QR #5: Quant (Q4_K_M, prev=#4)
          → QR #6: Eval (HumanEval 65%, prev=#5)
            → QR #7: Publish (continuum-ai/model, prev=#6)

Package Delivery (future domain)

QR #1: Manufacturer (product hash)
  → QR #2: Warehouse (packaged, prev=#1)
    → QR #3: Carrier (in transit, prev=#2)
      → QR #4: Delivered (recipient signature, prev=#3)

Grid Compute Transaction

QR #1: Job submitted (alloy recipe hash)
  → QR #2: Node accepted (node attestation, prev=#1)
    → QR #3: Compute complete (output hash, GPU-hours, prev=#2)
      → QR #4: Verified (client verified output, prev=#3)
        → QR #5: Credits transferred (ledger entry, prev=#4)

Verification Algorithm (spec)

Must be implementable by ANYONE — not just our tools:

1. Parse QR → extract type byte + payload
2. Verify signature against signer's public key
3. Recompute output_hash from actual data
4. Compare computed hash to claimed hash
5. If prev exists → fetch previous link → verify recursively
6. Origin link has no prev — that's the root of trust

The spec defines the algorithm. Any implementation (JS, Rust, Python, mobile app) can verify.

Priority

High — this is the trust infrastructure for everything: grid economy, public forge, model marketplace.

Related

• Stage types are LLM-specific — forge-alloy should be domain-agnostic #7 Domain-extensible stages
• Client-side verification: no trusted server, math is the authority #8 Client-side verification
• continuum#716 Grid economy
• continuum#717 QR pairing