
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
- 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.
- Seal → single-bound proof → recomputable certificate — the cap is committed as a Pedersen-style commitment (C = g^c · h^r mod p over the pinned RFC 3526 §3 2048-bit safe-prime fixture group); the prover shows d = c − s ∈ [0, 2^k) by bit decomposition (Schnorr OR-proof per bit + homomorphic-sum / difference-linkage proof, Fiat–Shamir challenges recomputable from the canonical transcript); on a full §6.4 recompute pass Capline issues a certificate binding commitment ↔ stated spend ↔ verdict ↔ proof hash. The mathematics is prior art and is credited as such; the claim is the composition only. Construction label on every certificate face: pedersen-commitment + bit-decomposition range proof, fixture parameters, unaudited.
- Decisive fixture F-C14 — bench re-derived (bench-capline.md §1 + rebench-capline.md §5): in a fresh verifier process with an empty data dir and no prover-private file, from the seal record + stated spend + proof + bencher-pinned keys alone, proof_present issued a certificate and certificate_verify returned verified: true, verdict: "within_cap"; the bencher's own independent §6.4 implementation recomputed the same pack to within_cap; the commitment opens under bencher math only at the true cap (brute-force sweep ±1,000 around the true cap, hits == [true cap] only, at bench cap 12,345 / spend 9,876, k=14 and again at re-bench cap 54,321 / spend 43,210, k=16); a structural scan of seal+proof+certificate found no field equalling or encoding the cap, d, or the blinding factor — the merchant learns the bound and nothing else the artifacts carry. Negative-wrap forgery (spend = cap+1, forger given the true cap and blinding factor) still fails at step 5 linkage (PROOF_LINKAGE_INVALID), with 0 metering.
- Two §11.4 disclosures, verbatim (on every certificate face, in server.legacy.json, and here): 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). The verdict-oracle leak is exactly one bit per query — the bencher recovered the cap by binary search through proof_build in exactly 14 queries over the 2^14 range, no more; over-cap refusal payloads are byte-identical and carry no distance-from-cap signal.
- Honest scope — LOCAL stdio, fixture policies + fixture spends ONLY, fixture unaudited group parameters, no live merchant, no real policy proven, value_class "test" on every artifact: Capline proves one integer bound only; it attests nothing about policy category rules, merchant legitimacy, funds availability, mandate validity, or whether the spend should occur, and it moves no money. Closed surface of exactly 11 tools (4 prover + 4 verifier + 3 operator, disjoint); no verb reveals the cap, the policy, a blinding factor, or a d bit in the clear, raises a committed cap, re-opens a void seal, or issues a certificate without a §6.4 pass. Startup is fail-closed (CONFIG_FENCE_REFUSED:<class>) on any non-pinned group-params file, network endpoint, live key, real-policy source, payment configuration, or value_class other than 'test' — the §10 two-key gate is genuinely unbuilt (fence battery 9/9) and no dormant live path exists. Signing is an HMAC fixture stand-in for Herald RS256 (disclosed). Conditions C1/C2/C3/C5 are listed verbatim in the certification block.
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
- MCP over stdio
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).