ERC20 transfer reports "Transferred" when the transaction reverts (receipt status ignored)
Los mantenedores suelen responder en 1 día
@AgenticFinanceGraph ya está trabajando en esto.
Desde el 12/10/2026.
Evaluación
- Dificultad
- 2/5
- Tiempo estimado
- 1-3 horas
- Aptitud para principiantes
- 65/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Activo
- Stack tecnológico
- typescript
Línea de trabajo
Empieza en ERC20ActionProvider.transfer e inspecciona cómo se gestiona el recibo devuelto por waitForTransactionReceipt; el issue indica que la ruta estándar de transferencia lo descarta, y que approve y gasless transfer podrían hacer lo mismo. Añade pruebas para un recibo revertido y verifica que la action indique un fallo en lugar de afirmar que la transferencia se realizó correctamente. El issue ofrece un archivo de reproducción, pero no menciona archivos de prueba.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Version: @coinbase/agentkit 0.10.4 (latest on npm); same code on main at 2e6dbaf.
What happens. ERC20ActionProvider.transfer sends the transaction, awaits the receipt and then always returns a success message:
const hash = await walletProvider.sendTransaction({ ... functionName: "transfer" ... });
await walletProvider.waitForTransactionReceipt(hash); // receipt discarded
return Transferred ${args.amount} of ${tokenDetails?.name} ...;
With ViemWalletProvider, waitForTransactionReceipt resolves with status: "reverted" for a mined, failed transaction; it does not throw. So a transfer that reverts after AgentKit's pre-checks pass is reported to the agent as "Transferred …", with the hash. No tokens moved.
This happens whenever the token's state changes between gas estimation and inclusion: an issuer pause or blacklist (as USDC supports), a balance or allowance used by a concurrent transaction, or a token with conditional transfer logic.
Reproduction. Attached agentkit-reverted-transfer-poc.zip: npm install && node poc.mjs. It runs on a local Ganache chain with throwaway keys, using the unmodified AgentKit, ViemWalletProvider and erc20ActionProvider; the only test hook pauses the token immediately before the signed transfer is broadcast.
== Control: normal transfer
AgentKit output : Transferred 100 of PoC Token (0x…) to 0x….
Receipt status : success
Transfer events : 1
Payee received : 100 POC
== Bug: token paused after signing, before inclusion
AgentKit output : Transferred 100 of PoC Token (0x…) to 0x….
Receipt status : reverted
Transfer events : 0
Payee received : 0 POC
The same behaviour on public Base Sepolia with our own test token and wallet: https://sepolia.basescan.org/tx/0x844bfcd961a4422ce050bef365f1274b480db60504b55311c1a97287ae839a82 (reverted, no Transfer event; AgentKit returned "Transferred 200 … Transaction hash for the transfer: 0x844bfcd9…").
Why it matters. An agent is told a payment succeeded, with a valid hash, when nothing moved. It then marks the invoice paid or confirms the order. No funds are taken from the wallet; the problem is a false payment confirmation.
Suggested fix.
const receipt = await walletProvider.waitForTransactionReceipt(hash);
if (receipt.status !== "success") {
return Error: transfer transaction ${hash} was mined but reverted; no tokens were transferred.;
}
By code inspection (not separately reproduced), approve and the gasless-transfer path of transfer in the published 0.10.4 build follow the same pattern.
Related: #1547 is the opposite case (a sent transfer reported as failed because the receipt lookup throws). A fix for both could wait for the receipt in its own try, return the hash with "sent, not confirmed" when the wait throws, and return an explicit revert error when status is "reverted".
Happy to open a PR with the fix and tests.
Found with EmberTail (https://embertail.xyz/), which tests payment correctness of AI agents.
- Lenguaje dominante
- TypeScript
- Estrellas
- 1.4k
- Forks
- 900
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de coinbase/agentkit
-
SolanaKeypairWalletProvider returns a signature when confirmation reports an execution errorPosiblemente ocupada @snuff12 la tomó hace 4 días. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
Los mantenedores suelen responder en 1 día
-
Python: Permit2 approval in CdpSmartWalletActionProvider.swap always reports failure (integer vs string receipt status)Posiblemente ocupada @0xLittleDream la tomó hace 12 días. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
coinbase/agentkit#1592 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
-
Moonwell redeem fails on Base Sepolia and uses 18 decimals for cbBTCPosiblemente ocupada @sebxt la tomó hace 15 días. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
coinbase/agentkit#1578 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
[TypeScript] `ViemWalletProvider` rejects a wallet client from a newer viem than the exactly pinned one (TS2345, `tokens` missing on `Client`)Posiblemente ocupada @PrabalParihar la tomó hace 15 días. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
coinbase/agentkit#1532 · 5 comentarios ·
Los mantenedores suelen responder en 1 día
-
coinbase-agentkit 0.7.x fails on fresh install: imports solana.rpc.api, which solana>=0.37 removedPosiblemente ocupada @JulienKervarrec la tomó hace 42 días. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día
Todos los issues de coinbase/agentkit
Issues similares
-
[Text] Add Reading Time & Word Count Estimator for Reflection Notes in src/lib/text/reading-time.tsAbiertoarea:core beginner-friendly community contributions-welcome difficulty:easy enhancement good first issue
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
Los mantenedores suelen responder en 1 día
-
[fullsend] E2E: scorecard — filecheck GitLab entity metrics unavailable due to initialDelay timingAbiertoe2e-failure ready-to-code
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
redhat-developer/rhdh-plugin-export-overlays#4698 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
devswha/herdr-web-ui#2884 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
b:minor bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
software-mansion/argent#1771 ·
Los mantenedores suelen responder en 1 día