Skip to Content
WhitepaperThe Problem Explained

The Problem Explained

Chapter 4 The Problem Explained 4.1 The problem In March 2026, OpenAI cancelled Sora—its video-generation product—despite an active API, a mobile application, and a Disney character-licensing agreement valued at over $1 billion. Disney was blindsided. Every pipeline hard-coded to call a Sora endpoint broke overnight. This is not an edge case; it is the normal failure mode of an industry where models improve monthly but the systems that connect them remain brittle, manually integrated, and economically opaque. A developer who wants to chain a vision model, an LLM planner, a video diffusion model, and a content-moderation filter into a single end-to-end workflow faces three unsolved problems:

  1. Composition without a contract. Each provider exposes a different API, a different auth story, a different failure mode. Frameworks like LangChain give raw parts but no managed execution—the developer is responsible for orchestration, retries, billing attribution, and versioning across every boundary. When a provider disappears (Sora, or any upstream API sunset), every downstream consumer breaks. In a recipe-based network, that same event is a self-healing reallocation: the recipe re-resolves to the next available agent by quality and availability, not hard-coded endpoint.
  2. No economic identity for capabilities. Models and services have no standard way to declare what they cost, how they are paid, or who is accountable when they fail. Payment is handled out-of-band (Stripe invoices, API keys, prepaid pools) with no machine-readable settlement path. The HTTP 402 status code has existed since 1997; only now is it gaining usable implementations (Coinbase/CDP x402 [5, 17], the broader x402 ecosystem [6, 7], and the Machine Payments Protocol [8]), and even those remain siloed.
  3. No verification for non-deterministic work. When three providers claim to run the same fine-tuning job, there is no lightweight protocol for checking whether their outputs are consistent—without re-running the job yourself. Trust defaults to brand reputation, not cryptographic or statistical evidence. If you believe the future is highly specialized and networked, you need a network where nondeterministic work is cryptographically verifiable, where workflows self-heal when providers fail, where quality—not just price—determines who wins attention, and where every component is itself an agent. That is Scrypted. 4.2 The thesis The Scrypted Network addresses these problems with three interlocking ideas: 18

Agents as the atomic unit. Every capability — a diffusion model, a text classifier, a deterministic parser, a financial data adapter — is packaged as an ingredient: a versioned, billable, independently deployable unit with a stable input/output contract. In product language, each ingredient is an agent. Agents compose into recipes (directed acyclic workflows) that can themselves become new agents, enabling recursive abstraction. A machine-readable economic layer. Agents declare their cost models. Jobs settle via HTTP 402 payment proofs (x402, MPP, or facilitator-mediated flows). An attention auction mechanism routes demand to supply by quality and fit, not price alone — analogous to searchengine placement, but for agent capabilities. The network targets at-cost passthrough on underlying provider fees rather than stacking transaction rakes. Verifiable non-deterministic work. The Commit–Reveal Pairwise Comparison Protocol (CRPC) [1] lets multiple independent workers prove consistency of non-deterministic outputs (images, predictions, text) without a trusted third party. For training verification, CRPC operates on model outputs—not weights—so that hardware variance and floating-point non-determinism are irrelevant; what matters is whether trained models behave the same. Staking and slashing via EigenLayer-style contracts [14, 15] create economic consequences for dishonesty. Ephemeral committees — short-lived, per-task validator groups, in the spirit of VRF-sampled committee literature [18, 19] — resist targeted attacks on static validator sets. The network is live in its API and orchestration layer today. Identity (ERC-8004), payment rails (x402, facilitators), and verification (CRPC, ephemeral committees) are at various stages of integration and research, described honestly throughout this document. Chapter 17 and Appendix D separate the shipped base stack from dependency-gated next work, so thesis language in this document should be read against that scaffold: vision first, sequencing second. 4.3 Design principles • Research before architecture. External specifications, prior art, and competitive reality inform the design — not the other way around. Claims that cannot be grounded in code or citations are marked as hypotheses. • Implemented, then envisioned. The paper documents what is shipped before what is planned. Where a mechanism exists only as a design, it is labeled as such. • Iterative, living document. No fixed publication deadline. Phases advance on quality gates. The document is versioned semantically; the repository is the source of truth. • Product-abstract. Real code paths are cited where useful for implementors, with the explicit caveat that internals are fluid. 4.4 Reader’s guide The paper is organized vision-first: Vision and economics (Chapters 1–3) introduce the founding thesis, Autonomous Virtual Beings, and the machine-economy model—the why before the how. The implemented system (Chapters 5–9) defines the primitives, orchestration engine, financial model, provider architecture, and trust & safety mechanisms as they exist in production. The network vision (Chapters 11–16) extends the system to a decentralized agent network: on-chain identity, verification, privacy, the competitive landscape, reliability, and the roadmap. 19

Appendices provide a glossary, the full ingredient and recipe catalog, and API surface documentation. Each chapter opens with its sources (internal documentation) and research packages (external citations from the Phase 1 research synthesis, denoted [Rn]), so the provenance of every claim is traceable. 20

Source: transcribed from the compiled Scrypted Network Design whitepaper PDF for web reading. Layout, figures, and pagination may differ from the PDF.

Last updated on