---
name: "stablecoin_payments_for_agents"
description: "Run a USDC stablecoin payment on Base end to end: verify the token contract, do the 6-decimal amount math, estimate fees, apply approval gates, pre-send dry-run, and track the transaction to a confirmed receipt. Triggers whenever an agent must send or verify a USDC payment on Base (chain 8453), set up a payment workflow, or audit a planned send."
---

# Stablecoin Payments for Agents

## Purpose

Move USDC on Base (chain id 8453) safely, with the exact sequence an agent should follow: identity check, amount math, fee estimate, approval gates, dry run, send, confirm, log. This is the payment workflow layer that sits above generic fee tuning and defensive wallet hygiene: a checklist with concrete checks you can actually execute.

## Workflow

1. **Verify the token contract.** The canonical native USDC on Base is `0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913` (Circle's own registry: https://developers.circle.com/stablecoins/usdc-contract-addresses). Never match by ticker alone. Read `decimals()` (expect 6) and `symbol()` over RPC, and confirm the contract on Basescan (basescan.org) before the first send to it.
2. **Do the amount math once, in integers.** USDC has 6 decimals, so 1 USDC = 1,000,000 base units. `amount_units = round(dollars * 1e6)`. Print the result back in both dollars and units before signing anything; this is where six-figure bugs are born.
3. **Decide transfer vs approve.** A plain `transfer(to, amount)` is the path when the paying wallet is yours. `approve(spender, amount)` exists only when a contract (router, escrow, pass minter) will pull the funds. Approval gates: never grant unlimited allowances; scope the approval to the exact amount; treat any approval request above a configured per-payment ceiling as a hard stop that needs human sign-off. Suggested default ceiling: payments over $100 need approval, anything else is fine, adjust per operator policy.
4. **Estimate the fee right before the send.** Use `eth_estimateGas` for the actual transaction, then price it with the current base fee and a tip from the last few blocks (EIP-1559). Fees on Base are normally tiny, but never zero; the estimate feeds the balance check, not your curiosity. Re-estimate if the send is delayed; never reuse a stale estimate from an hour ago.
5. **Dry-run the send.** Run the transaction as `eth_call` with the same `from`, `to`, `data`, and fee fields first. A failed call means the real send would burn gas for a revert; fix the cause before proceeding. Confirm the sender balance covers amount plus the fee estimate. Read state on two RPCs if the number looks wrong: public Base RPCs can serve stale balance reads for a few seconds right after a transaction mines, so a suspicious zero deserves a second look, not a panic.
6. **Send, then track to receipt.** Capture the transaction hash. Poll `eth_getTransactionReceipt` with a timeout (Base blocks land about every 2 seconds, so a normal receipt arrives fast). If it is stuck, bump the fee instead of blindly resending the same fields. A receipt with status `1` is inclusion, not finality: for larger amounts wait a few minutes of block depth ("safe" on Base is roughly 2 minutes; full L1-backed finality takes about 20 minutes). Verify the Transfer event on the receipt and cross-check with Basescan or the Blockscout API (`https://base.blockscout.com/api/v2`).
7. **Log the payment.** One ledger row per payment: timestamp, chain, from, to, amount in USDC, tx hash, confirmations at sign-off, fee paid in ETH, operator, and the reason or invoice reference. No payment is done until the ledger row exists.

## Output Contract

For every payment the agent must produce, in this order: (a) a payment plan stating recipient, amount (both units and dollars), fee estimate, and the approval-gate decision; (b) the signed transaction hash after send; (c) the confirmed receipt with status and Transfer event; (d) the ledger row. If any step fails, the output is the failure evidence and what must change, never a retry loop on the same fields.

## Operating Rules

1. Never invent a contract address, chain id, or confirmation depth. Verify every factual claim against RPC, an explorer, or an official registry.
2. Verify identity of the token contract before the first send of the day, and verify the recipient address character by character (EIP-55 checksum) before every send. Address poisoning is real: the first and last characters matter, so do all of them.
3. Unlimited approvals are never granted. If a contract demands one, that is a stop-and-ask event.
4. A dry run that fails is a veto on the send, not a suggestion. Do not sign through it.
5. Treat a receipt as inclusion and a depth check as settlement. Say which one you have, never blur the two.
6. One send per payment instruction. If the state after a failed send is unknown, diagnose before any second attempt; do not send twice to "make sure."
7. This skill executes payments the operator authorized. It does not authorize spending, choose recipients, or set approval ceilings; those come from the operator's own standing policy.

Full step-by-step checklist with exact RPC calls, the approval-gate policy template, confirmation depth guidance, the ledger schema, and troubleshooting for stuck or dropped transactions: `references/payment-runbook.md`.