Skip to main content
Ace Data Cloud X402 currently settles around USDC and supports two types of chains: EVM and Solana. Different networks have different signing methods, asset addresses, gas behaviors, and applicable scenarios, so you need to choose the network before integration.

​
Network Identifiers Use CAIP-2

The accepts[].network of x402 v2 is a CAIP-2 identifier, not an abbreviation such as base or skale. Clients must compare by the CAIP-2 string when matching networks:

​
Support Matrix

upto is currently provided only on Base. The actual available options are subject to the accepts returned by the API. You can also check the Facilitator:
The response from Facilitator /supported:
Explanation of the results:
  • exact on Base, SKALE, and Solana is a fixed-amount payment path.
  • Only Base provides the upto post-metered path, which depends on Permit2 approve.
  • The extra.facilitatorAddress in the upto entry is the address that must be written into the witness when the client signs, and it must be consistent with the value returned by the server.

​
Base

Base uses the official USDC contract:
In the exact scheme, the client signs EIP-712 TransferWithAuthorization. The signature content includes:
  • from: payer wallet address
  • to: Ace Data Cloud receiving address
  • value: payment amount for this transaction
  • validAfter / validBefore: signature validity time window
  • nonce: 32-byte random nonce
After verifying the signature, the Facilitator calls USDC’s transferWithAuthorization on-chain to complete the transfer. Base is the most recommended network for production integration, especially suitable for upto post-metering, because the Permit2, USDC, and wallet ecosystems are all more mature. Example Base exact verification result:
Explanation of the results:
  • The API paid retry returns the model content ADC_BASE_E2E_OK.
  • The on-chain transaction can be queried on BaseScan, and the block number is 46726299.
  • 95215 atomic USDC corresponds to 0.095215 USDC, which is the actual settlement amount for this API call.
Program execution result for order payment using Base exact:
Explanation of the results:
  • The final platform order status is Finished.
  • The order pay_id is written with the same Base transaction hash.
  • 1200000 atomic USDC corresponds to 1.2 USDC, which is the historical actual payment amount for this 10 Credits order under the old policy; new orders no longer receive an additional X402 payment method discount, and the specific signature amount is subject to the 402 response of this transaction.

​
SKALE

SKALE uses bridged USDC. Its signing method is similar to Base and also uses EIP-3009. It is suitable for EVM payment scenarios with low gas costs; actual calls are still subject to the accepts returned by the API. A typical SKALE 402 accepts includes:
SKALE currently provides only exact. If you need post-metering, please use Base upto. Example SKALE exact verification result:
Explanation of the results:
  • API paid retry returned model content ADC_SKALE_E2E_OK.
  • The transaction can already be found in the SKALE explorer, and the block number is 1969317.
  • The settlement amount for this exact payment is 0.095215 USDC.

​
Solana

Solana uses SPL USDC TransferChecked. The client constructs a transfer transaction, signs and submits it, and then puts the transaction signature or serialized transaction into the PAYMENT-SIGNATURE envelope. Characteristics of Solana:
  • Uses Solana wallet adapter or base58 secret key;
  • The asset is Solana USDC mint;
  • Currently only supports exact;
  • The Facilitator validates the transfer instruction’s mint, destination, authority, and amount.
If using wallet fee payer mode, the wallet directly submits the transaction, and the Facilitator is responsible for confirming the transaction and returning the settlement result. Example of Solana exact validation result:
Result description:
  • The paid retry has already returned HTTP 200, and the model output ADC_SOLANA_E2E_OK.
  • Rate limiting may be encountered when querying the on-chain signature through public RPC.
  • Because public RPC queries may be rate-limited, the Solana explorer is not included here. When strict reconciliation is required, please use your own Solana RPC or platform-side settlement records to confirm the transaction signature.

​
How to Choose

No matter which chain you choose, do not hardcode prices on the client. The price is determined by the accepts[].maxAmountRequired returned by the server.