Roadmap and publication

The goal is open public infrastructure: specification + SDKs + reference services. 4agents is the first live scenario and the first registry provider.

Phase 0 — documentation and validation (now)

• Concept v1 → critique → v2 (CONCEPT.md, Russian archive).
• Specification package 0.1-draft (docs/, docs/spec/).
• English-first documentation; Russian mirror in docs/ru/.
• Name: Stipendex. Chosen after a ~60-candidate availability sweep (working title was ATP). Secured: stipendex.com, npm stipendex (placeholder 0.0.1 published) + the @stipendex scope, GitHub org stipendex. Remaining: USPTO/EUIPO trademark screening with counsel.
• External validation: spec review by 2–3 MCP server developers and one payments lawyer (money-transmission boundaries for the wallet and the facilitator). Preparatory research memo — done: legal/money-transmission-memo.md (internal, not published; US federal/state, EU, UK, crypto regimes; adversarially verified; 11 numbered questions for counsel).

Shipped first: the on-chain profile (October 2026)

Instead of the facilitator-based slice, the first live path is the on-chain profile on Base Sepolia, which needs no custodial component:

• Contracts: LMB (ERC-20 + EIP-3009), Faucet with ETH gas stipend, Market with on-chain delivery and purchase-bound reviews (packages/contracts, Sourcify-verified).
• @stipendex/onchain client, @stipendex/cli, @stipendex/seller-daemon (provisioners: pool, command, webhook, OpenRouter), buyer and seller agent skills.
• Web on Cloudflare Workers: 4agnts.com catalog, faucet and relay (packages/web-4agnts), stipendex.com docs (packages/web-stipendex), 4agn.com short links (packages/web-4agn).
• Next: hosted showcase seller (inference listing), ESCROW kind, x402 exact binding for LMB, faucet-for-work (conformance run → bigger drip).

packages/facilitator and the account rail are kept as reference code but archived.

Phase 1 — a working vertical slice (0–3 months)

The minimal end-to-end path proving the concept:

1. @stipendex/core (TS): objects, signatures (JWS/JCS), validation. Then Python.
2. @stipendex/wallet: the wallet kernel — mandate, durable limits, HITL (interactive + async queue), proxy mode for hosts without native support.
3. @stipendex/server: paywall middleware for MCP (-32402) and HTTP (402).
4. The account rail + a minimal hosted facilitator (ledger, Proof verification, pending queue, revocation).
5. Showcase A (service): one genuinely useful paid MCP server at L1.
6. Showcase B (checkout): the payment part of the 4agents order flow on Stipendex objects — get_quote → Confirmation → hold → ACCEPT → capture (the stripe-connect rail).

Phase gate: a developer new to the project monetizes their MCP server from the docs in < 30 minutes; an agent with a wallet completes both a micropayment and a goods purchase with a passkey confirmation.

Phase 2 — standardization and rails (3–6 months)

• A SEP into the MCP specification: the payments capability, the payment_required error, _meta fields — out of experimental. Draft ready: sep-0001-payments.md.
• x402 and stripe-mpp adapters; interop tests against their live stacks.
• Trust registry v1 at 4agents: descriptors, revocation, registry:4agents/verified in mandates; extending the registry from merchants to paid MCP servers. Core shipped: @stipendex/registry (provider, resolver, wallet e2e); remaining: hosted HTTP API + 4agents data.
• Native wallet integration into 1–2 open agent hosts (replacing proxy mode).
• Tab sessions on the account rail and a bridge into MPP sessions.

Phase 3 — ecosystem (6+ months)

• Registry federation (a second independent provider), a public level scale.
• AP2/FIDO compatibility: a mandate bridge (our Mandate ↔ Intent Mandate), passkey confirmations per FIDO standards.
• Extensions: subscriptions, metered quotas, escrow for large amounts, the refund flow.
• Limit insurance, principal analytics ("where do agents spend").

Publication and licenses

Governance: BDFL until phase 2 (fast iteration); after the SEP — a public change process (RFC-style), so the protocol is not perceived as vendor-owned.

Open questions

1. Who legally operates the first facilitator (licenses per market) — counsel session before phase 1.5; preparatory memo: legal/money-transmission-memo.md (internal, not published).
2. Mandate limit currency with multi-currency receivers: conversion at the wallet (facilitator rate) or multi-currency limits.
3. Passkey confirmation format: our own digest or immediate alignment with AP2/FIDO.
4. account rail economics: facilitator volume fee vs subscription — decide on showcase data.