
Eclipse Faircharge
Subscription-creep measurement over fixture charge streams against a sealed original authorization — creep is detected against the sealed price history from the original authorization, so a merchant's gradual increases are measured against proof, not memory. PASS (local, fixture charge streams + sealed authorizations) — local stdio MCP, fixture charge streams + sealed authorizations only, value_class "test"; Faircharge measures drift — it makes no breach, overcharge, or misconduct finding.
status: in-developmentclass: mcpAgent PaymentsTrust & Receipts
Vendor: Cyan Eclipse Technologies
What it does
- Novel mechanism (SPEC §2.1, verbatim) — creep is detected against the sealed price history from the original authorization, so a merchant's gradual increases are measured against proof, not memory.
- Sealed baseline or nothing (SPEC L5) — at authorization time the original price terms (baseline amount, unit, period, the authorization's own per-charge + cumulative thresholds, any scheduled steps) are hash-sealed and Herald-signed (RS256 JWS, per-term hashes); a charge stream with no original authorization sealed at authorization time can receive no measurement — retrospective baselines are refused, only an unsigned UNSEALED_SUMMARY (sealed:false) can be issued for a reconstructed stream, and the verifier rejects it as a Faircharge artifact
- Pinned creep rule (SPEC §2.2, integer minor units / basis points only, no floats, unmappable units refused never coerced) — per-charge delta vs the amount expected given the stream so far (scheduled-step amount effective at that index, else previous charge in the current seam segment, else the segment baseline) and cumulative drift always vs the current seam segment's baseline; verdicts WITHIN_TERMS / CREEP_PER_CHARGE / CREEP_CUMULATIVE / CREEP_BOTH, stream roll-up = worst per-charge verdict; a stream can verdict CREEP_CUMULATIVE while every individual charge is within its per-charge delta — that asymmetry is the mechanism; an unpinned dimension is not judged and every receipt states dimension_unpinned for it (§6.3)
- Signed creep receipts + measurement pack — on any non-WITHIN_TERMS measurement a Herald-signed creep receipt names the charge, the sealed baseline values, expected + presented amounts, delta, cumulative drift, the sealed threshold(s) crossed, and the measurement record id; measurement_pack_export assembles terms + seal + all measurement records + all presented charge objects + creep receipts + re-authorization records + a signed head anchor (record_hash + record_count) as the deliverable to Docket — Faircharge supplies the recomputable measurement, Docket/counsel decide what, if anything, it breaches
- Offline verification (SPEC §6.4) — measurement_verify recomputes per-term hashes, the whole hash chain, Herald signatures (+ caller counter-signature presence matching its on-face label), every expected_amount / delta / cumulative_drift / verdict, the roll-up, and every receipt from the pack + pinned public keys alone (keys/pinned-public.json only; key material in tool args or inside a pack is refused pre-verification); decisive fixture F-FC8 passes in a fresh process with an empty data dir; any step failing returns FAIRCHARGE_VERIFY_FAIL:<step>, no partial verdict, and the pack downgrades whole to UNWITNESSED_EXPORT — unverifiable ⇒ downgraded, never upgraded
- Re-authorization seam (SPEC §3.2) — a genuinely re-authorized price enters only as an explicit re-authorization record citing the prior seal; the old baseline and all pre-seam measurements stay in history permanently and post-seam charges measure against the new baseline; no charge, verdict, or caller assertion can create a seam implicitly; state + current baseline are derived from the signed chain at read (post-close measurements are refused; the verifier refuses measurements after a stream_close)
- Stored-serve + pack hardening (bench conditions C0–C7, D1–D6, E1–E4, all CLOSED at v0.1.3) — signed head anchor defeats tail truncation; presented-charge fields (charged_at / merchant_ref) are hash-bound into the signed measurement; time fields are really RFC3339-parsed with expiry + pre-authorization ordering enforced; anomaly queue + metering are chain-anchored; creep receipts verify before serve; the canonical pack binds all 15 face fields exactly (injected certification/verdict keys fail pack_face; verifier_transcript dropped); the anomaly queue gates every store-consuming surface; the stdio envelope survives non-object requests; mutators whole-store-validate before any write, garbage siblings refuse STORE_DEFECT with store bytes unchanged. One non-blocking hygiene note stands (F1, in not_tested): container-level foreign keys undetected + re-persisted (never served, no verdict impact)
- Measurement-not-breach fence (SPEC §11.2, verbatim on every creep receipt + pack face) — Faircharge measures drift against the sealed original authorization. Whether a measured increase breaches the merchant's terms or any law is a contract/legal question for Docket/counsel — Faircharge makes no breach, overcharge, or misconduct finding.
Tools
authorization_seal · charge_measure · relationship_reauthorize · relationship_status · creep_receipt_get · measurement_verify · measurement_pack_export · relationship_close · anomaly_queue_read
Platforms
- MCP over stdio
Certification
Bench verdict: PASS (local, fixture charge streams + sealed authorizations)
Certified scope: PASS (local, fixture charge streams + sealed authorizations) — Verity bench of v0.1.0 (2026-10-27, argus101-program-20261027/wave2/bench-faircharge.md) PASS-CONDITIONAL (local, fixture charge streams + sealed authorizations) with conditions C1–C7 plus spec-hygiene condition C0 (spec §2.2.2 formula sentence contradicted fixtures F-FC4/F-FC8; Verity ruled the fixture/defining-test reading governs and the shipped behaviour IS the fixture's; §2.2.2 + §6.4 step-3 amended to it); fix round v0.1.1 closed C0–C7; delta re-bench of v0.1.1 (rebench-faircharge.md) and round 2 of v0.1.2 (rebench2-faircharge.md) raised D1–D6 and E1–E4; delta re-bench round 3 of v0.1.3 (rebench3-faircharge.md): E1 (pack face binding) + E2 (anomaly gate coverage) + E3 (envelope) + E4 (whole-store validation) CLOSED, C0–C7 and D1–D6 hold under serialized re-runs and full-strength frontier sweeps — CONDITIONS CLOSED, Faircharge — PASS (local, fixture charge streams + sealed authorizations). Builder suite re-run by the bencher at every bench: 18/18 at v0.1.0, 44/44 at v0.1.3 (38 prior + 6 round-3 fixes); R3 independent probes: 213 PASS / 1 probe-bug FAIL, standalone re-run PASS = 214/214 effective serialized checks. Decisive fixture F-FC8 independently reproduced at every bench: counter-signed seal (both thresholds pinned minor-only, scheduled step 1050@idx4), charges [1000,1030,1090,1050,1090,1095,1200] → exact sequence WITHIN, WITHIN, CREEP_PER_CHARGE, WITHIN, WITHIN, CREEP_CUMULATIVE, CREEP_BOTH; serialized pack verifies in a fresh process from pack + pinned public keys alone. PASS (local, fixture charge streams + sealed authorizations) is not CERTIFIED — certified is false, and nothing beyond the PASS verdict at its exact scope is claimed. Scope is exactly: local, fixture charge streams + sealed authorizations only; no live merchant, card network, bank feed, billing system, or real charge is touched; no real consumer financial data enters any fixture; value_class:"test" throughout. SPEC §11.2 measurement-not-breach fence: Faircharge measures drift against the sealed original authorization. Whether a measured increase breaches the merchant's terms or any law is a contract/legal question for Docket/counsel — Faircharge makes no breach, overcharge, or misconduct finding. A CREEP verdict is a measurement, not an accusation and not a breach finding; WITHIN_TERMS means only that the stream measured within its own sealed thresholds (or that a dimension was unpinned, labelled on the face — §6.3 no-verdict-laundering). The SPEC §10.1 counsel gates are UNBUILT, named in not_tested. Novel mechanism (SPEC §2.1, verbatim): creep is detected against the sealed price history from the original authorization, so a merchant's gradual increases are measured against proof, not memory. Stored serves in v0.1.3 are verify-before-serve (receipts hash/signature-gated, C3), the canonical measurement pack binds all 15 face fields exactly (E1, verifier_transcript dropped), the anomaly queue gates every store-consuming surface (E2), the stdio envelope survives non-object requests (E3), and mutators whole-store-validate before any write (E4). Non-blocking hygiene note F1 stands, verbatim class: container-level foreign keys undetected + re-persisted (never served, no verdict impact) (full text in not_tested).
Not tested:
- Hygiene note F1 (Verity delta re-bench round 3, MINOR, class-c hygiene, E4-adjacent, NON-BLOCKING): container-level foreign keys undetected + re-persisted (never served, no verdict impact). A foreign key on a relationship OBJECT (relationships.<ref>.certified=true) or at store ROOT (certification:"Cyan Eclipse Certified"), serialized, is never checked by _store_shape_ok / _chain_defect / _whole_store_defect (container key sets are not allowlisted) — status serves clean and a mutator on that relationship mints and re-persists the foreign key verbatim. No false serve resulted: status/export/receipt outputs are constructed explicitly (the key never appears in any output; the export pack is the canonical 15 fields, key absent from export JSON — verified), no verdict/anchor/receipt is affected, and the same key inside a PACK fails pack_face. The store is internal state, never the Docket deliverable. Hygiene fix for a later pass: exact key-set allowlists for store root + relationship objects in _store_shape_ok / _whole_store_defect. F1 is recorded as hygiene debt; it does not gate the deliverable and did not affect the verdict.
- Live charge streams or real consumers' authorizations — sealing real consumers' real subscription authorizations or measuring live charge streams from any real account/card/bank source (privacy + financial-data review) is SPEC §10.1 counsel gate (a), UNBUILT by design: v0.1.3 has no network imports tree-wide, the fail-closed fence refuses merchant/bank/card endpoints, live keys, real-format financial identifiers, and value_class other than "test"; no live merchant, card network, bank feed, billing system, or real charge is touched and no real consumer financial data enters any fixture
- Use of a measurement pack in a live chargeback, regulator complaint, or legal proceeding (SPEC §10.1 gate (b), evidence-language review, Docket-coordinated) and any integration that acts on a verdict automatically against a live charge — blocking/cancelling (gate (c), interference review) — are UNBUILT: no such verb exists on either surface, Faircharge never blocks, reverses, disputes, or alters any charge, contacts any merchant, or cancels anything; the measurement pack is Docket's deliverable and breach is Docket/counsel's question (§11.2 fence on every creep receipt + pack face)
- Marketing language asserting breach, overcharging as a legal conclusion, or merchant misconduct (SPEC §10.1 gate (d)) — fenced pre-counsel in README/manifest/receipts; never "catches merchants cheating", "proves overcharging", or "unauthorized charge detector"; also never claimed: live monitoring of any account, charge blocking/reversal, savings amounts, or that WITHIN_TERMS means a price is fair
- Production signing / Herald authority — Herald signing in v0.1.3 uses locally generated fixture keys (keys/, chmod 600, gitignored, never committed); verification reads keys/pinned-public.json only ({n,e} per role, Herald + caller publics) and key material in tool args or inside a pack is refused pre-verification. The fixture signing key holds no funds and authorizes no charge. A fresh clone generates its own fixture keys on first run to run the full suite
- Hosted or live operation — local stdio only; metering points only per SPEC §9 (exactly one Meter-grammar relationship-month record per sealed relationship non-terminal in that period, fixture clock in v0.1; measurements, creep receipts, status and exports emit no further metering, a creep finding is never a per-event charge per §11.4, CLOSED/BASELINE_DEFECT relationships emit none), the $5/mo shape is a book reference with no payment verb, invoice, collection mechanism, or charge path built and no live Meter ingest
Live state note: Bench evidence: argus101-program-20261027/wave2/bench-faircharge.md (Verity bench of v0.1.0, PASS-CONDITIONAL (local, fixture charge streams + sealed authorizations), conditions C0–C7, suite 18/18 re-run x2, F-FC8 decisive independent, spec-contradiction ruling on §2.2.2) + fix-faircharge.md / rebench-faircharge.md (v0.1.1) + fix2-faircharge.md / rebench2-faircharge.md (v0.1.2, D1–D6) + fix3-faircharge.md / rebench3-faircharge.md (v0.1.3: E1–E4 CLOSED, C0–C7 + D1–D6 hold, suite 44/44, 214/214 effective serialized checks, one new minor F1 hygiene note, non-blocking). Shipper suite re-run fresh pre-ship: 44/44 OK (x2, pre- and post-ship-prep). No test-bench scorecard was issued for this verdict and none is claimed (scorecard_ref/card_url null).
Pricing
PRICED — $5/mo, via the Eclipse Bazaar bench-order/intake path only. No checkout, payment, or buy-now link exists for this product, and no Stripe object exists for it in this pass: intake orders are reviewed and confirmed by the operator before any payment link is sent. Metering shape per SPEC §9 (metering points only in v0.1.3, no charge path built): exactly one Meter-grammar relationship-month record per sealed relationship that is non-terminal in that period (fixture clock) — individual measurements, creep receipts, status, and exports never meter, a creep finding is never a per-event charge (SPEC §11.4), and idempotent retries never double-meter. The local package is the reference implementation. Repository is PRIVATE (priced-product policy).
Install / verify
No install command is published for this product in the catalog or its registry record.
Official MCP Registry name: io.github.CYAN-ECLIPSE-TECHNOLOGIES-LLC/eclipse-faircharge-mcp
Registry listing: https://registry.modelcontextprotocol.io/v0.1/servers/io.github.CYAN-ECLIPSE-TECHNOLOGIES-LLC%2Feclipse-faircharge-mcp/versions/0.1.3
Repository: https://github.com/CYAN-ECLIPSE-TECHNOLOGIES-LLC/eclipse-faircharge-mcp
Verify any MCP server in your client configs against this catalog with bazaar check (Eclipse Bazaar MCP / CLI — see llms.txt).