[ BLOG ]

1Claw Joins the Circle Alliance Program

We're in the Circle Alliance Program. Here's what that means for AI agents, what we've already built on Circle's infrastructure, and where we're taking it.

We got into the Circle Alliance Program. We'd rather explain what that actually means than slap a badge on the site and call it a day.

Circle runs the Alliance for teams shipping real products on their stack: live USDC or EURC integrations, not roadmap slides. The bar is a working product. We have one.

Below is what we've already built on Circle's infrastructure, what we're building next, and why agent key management and Circle's payment rails fit together.

What 1Claw does

1Claw gives AI agents a place to keep secrets and signing keys, plus a policy layer that controls how they spend.

An agent that can sign whatever it wants is a liability. It can drain a treasury, send to the wrong address, get talked into a bad transfer by a prompt injection, or burn through gas because nobody set a daily cap. That's not an edge case. It's what happens when you hand signing authority to something you don't constrain.

We handle this at the infrastructure layer. Keys sit in HSM-backed storage (Google Cloud KMS). Transactions go through the Intents API first: spend caps, recipient allowlists, rolling daily limits. Nothing gets signed until those checks pass. We also run Tenderly simulation before the key is touched. If the sim reverts, the request dies and the key stays put.

The /for-ai page has MCP config, SKILL.md, llms.txt, and the OpenAPI spec. The MCP server exposes 36 tools for vault ops, Intents, treasury, approvals, and Bankr key vending. If you're building an agent that moves money, start there.

What we've already built on Circle's stack

Joining the Alliance isn't day one for us. We've been building on Circle's infrastructure for a while. Here's what's live today.

  • Arc Testnet is registered. Chain ID 5042002 is in our chain registry. Agents can sign and broadcast USDC on Arc through the Intents API today, with the same guardrails as Ethereum or Base. Arc is the first EVM chain where USDC is the native gas token. One asset, one ledger line, no ETH refill babysitting.
  • x402 USDC payments are live. Our middleware handles HTTP 402 paywalls by collecting USDC before an API call proceeds. Settlement runs on Base via the Coinbase CDP facilitator. Agents can pay for API access in USDC without a human clicking approve.
  • ERC-4337 gasless transactions work.Bundler infra for account abstraction and sponsored txs runs through Pimlico. On chains where a paymaster is available, agents don't need ETH sitting around just to cover fees.
  • USDC gets the same guardrails as ETH.Spend caps, allowlists, daily limits, simulate-before-sign: all of it applies to USDC transfers the same way it applies to native ETH. The policy engine doesn't care which token you're moving. It cares whether the transfer is allowed.

We built all of this before any formal tie-in with Circle. The Alliance is recognition of that work. It's also a push to go further.

Why Arc matters for agent economics

We registered Arc early on purpose. The fee model is different from every other EVM chain, and that difference hits agent workloads hard.

When gas is ETH, you maintain a separate ETH balance per agent. You write refill logic. Your spend caps are estimates, not hard numbers, because the ETH/USD rate at execution time sets the real cost. Run thousands of txs a week and that overhead adds up fast.

On Arc, gas is USDC. A $10 daily limit means $10, not $9.73 because ETH dipped overnight. Run out of USDC and you're done. No second wallet to top up. No swap step. One asset from balance sheet to gas tank.

We think Arc is the chain a lot of agent developers were waiting for, even if they hadn't named it yet. That's why we built for it early.

What's next

The Alliance speeds up a few integrations we were already planning. Here's the roadmap.

Circle Paymaster on Arc

We route account abstraction through Pimlico today. Next step: Circle's native USDC Paymaster on Arc. That drops the last ETH dependency from the Arc agent flow. Paymaster takes USDC, agent signs a UserOperation, whole thing settles in one asset. Bootstrapping a new agent through the Platform API could mean: fund with USDC, start signing. No ETH side quest.

CCTP cross-chain USDC

Agents need to work across chains. Moving USDC today usually means a bridge with counterparty risk or a detour through an exchange. Circle's Cross-Chain Transfer Protocol burns on the source and mints canonical USDC on the destination. No wrapped tokens. No bridge holding your funds.

We're adding a /transfers/cross-chain endpoint to the Intents API. Call it with source chain, destination, amount, recipient; we handle the CCTP burn and attestation relay. Same guardrails as any other transfer: per-tx caps, chain allowlists, daily limits. For stricter setups, CCTP burns can route through Shroud (our AMD SEV-SNP TEE proxy) so the key never leaves the enclave for an irreversible on-chain move.

Circle Programmable Wallets as a custody backend

Our default custody is Google Cloud KMS and HSM-backed keygen. That's the right default for most teams. Some enterprise and fintech shops need Circle's MPC custody instead: compliance boxes to check, institutional requirements, or they're already Circle customers and want the same vendor for agent wallets.

We're wiring Circle Programmable Wallets in as an alternate backend. Set custody: "circle"in your bootstrap template and wallet creation goes to Circle's API instead of our native keygen. Intents, guardrails, treasury, spend policies: same surface on top, different custody underneath.

Agent-to-agent nanopayments

x402 handles agent-to-platform billing well. Agent hits a paywall, pays USDC, gets through. It doesn't handle agent-to-agent: one agent paying another for a tool call or a data fetch at sub-cent amounts without a full on-chain tx every time.

Payment channels on Arc change the math. Open a channel with a small USDC balance, settle individual payments off-chain with signed updates, close to Arc when you're done. At current testnet fees, opening and closing a channel is cheap relative to what flows through it. Sub-cent agent payments become viable on EVM for the first time, in our view.

We're folding this into the MCP tool marketplace idea: agents pay tool providers per invocation in USDC, with spend caps enforced at our layer.

Circle Agent Stack integration

Teams on Circle Agent Stack still need secret storage, signing policy, and LLM guardrails. We do all three. Plan is a first-class hookup, not a bolt-on: OIDC federation so Circle agents auth to 1Claw without static API keys, plus our MCP server as a tool provider for secrets, signing, treasury, and cross-chain transfers.

The gap nobody talks about

There's a hole in the agent stack between "can technically sign a transaction" and "enterprise will actually run this with signing authority." Policy and guardrails are the difference.

Raw private key in the agent process? Liability. HSM-backed signing, server-side caps, simulate-before-sign, audit trail? Something you can put in prod and sleep on.

Circle owns the payment rails, settlement, cross-chain liquidity, stablecoin issuance. That stack is excellent. What it doesn't answer on its own: how do you stop the agent from overspending? How do you give it signing keys without handing it the keys to the kingdom? How do you run fifty agents on fifty different spend policies without writing a policy engine from scratch?

That's the 1Claw piece. The Alliance is Circle and us saying those layers belong together.

Building agents that handle money? Start here. Want the Arc walkthrough end to end, see the Arc integration guide.

Build with 1Claw · Arc integration guide · Circle Alliance Program

Back to blog