Cyan Eclipse Layaway

Vendor: Cyan Eclipse Technologies · Platforms: MCP over stdio

What it does

• Novel mechanism (SPEC §2.1, verbatim) — the mandate self-executes only when two witnessed conditions coincide — goal balance reached and a witnessed price at or below the target — with progress receipts throughout.
• Two witnessed inputs, independently sealed — the goal-balance ledger's hash-chained segment shows balance at or above the goal, and a Trueprice-style sealed observation for the mandate's exact item shows price at or below target, fresh within the mandate's stated window; both are evaluated as of the same evaluation tick, the execution record binds both witness citations in one record, and condition statuses from earlier ticks have no causal force (no latching). 'Witnessed' in this scope means a Trueprice-style seal over a fixture observation, verified in its native grammar against a pinned fixture witness key — not attestation by any real price service, and not evidence about any real item's price.
• Decisive fixture F-L13 — bench re-derived from the bencher's own corpus (bencher keys throughout, bencher battery 90/90): a 12-tick history on 2026-03-01 (price-only, balance-only, neither, and a PRICE_STALE tick) executed at exactly the coincidence tick and no other — exactly 12 tick receipts, exactly 1 execution record, executed_at 2026-03-01T07:30:00Z, balance 62,000 / price 31,000 (== target). Both witnesses (balance 62,000, price 31,000) were recomputed fresh-process two ways: the artifact's execution_verify in a fresh operator process from pack + pinned keys alone, and the bencher's standalone recompute with no artifact code at all.
• Honest scope — simulator only, local stdio, fixture goal-balance ledger + fixture witnessed prices ONLY, value_class "test": execution = a mandate state transition only — NO purchase is executed, no funds move, nothing was bought, ordered, or paid, and nothing is instructed to any merchant. Closed surface of exactly 12 tools (8 owner + 4 operator, disjoint); no purchase/order/funds verb exists on either surface (18 forbidden verbs bench-probed NO_SUCH_TOOL). Startup is fail-closed (CONFIG_FENCE_REFUSED:<class>) on any merchant/marketplace/payment/price-feed endpoint or key, real balance source, or value_class other than 'test'. Signing is an HMAC fixture stand-in for Herald RS256 (disclosed). Sole condition: cross-artifact cross-commitment is fenced — external anchor required before live/multi-party use.

Tools

Problems it addresses

• Savings goals execute at goal-reached regardless of price (buying high because the money is ready), while price alerts fire regardless of funds (a deal the owner cannot yet take, gone by the time they can) — each half exists separately and fails separately
• The conjunction is the product, and it must be witnessed: a self-reported price or a self-reported balance makes any execution claim self-attested
• I need an execution record that binds both witnesses — goal-balance ledger state and a sealed price at or below target, coinciding at one evaluation tick — so a third party can recompute that both conditions genuinely held, together, at execution, with progress receipts throughout showing why it had not executed earlier

Not tested

• Real purchase execution — SPEC §10 counsel gate (named, unbuilt): real purchase execution (plus Till's own gates), real funds custody/direction, real price feed as witness — counsel gate, unbuilt; no merchant stub exists. Any execution that places a real order, instructs a merchant, or triggers a real payment (which must additionally pass Till's own gates), holding/directing real goal funds in any form, consuming a real price feed as a witnessed source, and any consumer-facing claim that funds are saved, held, protected, or guaranteed available are counsel-gated and unbuilt; there is no dormant live path, no merchant integration stub, and no funds verb waiting to be enabled
• Sole condition (verbatim from the bench record): cross-artifact cross-commitment is fenced — external anchor required before live/multi-party use. Cross-artifact cross-commitment (mandate chain + balance segment + price observation bound by hash citations in one execution record) is a fenced condition — external anchor required before live/multi-party use
• Real balances, prices, merchants, products, or purchases — simulator/fixture only: fixture goal-balance ledger + fixture witnessed prices only, value_class "test"; the 'execution' is a simulator state transition — NO purchase is executed, no funds move, and nothing is instructed to any merchant
• Production signing — v0.1.0 signing is an HMAC fixture stand-in for Herald RS256, disclosed on the product's face; verification uses keys pinned out-of-band in a local chmod-600 gitignored key file, never keys supplied by a record; a live phase requires real Herald signing and a re-bench
• Production key custody — fixture keys live in keys/fixture-keys.json (chmod 600, gitignored, never committed; GitHub contents/keys verified 404); a fresh clone must create its own fixture key file to run the full suite
• Hosted or live operation / charge path — local stdio only; metering points only per SPEC §9 (exactly 1x layaway_execution point per simulated execution + 1x free-funnel active-period accounting event per mandate; 0 for refusals/non-executions; no charge path built, no payment taken, no live Meter ingest claimed)