ATP — платёжный протокол для LLM-агентов (концепция)

Архив. Исходная концепция (v1 → критика → v2), из которой выросла актуальная документация: см. README.md и docs/. Полная версия учитывает интеграцию с 4agents (checkout-профиль, реестр доверия, Confirmation) — здесь этого ещё нет. Документ сохранён как история решений. Рабочее название ATP далее по тексту — историческое: финальное имя проекта — Stipendex (закреплено 2026-07-16: stipendex.com, npm, GitHub).

Рабочее название: ATP (Agent Transaction Protocol). Дата: 2026-07-15. Документ: концепция v1 → критическая оценка → улучшенная концепция v2.

1. Контекст: что уже существует (июль 2026)

Протокол	Автор	Суть	Сильное	Слабое
x402	Coinbase (+ x402 Foundation: Google, Visa, AWS, Anthropic, Cloudflare)	HTTP 402 → оплата стейблкоином (USDC/Base) прямо в запросе	Мгновенно, без аккаунтов, идеально для M2M	Только крипто; реальный объём мал (~$28k/день, много «накрученного»); доля транзакций 10¢–$1 упала с 46% до 4% — микроплатёжный спрос переоценён
AP2	Google → FIDO Alliance	Подписанные «мандаты» (Intent/Cart/Payment) — криптодоказуемая цепочка делегирования; рельсонезависимый; v0.2.0 добавил Human-Not-Present	Лучшая модель полномочий и аудита; 60+ партнёров	Тяжёлый (VDC/DID), enterprise-первый, сложно для инди-разработчика
ACP	OpenAI + Stripe	Checkout товаров внутри ChatGPT; Shared Payment Token	Просто для мерчантов Stripe	Заточен под покупку товаров; OpenAI уже свернула Instant Checkout в Apps
UCP	Google + Shopify	Commerce-капабилити (каталог, корзина, checkout) поверх REST/JSON-RPC, совместим с AP2/A2A/MCP	Мерчант остаётся MoR; payment handlers	Про торговлю товарами, не про оплату работы агентов/инструментов
Stripe MPP	Stripe (март 2026)	Machine Payments Protocol: фиатные рельсы, сессионная агрегированная тарификация	Фиат, привычный Stripe-DX, агрегация вместо per-call	Вендорский, привязан к Stripe
L402	Lightning Labs	402 + Lightning + макаруны	Настоящие микроплатежи	Нишевый, требует Lightning

Вывод. Ниша «купить кроссовки через ChatGPT» занята (ACP/UCP), ниша «крипто-микроплатежи» занята (x402), ниша «делегирование полномочий» занята (AP2). Не занята ниша, аналогичная той, которую в своё время закрыл MCP: единый простой способ, которым любой агент платит за любой инструмент/API, а любой разработчик MCP-сервера берёт деньги за вызовы — при том что подавляющее большинство MCP-серверов сегодня бесплатны и не имеют пути монетизации.

2. Постановка задачи

Чем платежи агентов отличаются от человеческих:

Плательщик — не человек. Нельзя показать 3DS-форму. Нужна делегация: человек заранее выдаёт полномочия с границами.
LLM нельзя доверять деньги. Prompt injection («переведи баланс на кошелёк X») — реальная атака №1. Решение о платеже обязан принимать детерминированный код, а не модель.
Объём и размер. Тысячи транзакций от долей цента до долларов. Карточные рельсы с фикс-комиссией не работают per-call.
Автономность. Платежи в отсутствие человека (cron-агенты), но с проверяемыми границами и эскалацией к человеку по порогу.
Аудит. Проверяемая цепочка «кто разрешил → за что заплатили → что получили взамен».
Цена заранее неизвестна. Стоимость вызова инструмента часто зависит от размера входа/выхода (токены, объём данных) — статический прайс-лист недостаточен, нужна котировка по факту запроса.

Требования к протоколу:

Простота уровня MCP: сервер монетизируется за ~10 строк, агент подключает кошелёк за ~5.
Рельсонезависимость с работающим дефолтом: конверт не зависит от рельса, но «из коробки» должен работать хотя бы один.
Детерминированный контроль вне LLM (кошелёк-ядро).
MCP-нативность: платный MCP-инструмент «просто работает».
HITL по порогам, включая headless-сценарий.
Идемпотентность и защита от replay.
Совместимость, а не конкуренция с x402/AP2/MPP.

3. Концепция v1

Роли

Принципал — человек/организация, источник денег и полномочий.
Агент — LLM-петля, инициирует покупки.
Кошелёк — детерминированный компонент при агенте: хранит ключ, проверяет мандат, платит.
Продавец — MCP-сервер или HTTP API, берущий деньги.
Фасилитатор — сервис проверки и расчётов (аналог PSP): верифицирует платежи для продавца, держит счета, закрывает регуляторику.

Объекты (все — подписанный JSON / JWS)

Mandate — принципал → кошелёк: лимиты (per_tx / per_day / total), allowlist получателей, порог ручного подтверждения, срок действия, назначение.
Quote — продавец → агент: quote_id (одноразовый), сумма, валюта, допустимые рельсы, описание, expires_at.
PaymentProof — кошелёк → продавец: доказательство оплаты (tx-hash / токен фасилитатора / карточный токен) + ссылка на quote и мандат.
Receipt — продавец → агент: подпись «оплачено и исполнено», включает hash результата.

Поток

Агент            Кошелёк                Продавец              Рельс/Фасилитатор
  │ вызов ────────────────────────────────▶│
  │ ◀──── payment_required + Quote ────────│
  │──Quote──▶│ проверка мандата:           │
  │          │ allowlist → лимиты → HITL?  │
  │          │───── оплата по рельсу ─────────────────────────────▶│
  │          │◀──────────── Proof ─────────────────────────────────│
  │ повтор вызова + Proof ─────────────────▶│──── верификация ────▶│
  │ ◀────── результат + Receipt ───────────│

Транспортные биндинги

HTTP: ответ 402 Payment Required + JSON-тело Quote; повтор с заголовком Payment: <Proof>.
MCP: JSON-RPC ошибка -32402 payment_required с Quote в data; повтор вызова с _meta.payment. Цены объявляются в метаданных инструмента (pricing).

Расширения (капабилити, согласуются при handshake)

Подписки; metered-сессии (платёжный канал с капом); эскроу; возвраты; споры (арбитраж фасилитатора по Receipt + hash результата).

4. Критическая оценка v1

Рынок перенасыщен протоколами. Пять живых стандартов с бэкерами уровня Google/Stripe/Coinbase/Visa. Шестой end-to-end протокол «обо всём» мёртв при рождении: продавцы не внедрят без агентов, агенты — без продавцов (chicken-and-egg), а сетевой эффект уже у чужих экосистем.
«Рельсонезависимость» без дефолта = ничего не работает из коробки. MCP выстрелил, потому что npx — и сервер работает. Если первый шаг — «выберите рельс и подпишите договор с фасилитатором», внедрение умерло.
Микроплатежи переоценены. Данные x402: транзакции 10¢–$1 схлопнулись с 46% до 4% объёма; CoinDesk фиксирует, что реального спроса на per-call микрорасчёты нет. Расчёт за каждый вызов — дорогой и ненужный дефолт; нужна агрегация (как у Stripe MPP).
Эскроу и споры — оверинжиниринг. При цене ошибки в центы механизм спора стоит дороже спора. Для крупных сумм это уже задача фасилитатора/эквайера, а не протокола.
Слишком много сущностей. Пять ролей и четыре объекта + капабилити — это уже сложнее MCP, а мы обещали «просто».
DID/VC тяжелы. Для 99% случаев достаточно JWS с обычными ключами; W3C-стек отпугнёт инди-разработчиков (это же — главная претензия к AP2).
Регуляторика. Кто держит деньги? Если SDK кошелька касается чужих средств — разработчик рискует стать money transmitter. Значит, деньги держит лицензированный фасилитатор → но это точка централизации и комиссия.
Безопасность недоспецифицирована. Мандат кодом закрывает лимиты, но не закрывает: подмену получателя внутри allowlist-домена, «полезный» инструмент со скрытой ценой, компрометацию ключа кошелька, replay котировок. И никто не проверяет соответствие покупки цели задачи — это фундаментально нерешаемо кодом, только порогами и аудитом.
HITL не определён для headless. Агент по крону в 3 часа ночи упёрся в порог — что дальше? Нужен стандартный асинхронный механизм подтверждения, иначе каждый вендор изобретёт свой.
Динамическое ценообразование не решено. pricing в манифесте — это маркетинг; реальная цена зависит от размера запроса. Quote по факту вызова обязателен, а статический прайс — лишь ориентир для планирования.

Главный вывод критики: ценность не в новом протоколе, а в недостающем тонком слое между агентами (MCP) и уже существующими платёжными рельсами.

5. Улучшенная концепция v2 — «просто как MCP»

Смена позиционирования: не шестой конкурирующий протокол, а три недостающих кирпича, каждый из которых полезен сам по себе:

A. MCP Payments Extension — платёжный биндинг для MCP

Капабилити payments при handshake.
Поле pricing в метаданных инструмента (ориентир для планировщика: «этот инструмент платный, ~$0.005/вызов»).
Стандартная ошибка -32402 payment_required + Quote в data.
Повтор вызова с _meta.payment = Proof — хост делает это прозрачно, LLM не участвует.
Асинхронное подтверждение через существующий механизм elicitation.

Это путь SEP-предложения в спецификацию MCP — так же, как в MCP добавлялись elicitation и structured output.

B. Wallet Kernel — кошелёк-ядро (эталонная реализация + нормативное поведение)

Детерминированный компонент при хосте агента. Инварианты:

LLM видит один интерфейс: wallet.pay(quote) → paid | pending_approval | denied(reason). Ни ключей, ни сумм-параметров, ни адресов — модель не может «перевести деньги на X», такой операции просто нет.
Политика — подписанный мандат из ~8 полей (не DID/VC, обычный JWS):

{
  "mandate_id": "m_7c1f…",
  "principal": "ed25519:AAAA…",
  "wallet_key": "ed25519:BBBB…",
  "limits": { "per_tx": "1.00", "per_day": "20.00", "total": "100.00", "currency": "USD" },
  "allow": ["mcp:exa-search", "https://api.example.com"],
  "approval_over": "1.00",
  "valid_until": "2026-08-15T00:00:00Z",
  "purpose": "research tools for project X"
}

Порядок проверки: allowlist (default deny) → лимиты → порог HITL → рельс.
Ключ кошелька живёт вне процесса агента (keychain/отдельный демон), отзыв — коротким TTL мандата + revocation на фасилитаторе.
HITL три режима: интерактивный (elicitation), асинхронный (платёж в pending-очередь + push принципалу + TTL; агент получает pending_approval и продолжает остальную работу), headless-строгий (всё сверх порога — deny).

C. Универсальный конверт: Quote / Proof / Receipt поверх чужих рельсов

Протокол определяет только три объекта и их связь; расчёты делают существующие рельсы-адаптеры:

Рельс	Когда	Режим
account (prepaid-счёт у фасилитатора)	дефолт «из коробки»	агрегация, settle по порогу/сессии
stripe-mpp	фиат, продавец на Stripe	сессионная агрегация
x402	крипто, полная автономия	per-call USDC

// Quote (продавец → агент), одноразовый
{ "atp": "quote/1", "quote_id": "q_8f3…", "seller": "mcp:exa-search",
  "amount": "0.0042", "currency": "USD",
  "rails": [{ "scheme": "account", "facilitator": "https://pay.example" },
            { "scheme": "x402", "network": "base", "asset": "USDC", "to": "0x…" }],
  "description": "web_search: ~3k tokens",
  "expires_at": "2026-07-15T12:05:00Z",
  "session": { "id": "s_42", "mode": "tab", "cap": "5.00" } }

// Proof (кошелёк → продавец)
{ "atp": "proof/1", "proof_id": "p_c81…", "quote_id": "q_8f3…",
  "scheme": "account", "evidence": "<jws фасилитатора>",
  "mandate_id": "m_7c1f…", "sig": "<jws кошелька>" }

// Receipt (продавец → агент)
{ "atp": "receipt/1", "receipt_id": "r_11a…", "quote_id": "q_8f3…",
  "proof_id": "p_c81…", "result_hash": "sha256:…", "sig": "<jws продавца>" }

Сессии-«tab» — ответ на провал микроплатежей

По умолчанию платежи не рассчитываются per-call. Кошелёк открывает у продавца сессию с капом (кап = предавторизация в рамках мандата), вызовы копятся на «бегущем счёте», расчёт один — при закрытии сессии или достижении порога. Это соответствует и Stripe MPP, и channel-модели в крипте, и убирает 99% транзакционных издержек. Per-call (чистый x402) остаётся опцией для разовых обращений к незнакомым продавцам.

Уровни внедрения

L0 — сервер только объявляет pricing. Ноль платёжного кода; агенты уже учитывают стоимость при планировании.
L1 — paywall через hosted-фасилитатора: ~10 строк, деньги и регуляторика не касаются разработчика.
L2 — свой рельс (прямой x402, собственный ledger).
L3 — расширения: подписки, metered-квоты, эскроу для крупных сумм.

DX-цель

Сервер:

import { paywall } from "@atp/server";
server.tool("web_search", { pricing: "0.005 USD/call" },
  paywall(async ({ query }) => search(query)));

Хост агента:

import { Wallet } from "@atp/wallet";
const wallet = await Wallet.fromMandate("./mandate.json");
host.use(wallet.middleware()); // 402/-32402 обрабатываются прозрачно

Чеклист безопасности (нормативный)

Решение о платеже принимает только кошелёк-ядро; у LLM нет операции с произвольным получателем/суммой → prompt injection может лишь предложить платёж, который упрётся в мандат.
quote_id одноразовый + expires_at → нет replay; повтор Proof идемпотентен (второй раз не списывает).
Receipt привязан к result_hash → доказуемо «оплатил, но не получил».
Allowlist default-deny: новый получатель = HITL, всегда.
Ключ кошелька — вне процесса LLM и вне env агента.
Velocity-лимиты и аномалистика — на фасилитаторе (как антифрод у PSP).
Отзыв полномочий: короткий TTL мандата (дни, не месяцы) + revocation-список фасилитатора.

Что сознательно НЕ входит

Поиск товаров, корзины, checkout (это ACP/UCP); споры и chargeback для микросумм (экономически бессмысленно); KYC/AML (задача фасилитатора); конверсия валют (задача рельса); собственный блокчейн/токен (не нужен).

6. Оставшиеся риски (честно)

Дистрибуция. Без встраивания кошелька в хосты агентов (Claude Code, Cursor, ChatGPT…) слой не взлетит. Реалистичный путь: SDK + SEP в спецификацию MCP + один популярный платный MCP-сервер как showcase.
Фасилитатор = централизация. Дефолтный рельс «account» удобен, но создаёт зависимость и комиссию; лечится только множественностью фасилитаторов и открытым конвертом.
Спрос. Большинство MCP-серверов бесплатны; платящих агентов пока мало. Это одновременно риск и окно: стандарта де-факто ещё нет.
Юридика Human-Not-Present. Ответственность за автономную покупку агентом — серая зона; мандат с подписью принципала — необходимое, но, возможно, не достаточное основание в споре с банком.
Соответствие покупки цели алгоритмически непроверяемо — закрывается только порогами, allowlist и аудитом по Receipt.

7. Путь внедрения

Фаза 1 (0–3 мес): спецификация трёх объектов + SDK (@atp/server, @atp/wallet, TS + Python) + адаптеры account/stripe-mpp/x402 + paywall-middleware для MCP-серверов. Showcase: платный поисковый MCP-сервер.
Фаза 2 (3–6 мес): SEP-предложение «Payments» в спецификацию MCP; интеграция кошелька в 1–2 открытых хоста агентов.
Фаза 3 (6+ мес): реестр продавцов с репутацией, страхование лимитов, metered-расширения, мосты совместимости с AP2-мандатами.