Desarrolladores · Bots

Ejecuta automatización de depósitos sin inventar un gestor de tasas.

Una integración de bot no es un flujo de navegador con los botones quitados. Necesita prevención de duplicados, estado a prueba de reinicios, custodia explícita de la wallet, verificación de webhooks y una regla clara para cuándo la liquidez debe ser privada.

01

Secuencia del bot

  1. 1Carga un cliente de wallet de Base desde tu propia infraestructura de firma.
  2. 2Llama a deposits(walletAddress) antes de crear un nuevo depósito; reutiliza el inventario activo cuando encaje con la orden.
  3. 3Llama a offramp(walletClient, params) con integratorId y referralId para que la automatización pueda identificarse.
  4. 4Usa otcTaker cuando el comprador ya se conoce; de lo contrario, el depósito es de relleno público.
  5. 5Persiste depositId, txHash, platform, currency, amount y el contexto del comprador previsto.
  6. 6Registra webhooks HMAC para que los fills y los cierres sobrevivan a los reinicios del proceso.
02

Disciplina de reintentos

  • El SDK reanuda los depósitos sin delegar delegándolos en lugar de crear un duplicado.
  • El cacheo de idempotencyKey del navegador no protege a los workers de Node. Tu worker debería comprobar deposits(address) antes de crear nueva liquidez.
  • Si la delegación falla tras la creación, reintenta la misma ruta de wallet; la vía de reanudación está diseñada para ese estado.
  • No reintentes USER_CANCELLED automáticamente. Eso indica que un firmante rechazó un aviso.

Common questions

¿Puede un backend crear depósitos sin una wallet de usuario?

Sí, si tiene su propio firmante de Base y saldo de USDC. El SDK firma a través del WalletClient de viem que le proporcionas; la custodia y la gestión de claves son tuyas.

¿idempotencyKey previene depósitos de bot duplicados?

No. idempotencyKey está respaldado por la sesión del navegador. En Node o en workers, usa deposits(address) y tu propia base de datos de órdenes para prevenir inventario duplicado.