Cyan Eclipse Warranty

Vendor: Cyan Eclipse Technologies · Platforms: MCP over stdio

What it does

• Novel mechanism — the claim pack is transferable on resale because it is bound to the product serial + sealed purchase proof (buyer mandate ref + retailer receipt ref), not to a retailer account login. verify_pack recomputes the seal from the serial, bindings, and transfer chain alone — no account credential, no original-holder proof. Bench: register → transfer in one process, then verify_pack by pack_id only in a fresh process = VALID with the original holder uninvolved; the exported pack object also verifies VALID in the fresh process with bindings intact.
• Sealed bindings + chained transfers: the five bindings (serial, product_ref, buyer_mandate_ref, retailer_receipt_ref, purchase_ts) are immutable at registration; transfer appends a chained record (each transfer's prev_seal equals the actual superseded seal, genesis prev_hash GENESIS) and re-seals without ever editing the bindings. Bench tamper matrix: 5/5 bound fields → INVALID, 11/11 chain tampers → INVALID, 6/6 supplied-pack attacks (seal transplant, naive SHA-256 reseal without the HMAC key, chain truncation + holder rollback, replayed duplicate transfer, seal deleted, mandate swap) → INVALID; a tampered pack refuses transfer with PACK_INVALID and claim_check reports transferable:false.
• Full-content seal (v0.1.1 fix for bench defect D1, MEDIUM): the seal now covers the complete pack object minus the seal field, and verify enforces strict structure — any key outside the specced top-level/binding/transfer sets, a missing or wrong-typed field, or a scope/seal_type outside the spec vocabulary (scope must be exactly LOCAL/fixture) verifies INVALID, supplied or stored. get_pack refuses structurally out-of-spec stored packs (PACK_INVALID) instead of serving injected or relabelled content as sealed pack content. Re-bench D1 attacks PASS 26/26, including bindings.injected_coverage = 'lifetime-full' and a top-level scope relabel to 'LIVE/production' — both INVALID.
• Advertised schemas enforced at dispatch (v0.1.1 fix for bench defect D2, LOW): required fields present, declared types exact (an int purchase_ts or a list serial is a clean validation error, never coerced via str()), and extra argument keys rejected per additionalProperties: false. Re-bench D2 attacks PASS 24/24 — every rejected attempt registered nothing, a serial burned by a rejected attempt remains registrable with correct types, and rejected calls left a good pack untouched and VALID.
• Disclosed seal break (not hidden): packs sealed under v0.1.0's projected seal verify INVALID under v0.1.1 — the bench crafted a pack with the exact v0.1.0 formula under the same demo key and confirmed the break is real. At LOCAL/fixture scope there is no migration: fixture packs are re-registered (SPEC Bench Fix addendum + BUILD-RECORD state this plainly). Any future scope upgrade would need a migration story.
• Honest scope: LOCAL / fixture only — registrations operate on fixture purchase records supplied by the caller (refs/strings the caller asserts); no retailer, manufacturer, or payment network is contacted. Seals are HMAC-SHA256 with a local demo key (runtime-generated into gitignored keys/demo.key, mode 0600; bench hygiene 6/6 — no key material in tree or history). Python 3 standard library only; MCP over stdio; exactly the 5 specced tools; no payment anything. The pack is a witness record, not a warranty contract: no adjudication, coverage, eligibility, or enforceability claim exists anywhere in the product.

Tools

Problems it addresses

• My agent bought a product for me — I need the warranty evidence bound to the product's serial and the sealed purchase proof, not locked inside a retailer account login
• When the product is resold, I need the claim pack to transfer with it and still verify — without the original buyer, their account, or their participation
• If anyone adds a field to the pack, relabels its scope, or edits a binding or a transfer record after the fact, I need verification to fail — nothing altered may pass as sealed

Not tested

• Live retailer, manufacturer, or payment integration — not in v0.1.1 by design: no third party is contacted and no claim is filed anywhere; registrations operate on caller-supplied fixture refs only
• Hosted or remote serving — v0.1.1 is local stdio only; transfer is a bearer capability on pack_id possession (bench D3, informational, by SPEC design) and must be revisited before any hosted/live scope
• Warranty adjudication, coverage, eligibility, or enforceability — none exists in the product at any scope; the pack is a witness record, not a warranty contract
• Migration of v0.1.0-sealed packs — none exists by disclosed design: v0.1.0 packs verify INVALID under v0.1.1 and fixture packs are re-registered (SPEC Bench Fix addendum)