Cyan Eclipse Feeseal

Vendor: Cyan Eclipse Technologies · Platforms: MCP over stdio

What it does

• Novel mechanism (SPEC §2.1, verbatim) — every fee charged is sealed against the published fee-schedule version in force; overcharges against that version are detected automatically.
• Seal, recompute, compare — a schedule version is sealed (hash + marketplace signature + Herald signature) as presented; each fixture transaction is checked by deterministic arithmetic only (SPEC §2.2: Fee = clamp( round_bps(base × rate_bps / 10_000) + flat , min , cap ), integer minor units, one named rounding step) over the sealed in-force version, reporting MATCH, OVERCHARGE, or UNDERCHARGE with the signed variance to the minor unit. A schedule whose fee cannot be computed deterministically from its face is refused at seal time (SCHEDULE_NOT_DETERMINISTIC), never interpreted; gaps, overlaps, and version skips refuse as SCHEDULE_INTERVAL_BREAK / SCHEDULE_VERSION_SKIP.
• Offline verification (SPEC §6.3) — a pure function of the sealed schedule chain + transaction + verdict export + pinned keys alone: schedule hashes and both signatures are recomputed and verified, the version in force at the transaction timestamp is identified (a relabelled schedule_version claim never governs — VERSION_CLAIM_MISMATCH is recorded on the verdict's face), and expected/charged/variance arithmetic must be exact. Any step failing names its step (FEESEAL_VERIFY_FAIL:<step>); unverifiable material exports only as UNVERIFIED_EXPORT, verified: false — downgrade law: no tool path upgrades it and no retro-seal path exists.
• Decisive fixture F-F9 — bench-reproduced: a batch spanning the v1 (250 bps) → v2 (300 bps) succession boundary recomputes exactly from the export + pinned keys in a fresh process, including OVERCHARGE +70 (charged 350 vs v1-prescribed 280); the same transaction relabelled as a v2 transaction still verifies against sealed in-force v1 and the OVERCHARGE +70 verdict stands; a sealed schedule copy edited to make 350 'correct' fails at step 1 (seal broken).
• Honest scope — LOCAL stdio, fixture schedules + fixture transactions ONLY: no live marketplace, payment, or ledger is touched, no real fee is charged, audited, refunded, or adjusted by Feeseal, and every emitted artifact carries value_class "test". Schedules are sealed as presented by the marketplace fixture, not published by Feeseal. Closed surface of exactly 8 tools (6 party + 2 operator, disjoint); no charge/refund/adjust/collect/pay/settle/publish/set/delete schedule verb exists on either surface. Startup is fail-closed (CONFIG_FENCE_REFUSED:<class>) on a live-key string, a non-local endpoint or any schedule-fetch/scrape configuration, value_class other than 'test', or any payment/billing/ledger module in the tree. Signing is an HMAC fixture stand-in for Herald RS256 (disclosed).

Tools

Problems it addresses

• A marketplace publishes a fee schedule and then charges against code, not against the page — a wrong rate, a stale version applied after an update, or a minimum or cap quietly dropped is small, deniable, and undetectable from a receipt that shows only what was charged
• I need charges bound to the published version in force, sealed at the time, so an overcharge against that version is a recomputable fact — provable offline, from the sealed schedule version + transaction record + pinned keys alone, to the minor unit — not an allegation against the current (possibly edited) fee page
• I need the verification kept honest on its face: detection, not collection — the witness never charges, refunds, or adjusts any fee, a relabelled version claim never moves a verdict, and unverifiable exports downgrade to UNVERIFIED_EXPORT instead of being upgraded post-hoc

Not tested

• Real fees, real marketplace schedules, or any live marketplace use — fixture schedules + fixture transactions only; the SPEC §10 counsel gate is unbuilt by design, named, with no dormant live mode: operating Feeseal live (sealing a real marketplace's schedule as evidence against it, publishing findings about a named live marketplace, enforcing or collecting on variances, or holding Feeseal out as an audit of a named live marketplace) is counsel-gated under the FinTech Law / marketplace packet, additionally implicating defamation/commercial-disparagement and contract-interference analysis counsel must scope before any live design exists
• Any real fee audited, charged, refunded, or adjusted — Feeseal detects and evidences variances against the sealed version only; it never charges, refunds, withholds, adjusts, or collects any amount and issues no instruction to do so; never claimed for v0.1.0 are 'fee audit', 'refund recovery', 'guaranteed accurate fees', 'certified fee schedule', any implication of live marketplace coverage or enforcement, or any finding about a real platform (SPEC §11.3 strings are named here only as never claimed)
• Provenance beyond the seal — a verdict proves only that the charged fee does or does not equal the deterministic output of the sealed version as presented, for the stated inputs; it does not prove the presented schedule was the one actually published to the world, that transaction inputs are complete, or that any remedy is owed (SPEC §11.4)
• Production signing — v0.1.0 signing is an HMAC fixture stand-in for Herald RS256 with local fixture keys (keys/ gitignored, mode 600, never committed); a live phase requires real Herald signing and a re-bench; a fresh clone generates its own fixture keys to run the full suite
• Hosted or live operation — local stdio only; metering point only per signed-verdict transaction ($0.002/transaction shape), no charge path built and no live Meter ingest