Payment Rails and Machine Economics

Chapter 3 Payment Rails and Machine Economics This chapter describes the multi-rail payment architecture and the economic thesis: at-cost passthrough on underlying provider fees, combined with attention-auction placement revenue. Where Chapter 7 documented the implemented billing system, this chapter extends it to the network’s full economic design. 3.1 HTTP 402: x402 and MPP as dual stacks HTTP 402 is attracting two major, partially overlapping implementations: x402 (Coinbase / x402 Foundation): Server responds 402 with payment requirements; client pays (stablecoin on a supported network) and retries with X-PAYMENT header carrying a base64 payment payload. Facilitators verify and settle [5, 6, 7]. This is the stack already integrated in the Scrypted API (Chapter 7). Machine Payments Protocol (MPP): IETF-oriented framing using WWW-Authenticate: Payment challenges, Authorization: Payment credentials, and optional Payment-Receipt headers [8]. Payment-method plugins (Tempo for stablecoins, Stripe for cards) extend the scheme. Body-binding via RFC 9530 Content-Digest prevents payload swaps after challenge issuance. Error semantics use RFC 9457 Problem Details [9]. The wire formats differ but the economic intent is identical: machine-readable payment proof on every HTTP request. The integration architecture normalizes both stacks behind VerifiedPayment: detection by header shape routes to the appropriate verifier; successful verification produces a common record with amount, currency, receipt identifier, and facilitator reference. Jobs, invoices, and ERC-8004 proofOfPayment hooks remain one code path. No MPP-specific code paths exist in the repository today. Integration is greenfield and documented as hypothesis. 3.2 Facilitators: Coinbase, Polygon, self-hosted The FacilitatorRegistry loads adapter configurations from YAML. The current default is coinbase_base (Coinbase Facilitator, Base network, USDC). The architecture supports: • Polygon’s hosted x402 facilitator (documented at x402.polygon.technology; not yet configured in this repository). • A Scrypted-hosted facilitator service (future; same adapter interface). 13

• Additional chain-specific facilitators (Solana, Ethereum mainnet) as configuration-only extensions. The system supports third-party facilitators and a self-hosted option with equal architectural standing; no single facilitator is privileged. 3.3 ERC-8183: on-chain job escrow EIP-8183 (Agentic Commerce) [10] defines a minimal on-chain Job with escrowed ERC-20 budget, three roles (client, provider, evaluator), and a state machine: Open → Funded → Submitted → {Completed, Rejected, Expired}. The evaluator alone resolves terminal states. Deliverables are typically a bytes32 reference (hash or CID). Optional hooks (IACPHook) extend lifecycle without forking the core. Ecosystem announcements (e.g. Virtuals co-authorship) are summarized in trade press [11]. Scrypted’s jobs today are off-chain orchestration with database state. ERC-8183 applies when on-chain auditable escrow is needed — high-value work, cross-party trust boundaries, or evaluator-gated release. It structures how a job is funded and settled, not how demand finds supply. The complete reason field is explicitly composable with ERC-8004 reputation. 3.4 ERC-8194 / PGTR: payment-gated transaction relay ERC-8194 (draft) defines forwarding on-chain calls where authorization is a payment receipt, not an ECDSA signature. pgtrSender() returns the effective payer; replay protection consumes receipt hashes. This contrasts with ERC-2771’s gas abstraction (key-holders) — PGTR provides key abstraction for token-holding actors. PGTR pairs naturally with x402: an HTTP payment proof, verified off- or on-chain, authorizes a specific contract call without the agent holding a hot signing key. This enables keyless or payment-first agent interactions with on-chain services. 3.5 Attention auctions: SEM for agents The network’s core economic innovation is attention auctions: agents and service providers bid for placement in discovery and routing surfaces, analogous to search-engine marketing (keyword bidding → embedding / API-routing “ads for agents”). At-cost passthrough: The network does not stack a transaction rake on top of underlying provider fees. When Scrypted wraps a third-party service as an ingredient, the user pays the provider’s price plus the network’s operating cost — not a percentage markup. Placement revenue: Revenue comes from agents paying for discovery priority: when multiple agents can fulfill an intent, the ranking incorporates bid amount alongside embedding similarity and reputation score. This is SEM economics applied to capability matching. Contrast with lowest-bid orderflow: In pure price auctions, the cheapest provider always wins. This incentivizes race-to-bottom pricing and quality erosion. Attention auctions let providers compete on fit and willingness to pay for visibility, preserving quality differentiation. The closest economic prior art is ERC-7683 [12] filler competition (UniswapX, Across) [13], where fillers compete to fulfill cross-chain intents. Scrypted extends this from “lowest price wins” to “best-fit bid wins” (embedding similarity × price × reputation). 14

3.6 Non-crypto payment rails for agents The agent payment landscape has fragmented into parallel crypto-native and fiat-native stacks. The Scrypted Network is rail-agnostic: all payment proofs are normalized behind VerifiedPayment, whether the source is x402 USDC, a Stripe Shared Payment Token, Google Pay via UCP, or Visa tokenized credentials. Protocol Operator Model ACP Stripe + OpenAI Shared Payment Token; live in ChatGPT; 1M+ Shopify merchants UCP Google + Shopify /.well-known/ucp discovery; native REST checkout AP2 Google + 60 partners Mandate-based authorization; cryptographic intent chains Visa Intelligent Commerce Visa Agent-specific tokenized credentials; “Agentic Ready” programme PayPal Agentic Commerce PayPal Supports ACP, UCP, and AP2; 400M+ accounts The network’s VerifiedPayment normalization layer already abstracts x402 and facilitatormediated flows. Extending it to ACP (Shared Payment Tokens), UCP (Google Pay), and AP2 (mandate credentials) is a near-term committed deliverable. The wire format differs; the internal record (amount, currency, receipt identifier, facilitator reference) is the same code path. 3.7 Liquid payment pools The network routes agent requests to providers that cost real money. Those providers may accept different currencies at different settlement cadences. Liquid payment pools decouple user-facing settlement (x402 USDC, real-time, per-request) from provider-facing settlement (invoices, periodic). The model is the IATA Clearing House (ICH)—the airline industry’s global settlement platform handling $60B+ annually across 560+ participants with 99.999% on-time settlement. When a cancelled flight rebooks a passenger on another airline, the ticket revenue settles through the ICH via periodic bilateral netting, not per-transaction settlement. The Scrypted analog:

1. User pays: x402 USDC (or ACP/UCP/AP2), instant, per-request.
2. Pool absorbs: The network credits the provider’s pool for the estimated cost.
3. Provider draws: The provider invoices against the pool at their cadence (hourly, daily, monthly).
4. Pool reconciles: The network replenishes pools from accumulated settlement, maintaining multi-currency balances as needed. Pools can extend credit to providers to prevent service interruption, with a minimum balance floor to keep services running. Early pool sizing is per-provider negotiation; governance via the DAO as the network matures. The network does not convert currencies—it maintains pools in whatever denomination the provider accepts. Liquid pools are the mechanism that makes at-cost passthrough viable across settlement timing mismatches: the user pays instantly, the provider is paid on their terms, and the network absorbs the timing difference. 15

3.8 Rails and cross-chain interoperability Rail Scrypted use EIL (Ethereum Interop Layer) Within-Ethereum cross-L2 interop for agent wallets and job flows; ERC-4337 account abstraction; public testnet since Nov 2025. Wire Network (UTL) Cross-ecosystem settlement layer (Ethereum ↔ Solana ↔ multi-currency pool accounting); hub-andspoke model; friendly ecosystem relationship. Uniswap v4 (hooks, ERC-7683) Mechanism-design metaphor for path-finding through fragmented liquidity. EigenLayer / AVS / EigenCloud Restaking-backed security and verifiable compute for worker decentralization [14, 15, 16]. 3.9 SCRY token economics (planned) SCRY is the planned native governance token for the Scrypted Network. It is not live with a contract address as of this writing. The network intends to operate as a DUNA-based DAO (Decentralized Unincorporated Nonprofit Association) once the governance and regulatory framework is established. 3.9.1 Token lifecycle Testnet: AVB (on Solana) may be used for expedited services while testnet SCRY operates as a limited fountain. AVB is liquid on the open market; testnet SCRY is scarce by design. The testnet fountain offers two modes: a standard human faucet and an agent faucet for entities registered with ERC-8004 [2]—enabling autonomous agents to bootstrap participation without human intermediation. Mainnet: SCRY is the sole native governance token. The network anticipates airdropping SCRY to AVB holders in proportion to holding duration and/or usage; the precise formula is subject to governance vote and regulatory approval—no binding commitment is made in this document. Internal accounting: SCRYPTOSHI (Chapter 7) remains the internal computation unit regardless of external settlement currency. 3.9.2 Value capture mechanism SCRY captures value through two complementary channels: Governance rights. SCRY holders govern network parameters that directly affect economic outcomes: attention-auction bid floors and placement weights, committee composition rules, provider onboarding criteria, and fee schedules. Governance also covers network admission: joining as an operator, registering new ingredient classes, and qualifying for watchtower duties (monitoring and challenging dishonest attestations during CRPC committee windows). Holding SCRY is a prerequisite for these roles, creating structural demand tied to network participation rather than speculation. Fee-sharing. A percentage of attention-auction placement revenue flows to the DUNA-based DAO treasury. Distribution to SCRY stakers follows governance-set formulas. This aligns token value with actual network throughput: more resolved intents → more placement revenue → 16

more DAO treasury inflow. The at-cost passthrough principle (no rake on underlying provider fees) remains intact; fee-sharing applies only to the placement premium that agents pay for discovery priority. Insurance and committee participation. SCRY stakers may provide insurance during committee-awaited decisions: staking against the outcome of a CRPC dispute provides economic backing for the challenge window, and honest participants earn a share of slashed stakes from dishonest actors. This creates a third demand channel beyond governance and fee-sharing. 3.9.3 Risk factors and disclaimers The Scrypted Network is not a company coin—the design target is a truly decentralized network, even though it starts centralized. All token mechanics are subject to governance and regulatory review. Nothing in this document constitutes financial advice or a binding commitment. The anticipated AVB → SCRY airdrop is subject to regulatory approval in target jurisdictions. Token distribution, vesting, and DAO structure will be published separately when finalized. Market-making agents — watching Scrypted Network interests when converting across Ethereum, Solana, Uniswap, Wire Network, EIL, and peers — are a vision-level concept, not a shipped feature. 17

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