Recurring Base USDC subscriptions for ENS agent infrastructure

Agents need identity and evidence before they need billing. Once an agent or fleet becomes production infrastructure, however, it also needs predictable capacity, durable receipts, renewal, cancellation, and an unambiguous recovery path.

ENS.Tools now supports one paid path for that layer: a recurring subscription denominated in official USDC on Base. Stripe, one-off transfers, ETH payments, and per-call x402 are not offered. Keeping one path makes the wallet boundary, entitlement rule, and support story easier for humans and agents to reason about.

This article covers platform capacity only. Agent-job escrow may separately use allowlisted USDC or WETH on Base or Ethereum, while ENS registration, renewal, gas, and marketplace settlement have their own onchain costs. Those flows never start or renew a capacity plan.

What a subscription buys

Operator, Team, and Scale increase authenticated gateway and deterministic sandbox capacity. Payment never buys a better directory rank, verification grade, health result, policy decision, canary result, or escrow label. Those remain derived from evidence.

Approval is bounded; charging is separate

A wallet-owned developer account chooses a plan in the direct Operator subscription journey (39 USDC every 30 days), or selects another plan in the developer console. The connected wallet—including MetaMask—can remain the developer account and ENS owner. A separate Base Account then approves a 30-day USDC spend permission for the isolated ENS.Tools subscription owner because Coinbase Base’s recurring primitive requires a smart account. The permission fixes the token, amount, period, payer, and spender. It is not an open-ended wallet grant.

Do customers already have a Base Account?

Not necessarily. A Base Account is Coinbase’s self-custodial smart wallet, not a generic name for every wallet on the Base network. Existing Base App or Smart Wallet users can sign in to the checkout. A new user can create a Base Account there with email or a passkey; they do not need to open a Coinbase exchange account. See Base’s Base Account overview.

The Base Account has its own balance. It must hold the plan amount in official USDC on Base before it can approve the subscription. USDC held only in MetaMask, in a Coinbase exchange balance, or on another network is not available to this permission. The checkout’s Fund from another wallet step moves money into the Base Account; the later approval still does not pay ENS.Tools.

After approval, the developer-account owner signs a short-lived EIP-712 message linking that exact payer, permission hash, plan, raw amount, period, nonce, and expiry. It sends no transaction, adds no allowance, and does not move the ENS name. If the owner does not sign, ENS.Tools does not register the permission and cannot charge it.

Linking still does not pay. The console next shows Not paid, the exact plan price, and a separate Pay … USDC now action. Only that explicit action authorises ENS.Tools to start the first transfer. The server then charges the exact due amount to enstools.eth, exposes the Base transaction when one exists, waits for five confirmations, and verifies the official USDC transfer log, payer, recipient, amount, and billing period. Only that evidence can extend entitlement.

Four roles, four different jobs

1. The developer-account owner controls the ENS identity and API-key administration. It may be MetaMask or another EOA or smart wallet and signs only the one-time billing link.
2. The customer Base Account holds subscription USDC and approves the exact recurring limit. It does not gain control of the ENS identity or developer account.
3. The isolated subscription-owner smart wallet is controlled by the ENS.Tools server through Coinbase CDP. It can exercise only a valid spend permission; it is not the treasury and should not hold customer subscription funds.
4. enstools.eth is the fixed treasury recipient. A successful charge sends the USDC directly there.

The API-using agent needs none of those wallet secrets. It receives a wallet-owned ENS.Tools API key after the operator creates it. This keeps payment approval, billing execution, treasury custody, and the agent runtime separate.

Who pays network gas?

The subscription-owner wallet executes an onchain charge or revocation. It therefore needs a small Base ETH balance for network gas, or ENS.Tools can configure a Coinbase Paymaster through PAYMASTER_URL to sponsor those transactions. Gas sponsorship changes who pays the network fee; it does not change the USDC allowance or recipient.

Base documents the Paymaster as optional for backend subscription charges. ENS.Tools treats a failed or unconfirmed transaction as unpaid and keeps the entitlement fail-closed.

Every state is recoverable

If Base Account approval succeeds but the server is unavailable or the browser reloads before linking, the user does not need to approve another limit. Already approved? Recover it signs in to the same Base Account, finds only that payer’s exact active ENS.Tools permission, and resumes the owner-wallet link. Recovery creates no allowance and makes no payment.

Permission registration, the explicit first-payment action, and each period charge are idempotent. An hourly reconciler cannot charge a newly linked permission until the first-payment action has been recorded. If a charge is requested but no Base transaction appears, Resume paymentrequeues only that already authorised period charge. If a charge is broadcast but confirmation times out, its transaction is retained and the reconciler resumes verification; it does not silently charge again. Revoking the permission stops future renewals without erasing paid time.

The console distinguishes Not paid, Payment requested, Payment sent · confirming,Paid, and Payment failed. It shows the subscription owner, payer, plan, current period, next renewal, and onchain charge receipts. Historical Stripe or direct-payment records, where they exist, remain read-only accounting history and cannot start a new purchase.

Instructions for agents

Agents should read the machine-readable pricing contract and the subscription recipe. They must preserve the human wallet-approval boundary and stop onbase_subscription_setup_required. They must never infer payment from a permission approval, owner-link signature, explicit payment request, browser redirect, or transaction hash.

A safe first production test

1. Use a dedicated customer Base Account, not the ENS.Tools treasury or subscription-owner wallet.
2. Fund it with the 39 USDC Operator price and enough Base ETH for any unsponsored wallet transaction.
3. Confirm the wallet shows official Base USDC, 39 USDC, a 30-day period, and the published subscription-owner address before approving.
4. Link the billing wallet, verify the console still says Not paid, then click Pay 39 USDC now. This is the explicit first-payment action; future renewals are automatic until revoked.
5. Wait for the initial charge receipt and five confirmations before expecting Operator quota.
6. Give the test agent the resulting developer API key, never the payment wallet or its signing material.
7. Cancel the subscription and verify that renewal stops while already paid access remains until the period end.

Why x402 is deliberately later

Pay-per-call purchasing is useful for occasional agent-to-agent work, but it introduces another payment state machine. ENS.Tools publishes its intended Base USDC x402 profile as disabled so integrations can discover the direction without treating it as live. It will activate only after budget policies, duplicate-charge protection, paid-result receipts, refund handling, adversarial fixtures, and the production canary all pass.

Explore plans on the agent pricing page or read the developer platform guide.