uvd-x402-sdk 2.96.0 → 2.98.0

package/README.md

@@ -4,7 +4,7 @@ Gasless crypto payments across 29 blockchain networks using the x402 protocol.
 
 Users sign a message or transaction, and the Ultravioleta facilitator handles on-chain settlement. No gas fees for users.
 
-**New in v2.94.0**: EURC on Arc mainnet and testnet, six-decimal euro amounts and token-specific signatures. Gas remains USDC. Contract metadata and offline tests verified; funded EURC payments pending. [Arc EURC guide](docs/networks/arc.md#eurc-prices-in-euros).
+**New in v2.94.0**: EURC on Arc mainnet and testnet, six-decimal euro amounts and token-specific signatures. Gas remains USDC. Funded EURC payments confirmed on Arc mainnet (x402 v1 and v2, 2026-09-22); Arc testnet funded acceptance pending. [Arc EURC guide](docs/networks/arc.md#eurc-prices-in-euros).
 
 **New in v2.95.0**: Hedera mainnet and testnet accept native USDC payments only, with offline signing and buyer/merchant helpers. HBAR funds sponsor network fees and is rejected as payment. [Hedera guide](docs/networks/hedera.md). Arc USDC/EURC remains supported on mainnet and testnet.
 
@@ -19,7 +19,7 @@ Users sign a message or transaction, and the Ultravioleta facilitator handles on
 - **React & Wagmi**: First-class integrations
 - **Signing Wallet Adapters**: EnvKeyAdapter (server/CLI), OWSWalletAdapter (Open Wallet Standard), or bring your own
 - **ERC-8128 Signed Requests**: Authenticate HTTP requests with a wallet (RFC 9421 + EIP-191) — no API keys
-- **ERC-8004 Trustless Agents**: On-chain reputation and identity across 21 networks (19 EVM + 2 Solana)
+- **ERC-8004 Trustless Agents**: On-chain reputation and identity across 23 networks (21 EVM + 2 Solana)
 - **Escrow & Refunds**: Hold payments with dispute resolution
 - **Advanced Escrow**: Full escrow lifecycle (authorize, release, refund, charge) with SigningWalletAdapter support
 - **Escrow Pre-Auth**: Sign-on-assignment `X-Payment-Auth` builder (`buildEscrowPreAuth`) — vector-pinned parity with the Python SDK and Execution Market
@@ -746,10 +746,10 @@ const header = svm.encodePaymentHeader(payload, chainConfig);
 | SKALE Base Sepolia | 324705682 | USDC.e |
 | Robinhood Chain | 4663 | USDG |
 | Robinhood Chain Testnet | 46630 | USDG |
-| Arc | 5042 | USDC |
-| Arc Testnet | 5042002 | USDC |
+| Arc | 5042 | USDC, EURC |
+| Arc Testnet | 5042002 | USDC, EURC |
 
-> **Arc mainnet and testnet:** payment amounts use 6 decimals and the `USDC` / `2` domain. Native gas uses 18 decimals on the same balance. Use `arc` / `eip155:5042` for mainnet and `arc-testnet` / `eip155:5042002` for testnet. See [Arc usage and validation](docs/networks/arc.md).
+> **Arc mainnet and testnet:** payment amounts use 6 decimals. USDC signs with the `USDC` / `2` domain; EURC (`0xbEf5…21c1` mainnet, `0x89B5…D72a` testnet) signs with `EURC` / `2` and its amounts are **euros**, not dollars (`tokenType: 'eurc'`, `usdPegged: false`). Native gas uses 18 decimals on the same balance. Use `arc` / `eip155:5042` for mainnet and `arc-testnet` / `eip155:5042002` for testnet. See [Arc usage and validation](docs/networks/arc.md).
 
 > **Robinhood Chain / USDG:** Robinhood Chain has no USDC — the settlement stablecoin is Paxos **USDG** (Global Dollar, 6 decimals, EIP-3009). Its on-chain `version()` getter reverts, so the EIP-712 domain `{ name: "Global Dollar", version: "1" }` can never be resolved on-chain. The SDK carries this domain in the chain config; when constructing `PaymentRequirements` yourself, send it in `extra`: `{ "name": "Global Dollar", "version": "1" }`. Use `tokenType: 'usdg'` (or the default, which resolves to USDG on these networks).
 
@@ -1194,7 +1194,9 @@ The same reading applies to `Erc8004LookupError` (`POST /register` goes through
 the same EVM path, so a mint can come back unconfirmed too) and to every gasless
 escrow call. An explicit `retryable: false` in a facilitator body always wins
 over the status — but only ever **downgrades**: a body claiming `retryable: true`
-on a `402` will not make this SDK resend a genuinely refused credential.
+on a `402` will not make this SDK resend a genuinely refused credential. The one
+exception is named, not read from a flag: `409 authorization_in_flight` is
+`retryable` (see [Portable facilitator receipts](#portable-facilitator-receipts)).
 
 Three independent signals stop a retry, because the cost of missing one is a
 second payment: the explicit `retryable: false`, the named
@@ -1216,18 +1218,30 @@ An unconfirmed settlement is the one 5xx that goes out as **`500`, with no
 be mining. The body carries `transaction`, `paymentId` and `retryable: false`, so
 the buyer's client can reconcile instead of paying again.
 
+An X-PAYMENT the facilitator already admitted for another request is answered
+**`409`** (`authorization_already_settled`, `receipt_request_conflict`: it was
+used, the handler does not run) or **`503` + `Retry-After`** while it is
+`authorization_in_flight` — never `402` and never `500`. Both middlewares add
+`PAYMENT-RESPONSE` to an existing `Access-Control-Expose-Headers` and `no-store`
+to an existing `Cache-Control` instead of replacing them, and in `'manual'` mode
+a `settle()` after the handler already answered no longer touches the sent
+response.
+
 ## ERC-8004 Trustless Agents
 
-Build verifiable on-chain reputation for AI agents and services. Supports **21 networks** (19 EVM + 2 Solana).
+Build verifiable on-chain reputation for AI agents and services. Supports **23 networks** (21 EVM + 2 Solana).
 
 > Name Base as `'base'`. The old `'base-mainnet'` spelling is rejected by the facilitator
 > (`400 Invalid network`); the SDK now rewrites it for you, but new code should use `'base'`.
 
 On EVM networks, agent IDs are sequential numbers. On Solana, agent IDs are base58 pubkey strings. The `AgentId` type (`number | string`) handles both.
 
-### EVM Networks (18)
+### EVM Networks (21)
+
+ethereum, base, polygon, arbitrum, optimism, celo, bsc, monad, avalanche, scroll, skale-base, arc, ethereum-sepolia, base-sepolia, polygon-amoy, arbitrum-sepolia, optimism-sepolia, celo-sepolia, avalanche-fuji, skale-base-sepolia, arc-testnet
 
-ethereum, base-mainnet, polygon, arbitrum, optimism, celo, bsc, monad, avalanche, skale-base, ethereum-sepolia, base-sepolia, polygon-amoy, arbitrum-sepolia, optimism-sepolia, celo-sepolia, avalanche-fuji, skale-base-sepolia
+Arc (`arc`, `arc-testnet`) since 2.98.0, with the canonical registries on both; see
+[ERC-8004 on Arc](docs/networks/arc.md#erc-8004-on-arc-2980).
 
 ### Solana Networks (2)
 
@@ -1345,14 +1359,16 @@ Pass the **same** feedback parameters, `deadline` and `nonce` back to
 registry calldata from them and refuses to relay anything the rater's signature
 does not cover.
 
-Available on the nine networks in `RELAYED_FEEDBACK_NETWORKS` -- the eight
+Available on the ten networks in `RELAYED_FEEDBACK_NETWORKS` -- the nine
 mainnets with a deployed `FeedbackDelegate` (base, ethereum, polygon, arbitrum,
-optimism, celo, bsc, monad) plus base-sepolia. **Avalanche is not one of them
+optimism, celo, bsc, monad, arc) plus base-sepolia. **Avalanche is not one of them
 and is not waiting to become one**: its C-Chain rejects the transaction type
 itself (`-32000 transaction type not supported`), so anchor the rating on a
 chain that supports EIP-7702 -- the payment stays where it was made.
+`arc-testnet` serves ERC-8004 reads but not this rail: no delegate is deployed
+there, and `prepare` answers 400.
 
-Requires facilitator v1.93.0+ for the mainnets; base-sepolia since v1.74.0.
+Requires facilitator v1.93.0+ for the mainnets (2.38.0+ for arc); base-sepolia since v1.74.0.
 
 ### The same thing on Solana, without a delegate
 
@@ -1986,4 +2002,13 @@ facilitator receipts: network, asset, atomic amount, payTo, request hash,
 settlement ID, status and refusal reason. Persist purchase context before sending
 the authorization and reuse it after uncertainty. Payment confirmation does not
 prove merchant delivery. See [the receipt guide](docs/facilitator-receipts.md).
-Live EURC acceptance remains pending.
+
+Every `/verify` and `/settle` carries an `Idempotency-Key`, the same one for both
+calls of a payment and for their retries: `verifyAndSettle` and both middlewares
+create one per payment, and `verify`/`settle` accept `{ idempotencyKey }`
+(`createIdempotencyKey()`). The facilitator returns an admitted payment's original
+answer (`SettleResponse.replayed`, from `Idempotent-Replayed: true`) only to that
+key or to the buyer's `X-UVD-Purchase`; a resend without them is
+`authorization_already_settled`, `authorization_in_flight` or
+`receipt_request_conflict`, and the SDK never serves it again.
+Funded EURC payments settled on Arc mainnet (x402 v1/v2, 2026-09-22); Arc testnet funded acceptance is pending.

package/dist/adapters/index.js

@@ -683,7 +683,8 @@ var SUPPORTED_CHAINS = {
   // Pinned by src/arc-testnet.test.ts.
   //
   // Mainnet (5042) and testnet (5042002) were verified independently against
-  // their official RPCs on 2026-09-16. EURC domains checked on 2026-09-17; live payments pending.
+  // their official RPCs on 2026-09-16. EURC domains checked on 2026-09-17; funded EURC payments settled on Arc mainnet on
+  // 2026-09-22 (x402 v1/v2, docs/networks/arc.md); testnet pending.
   arc: {
     chainId: 5042,
     chainIdHex: "0x13b2",