Vendor: Cyan Eclipse Technologies · Platforms: MCP over stdio
Certification scope
CERTIFIED (simulator, fixture records) — Verity re-bench of v0.1.1, 2026-10-27 (argus101-program-20261027/rebench-settleseal.md): all three blockers, both majors, and the minor from the v0.1.0 FAIL bench are fixed and independently re-proven — verify pins only the out-of-band key-store Herald key (attacker reseals and presented-key swaps all FAIL), the shipped v0.1.0 private key is burned and absent tree-wide outside keys/, and the run receipt is fully recomputed with run_id bound (rebind/window/leg tampers FAIL by named step). M1 two-leg taxonomy RATIFIED: SPEC §2.5 enum extended 8→11 with MISSING_PAYOUT / MISSING_RAIL / MISSING_LEDGER (present in exactly two legs, absent from the named leg), amendment logged in SPEC.md AMENDMENTS 2026-10-27. Builder suite 27/27 fresh process; F-S9 decisive test passed against a bench-written dataset and bench-written spec matcher (13 keys: 2 matched, 11 exceptions, 11 distinct classes) with fresh-process recompute SETTLE_VERIFY_PASS. Scope never exceeds simulator / fixture records: three-way reconciliation (mandate ledger vs rail settlement vs bank payout) over fixture records only; moves no money; no live rail/bank integration.
What it does
- Novel mechanism — rail-agnostic three-way match: mandate ledger vs rail settlement records (x402/MPP/card shapes) vs bank payout, with every unmatched item emitted as a sealed exception receipt a third party can recompute offline from the export + public keys alone (SPEC §2.1, verified verbatim via F-S9). The matcher operates on normalized records only; rail identity enters solely as a profile tag in normalization — no rail-specific branch exists in the matcher.
- Complete residue (L4) — nothing unmatched is a log line or a silent drop: matched + exceptioned keys = the full key union of the three legs. Exception taxonomy is 11 classes (SPEC §2.5 as amended 2026-10-27): LEDGER_ONLY / RAIL_ONLY / PAYOUT_ONLY for single-leg presence, MISSING_PAYOUT / MISSING_RAIL / MISSING_LEDGER for two-leg presence (absent from the named leg), AMOUNT_MISMATCH / FIELD_MISMATCH (field named) / FEE_MISMATCH / FEE_UNSTATED (fee never assumed zero) / DUPLICATE (never netted).
- Sealed, pinned verification — the run receipt binds the three leg head hashes, the matched set, and every exception receipt hash; settle_verify recomputes each leg chain, re-runs the deterministic match, and verifies each Herald seal against a key pinned out-of-band from the local key store — a presented public key is never trust material (v0.1.0 self-keyed verify blocker fixed and re-proven adversarially in the re-bench). Unverifiable exports are labelled UNVERIFIED_EXPORT with no outcome claim and are never upgraded post-hoc.
- Honest scope — SIMULATOR, fixture records only: fixture mandate-ledger entries, fixture rail settlement records (x402/MPP/card shapes), and fixture bank-payout records. Settleseal moves no money, initiates no payout, corrects no ledger, and instructs no rail; no live rail connection, bank connection, or production ledger is touched, read, or designed around. Live rail/bank connections are a named counsel-gated phase (SPEC §10), not built. Disjoint surfaces: desk = exactly 7 tools, auditor = exactly 3 (read/verify only); there is deliberately no resolve-exception, manual-match, tolerance, delete-exception, payout, or ledger-correction verb.
Tools
settle_run_opensettle_leg_ingestsettle_leg_sealsettle_matchsettle_exception_listsettle_run_receipt_getsettle_exception_acksettle_export_getsettle_verifysettle_exception_get
Problems it addresses
- My desk settles across x402, MPP, and card rails at once and reconciles by spreadsheet and sampling — I need the full three-way match (mandate ledger vs rail records vs bank payout) performed neutrally, with the residue sealed as evidence
- A settlement was paid but never appears in my ledger — or a payout moved with no mandate behind it — and I need that discrepancy as a sealed exception receipt a third party can recompute, not a count in a report
- Two of my three legs agree and I cannot tell whether the third disagrees — I need per-key exception classes that name exactly which leg is missing or which field/amount/fee diverged
Evaluation-intake listing
This listing records the tool's place in the Bazaar's evaluation
and monitoring pipeline, with the evidence gathered so far printed above — verdict, scope,
and not-tested items included. It is not sold on this site, and its presence in the catalog
is not a claim beyond that evidence. The service behind every verdict is the bench:
what a bench run buys →