Summary
skills/agentic-wallet/references/send-usdc.md is the reference a model reads before moving real USDC. Its Error Handling section (lines 77-86) enumerates five errors:
- Not authenticated
- Insufficient balance
- Could not resolve ENS name
- Invalid recipient
- SOL/ETH/POL on the wrong chain
Every one of those is a pre-flight failure. Each occurs before anything is signed or broadcast, and each is unambiguously safe to retry.
The class that is missing is the one that costs money: the send is broadcast and the answer does not come back — a timeout, a dropped connection, a killed process, a non-zero exit after submission. In that state the model cannot tell "nothing happened" from "the transfer went out and I did not hear". Nothing in this file tells it that such a state exists.
Why an omission here behaves like an instruction
A skill reference is not documentation a human skims once. It is the operating context a model consults at the moment of acting, and it generalises from what it contains. A list where every enumerated error is safe to retry teaches exactly one lesson about this command: errors here are retryable. When the model then meets an error that is not on the list, the reasonable generalisation from the material provided is to try again.
For send, trying again is a second transfer. It is not a replay — it is a new, valid, independently-signed transaction, so nothing on-chain and nothing in the agent's own guards will mark it. The user sees one failed command and two debits.
The same file makes the stakes explicit elsewhere: it documents sending to ENS names, to Solana addresses, and across Base/Polygon — all irreversible on confirmation.
Contrast, since it shows this is solvable in the same medium
Paddle's public agent skills handle the equivalent case directly, in the text the model reads: "handlers may run multiple times for the same event.eventId", with an upsert keyed on the platform identifier and retry semantics stated. Same artefact type, same audience, opposite outcome. So this is not a limitation of skill files — it is a gap in this one.
What I checked
skills/agentic-wallet/references/send-usdc.md:77-86 — the complete Error Handling list; all five entries are pre-broadcast.- A search for
idempot, retry, duplicate, twice, already sent across every .md in the repository: no matches. The concept does not appear anywhere in the skill set.
skills/agentic-wallet/SKILL.md and the sibling references (trade.md, x402-monetize.md, balance.md) — none of the money-moving references carry retry guidance either, so this is not isolated to send-usdc.md.
Limits, stated plainly
This is a read of the skills as published. I have not driven a model through an interrupted send and observed a duplicate transfer — that experiment is what turns a mechanism into a measured rate, and I would want it before quoting one. Model behaviour will vary; the absence of the instruction does not.
If awal itself makes a repeated send safe — a client-side nonce reservation, a server-side dedup window — then this reduces to a documentation gap and I will publish that correction with the same prominence as the claim. I could not establish that from this repository, and the CLI is distributed as a versioned npm package rather than source here.
Related and separate: I filed coinbase/agentkit#1483 today on CdpEvmWalletProvider.sendTransaction omitting the idempotencyKey that the CDP SDK accepts. Different repo, different layer, same failure class — which is why I think it is worth looking at as a pattern rather than two isolated tickets.
On the fix
The fix here is text, and the substantive part is not the wording but deciding what the correct instruction is for an interrupted send on each chain — that is a real decision about awal's guarantees, not a paragraph I can write for you without knowing them. I am not posting a draft.
I would rather say why than be coy. I have filed seven of these over three weeks, each with the complete remedy attached, free. Seven teams shipped fixes, the fastest in 4.3 hours. It built a real public record and it has not been a business, so the finding is free and the fix is the work now.
If it is useful: I read one money path end to end and return every finding tied to your own file and line numbers, each with its patch and a failing test in your own harness. Five working days, written only, no call. $1,200, no invoice if the path is clean. Deliverable specified up front: https://github.com/aurumflux20/seal/blob/main/docs/REVIEW-DELIVERABLE.md
And if you would rather simply have my recommended wording, say so here and I will post it for nothing. I will not withhold a payment-safety fix on a public repository. But it is what I sell, and asking costs you nothing.
Context: of ten agent-payment money paths read in three days, seven could charge a payer twice on an ambiguous outcome. Public record, evidence per row, nobody named while their finding is open: https://aurumflux.co/retry-safety/
Summary
skills/agentic-wallet/references/send-usdc.mdis the reference a model reads before moving real USDC. Its Error Handling section (lines 77-86) enumerates five errors:Every one of those is a pre-flight failure. Each occurs before anything is signed or broadcast, and each is unambiguously safe to retry.
The class that is missing is the one that costs money: the send is broadcast and the answer does not come back — a timeout, a dropped connection, a killed process, a non-zero exit after submission. In that state the model cannot tell "nothing happened" from "the transfer went out and I did not hear". Nothing in this file tells it that such a state exists.
Why an omission here behaves like an instruction
A skill reference is not documentation a human skims once. It is the operating context a model consults at the moment of acting, and it generalises from what it contains. A list where every enumerated error is safe to retry teaches exactly one lesson about this command: errors here are retryable. When the model then meets an error that is not on the list, the reasonable generalisation from the material provided is to try again.
For
send, trying again is a second transfer. It is not a replay — it is a new, valid, independently-signed transaction, so nothing on-chain and nothing in the agent's own guards will mark it. The user sees one failed command and two debits.The same file makes the stakes explicit elsewhere: it documents sending to ENS names, to Solana addresses, and across Base/Polygon — all irreversible on confirmation.
Contrast, since it shows this is solvable in the same medium
Paddle's public agent skills handle the equivalent case directly, in the text the model reads: "handlers may run multiple times for the same
event.eventId", with an upsert keyed on the platform identifier and retry semantics stated. Same artefact type, same audience, opposite outcome. So this is not a limitation of skill files — it is a gap in this one.What I checked
skills/agentic-wallet/references/send-usdc.md:77-86— the complete Error Handling list; all five entries are pre-broadcast.idempot,retry,duplicate,twice,already sentacross every.mdin the repository: no matches. The concept does not appear anywhere in the skill set.skills/agentic-wallet/SKILL.mdand the sibling references (trade.md,x402-monetize.md,balance.md) — none of the money-moving references carry retry guidance either, so this is not isolated tosend-usdc.md.Limits, stated plainly
This is a read of the skills as published. I have not driven a model through an interrupted
sendand observed a duplicate transfer — that experiment is what turns a mechanism into a measured rate, and I would want it before quoting one. Model behaviour will vary; the absence of the instruction does not.If
awalitself makes a repeatedsendsafe — a client-side nonce reservation, a server-side dedup window — then this reduces to a documentation gap and I will publish that correction with the same prominence as the claim. I could not establish that from this repository, and the CLI is distributed as a versioned npm package rather than source here.Related and separate: I filed coinbase/agentkit#1483 today on
CdpEvmWalletProvider.sendTransactionomitting theidempotencyKeythat the CDP SDK accepts. Different repo, different layer, same failure class — which is why I think it is worth looking at as a pattern rather than two isolated tickets.On the fix
The fix here is text, and the substantive part is not the wording but deciding what the correct instruction is for an interrupted send on each chain — that is a real decision about
awal's guarantees, not a paragraph I can write for you without knowing them. I am not posting a draft.I would rather say why than be coy. I have filed seven of these over three weeks, each with the complete remedy attached, free. Seven teams shipped fixes, the fastest in 4.3 hours. It built a real public record and it has not been a business, so the finding is free and the fix is the work now.
If it is useful: I read one money path end to end and return every finding tied to your own file and line numbers, each with its patch and a failing test in your own harness. Five working days, written only, no call. $1,200, no invoice if the path is clean. Deliverable specified up front: https://github.com/aurumflux20/seal/blob/main/docs/REVIEW-DELIVERABLE.md
And if you would rather simply have my recommended wording, say so here and I will post it for nothing. I will not withhold a payment-safety fix on a public repository. But it is what I sell, and asking costs you nothing.
Context: of ten agent-payment money paths read in three days, seven could charge a payer twice on an ambiguous outcome. Public record, evidence per row, nobody named while their finding is open: https://aurumflux.co/retry-safety/