Cyan Eclipse Holdfast

Vendor: Cyan Eclipse Technologies · Platforms: MCP over stdio

What it does

• Novel mechanism (SPEC §2.1, verbatim) — release is triggered by a counter-signed acceptance proof generated by executing the buyer's own acceptance tests — the test-run receipt, not a human click, unlocks funds.
• Decisive fixture F-H9 — bench-reproduced independently (bencher corpus, bencher keys, amount 77700): Run 1 — a genuine passing, counter-signed proof over the sealed bundle releases (RELEASED_SIM, release entry = terms amount, simulated: true), the receipt's proof_hash equals the release entry's and the bencher-recomputed proof hash, metering exactly 1 record, idempotent re-presentation mints nothing new, and in a fresh process with an empty data dir the §6 export + pinned keys alone verify (verified: true, release claim RELEASED_SIM). Run 2 (decisive) — a run whose test_bundle_hash is an alien, never-sealed bundle hash, with all tests passing, results/proof hashes recomputed over the alien hash, and both counter-signatures valid over the proof as presented, is refused BUNDLE_HASH_MISMATCH; the escrow stays ACCEPTANCE_PENDING, chain and ledger unchanged, metering 0. A bench that only checked 'tests passed' would have released Run 2; this one did not.
• Recompute-only, fail-closed release — the §2.3 checks run in the spec's fixed order (terms binding, bundle identity, results recompute, pass criterion, counter-signatures, freshness/state) and any doubt refuses release by name with no ledger movement; there is no human approval verb, override verb, manual-release path, or partial release on any surface (13 forbidden verbs bench-probed absent). State is derived from the signed chain on every read; no stored state field exists.
• Offline verification (SPEC §6.3) — a pure function of the terms + chain + proof + receipt export + pinned keys alone: terms hash and both party signatures recomputed, chain recomputed head-to-tail against its signed anchors (terms hash, signed head hash, record count), §2.3 checks re-run, and the release entry bound to the verified proof. Any step failing names its step (HOLDFAST_VERIFY_FAIL:<step>); an unverifiable export is labelled UNVERIFIED_EXPORT on its face, carries no release claim, and can never be upgraded.
• Condition C-1: external anchor required before live/multi-party use — coordinated rollback across artifacts is not claimed by this local build.
• Condition C-2: SETTLEMENT_BPS = 59 requires price-book/owner ratification before priced reliance (SPEC states no numeric figure — §9.1 shape only, §9.2 defers to price book; the 59 bps component is disclosed and NEVER collected in this scope, collected:false on every metering record).
• Honest scope — SIMULATOR, fixture escrow ledger only: local stdio, fixture terms/funding/delivery/run artifacts only, value_class "test" on every artifact and simulated: true on every ledger entry; no real funds are held, moved, or owed and no custody, payment rail, bank, wallet, or processor is touched. Closed surface of exactly 10 tools (8 party + 2 operator, disjoint; a cross-surface verb returns the identical NO_SUCH_TOOL as a nonsense name). Startup is fail-closed (CONFIG_FENCE_REFUSED:<class>) on a live-key string, a non-local endpoint, value_class other than "test", or any custody/wallet/rail/bank/processor module or configuration. Signing is an HMAC fixture stand-in for Herald RS256 (disclosed).
• Grammar attribution is exact and minimal: mandates are Till's, metering records are Meter's grammar, signing follows Herald's pattern, dispute packs go to Docket, party refs come from Agent Wallet — consumed by grammar or reference only, none redefined and none depended on in code. Cyan Eclipse Verity Bench and Eclipse Cupel are internal tools, not products: this product has no dependency on them, no integration with them, and no buy path, price, licence, or checkout for them anywhere.

Tools

Problems it addresses

• Escrow and milestone-payment flows release on a human's "looks good" click or on a seller's self-attested delivery claim — both unrecomputable: neither proves the delivered artifact was ever run against the buyer's acceptance criteria
• I need the acceptance evidence itself to be the release key: buyer and seller seal terms embedding the hash of the buyer's own acceptance-test bundle, and release follows if and only if a counter-signed test-run receipt recomputes against those sealed terms and shows a pass — a different bundle, however passing, releases nothing
• I need the whole flow rehearsed with zero custody risk: a fixture ledger where releases and returns are simulated accounting records, every refusal mutates nothing, and any export that cannot be recompute-verified downgrades to UNVERIFIED_EXPORT with no release claim instead of being upgraded post-hoc

Not tested

• Live custody / escrow licensing — SPEC §10 counsel gate (named, unbuilt): real fund custody or movement in an escrow form — holding buyer funds, acting as escrow agent, releasing real funds, or marketing a live escrow offering — is counsel-gated under the FinTech Law packet, additionally implicating escrow-agent / money-transmission licensing analysis counsel must scope before any live design exists; no custody, rail, wallet, bank, or processor code exists in this tree, there is no dormant live mode to activate, and a live phase is a separate, counsel-cleared, re-benched build, not a configuration change
• Condition C-1: external anchor required before live/multi-party use — coordinated rollback across artifacts is not claimed by this local build.
• Condition C-2: SETTLEMENT_BPS = 59 requires price-book/owner ratification before priced reliance (SPEC states no numeric figure — §9.1 shape only, §9.2 defers to price book; the 59 bps component is disclosed and NEVER collected in this scope, collected:false on every metering record).
• Production signing — v0.1.0 signing is an HMAC fixture stand-in for Herald RS256, disclosed on the product's face and on the signer face of receipts/evaluations; keys are pinned out-of-band in a local chmod-600 gitignored key file — a record-supplied key field is an unknown field, refused by name with its value never echoed, and a missing pinned key verifies nothing (fail-closed); a live phase requires real Herald RS256 signing and a re-bench
• Proof honesty (SPEC §11.4) — a release receipt proves a counter-signed run of the sealed bundle met the sealed criterion over the presented run record; it does not prove the delivered goods are good in any broader sense, that the tests were well-chosen, or that the runner's environment was honest; under NO_CRITICAL_FAIL, per-test criticality is taken from the counter-signed proof's outcomes (the bundle itself is never presented, only its sealed hash — bench advisory F-2)
• Multi-deliverable or staged escrows and a mutual-cancel verb — out of v0.1 (one deliverable, one amount, all-or-nothing release; §5 defines no cancel verb; the v0.1 return path is expiry-only); an ACCEPTANCE_PENDING escrow read past expiry does not auto-return (bench advisory F-3) and a post-expiry proof is refused ESCROW_EXPIRED
• Production key custody / fresh clone — fixture keys live in keys/fixture-keys.json (chmod 600, gitignored, never committed); a fresh clone generates 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 one Meter-grammar record per escrow reaching a terminal settlement state, RELEASED_SIM or RETURNED_SIM, at the $1/settlement + bps shape; refusals, failed runs, and idempotent re-presentations emit 0; the bps component is disclosed and never collected — collected: false on every metering record), no charge, checkout, invoice, or payment-collection path is built and no live Meter ingest is claimed