
Eclipse Allowance
Sealed family budget mandates for household agents — category caps, merchant lists, and amounts are sealed by the account holder; every spend lands in a family ledger as a receipt the agent cannot edit. PASS-CONDITIONAL (local/simulator) — local stdio, fixture family mandates + fixture spends only, value_class "test"; no real money, no payment rail, counsel gate (§10) unbuilt. Ledger receipts are Herald-counter-signed; the household agent holds no ledger signing key.
status: in-developmentclass: mcpAgent Spend GovernanceTrust & Receipts
Vendor: Cyan Eclipse Technologies
What it does
- Novel mechanism (SPEC §2.1, verbatim) — category caps, merchant lists, and amounts are sealed by the account holder; every spend lands in a family ledger as a receipt the agent cannot edit.
- Decisive fixture F-A13 stands from the bench record — in a fresh process from the export alone, empty data dir, Verity-generated pinned keys: ALLOWANCE_VERIFY_PASS, spends_checked: 5 (regression spot, delta re-bench 2); the 99999 cap-breaching attempt is present only in the refusal log, never in the ledger; tampered entries fail verification by hash/chain/Herald counter-signature while the untampered chain verifies.
- Integrity (v0.1.2, R1–R7 closed at delta re-bench 2) — each mandate's ledger entries form their own hash chain under a per-mandate signed head anchor; metering is sealed per-mandate and store-wide, so wiping, fabricating, or subset-rolling metering is detected; offline verification fails closed on absent/invalid/unverifiable holder signatures (step 1, by name); seal inputs carry exact field sets (unknown keys refused by name, never echoed); serves are constructed from verified components; amendments must be timestamped after every existing record; malformed store shapes are named store defects on every entry path with zero raw exceptions and zero writes on mutation paths.
- Condition 1 — R8 — cross-mandate transplant id↔hash pairing is detected only indirectly (transplanted record never served/counted/exported); Tier-G structural check or README fence stands as the condition.
- Condition 2 — O1 — ledger_get VERIFIED slice-export vs downgraded faces on a Tier-G-defected store (documented slice semantics; no false data).
- Rollback fence (README Integrity model (v0.1.2), verbatim): Honesty fence — rollback residual: within this local file model, a rollback that restores *every* local artifact (mandates, ledger, refusals, revocations, all anchors, and metering) to one consistent earlier snapshot is undetectable; the per-mandate anchors and the sealed-metering cross-checks detect partial rollbacks, subset restores, and single-artifact tampering, not a complete coordinated snapshot restore. Detecting a full coordinated restore requires an external anchor outside the local store; an external anchor is required for any live or multi-party use and is not built in this local/simulator scope. No stronger claim is made.
- Key-fact label (SPEC §11.2, verbatim): ledger receipts are Herald-counter-signed; the household agent holds no ledger signing key. It is never shortened to "tamper-proof" or "immutable": the claim is specifically about the agent, and detection (§6.4 offline recomputation), not metaphysical impossibility. A refused spend is a check result — "refused at mandate check (simulator)" — not a protection outcome: enforcement of a refusal at an actual purchase step is the consuming platform's act, and a spend a platform never presents produces no refusal and no record.
- Downgrade law (SPEC §6.5) — an export that cannot be recomputed (chain, Herald counter-signatures, mandate seal) receives only a labelled UNVERIFIED_LEDGER_EXPORT (agent_editable: unknown, recomputable: false) on its face; no tool path removes a refusal, repairs a broken chain, re-signs an entry, or converts a refusal into a spend.
- Format attribution is exact and minimal: mandates are Till mandate objects carrying the Allowance profile (Till consumed, never redefined), counter-signing is Herald's pattern (fixture HMAC stand-in), and metering points are emitted in Meter grammar — consumed, never redefined. Eclipse Assay 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
mandate_seal · mandate_amend · mandate_revoke · ledger_get · ledger_verify · refusal_log_get · spend_present · mandate_status · spend_history_get
Platforms
- MCP over stdio
Certification
Bench verdict: PASS-CONDITIONAL (local/simulator)
Certified scope: PASS-CONDITIONAL (local/simulator) — Verity delta re-bench 2 of v0.1.2, 2026-10-27 (argus101-program-20261027/wave2/rebench2-allowance.md): R1–R7 all CLOSED on fresh repros (per-mandate chains + Tier-M/Tier-G isolation; sealed metering; fail-closed holder-signature verify; exact seal field sets; monotonic amendments; structured store-defect faces with zero raw exceptions; subset restores detected), R7 full-restore residual adjudicated as fenced (condition, not fail), regression spot PASS (F-A13 decisive fresh-process recompute; F8 §7.4 split key custody re-verified); builder suite 44/44 PASS x2 clean runs, independent probes ~110 checks. PASS-CONDITIONAL is not CERTIFIED — certified is false, and nothing beyond the conditional verdict at its exact scope is claimed. Scope is exactly: local/simulator only, fixture family mandates only (fixture holders, members, agents, merchants, categories and spends, value_class "test"), local stdio MCP (SPEC §0.1); no real money, no payment rail, no merchant, bank, or household account is connected in v0.1.2, and Allowance moves no money even in simulation — it checks and records fixture spends. Condition 1 (verbatim): R8 — cross-mandate transplant id↔hash pairing is detected only indirectly (transplanted record never served/counted/exported); Tier-G structural check or README fence stands as the condition. Bench condition text (verbatim): R8: add the id↔hash pairing to the structural/Tier-G check (an entry whose `mandate_id` and `mandate_hash` name different mandates defects the store on every path, incl. target-mandate spend), or fence the pairing class in the README integrity section. Condition 2 (verbatim): O1 — ledger_get VERIFIED slice-export vs downgraded faces on a Tier-G-defected store (documented slice semantics; no false data). Bench condition text (verbatim): O1: make `ledger_get` downgrade when Tier-G defect exists outside the served slice, or document the slice-only semantics on the export face.
Not tested:
- Cross-mandate record transplant, id↔hash pairing — CONDITION 1 (bench, verbatim): R8 — cross-mandate transplant id↔hash pairing is detected only indirectly (transplanted record never served/counted/exported); Tier-G structural check or README fence stands as the condition. Bench condition text (verbatim): R8: add the id↔hash pairing to the structural/Tier-G check (an entry whose `mandate_id` and `mandate_hash` name different mandates defects the store on every path, incl. target-mandate spend), or fence the pairing class in the README integrity section. The README fence stands in v0.1.2: the transplanted record is never served, counted, or exported as the target mandate's; the source mandate goes SEAL_DEFECT and the target mandate's history downgrades; the hash-also-switched variant is fully detected (SEAL_DEFECT, verify FAIL step 2).
- ledger_get slice semantics on a Tier-G-defected store — CONDITION 2 (bench, verbatim): O1 — ledger_get VERIFIED slice-export vs downgraded faces on a Tier-G-defected store (documented slice semantics; no false data). Bench condition text (verbatim): O1: make `ledger_get` downgrade when Tier-G defect exists outside the served slice, or document the slice-only semantics on the export face. The slice-only semantics are documented on the export face and in the README: the export attests only the clean per-mandate slice it serves, no false data is served, and status/history/refusal faces downgrade on the same store.
- Full coordinated restore of all local artifacts to a consistent earlier snapshot — Honesty fence — rollback residual: within this local file model, a rollback that restores *every* local artifact (mandates, ledger, refusals, revocations, all anchors, and metering) to one consistent earlier snapshot is undetectable; the per-mandate anchors and the sealed-metering cross-checks detect partial rollbacks, subset restores, and single-artifact tampering, not a complete coordinated snapshot restore. Detecting a full coordinated restore requires an external anchor outside the local store; an external anchor is required for any live or multi-party use and is not built in this local/simulator scope. No stronger claim is made.
- Counsel-gated phase (SPEC §10, named, unbuilt/unclaimed): any live household spend — real payment rails, real merchant presentment, mandates governing minors' actual purchases, custodial or stored-value anything, platform contracts making refusals financially effective — is out of v0.1, hard. The live phase is a separate post-gate, re-benched build: counsel review of consumer-finance / payments exposure, minors'-finance and consent questions (who may seal for whom), and the §11 label set first. No dormant rail path and no real-money shape exists in v0.1.2 — the startup fence refuses payment-rail / bank / card configuration, non-local endpoints, and agent-side ledger signer keys.
- Real money and real households — fixture mandates only: fixture holders, members, agents, merchants, categories, and spends under a deterministic seed + fixture clock; merchant/category refs name no real merchant or family, and every artifact carries value_class "test"
- Live Herald signing — v0.1.2 signing is a fixture HMAC stand-in for the Herald RS256 pattern, disclosed on the product's face; verification keys are pinned out-of-band in code — a presented record can never select its own verification key
- Production key custody — fixture keys live split per role in keys/ (keys/holder-key.json, keys/recorder-key.json, keys/herald-key.json, keys/holder-token.json; chmod 600, gitignored, never committed); an agent-surface process loads only the recorder and Herald role files and never loads holder key material or the holder token; a fresh clone must create its own per-role fixture key files to run the full suite
- Hosted or live operation / charge path — local stdio only; metering points only per SPEC §9.1 (mandate_active — one per ACTIVE mandate per fixture period; premium_mandate_active; spend_recorded / spend_refused counts, informational), no charge path is built, no payment is taken, and no live Meter ingest is claimed; downgraded exports and refused spends are not premium metering points
Live state note: Bench evidence: argus101-program-20261027/wave2/rebench2-allowance.md (Verity delta re-bench 2, suite 44/44 re-run by the bencher x2 clean runs, ~110 independent probe checks; F-A13 decisive fresh-process recompute verified in the regression spot). No test-bench scorecard was issued for this verdict and none is claimed (scorecard_ref/card_url null).
Pricing
FREE + $5/mo premium, 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. Price shape per SPEC §9.2 (FREE + $5/mo premium per the Argus-101 price shape; the price book governs): what premium includes beyond the free tier is a price-book / listing decision, not defined by the spec and never implied by a metering point. Metering points only — mandate_active (one per ACTIVE mandate per fixture period, the free-tier unit), premium_mandate_active (the $5/mo shape's unit), spend_recorded / spend_refused (counts, informational); downgraded exports and refused spends are not premium metering points. No charge path is built, no payment is taken, and no live Meter ingest is claimed. The local package is the reference implementation. Repository is PRIVATE.
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-allowance-mcp
Registry listing: https://registry.modelcontextprotocol.io/v0.1/servers/io.github.CYAN-ECLIPSE-TECHNOLOGIES-LLC%2Feclipse-allowance-mcp/versions/0.1.2
Repository: https://github.com/CYAN-ECLIPSE-TECHNOLOGIES-LLC/eclipse-allowance-mcp
Verify any MCP server in your client configs against this catalog with bazaar check (Eclipse Bazaar MCP / CLI — see llms.txt).