Développeurs · Base

Vérifiez l’attribution du Builder Code pour les dépôts USDCtoFiat.

Le code attribué est intégré à la calldata des transactions de l’application en production. Ce guide indique quel parcours gère le suffixe et ce qui doit être vérifié après une transaction.

Partir du modèle BaseOuvrir le flux de vente
01

Séquence d attribution

  1. 01Déployez la Base Mini App sur une origine HTTPS stable.
  2. 02Enregistrez et vérifiez l app sur Base.dev.
  3. 03Copiez le vrai Builder Code depuis les paramètres Base.dev.
  4. 04Générez le dataSuffix ERC-8021 depuis ce code avec ox/erc8021.
  5. 05Pour un parcours de transaction directe que vous gérez, ajoutez un unique dataSuffix normalisé après avoir supprimé tout suffixe existant.
  6. 06Créez un petit dépôt USDCtoFiat et vérifiez l attribution avant de lancer une campagne.
02

Où cela appartient

SurfaceChemin d attribution
Base AppLa documentation Base indique que les apps enregistrées peuvent recevoir une attribution automatique pour l activité dans la Base App.
App webL’adaptateur web USDCtoFiat remplace tout suffixe existant et ajoute les codes de production.
SDK USDCtoFiatLe SDK fournit son propre référent galleonlabs. N’ajoutez pas un second suffixe côté client ; l’API actuelle du SDK ne prend pas en charge les codes d’intégrateur distincts.
ContratsAucun changement de contrat n est nécessaire ; les données de suffixe ERC-8021 sont ajoutées au calldata et indexées offchain.
03

Notes d implémentation

  • Utilisez viem 2.45.0 ou plus récent pour le parcours documenté par Base ; cette app utilise déjà une version plus récente de viem.
  • L’adaptateur de production de USDCtoFiat est configuré avec un Builder Code attribué. La bonne attribution doit néanmoins être vérifiée au niveau de la transaction.
  • Pour les transactions directes avec Viem ou Wagmi que vous gérez, générez un unique dataSuffix à partir de tous les codes prévus.
  • Ne concaténez pas des suffixes ERC-8021 indépendants. Analysez et remplacez le suffixe, ou fusionnez les codes en un seul suffixe avant de signer.
  • Le SDK @usdctofiat/offramp fournit déjà l’attribution Galleon Labs. Il ne propose pas d’option distincte pour fusionner un Builder Code.
04

Vérification

ContrôleCondition de réussite
Base.devLes compteurs de transactions onchain augmentent pour le Builder Code de l app.
Explorateur de blocsL input de transaction se termine par le marqueur de suffixe ERC-8021 et se décode vers le code attendu.
Résultat USDCtoFiatLe dépôt créé renvoie depositId et txHash, puis apparaît dans deposits(address).
PeerlyticsLe cycle de vie du dépôt et de l intent peut être inspecté après rattrapage de l indexation.

Poursuivre l’exploration

SDK d’off-rampAPI PeerlyticsEspace développeurs

Questions fréquentes

USDCtoFiat utilise-t-il déjà un Builder Code émis ?

Oui. L’adaptateur de production ajoute le Builder Code qui lui a été attribué à la calldata onchain du dépôt. Vérifiez la bonne attribution dans Base.dev ou un explorateur de blocs après une transaction réelle.

@usdctofiat/offramp a-t-il besoin d une option Builder Code séparée ?

Non. Le SDK fournit déjà un référent galleonlabs et ne propose actuellement aucun parcours pris en charge pour fusionner un Builder Code distinct. N’ajoutez pas un second suffixe côté client.

ERC-8021 change-t-il les contrats ZKP2P ?

Non. La documentation Base décrit les Builder Codes comme une attribution par suffixe calldata. Les contrats s exécutent normalement ; l attribution est lue par des indexeurs offchain après l arrivée de la transaction.