Stipendex: product and positioning

Problem, landscape, distribution strategy, and monetization. Technical details live in spec/.

The problem

Agents have learned to act (MCP) but not to pay. Today an agent paying for anything means either API keys and cards a human pre-registered on every service separately, or a full stop: "ask the owner". Consequences:

• For tool developers: 19,000+ MCP servers, almost all free — not because the authors are altruists, but because there is no way to charge for a call.
• For agent owners: delegating money to an agent is scary — LLMs are vulnerable to prompt injection, and nobody enforces boundaries ("no more than $20 a day, only to these services").
• For commerce: an agent buying goods runs into questions with no standard answers: who confirmed the amount? how do you prove the agent's authority in a chargeback? how do you hold an estimate when only the seller knows the final price?

How agent payments differ from human payments

1. The payer is not a human: you cannot show a 3DS form; you need delegation with boundaries.
2. An LLM cannot be trusted with money: the payment decision must be made by deterministic code.
3. Frequency and size: from fractions of a cent (tools) to hundreds of dollars (goods).
4. Autonomy: payments with no human in the loop, but with verifiable limits and threshold escalation.
5. Audit: a provable chain of "who authorized → what was paid → what was received".
6. The amount is often unknown upfront (tokens, shipping, tax) — you need quotes-at-call-time and tolerances, not price lists.

The landscape (July 2026) and our gap

The gap: an open, neutral "authority + envelope + trust" layer on top of these rails, as simple as MCP. We deliberately do not build: new rails, commerce scenarios (search/cart/checkout UI), KYC. We build what nobody has: a standard wallet with a mandate + a unified payment cycle + a federated trust registry.

Two quadrants — one protocol

The quadrants share 80% of the mechanics: mandate, wallet, Quote/Proof/Receipt, registry, idempotency, audit. What differs is the settlement mode and whether HITL is mandatory. Hence one protocol with two profiles, not two protocols.

Distribution strategy (the answer to "who will adopt this")

The classic death of a payment protocol is the chicken-and-egg: sellers wait for agents, agents wait for sellers. Our plan breaks the loop with three moves:

1. 4agents as the first live scenario. Not an abstract "showcase" but a working product with real merchants: the Stipendex checkout profile is the payment part of its order-flow v2.1, and the wallet is the standard implementation of its HITL step. Stipendex launches inside existing demand, not into a vacuum.
2. The wallet as the agent-side hook. To an agent owner we sell safety, not "a protocol": "install @stipendex/wallet — your agent can spend money without scaring you: budgets, limits, confirmations, verified receivers only". The wallet brings agents → agents bring traffic to receivers → receivers bring new wallet users. The wallet's default allowlist is the trust registry: the network effect closes.
3. A SEP into the MCP specification. The payment_required error and the payments capability are candidates for standardization the same way elicitation and structured output entered MCP. Until the SEP lands, everything works through _meta with no spec changes.

Monetization (who earns what)

The protocol and SDKs are free and open (an adoption precondition). The money in the ecosystem:

• Facilitator — volume fee / subscription for hosted accounts, verification, the HITL queue, anti-fraud. The reference API is open; there can be many operators; the first is the 4agents operator.
• Trust registry provider — receivers subscribe for verification (the 4agents "verified" model, extended from merchants to paid MCP servers).
• Orchestrating platforms (4agents and the like) — take rate on their own scenarios.

The separation of roles is essential: an open protocol doesn't lock anyone into a single operator, and operators compete on service — like mail servers on top of SMTP.

Risks