Desenvolvedores · Bots

Rode a automação de depósitos sem inventar um gerente de taxas.

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

Sequência do bot

  1. 01Carregue um wallet client da Base a partir da sua própria infraestrutura de signatário.
  2. 02Chame deposits(walletAddress) antes de criar um novo depósito; reutilize o inventário ativo quando ele couber na ordem.
  3. 03Chame offramp(walletClient, params) com integratorId e referralId para que a automação possa ser identificada.
  4. 04Use otcTaker quando o comprador já for conhecido; caso contrário, o depósito é preenchível publicamente.
  5. 05Persista depositId, txHash, platform, currency, amount e o contexto do comprador pretendido.
  6. 06Poll deposits(address) or Peerlytics deposit/intent reads so fills and closes survive process restarts.
02

Disciplina de retentativa

  • O SDK retoma depósitos não delegados delegando em vez de criar uma duplicata.
  • O cache de idempotencyKey do navegador não protege workers Node. Seu worker deve verificar deposits(address) antes de criar nova liquidez.
  • Se a delegação falhar após a criação, tente a mesma rota de carteira novamente; o caminho de retomada foi projetado para esse estado.
  • Não tente novamente USER_CANCELLED automaticamente. Isso indica que um signatário rejeitou um prompt.

Perguntas comuns

Um backend pode criar depósitos sem uma carteira de usuário?

Sim, se ele tiver seu próprio signatário da Base e saldo de USDC. O SDK assina por meio do WalletClient da viem que você fornece; a custódia e o gerenciamento de chaves são seus.

O idempotencyKey evita depósitos duplicados de bot?

Não. O idempotencyKey é respaldado pela sessão do navegador. Em Node ou workers, use deposits(address) e o seu próprio banco de dados de ordens para evitar inventário duplicado.