diff --git a/MRC91-PLACEHOLDER.md b/MRC91-PLACEHOLDER.md new file mode 100644 index 0000000..7fddbe8 --- /dev/null +++ b/MRC91-PLACEHOLDER.md @@ -0,0 +1,119 @@ +# MRC 91: Token Native Docker Compute + +- **Author:** Robert Christian (@robertjchristian) +- **Category:** Runtime Infrastructure / Router Extension +- **Status:** Discussion +- **Discussion:** + +--- + +## Abstract + +This proposal defines a Router-integrated runtime layer that enables Morpheus subnets to execute Docker and OCI workloads using MOR-denominated resources. Execution capacity derives from stake via Morpheus Compute Units (MCUs), which convert to Morpheus Execution Units (MEUs) at runtime: temporary, non-tokenized ledger entries tracked by the Router. + +MEUs are epoch-scoped and expire at epoch boundaries, functioning as reserved capacity guarantees rather than transferable credits. This "use it or lose it" model ensures provider headroom for burst demand, prevents capacity hoarding, and maintains predictable availability (similar to GCP committed use or AWS reserved instances, but trustlessly coordinated through the Router). Unused MEUs reset daily, allowing stakers to right-size their reservations while enabling compute lending markets (MRC-48) for dynamic capacity allocation. + +By treating stake as capacity reservation rather than speculative credit, subnets operate fully within MOR's trust and coordination boundary while remaining modular and provider-agnostic. MOR becomes infrastructure: not just a governance token, but the economic substrate for reserved, verifiable, on-chain compute capacity. + +--- + +## Motivation + +Subnets require a secure and accountable way to run general-purpose compute (APIs, web services, schedulers, data pipelines) without leaving the MOR economy. External infrastructure fragments settlement, weakens token alignment, and prevents unified accounting across inference and execution workloads. Providing a Router-managed runtime closes the operational loop: stake → execution → settlement → burn. + +--- + +## Specification + +**Extend the Router to support Docker/OCI workloads priced via MEUs:** + +- **MCU → MEU conversion:** Stakers earn MCUs (1 MCU = 1 MOR staked per epoch). At session start, MCUs convert 1:1 to MEUs, which are consumed by runtime execution. +- **Epoch-scoped accounting:** MEUs expire at epoch boundaries (default: 24h). Unused MEUs do not roll over unless governance enables auto-renewal. +- **Provider adapters:** Minimal interface (provision, start, stop, meter, attest) enables decentralized backends (Akash, Flux, Edge). +- **Capability profiles:** + - `d.strict` - deterministic execution (pinned images, m-of-n validation) + - `t1.confidential` - TEE attestation (SGX, SEV-SNP, TDX) +- **Resource classes:** Governance-defined CPU/GPU/RAM/IO tiers (e.g., c1.small, g1.small). +- **Privacy by design:** Router records only metadata (service handle, duration, provider ID) with no payloads. + +--- + +## Economic Flow + +1. Subnet stakes MOR → earns MCUs +2. Session initiates → MCUs convert to MEUs +3. Runtime burns MEUs per resource-hour +4. Provider receives MOR escrow on verified completion +5. Burn reduces supply; staking increases demand + +--- + +## Governance Parameters + +- `EPOCH_LENGTH` - Default: 86400s (24h); tunable for testnets +- `ROLLOVER_POLICY` - Auto-terminate vs. auto-renew across epochs +- `MIN_PROVIDER_BOND` - MOR bond required for provider participation +- `BURN_RATE_CURVE` - MEU cost per resource class (initially fixed, transitions to dynamic pricing based on utilization) + +--- + +## Dependencies + +- **MRC 54:** MCU framework (staking entitlement) +- **MRC 25:** Router contracts (session and settlement) +- **MRC 59:** Subnet namespace (service naming) +- **MRC 48:** Compute lending (delegation and borrowing) + +--- + +## Risks & Mitigations + +| Risk | Mitigation | +|------|-----------| +| Provider centralization | Adapter interface enables permissionless provider addition | +| Long-running sessions | Auto-terminate T-5min before epoch boundary with prorated refunds | +| Provider failure | Bond requirement + slashing for non-performance | +| MEU price discovery | Phase 1: fixed rates; Phase 2: dynamic pricing via Router telemetry | + +--- + +## Open Questions + +1. Should cross-epoch sessions auto-rollover (opt-in) or always terminate? +2. Refund policy for interrupted sessions (full, partial, none)? +3. MEU attestation standard for confidential workloads? +4. Cross-subnet composability and shared state semantics? + +--- + +## Summary + +MRC 91 converts staking entitlement into execution capacity, grounding general-purpose compute inside the Router. It extends MOR's economic model from inference to full application stacks, enabling subnets to run APIs, schedulers, and data jobs with unified on-chain accounting. + +**Autonomy through protocol.** + +--- + +## Compatibility + +This proposal extends MRC-25 (Router) without replacing existing functionality. MEU accounting, adapter interfaces, and namespace resolution are additive modules. Any modifications to Router contracts should be proposed via focused MRC-25 amendments. + +--- + +**Non-normative.** Reference implementations may be contributed by community maintainers; details live in the runtime/registry repos. + +--- + +## Metadata + +```yaml +id: MRC91 +title: Token Native Docker Compute +authors: ["Robert Christian (@robertjchristian)"] +category: "Runtime Infrastructure" +summary: "Router-integrated runtime layer converting MCU stake to MEU execution capacity for general-purpose Docker/OCI workloads." +status: "Discussion" +discussion_url: "https://discord.gg/morpheusai" +contact: "@robertjchristian" +keywords: ["docker","oci","runtime","router","subnet","mcu","meu","mrc25","mrc48","mrc54","mrc59"] +``` diff --git a/MRC92-PLACEHOLDER.md b/MRC92-PLACEHOLDER.md new file mode 100644 index 0000000..29ef476 --- /dev/null +++ b/MRC92-PLACEHOLDER.md @@ -0,0 +1,140 @@ +# MRC 92: Subnet Service Registry + +- **Author:** Robert Christian (@robertjchristian) +- **Category:** Service Registry / Router Integration +- **Status:** Discussion +- **Discussion:** + +--- + +## Abstract + +This proposal defines a canonical on-chain registry for services hosted by Morpheus subnets. The registry provides standardized discovery, pricing, and access for APIs and runtimes hosted through the compute framework introduced in MRC 91. It establishes the bridge between subnet-deployed services and Morpheus Core (MCP, Router, Agents), enabling community-built APIs to integrate with consistent accounting, provenance, and governance. + +--- + +## Motivation + +Subnets can host workloads via MRC 91, but without a shared registry, integration into MCP tooling and Morpheus Core processes remains manual and fragmented. There is no standardized way to discover, price, monetize, or govern subnet-hosted services, limiting composability and network effects. A canonical registry transforms isolated services into composable network primitives. + +--- + +## Specification + +**Create an on-chain registry with standardized schema for subnet services:** + +- **Core schema:** service_id, namespace (MRC-59), version, spec_type (MCP/OpenAPI/A2A), endpoint, pricing_model, payment_address +- **Pricing models:** fixed, subscription, metered (denominated in MOR, MCU, or MEU) +- **Access control:** public, allowlist, token-gated (ERC-20/721/1155) +- **Reputation scoring:** Router-verified telemetry (uptime, latency, success rate, session volume) +- **Network Programs (RFPs):** Governance or core teams publish RFPs with objective acceptance criteria; providers submit services; Router canary tests validate; escrow releases on SLA achievement +- **Revenue splits:** `beneficiaries` array enables protocol-level royalty distribution + +--- + +## Economic Flow + +1. Subnet registers service → stakes MOR (anti-spam) +2. Service listed in registry → discoverable via MCP/Router +3. Usage metered via Router → MEU burn or MOR payment +4. Router telemetry updates reputation score +5. Revenue settles via escrow → split per `beneficiaries` + +--- + +## Governance Parameters + +- **Registration stake:** Tiered by service type (public: 100 MOR, allowlist: 50 MOR, subnet-internal: 10 MOR) +- **Rate limits:** Default 50 registrations per namespace per epoch (tunable) +- **Reputation thresholds:** MCP visibility tiers (score < 200: hidden, 200-600: "New", > 600: "Verified") +- **Slashing conditions:** False metadata, malicious endpoints, persistent downtime +- **Schema versioning:** `schema_version` field; registrars reject unknown major versions + +--- + +## Dependencies + +- **MRC 91:** Runtime execution layer (service hosting) +- **MRC 58:** Agent Registry (schema alignment for spec_type) +- **MRC 59:** Subnet Namespace (naming and resolution) +- **MRC 25:** Router (telemetry and settlement) +- **MRC 54:** MCU accounting (metered pricing) + +--- + +## Network Programs (RFPs) + +Governance or Core teams may publish RFPs specifying: +- Required spec_type (MCP/OpenAPI/A2A) +- Capability requirements (TEE, determinism, GPU) +- SLA targets (uptime %, p95 latency, error rate) +- Funding escrow and payout model (fixed, metered, milestone, stream) + +**Acceptance flow:** +1. Provider submits service_id satisfying RFP +2. Router canary tests validate functionality and SLA +3. On pass, escrow releases; registry emits `RfpFulfilled(rfp_id, service_id)` + +This transforms protocol needs into open market opportunities. + +--- + +## Risks & Mitigations + +| Risk | Mitigation | +|------|-----------| +| Spam registrations | Stake requirement + 30-day lock + rate limits | +| Reputation manipulation | Router-verified telemetry only; governance-versioned weighting | +| Duplicated services | Namespace collision prevention via MRC-59 | +| Malicious endpoints | Stake slashing (50% burn, 50% treasury) + transparent moderation | + +--- + +## Open Questions + +1. Should MCP auto-surface all public services or apply reputation thresholds by default? +2. Deprecation policy for superseded service versions? +3. Privacy controls for allowlisted/subscription services? +4. RFP selection criteria when multiple providers qualify (first-to-deliver, governance vote, performance trial)? + +--- + +## Summary + +MRC 92 establishes the Subnet Service Registry, linking sovereign compute (MRC 91) to Core orchestration (MCP, Router, Agents). It provides a canonical structure for subnets to publish, price, and monetize services, transforming autonomy into composability. The RFP system enables the network to procure capabilities with verifiable SLAs, creating a two-way marketplace between Core and community. + +The registry transforms Morpheus from a compute protocol into an open service economy. Subnets don't just run workloads: they advertise, transact, and evolve under shared accounting. MOR becomes the coordination layer for a self-improving network, where every useful service becomes an on-chain primitive others can build on. + +**Velocity through coordination.** + +--- + +## Compatibility + +MRC 92 composes with existing components without modification: +- Router (MRC-25): consumes telemetry for reputation and settlement +- Agent Registry (MRC-58): aligns spec_type enum (MCP/OpenAPI/A2A) +- Subnet Namespace (MRC-59): binds services to `.mor` identities +- Tools Marketplace (MRC-60): may use registry as backend + +No changes to MRC-25 contracts assumed; hooks delivered as additive modules. + +--- + +**Non-normative.** Reference implementations may be contributed by community maintainers; details live in the runtime/registry repos. + +--- + +## Metadata + +```yaml +id: MRC92 +title: Subnet Service Registry +authors: ["Robert Christian (@robertjchristian)"] +category: "Service Registry" +summary: "Canonical on-chain registry for subnet-hosted services with Router-verified reputation, RFP procurement, and MCP integration." +status: "Discussion" +discussion_url: "https://discord.gg/morpheusai" +contact: "@robertjchristian" +keywords: ["registry","service","router","namespace","mcp","subnet","mcu","meu","mrc25","mrc54","mrc58","mrc59","mrc91"] +```