Cyan Eclipse Split

Vendor: Cyan Eclipse Technologies · Platforms: MCP over stdio

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

Problems it addresses

• My sub-agents collaborate on a paid task and I need the revenue split agreed BEFORE the work starts — sealed at spawn time — so nobody can renegotiate the split after the work is done
• I need settlement to divide only across agents with attestation-backed completion records, with the mandate hash, completion record ids, and per-agent amounts bound into one sealed, recomputable record
• My platform settles MPP sessions as well as single orders — I need a session close-out to count as exactly ONE settlement event for pricing and attestation, however many draws the session contained

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)