Coinbase x402 против Google A2A: Два противоположных подхода к порядку платежей между агентами

Разработчик, создающий исследовательского агента, который распределяет работу между тремя другими (поиск, суммаризация, перевод), столкнулся с необходимостью машинных платежей менее цента. Минимум Stripe в $0.30 при вызове за $0.001 — это наценка в 300 раз; комиссия L1 аналогична; подписки требуют предварительного согласования. Они нашли x402 — реализацию HTTP 402 "Payment Required" от Coinbase, которая представляет собой статeless-посредника для платежей менее цента на Base, с расчетом за ~2 с при стоимости ~$0.0001 с помощью предварительно подписанных авторизаций EIP-3009, передаваемых в заголовках.

Главный вопрос: порядок платежа

При наличии verify (быстро, офчейн), settle (медленно, ончейн) и собственно работы (LLM-вызов) возможны три порядка:

• A: verify → run → settle
• B: verify → settle → run
• C: verify → reserve → run → capture (паттерн удержания с кредитной карты — невозможен при одноразовом дизайне EIP-3009)

Промежуточное ПО Coinbase использует A; расширение A2A x402 от Google — B. Разница зависит от длительности работы: у Coinbase вызывающая сторона — это быстрая API-точка (менее 500 мс), поэтому разрыв между verify и settle незначителен. Для агента, вызывающего других агентов, окно растягивается до секунд или минут — достаточно, чтобы плательщик опустошил кошелек после verify, но до settle, получив бесплатные вычисления.

Расчет вперед лучше для агентных нагрузок

Разработчик выбрал B (verify → settle → run), потому что работа агента стоит реальных денег ($0.30+ за вызов) и выполняется медленно. При расчете вперед неудачный платеж никогда не запускает LLM. Они протестировали четыре сценария:

• Действительная подпись, кошелек опустошен до завершения settle → settle отменяется, вычислительные ресурсы не потрачены (потеря $0).
• Два параллельных запроса с одного кошелька с разными nonce, одним балансом → один settle успешен, второй проигрывает гонку на блокчейне и не доходит до модели.
• Повторная отправка заголовка платежа → перехвачена при проверке nonce до verify, возвращает 402.
• Тайм-аут посредника 10 с, но цепочка подтверждает за 25 с → потерянный платеж (плательщик списал, задача не выполнена). Это свойство загрузки цепочки, не исправляемое порядком.

Проблема расчета вперед: платеж проведен, но работа не удалась (ошибка 500, баг). Поставщик обрабатывает это сохраненными метаданными nonce/авторизации и ручными возвратами.

Полный процесс с открытым исходным кодом и e2e-тестами всех четырех сценариев на ноутбуке: github.com/GetBindu/Bindu