/ Техническая архитектура
Как BlockVault реализует x402.
От ответа HTTP 402 до завершённого платежа меньше чем за 3 секунды. Технический разбор архитектуры x402-клиента в BlockVault.
/ Pipeline: x402Fetch → Handler → Selection → Approval → Payload → Signer → Retry
Обзор архитектуры
Подсистема x402 — это конвейер: x402Fetch перехватывает 402 → PaymentHandler парсит требования → SelectionLogic выбирает EIP-3009 или Permit2 → ApprovalQueue показывает модалку → PayloadBuilder собирает EIP-712 данные → Signer подписывает → RetryEngine повторяет запрос с payment-signature.
Выбор метода оплаты
BlockVault всегда приоритизирует EIP-3009, когда: (1) токен — USDC, (2) сеть поддерживает transferWithAuthorization, (3) facilitator принимает это. Иначе откат на Permit2.
UX одобрений
Каждый платёж x402 проходит через очередь одобрений. Очередь группирует частые запросы, применяет политики трат и показывает окно подтверждения: домен получателя, сумма, токен, сеть и накопительные траты.
Очередь и политики
Политики выполняются локально до подписи: дневной лимит на домен, максимум за запрос, белый список токенов и ограничения по времени. Если запрос превышает политику, он отклоняется без вашего участия.
Повтор и обработка ошибок
После подписи x402Fetch повторно отправляет исходный запрос с заголовком payment-signature. Если сервер возвращает ошибку (недостаточно средств, истёк nonce, неверная сеть), wallet показывает понятное сообщение и не повторяет автоматически.
/ Usage example
// x402Fetch is a drop-in replacement for fetch()
import { x402Fetch } from '@blockvault/x402'
const response = await x402Fetch('https://api.example.com/data', {
method: 'GET',
// If server returns 402, the wallet handles payment automatically
// EIP-3009 is preferred when token is USDC
})
// response is the final 200 OK with paid content
const data = await response.json()Последнее обновление: