Eclipse Bazaar · products.json · verdicts.json · llms.txt

Eclipse Capline

Sealed-policy cap bound proofs over fixture policies — a range proof over a sealed internal policy: the agent proves 'this spend is within my cap' to a merchant without revealing the cap or the policy. PASS-CONDITIONAL(local) — fixture policies/spends + fixture unaudited group parameters only, value_class "test"; no live merchant, no real policy proven. verdict-oracle disclosure: each verdict reveals one bit of ordering information about the sealed cap (whether the stated spend is above or below it); repeated proofs against one commitment narrow the cap by binary search (spec 2.3(c)). stated-spend disclosure: the stated spend is public to the verifier (it is the merchant's own price) (spec 11.4).

status: in-developmentclass: mcpAgent PaymentsTrust & Receipts

Vendor: Cyan Eclipse Technologies

What it does

Tools

capline_policy_seal · capline_proof_build · capline_proof_status · capline_seal_revoke · capline_proof_present · capline_certificate_verify · capline_verifier_counter_sign · capline_certificate_get · capline_seal_list · capline_dispute_pack_get · capline_anomaly_queue_read

Platforms

Certification

Bench verdict: PASS-CONDITIONAL(local)

Certified scope: PASS-CONDITIONAL(local) — Verity bench of v0.1.0 (2026-10-27, argus101-program-20261027/wave3/bench-capline.md) + delta re-bench (argus101-program-20261027/wave3/rebench-capline.md, 45/45 checks PASS: D1 CLOSED, D2 CLOSED, D3 CLOSED, D4 accepted as documented deviation (not a defect), C4 DISCHARGED): builder suite 31/31 re-run clean by bencher at re-bench (27 original + 4 D1/D2/D3 regressions); decisive fixture F-C14 independently re-derived at bench and re-bench (see capabilities). PASS-CONDITIONAL is not CERTIFIED — certified is false. Scope is exactly: local stdio, fixture policies/spends, fixture unaudited group parameters, no live merchant, no real policy proven, value_class 'test'. Conditions (verbatim-listable): C1 §10 two-key gate — counsel clearance via FinTech Law packet AND independent crypto audit, both required, no dormant live path: live phases (real enterprise policy/cap, merchant-facing reliance, production parameters/audited cryptosystem, privacy/compliance marketing claims) require BOTH (i) counsel clearance through the existing FinTech Law packet AND (ii) an independent cryptographic audit of the §2.2 construction and this implementation; neither substitutes for the other. C2 cross-artifact cross-commitment fenced — external anchor required before live/multi-party use: full coordinated cross-artifact rollback requires an external anchor before live/multi-party use; v0.1 state is single-process local, anchored only by its signed store head + hash chains (re-bench §1 demonstrated a whole-store rollback to an earlier self-consistent snapshot is accepted locally — exactly this fenced condition). C3 deterministic fixture-seed prover randomness must be replaced/audited before any live phase: deterministic fixture-seed-derived prover randomness must be replaced by a CSPRNG (or an audited deterministic derivation under production key custody) before any live phase — seed compromise recomputes every nonce and blinding factor, including the cap. C5 "Capline" trademark screen still pending: trademark screen on the name "Capline" is still pending; the name remains a placeholder. Both §11.4 disclosures, verbatim: verdict-oracle disclosure: each verdict reveals one bit of ordering information about the sealed cap (whether the stated spend is above or below it); repeated proofs against one commitment narrow the cap by binary search (spec 2.3(c)). stated-spend disclosure: the stated spend is public to the verifier (it is the merchant's own price) (spec 11.4). Novel mechanism (SPEC §2.1, verbatim): a range proof over a sealed internal policy — the agent proves 'this spend is within my cap' to a merchant without revealing the cap or the policy. Signing is an HMAC fixture stand-in for Herald RS256 (HMAC Herald stand-in, disclosed on every artifact face as signature_scheme); a live phase would need real Herald signing and a re-bench.

Not tested:

  • C1 — §10 two-key gate (verbatim): live phases (real enterprise policy/cap, merchant-facing reliance, production parameters/audited cryptosystem, privacy/compliance marketing claims) require BOTH (i) counsel clearance through the existing FinTech Law packet AND (ii) an independent cryptographic audit of the §2.2 construction and this implementation. Neither substitutes for the other. No dormant live path exists in v0.1 (fence-verified): no real policy, real cap, real merchant, network call, or live key exists in the tree, and the startup fence refuses such configuration by name (CONFIG_FENCE_REFUSED:<class>)
  • C2 — cross-artifact cross-commitment fenced (verbatim): external anchor required before live/multi-party use. Full coordinated cross-artifact rollback requires an external anchor before live/multi-party use; v0.1 state is single-process local, anchored only by its signed store head + hash chains. Re-bench demonstrated the one undetected mutation class: replacing the whole store with an earlier self-consistent snapshot is accepted locally — a rolled-back head is indistinguishable from a current one without an external reference
  • C3 — deterministic fixture-seed prover randomness (verbatim): deterministic fixture-seed-derived prover randomness must be replaced by a CSPRNG (or an audited deterministic derivation under production key custody) before any live phase. At fixture scope the bencher rated this LOW (168/168 nonce commitments distinct across 6 proofs, zero reusable pairs / zero extractions); whoever obtains the prover seed can recompute all nonces and blindings, including cap recovery, and determinism makes repeat spends linkable by transcript_hash equality
  • C5 — "Capline" trademark screen still pending (verbatim): trademark screen on the name "Capline" is still pending; the name remains a placeholder
  • D4 deviation (documented, bench-accepted, not a defect): F-C9 step attribution — failures name step 1/step 3 where the checks actually fire (seal-only commitment swap fails at step 1 proof_seal_consistency; both-fields swap fails at step 3 challenge_mismatch), while SPEC §8 F-C9 names step 5; the commitment is an input to the step-1 consistency check and the Fiat–Shamir transcript recomputed at step 3, so a swapped commitment necessarily fails those earlier, normatively-ordered checks first. Outcome is identical (named refusal, no certificate, no state). Spec-owner amendment recommended (re-bench ruling): amend F-C9 to read step 1 (proof_seal_consistency, seal-only swap) / step 3 (challenge_mismatch, both-fields swap); no code change required or wanted
  • D5 ruling (bench-accepted): over-cap proof_build → PROOF_MALFORMED — §5.4 contains no build-side over-cap code; the amount is well-formed (so AMOUNT_INVALID would be wrong), the refusal is named, its detail is accurate, and it changes no state and stores no proof. Least-wrong reading, ruled acceptable in the bench; a spec amendment to §5.4 (annotate the build-side use) is recommended rather than a code change
  • HMAC Herald stand-in: production signing is not tested — v0.1.0 signing is an HMAC fixture stand-in for Herald RS256 (HMAC Herald stand-in), disclosed on every artifact face as signature_scheme; 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
  • proof_id/merchant_class/built_at not transcript-bound (bench observation O1, §10 audit note): proof_id, merchant_class, and built_at are not transcript-bound — proof_id is a label; transcript_hash is the cryptographic binding and is enforced at §6.4 step 6 (certificate_binding). A relabelled valid proof can therefore take a foreign proof_id onto a fresh store; all value-bearing fields are bound. Noted for the §10 audit
  • Verdict-oracle + stated-spend honesty (§11.4, verbatim): verdict-oracle disclosure: each verdict reveals one bit of ordering information about the sealed cap (whether the stated spend is above or below it); repeated proofs against one commitment narrow the cap by binary search (spec 2.3(c)). stated-spend disclosure: the stated spend is public to the verifier (it is the merchant's own price) (spec 11.4). A certificate attests one proposition only — this stated spend is ≤ the cap committed in this sealed policy, as of proof time; it attests nothing about policy category rules, merchant legitimacy, funds availability, mandate validity, or whether the spend should occur. Never claimed for v0.1.0 are unqualified 'zero-knowledge', 'proves policy compliance', 'production-grade cryptography', 'private by design', or any 'audited' claim (SPEC §11.3 strings named here only as never claimed; only 'unaudited' / 'not an audited cryptosystem' appear)
  • Production key + prover-private custody — fixture keys live in keys/fixture-keys.json and fixture caps/blinding factors live only in the gitignored fixtures/prover-private.json (both chmod 600, 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 point per certificate issuance, unit certificate; 0 for refusals, verifications, exports, and idempotent re-presentations; no charge path built, no payment taken, no live Meter ingest claimed)

Live state note: Bench evidence: argus101-program-20261027/wave3/bench-capline.md (Verity bench of v0.1.0, 2026-10-27; builder suite 27/27 re-run by bencher, bencher harness 125 checks / 121 pass with the 4 non-passes resolving to D2/D3 + two probe artifacts; F-C14 decisive PASS; forgery battery all failing at named verify steps) + argus101-program-20261027/wave3/rebench-capline.md (delta re-bench, harness 45/45 PASS: D1 CLOSED — signed store head binding record_count/per-class counts/SET anchors, deletion+insertion probes 12/12 fail with STORE_INTEGRITY_FAIL:store_head_record_count; D2 CLOSED — both §11.4 disclosures byte-present in the manifest and identical to the issued-certificate face strings; D3 CLOSED — both disclosures verbatim on the UNVERIFIED_PROOF_EXPORT face on both paths; D4 accepted as documented deviation; builder suite re-run 31/31; F-C14 + negative-wrap spot checks PASS; metering exactly 1 per issuance). No test-bench scorecard was issued for this verdict and none is claimed (scorecard_ref/card_url null).

Pricing

PRICED — $1/certificate, 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 honesty per SPEC §9 (metering point only in v0.1.0, no charge path built): exactly 1 metering point per certificate issuance (count 1, unit certificate); 0 for proof builds, refusals, verifications, exports, transcripts, and idempotent re-presentations. The local package is the reference implementation. Repository is PRIVATE (priced tier).

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-capline-mcp

Registry listing: https://registry.modelcontextprotocol.io/v0.1/servers/io.github.CYAN-ECLIPSE-TECHNOLOGIES-LLC%2Feclipse-capline-mcp/versions/0.1.0

Repository: https://github.com/CYAN-ECLIPSE-TECHNOLOGIES-LLC/eclipse-capline-mcp

Verify any MCP server in your client configs against this catalog with bazaar check (Eclipse Bazaar MCP / CLI — see llms.txt).