Eclipse Split
Pre-agreed revenue splits for multi-agent tasks: split weights are sealed into the delegation mandate at spawn time and settled against attestation-backed completion records — the split cannot be renegotiated after work is done. LOCAL/fixture scope only — allocation math and sealed records only, no money movement, no payment rails, wallets, or payouts; fixture completion records with unkeyed SHA-256 demo seals (keyed seal required before any non-fixture use). A settlement event is a per-order settlement OR an MPP session close-out — the accumulated session settles as ONE settlement event (SPEC Amendment #1).
status: in-developmentclass: mcpTrust & ReceiptsAgent Payments
Vendor: Cyan Eclipse Technologies
What it does
- Novel mechanism — split weights are sealed into the delegation mandate at spawn time and settled against attestation-backed completion records; the split cannot be renegotiated after the work is done (SPEC §3): create_mandate seals {task_ref, delegator, participants[{agent_id, weight}], spawn_ts} under a SHA-256 hash at spawn time; amend_weights always refuses MANDATE_SEALED, and the only change path is supersede_mandate — a new sealed mandate naming the old one — and only before any completion exists. record_completion chains each completion record to the mandate hash (only mandate participants can complete); settle allocates only across participants with valid completion records, binding {mandate_hash, completion_record_ids, per-agent amounts} into one sealed settlement record; verify_settlement recomputes everything from the mandate + completions — any tamper → INVALID. Bench: allocations + hashes independently recomputed from SPEC §6/§8 (builder code never imported for expected results); partial-completion renormalization per the documented §6 rule (weights 0.5/0.3/0.2, A+B complete, total 100 → 63/37); rounding 100 over 3 equal weights → 34/33/33 byte-exact.
- Amendment #1 settlement event (v0.1.2, delta-bench 94/94, 0 defects): a settlement event is exactly one of (a) a per-order settlement, or (b) an MPP session close-out — a settle that closes out an MPP session and settles the accumulated session total as ONE settlement event for pricing and attestation, regardless of how many draws the session contained (tested at draw_count 4117 → exactly one settlement record). settle carries optional event_type (order default / session_closeout); a close-out requires session_id, draw_count (true integer ≥ 1), and draw_attestation_ref, each refusal a clean typed error (INVALID_SESSION_ID / INVALID_DRAW_COUNT / INVALID_DRAW_ATTESTATION_REF / INVALID_EVENT_TYPE; 36 validation cases pass, no settlement written, process alive). settlement_event is sealed hash-covered content — tampering with any event field → INVALID, including fully re-hashed malformed event data (18/18). Idempotence is absolute: the first settlement event wins and a repeat settle returns the first sealed record verbatim regardless of repeat total or event arguments. Legacy v0.1.1 records without settlement_event remain verifiable as order events; verify fabricates nothing.
- Bench-fix round D1–D4 (v0.1.1, re-bench 35/35): D1 crash-proofing — dispatch type-guards + structural validation of supplied mandate/settlement objects before any field use, 59 wrong-type fuzz cases + 9 protocol fuzz cases all clean errors, process alive; D2 producibility — verify enforces that a settlement is producible from sealed weights + recorded completion set + total (crafted zero-completion / non-completer / off-by-one records → INVALID; genuine → VALID); D3 double-settle idempotence regardless of the total passed on the repeat call; D4 superseded mandates still recompute to their own hash (mutable lifecycle fields status/superseded_by excluded from hash-covered content; weights remain hash-covered). Prior verdict on v0.1 (VERDICT.md): CONDITIONAL (local, fixture) 65/69 — all four defects closed at v0.1.1.
- Honest scope — LOCAL/fixture ONLY: allocation math + sealed records only. NO money movement, no payment rails, no wallets, no payouts — v0.1.2 computes who would get what and seals the record; execution of any payment is out of scope (a later phase, gated on counsel + payments review). Attestations are fixture completion records with unkeyed SHA-256 demo seals, labelled 'SHA256 hash seal (demo, local only)' on every record — no production attestation, identity, or non-repudiation claim. DISCLOSED fix-before-live: a keyed seal (HMAC / signature) anchoring settlements to a stored, keyed record is required before any non-fixture use, together with verified attestations replacing caller-asserted fixture seals and a settle gate (in fixture scope any caller may settle the moment ≥1 completion exists, and double-settle idempotence makes that eligible set permanent). Amounts are integer minor units; no currency conversion, no floating-point money; exactly 6 tools; MCP over stdio; Python 3 standard library only. Pricing is a commercial term only — no payment, checkout, or MPP network code exists in this build; 'MPP' occurrences are the Amendment #1 settlement-event definition and explicit negations.
Tools
create_mandate · record_completion · settle · verify_settlement · amend_weights · supersede_mandate
Platforms
- MCP over stdio
Certification
Bench verdict: CERTIFIED (local, fixture)
Certified scope: CERTIFIED (local, fixture) — Verity: v0.1.1 independent re-bench 35/35 PASS, 0 FAIL (REBENCH-1 of the v0.1.1 Bench Fix D1–D4 round, repo @ e213490) plus v0.1.2 Amendment #1 scoped delta-bench 94/94 PASS, 0 FAIL (repo @ 1daf662) — the CERTIFIED (local, fixture) verdict carries to v0.1.2. Delta-bench: order event default + explicit identical (partial-completion allocations 63/37 over 100 per §6 independent recompute; settlement hash recomputes with settlement_event as hash-covered sealed content; genuine order verifies VALID via stored and supplied paths); session close-out seals settlement_event {type: session_closeout, session_id, draw_count, draw_attestation_ref} exactly as specified, draw_count 4117 → exactly ONE settlement record/event, accumulated total 250 allocated exactly; required-field validation 36/36 clean typed refusals with no settlement written and a valid settle succeeding afterward; hash/producibility on event data — tamper without rehash INVALID 5/5, malformed settlement_event with fully consistent rehash INVALID 18/18, never a crash; idempotence absolute in both orders (first sealed record returned verbatim, incl. garbage repeat arguments — judged consistent with the amended spec's verbatim wording); legacy v0.1.1 compatibility — supplied and stored-path legacy records without settlement_event verify VALID as order events, stored record byte-identical afterwards (verify fabricates nothing); process safety — wrong-type + protocol fuzz all clean errors, process alive, happy path works afterward; version metadata — initialize serverInfo 0.1.2, server.json 0.1.2, exactly six tools, settle schema documents session_closeout as ONE event. Re-bench v0.1.1: D1 CLOSED (4 original death vectors → clean errors, alive, incl. fresh-process re-runs; 59 wrong-type fuzz + 9 protocol fuzz cases clean; raw NaN/Infinity weights refused; garbage non-JSON line survived; happy path works after the full battery in the same process); D2 CLOSED (crafted zero-completion/total-0/empty-allocations record, non-completer allocation, and off-by-one allocations, each with consistent re-hash → INVALID; genuine settlement VALID via stored and supplied paths); D3 CLOSED (repeat settle with total 0, a different total 999, or a string total all return the SAME sealed record); D4 CLOSED (superseded mandate recomputes clean to its own mandate_hash under independent recompute excluding lifecycle fields; weights remain hash-covered). Regression spot-checks PASS: rounding 100/3 equal → 34/33/33 byte-exact; partial-completion renormalization 63/37 per §6; amend_weights → MANDATE_SEALED. Prior verdict on v0.1.0 (VERDICT.md): CONDITIONAL (local, fixture), 65/69 — defects D1–D4, all closed at v0.1.1. Scope = LOCAL/fixture only: allocation math + sealed records only — no money movement, no payment rails/wallets/payouts; fixture completion records with unkeyed SHA-256 demo seals (fix-before-live: keyed seal required before any non-fixture use); partial-completion renormalization is the documented §6 rule; the $1.00/settlement-event figure is a commercial term only — no payment/checkout/MPP network code exists in the build.
Not tested:
- Any money movement, payment rails, wallets, payouts, checkout, or MPP network/session code — none exists in v0.1.2 by design (SPEC §2/§7): allocation math + sealed records only; the Amendment #1 session close-out is a settlement-event definition over local records, not a live MPP integration
- Production attestation, identity verification, or non-repudiation — fixture completion records with unkeyed SHA-256 demo seals only; DISCLOSED fix-before-live: a keyed seal (HMAC/signature) is required before any non-fixture use
- A settle gate for non-fixture use — in fixture scope any caller may settle once ≥1 completion exists and idempotence makes that eligible set permanent; delegator-only settle / all-participants-recorded / settle window required before any non-fixture claim (SPEC v0.1.1 addendum)
- Hosted or remote deployment, multi-currency / FX, and dispute resolution — none exists in v0.1.2 by design (SPEC §7 non-goals)
Live state note: Bench evidence: argus-batch-20261026/bench/split/VERDICT.md + REBENCH-1.md + DELTA-BENCH-AMENDMENT-1.md (Verity, independent benches over stdio JSON-RPC only, allocations + hashes recomputed from SPEC §6/§8, builder code never imported for expected results; builder suite 60/60 at v0.1.2). This bench issued no test-bench/results scorecard; scorecard_ref is null and no scorecard is claimed or hosted for this product.
Pricing
PRICED — $1.00 per settlement event (Amendment #1: a settlement event is a per-order settlement OR an MPP session close-out — the close-out settles the accumulated session as ONE event, however many draws it contained), via the Eclipse Bazaar bench-order path only. No checkout, payment, or buy-now link exists for this product: v0.1.2 is LOCAL/fixture allocation math + sealed records only and contains no money-movement, payment, checkout, wallet, payout, or MPP network code (the price is a stated commercial term only). Repository is PRIVATE (priced-product policy).
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-split-mcp
Registry listing: https://registry.modelcontextprotocol.io/v0.1/servers/io.github.CYAN-ECLIPSE-TECHNOLOGIES-LLC%2Feclipse-split-mcp/versions/0.1.2
Verify any MCP server in your client configs against this catalog with bazaar check (Eclipse Bazaar MCP / CLI — see llms.txt).