Cyan Eclipse Crosspay

Vendor: Cyan Eclipse Technologies · Platforms: MCP over stdio

What it does

• Novel mechanism (SPEC §2.1, verbatim) — rate source, rate, and spread are sealed at execution, and settlement is refused pre-flight when the spread exceeds the mandate's cap — enforcement before money moves, not evidence after.
• Sealed pre-flight verdict — fx_seal = sha256(canonical(source_id ‖ benchmark_rate ‖ offered_rate ‖ spread_bps ‖ mandate_hash ‖ intent_hash)); rates are scaled integers (never floats) so spread_bps = round_half_even((benchmark_rate − offered_rate) × 10_000 / benchmark_rate) recomputes exactly; the quote's self-stated spread is recorded, never trusted (SPREAD_MISSTATED), and a mandate carrying no max_spread_bps can never be cleared (MANDATE_NO_SPREAD_CAP — the cap is read from the mandate's face, never set, defaulted, or coerced). Refusals are first-class sealed, Herald-signed verdict records (except the no-seal INTENT_INCOMPLETE class, which issues no seal, no verdict, and no metering point).
• Decisive fixture F-X9 — bench independently re-derived from the bencher's own corpus (GBP/USD pair the builder never used, bencher-owned keys): under-cap check → CLEAR, spread_bps 40, max_spread_bps 100 on the face, fx_seal == bencher-recomputed seal; over-cap twin (offered 103939500) → REFUSED / SPREAD_CAP_EXCEEDED, spread_bps 101, cap 100 on the face; fresh process, export + pinned keys alone, empty data dir: both exports verify (CLEAR claim and REFUSED/SPREAD_CAP_EXCEEDED claim reproduced). Re-bench confirmed F-X9 end-to-end after the D1/D2/D3 fixes.
• Offline verification — fail-closed and recompute-only: intent, mandate, and quote hashes, the seal, the spread, the cap comparison, the Herald signature, and every counter-signature are recomputed and verified on every check and every offline verify against keys pinned out-of-band in a local chmod-600 gitignored key file (keys are never accepted from the record under verification). An export that cannot be recompute-verified is labelled UNVERIFIED_EXPORT, carries no verdict claim, and can never be upgraded back to a sealed verdict. D2 lineage exports: prior_export carried in verdict_get bundles; replay verdicts verify from export + pinned keys alone.
• Honest scope — local/simulator, fixture FX records only, pre-flight verdicts only, value_class "test": Crosspay never converts, settles, or moves currency, fetches no live rates, and holds no funds; no live FX source/rails exist (fixture records only). Closed surface of exactly 6 tools (4 caller + 2 operator, disjoint); 25 forbidden verbs (convert/settle/transfer/pay/fetch_rate and peers) probed on both surfaces return the same NO_SUCH_TOOL as a nonsense name. Signing is an HMAC fixture stand-in for Herald RS256, disclosed on every face.

Tools

Problems it addresses

• Cross-currency agent payments leak value in the spread, invisibly: the payer sees a rate, not the distance between that rate and the source benchmark, and the mandate that authorized the payment almost never says how much spread is too much
• Post-hoc reporting doesn't fix this — by the time an auditor finds a 4% spread on a payment capped at 1%, the money has moved at 4%; nobody seals the three numbers (source, rate, spread) at the moment of decision and refuses before movement when the cap is breached
• I need a sealed pre-flight verdict a third party can recompute offline — from export + pinned keys alone — proving the spread was checked against the mandate's cap before any settlement could occur, and the over-cap twin of the same payment refused pre-flight by name

Not tested

• Live FX — SPEC §10 counsel gate (named, unbuilt): live FX — fetching live rates for real payments, quoting or executing conversion, or any cross-border settlement — is counsel-gated (joined to the existing FinTech Law packet (Till/x402)) and unbuilt; no live FX source/rails exist in v0.1.0 (fixture records only), no live rate is fetched, no currency is converted or settled, and any live phase is a separate, counsel-cleared, re-benched build, not a configuration change
• Sole condition (verbatim): cross-artifact cross-commitment is fenced — external anchor required before live/multi-party use. Cross-artifact cross-commitment (seal ↔ verdict ↔ export) provides full coordinated rollback only as a fenced condition: external anchor required before live/multi-party use. No live or multi-party use is licensed until that anchor exists and the build is re-benched
• D2 lineage exports — CHECK_REPLAY sealed verdicts are offline-verifiable from export + pinned keys alone via lineage: prior_export is carried in verdict_get bundles, and replay verdicts verify from export + pinned keys alone (re-bench D2 CLOSED, condition C3 discharged); a replay bundle is never served unlabelled/unverifiable
• Non-blocking observation (re-bench): with ≥2 priors a second replay's prior_export may point to the earliest prior rather than the immediate predecessor (spec predicate unaffected) — §5.3's replay predicate requires only the existence of a prior distinct-triple same-intent sealed check, which the shipped prior satisfies and the verifier re-derives; soundness is unaffected
• Real FX rates, quotes, mandates, payments, or settlement — local/simulator, fixture FX records only, value_class "test": no live FX source/rails (fixture records only); Crosspay never converts, settles, or moves currency, fetches no live rates, and holds no funds; a CLEAR speaks only to the sealed fixture quote against the presented mandate's cap
• Production signing — v0.1.0 signing is an HMAC fixture stand-in for Herald RS256 (HMAC Herald stand-in), 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 +1 per sealed verdict, CLEAR or REFUSED alike; 0 for no-seal refusals, verifies, verdict-gets, handoff marks, and idempotent re-presentations; no charge path built, no payment taken, no live Meter ingest claimed)