Cyan Eclipse Capline

Vendor: Cyan Eclipse Technologies · Platforms: MCP over stdio

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

Problems it addresses

• Caps are negotiating intelligence: a merchant who learns an agent's spend cap can price to it, and a policy that circulates cannot be uncirculated — yet a merchant who gets no cap assurance at all must either refuse agent spend or accept unbounded-looking risk
• I need the single bound proven without disclosure: the agent proves 'this spend is within my cap' against a previously sealed commitment, revealing neither the cap nor any policy field, in a form the merchant can recompute offline from the seal record + stated spend + proof + pinned keys alone
• I need the proof kept honest on its face: the stated spend is public, each verdict leaks exactly one ordering bit about the cap (and no more), unverifiable material downgrades to an unsigned UNVERIFIED_PROOF_EXPORT with certified: false instead of being upgraded, and no certificate exists without a full §6.4 recompute pass

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)