# ArbSphere Toy MVP: Two-Venue Federated Cross-Exchange Arb

Overview
- A lightweight, privacy-preserving, two-venue MVP to demonstrate canonical ArbSphere primitives and federated coordination.
- Primitives used:
  - LocalArbProblem: per-venue task defining asset_pair, target_mispricing, liquidity budget, latency budget
  - SharedSignals: aggregated price deltas, cross-venue correlations, liquidity proxies, latency proxies
  - PlanDelta: incremental hedge actions with legs, sizes, and timing
  - DualVariables, PrivacyBudget, AuditLog: governance and provenance hooks for later phases

Canonical IR mapping
- EnergiBridge (vendor-agnostic IR) maps primitives to a stable, versioned IR that adapters can consume.
- Phase 0 MVP uses a minimal IR shape:
  - Object: LocalArbProblem
  - SharedSignals
  - PlanDelta (optional)

Two-venue MVP surface
- Data-feed adapter: streams quotes and order-book depth from venue A and B (toy data for MVP).
- Execution adapter: aggregates legs and routes orders across venues with per-order metadata.
- Lightweight ADMM-lite coordinator at the edge/regional node coordinates local tasks and shares only aggregated signals.

Data contracts seeds (seed artifacts)
- LocalArbProblem, SharedSignals, PlanDelta, DualVariables, PrivacyBudget, AuditLog, TimeRounds
- Graph-of-Contracts (GoC) registry for adapter metadata, versioning, and compatibility checks

MVP milestones (8–12 weeks)
- Phase 0: protocol skeleton + 2 adapters over TLS; deterministic delta-sync; toy cross-venue hedge.
- Phase 1: governance ledger scaffold; DID/short-lived certs; secure aggregation defaults.
- Phase 2: cross-domain demo in a simulated two-venue environment; ArbSphere SDK; reference transport.
- Phase 3: latency tests; KPI dashboards for convergence, delta-merge latency, and auditability.

Open questions
- Do we start with two venues using synthetic feeds, then scale to live pilots?
- What is the minimum EnergiBridge surface and per-message metadata needed for plug-and-play adapters?

Notes
- This document intentionally stays lightweight and extensible to avoid premature optimization.