Skip to main content
Ace Data Cloud X402 est actuellement centré sur le règlement en USDC et prend en charge deux types de chaînes : EVM et Solana. Les méthodes de signature, les adresses d’actifs, le comportement du gas et les scénarios applicables diffèrent selon les réseaux ; vous devez donc choisir le réseau avant l’intégration.

​
Les identifiants de réseau utilisent CAIP-2

Le champ accepts[].network de x402 v2 est un identifiant CAIP-2, et non une abréviation telle que base ou skale. Les clients doivent comparer les réseaux selon la chaîne CAIP-2 :

​
Matrice de prise en charge

upto est actuellement fourni uniquement sur Base. Les options réellement disponibles dépendent du champ accepts renvoyé par l’API. Vous pouvez également consulter le Facilitator :
La réponse de Facilitator /supported :
Explication des résultats :
  • Les exact de Base, SKALE et Solana sont des parcours de paiement à montant fixe.
  • Seule Base fournit le parcours de facturation a posteriori upto, qui dépend de l’approbation Permit2.
  • L’adresse extra.facilitatorAddress dans l’entrée upto est l’adresse que le client doit inscrire dans le witness lors de la signature ; elle doit être identique à la valeur renvoyée par le serveur.

​
Base

Base utilise le contrat USDC officiel :
Dans le schéma exact, le client signe EIP-712 TransferWithAuthorization. Le contenu de la signature comprend :
  • from : adresse du wallet payeur
  • to : adresse de réception d’Ace Data Cloud
  • value : montant de ce paiement
  • validAfter / validBefore : fenêtre de validité de la signature
  • nonce : nonce aléatoire de 32 octets
Après avoir vérifié la signature, le Facilitator appellera transferWithAuthorization de l’USDC on-chain afin d’effectuer le transfert. Base est le réseau le plus recommandé pour une intégration officielle, particulièrement pour la facturation a posteriori upto, car les écosystèmes Permit2, USDC et de wallets y sont plus matures. Exemple de résultat de vérification Base exact :
Explication des résultats :
  • Le paid retry de l’API renvoie le contenu de modèle ADC_BASE_E2E_OK.
  • La transaction on-chain est consultable sur BaseScan, et le numéro de bloc est 46726299.
  • 95215 atomic USDC correspond à 0.095215 USDC, soit le montant réellement réglé pour cet appel API.
Résultat de l’exécution du programme de paiement de commande Base exact :
Explication des résultats :
  • L’état final de la commande de la plateforme est Finished.
  • Le pay_id de la commande inscrit le même hash de transaction Base.
  • 1200000 atomic USDC correspond à 1.2 USDC, soit le montant historique effectivement payé pour cette commande de 10 Credits sous l’ancienne politique ; les nouvelles commandes ne bénéficient plus d’une remise supplémentaire pour le mode de paiement X402, et le montant de la signature dépend de la réponse 402 actuelle.

​
SKALE

SKALE utilise de l’USDC bridgé ; sa méthode de signature est similaire à celle de Base et utilise également EIP-3009. Il convient aux scénarios de paiement EVM à faible coût de gas ; les appels effectifs dépendent toujours du champ accepts renvoyé par l’API. Les accepts 402 typiques de SKALE incluent :
SKALE fournit actuellement uniquement exact. Si vous avez besoin d’une facturation a posteriori, utilisez Base upto. Exemple de résultat de vérification SKALE exact :
Explication des résultats :
  • La nouvelle tentative payante de l’API renvoie le contenu du modèle ADC_SKALE_E2E_OK。
  • La transaction est consultable dans le SKALE explorer, avec le numéro de bloc 1969317。
  • Le montant de règlement de ce paiement exact est de 0.095215 USDC。

​
Solana

Solana utilise SPL USDC TransferChecked。Le client construit une transaction de transfert, la signe et la soumet, puis place la signature de la transaction ou la transaction sérialisée dans l’enveloppe PAYMENT-SIGNATURE。 Les caractéristiques de Solana：
  • utilise Solana wallet adapter ou une clé secrète base58；
  • l’actif est le mint Solana USDC；
  • seul exact est actuellement pris en charge；
  • le Facilitator vérifiera le mint, la destination, l’authority et le amount de la transfer instruction。
Si le mode wallet fee payer est utilisé, le wallet soumet directement la transaction, et le Facilitator est responsable de confirmer la transaction et de renvoyer le résultat de settlement。 Exemple de résultat de vérification Solana exact：
Explication des résultats：
  • La nouvelle tentative payante a déjà renvoyé HTTP 200, et le modèle a généré ADC_SOLANA_E2E_OK。
  • Des limitations de débit peuvent être rencontrées lors de la requête de la signature on-chain via le RPC public。
  • Étant donné que les requêtes RPC publiques peuvent être limitées en débit, le Solana explorer n’est pas indiqué ici。Lorsqu’une réconciliation stricte est nécessaire, veuillez utiliser votre propre RPC Solana ou les enregistrements de règlement côté plateforme pour confirmer la signature de la transaction。

​
Comment choisir

Quelle que soit la chaîne choisie, ne codez pas en dur les prix dans le client。Le prix est déterminé par accepts[].maxAmountRequired renvoyé par le serveur。