Desarrolladores · Bots

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

A bot integration is not a browser flow with the buttons removed. It needs duplicate prevention, restart-safe state, explicit wallet custody, and a clear rule for when liquidity should be private.

01

Secuencia del bot

  1. 01Carga un cliente de wallet de Base desde tu propia infraestructura de firma.
  2. 02Llama a deposits(walletAddress) antes de crear un nuevo depósito; reutiliza el inventario activo cuando encaje con la orden.
  3. 03Llama a offramp(walletClient, params) con integratorId y referralId para que la automatización pueda identificarse.
  4. 04Usa otcTaker cuando el comprador ya se conoce; de lo contrario, el depósito es de relleno público.
  5. 05Persiste depositId, txHash, platform, currency, amount y el contexto del comprador previsto.
  6. 06Poll deposits(address) or Peerlytics deposit/intent reads so fills and closes survive process restarts.
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.

Preguntas frecuentes

¿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.