Whitepaper

Abstract

The name references HTTP 402 Payment Required: d402 extends paid HTTP service access into a distributed worker network. A requestor submits a structured paid task to any reachable gateway or ingress node. The network discovers capable sellers, workers bid to execute the task, selected workers return signed result claims, validators accept or reject those claims, and payment is settled to the workers that produced valid results.

The design avoids arbitrary unbounded code execution as the trust model. Work is organized into capability manifests with explicit input schemas, output schemas, runtime permissions, validators, evidence requirements, and pricing units. Capability registration is permissionless but policy-aware: signed registration envelopes, namespace proofs, provider records, validator offers, and gateway acceptance rules make discovery scalable without making every gateway accept every manifest.

Motivation

Many useful services are small composable jobs: fetch a page, render it, extract markdown, classify a document, validate a proof, run a deterministic transform, crawl a product listing, or produce a structured JSON result. Centralized APIs make these jobs available, but availability, pricing, reliability levels, and seller participation remain controlled by one operator.

d402 proposes a network where capability sellers can join permissionlessly, publish what they can do, compete on price and quality, and receive payment for valid work. Requestors tune cost and reliability by selecting single-worker, race, or quorum execution.

Design goals

• Any node can receive, route, and coordinate a request.
• New nodes strengthen capacity, paths, validators, and storage.
• Work is described by versioned capabilities, not opaque arbitrary code blobs.
• Requestors can select fanout, quorum, validation model, deadline, and budget.
• Workers are paid only when they return valid results.
• Evidence is content-addressed so results can be audited and compared.
• Payment adapters support simulated settlement, x402, Solana, and MPP-like flows.

System overview

d402 is event-driven. Nodes publish signed objects. Other nodes validate, store, relay, and act on those objects. The application-facing boundary is intentionally narrower: buyers call d402 HTTP gateways and handle payment challenges, while gateways perform peer discovery, worker selection, orchestration, validation, and settlement.

Payment model

d402 separates task execution from payment mechanics through adapters. The implementation supports simulated payment, Base x402, Base task escrow, Solana direct payment, Solana task-vault escrow, Solana channel escrow, and MPP-shaped challenge boundaries.

The key timing issue is solved with deterministic router destinations: when final recipients are unknown at payment time, the buyer pays a task escrow or channel vault. Validator-approved settlement routes funds after work.

Network discovery

The prototype uses explicit bootstrap peers and peer exchange. Production discovery should use multiple independent bootstrap paths, signed peer records, persisted peerstores, sharded DHT provider records for manifests and capability topics, gossipsub topics for registrations/offers/tasks/claims/receipts/reputation, NAT traversal, relay support, peer scoring, and Sybil defenses.

Roadmap

• Keep docs and operator runbooks aligned with live settlement code.
• Deploy ops monitoring alongside live gateways.
• Harden capability registry operations: namespace proofs, spam controls, schema compatibility checks, validator marketplace discovery, and gateway deprecation policy.
• Add live web benchmark harness and extraction quality taxonomy.
• Add browser worker pools and sandbox limits.
• Add durable task and receipt storage.
• Replace bootstrap-only TCP with libp2p discovery and gossip.
• Audit escrow contracts, Solana program, gateway payment sequencing, and validator operations.