DEV Community

imokokok
imokokok

Posted on

When an AI Agent’s Swap Times Out, What Can It Safely Retry?

#ai #web3

An AI agent submits a WETH → USDC swap. The RPC request times out immediately afterward.

The application did not receive a transaction hash. That does not establish that the transaction was never broadcast. A retry routine that simply builds and signs another swap may create a second action while the first is still pending.

The useful question is: which operation are we retrying?

1. Observe the original attempt

Persist the prepared call and its identifiers before dispatch. Record the chain, sender, nonce, target, calldata hash, authorization ID, and transaction hash whenever one becomes available.

After a timeout, query the known hash and sender nonce through your configured chain observers. Keep these outcomes separate:

  • Pending: continue observing; do not infer failure.
  • Not found or RPC unavailable: the result is still uncertain. One missing response is not proof that nothing was broadcast.
  • Confirmed: recover the evidence for that execution. Do not submit another swap to fix a missing receipt.
  • Reverted: the transaction reached the chain but failed. A new swap is a new decision.
  • Reorged: preserve the earlier observation and reassess the canonical chain and required finality.

PriorSeal’s lifecycle documentation keeps pending, unavailable, reverted, and reorged states explicit. A confirmed or reverted transaction correlated with a single-use authorization consumes that authorization; an action mismatch does not reopen it.

2. Retry evidence collection without executing again

If the transaction hash is known and the combined Insight–PriorSeal workflow has saved a checkpoint, the application can resume evidence recovery:

import { InsightGuard } from 'oracle-insight-guard';

const guard = new InsightGuard({
  apiKey: process.env.INSIGHT_API_KEY!,
});

const checkpoint = JSON.parse(await loadCheckpoint());

const recovered = await guard.resumeAssessedSwapExecution(
  checkpoint,
  { client: priorSealClient }
);

await saveCheckpoint(JSON.stringify(recovered.checkpoint));
Enter fullscreen mode Exit fullscreen mode

The application supplies loadCheckpoint, saveCheckpoint, and priorSealClient. This recovery path has no transaction signing or submission callback. It retains existing evidence, checks the existing observation job, and requests missing artifacts. Insight’s SDK guide also provides an evidence-only receipt retry for its independent execution flow.

This code does not resolve a lost broadcast response when no transaction hash or checkpoint was recorded. That attempt remains uncertain until it is reconciled against chain and signer state.

3. Treat a new execution as a new decision

Only consider another trade after assessing whether the original could still execute. Rebuild and review the exact call, refresh the oracle and route evidence, and obtain a new time-bounded authorization when the previous single-use authorization has been consumed or the call has changed.

Insight’s transaction-specific review describes a simulated quote at one observed block. Changed calldata or expired evidence requires a fresh review. A past favorable assessment cannot approve a later transaction by itself.

The central recovery rule is simple: retry observation and missing evidence; never turn an uncertain response into automatic permission for another trade.

What does your agent persist before it asks a signer to broadcast?

Top comments (0)