Faites tourner l'automatisation de dépôts sans inventer de gestionnaire de taux.
Une intégration de bot n'est pas un flux de navigateur dont on aurait retiré les boutons. Elle a besoin de prévention des doublons, d'un état résilient aux redémarrages, d'une custody de wallet explicite, de vérification des webhooks et d'une règle claire pour savoir quand la liquidité doit être privée.
Séquence du bot
- 1Chargez un wallet client Base depuis votre propre infrastructure de signature.
- 2Appelez deposits(walletAddress) avant de créer un nouveau dépôt ; réutilisez l'inventaire actif quand il correspond à l'ordre.
- 3Appelez offramp(walletClient, params) avec integratorId et referralId pour que l'automatisation puisse être identifiée.
- 4Utilisez otcTaker quand l'acheteur est déjà connu ; sinon le dépôt est remplissable publiquement.
- 5Persistez depositId, txHash, platform, currency, amount et le contexte de l'acheteur visé.
- 6Enregistrez des webhooks HMAC pour que les fills et les clôtures survivent aux redémarrages de processus.
Discipline de retry
- Le SDK reprend les dépôts non délégués en les déléguant au lieu de créer un doublon.
- Le cache navigateur idempotencyKey ne protège pas les workers Node. Votre worker devrait vérifier deposits(address) avant de créer de la nouvelle liquidité.
- Si la délégation échoue après la création, réessayez la même route de wallet ; le chemin de reprise est conçu pour cet état.
- Ne réessayez pas USER_CANCELLED automatiquement. Cela indique qu'un signataire a rejeté une invite.
Patterns de bots utiles
File de paie ou de paiements
Créez un dépôt OTC privé par wallet acheteur connu, puis envoyez le lien retourné.
Bot de liquidité de trésorerie
Maintenez un petit dépôt délégué sur une route préférée et réapprovisionnez après les fills confirmés par webhook.
Réconciliation de support
Utilisez depositId et txHash comme identifiants de support, puis réconciliez avec deposits(address).
Keep exploring
Common questions
Un backend peut-il créer des dépôts sans wallet utilisateur ?
Oui, s'il dispose de son propre signataire Base et d'un solde en USDC. Le SDK signe via le WalletClient viem que vous fournissez ; la custody et la gestion des clés vous appartiennent.
idempotencyKey empêche-t-il les dépôts de bot en double ?
Non. idempotencyKey est soutenu par la session du navigateur. Dans Node ou les workers, utilisez deposits(address) et votre propre base de données d'ordres pour empêcher l'inventaire en double.