Turnkey guide: Agentic USDC payouts on Base, 2026

Turnkey published a developer guide outlining how to deploy agentic USDC payouts on Base. The documentation, updated in June 2026 with references current as of October 4, 2026, describes a production pattern for automated systems and AI agents that must send USDC on Base.

The reference architecture centers on one dedicated company wallet per agent or trust tier, a non‑root P‑256 API key for the agent runtime, and policy checks executed inside Turnkey’s enclave before signatures are produced. Administrators must create EFFECT_ALLOW policies scoped to the agent wallet that pin the Base USDC contract address and any destination allowlists or spend caps required. Turnkey’s default policy is deny, so an agent cannot sign or send until explicit ALLOW policies exist.

Root-level setup requires creating an organization and provisioning a SECP256K1 wallet using a BIP32 path. Teams generate a non‑root API user whose private API key never touches Turnkey. Administrators then add ALLOW policies that reference the agent wallet and the token contract for Base USDC. The Base USDC contract used in the guide is 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913 and the CAIP2 identifier for Base mainnet is eip155:8453.

At runtime the agent checks balances with getWalletAddressBalances on CAIP2 eip155:8453 and encodes an ERC‑20 transfer to the USDC contract. The agent calls ethSendTransaction with sponsor:true so Turnkey sponsors gas while the agent wallet holds USDC and zero native ETH. After submission, operators confirm settlement by polling pollTransactionStatus or receiving webhooks until the transaction status is INCLUDED and by verifying the returned eth.txHash on a Base block explorer.

The guide notes that ERC‑20 transfers are sent to the token contract and that the recipient is encoded in calldata. Policies that only check eth.tx.to therefore pin the token contract but do not constrain the human recipient. Operators can upload the token ABI and write policies that inspect function parameters to restrict recipients. The documentation also shows how to use EFFECT_DENY to cap native‑value transfers and how to require multi‑party consensus for higher‑value operations.

Turnkey documents two additional rails that reuse the same wallet foundation. After the sponsored ERC‑20 payout is working, teams can add an x402 client via @turnkey/viem for HTTP 402‑style interactions or pass the account into Mppx for MPP rails. The guide advises that root credentials are needed only for initial wallet, user and policy creation and should be kept separate from agent keys in a secrets manager. If compromise is suspected, the recommended immediate revocation method is deleting the agent user. The guide lists API names and example values, including getWalletAddressBalances, ethSendTransaction, pollTransactionStatus and a sample amount of 1_000_000n to represent 1.00 USDC with six decimals.