Dogfooding is in our DNA. We built smart402 and have been using it the way other developers would to find ways to make it better and easier to use, and the results have been fun. We just ran that process against smart402 on Base mainnet with a live CDP managed wallet, a real x402 Bazaar service, and actual USDC; and it went exactly as planned, which is to say it did not go smoothly at all.

Here is what happened, in order:

What we set out to build

The goal was clean: a production agent using a Coinbase CDP managed wallet, with smart402 governing every x402 payment. We picked twit.sh as our target service. The dream architecture was:

The wall we hit

coinbase-agentkit 0.7.4 (released Oct '25) is the current PyPI release as of this writing, and it requires x402<2. That is a hard dependency pinned in the package.

twit.sh runs x402 V2.

So the two things we needed to connect (AgentKit and a live Bazaar service) speak different versions of the same protocol. We confirmed this with Coinbase support in Discord. Their response: AgentKit 0.7.4 is tested and published with a dependency on x402 versions >=0.1.4 and <2.0.0. That means it is officially supported only with the pre-2.0 x402 Python client line. Using x402 2.x or higher together with AgentKit 0.7.4 is not a supported combination and may lead to unexpected behaviour.

We still had an agent to test, so we pivoted.

What we actually tested

We dropped AgentKit from the payment path entirely. Instead, we used a raw EOA wallet with eth_account for x402 signing. It is not the dream architecture, but it worked.

smart402 stayed in the path throughout. Every payment request hit the evaluator, got approved, and landed in the dashboard. That part worked exactly as designed, so we finally dogfooded :). You want to find out where the product breaks, and smart402 did not.

But we also found and fixed a few real infrastructure issues along the way:

None of these would have surfaced in a test environment, so this is why we'll keep running against mainnet.

What the dashboard looks like now

smart402's dashboard now shows "confirmed" spend. smart402 approved every payment (that was within policies), the policy rules fired correctly, and the triggered_rules array came back clean on each evaluation.

The agent works. It is just not the agent we originally designed.

What we're waiting for

The pure AgentKit + smart402 integration is one PyPI release away. When the release ships, we'll post the integration guide.

That is it. Smart402Guard takes a wallet address as a plain string and does not care where it came from. The 0.2.0 we shipped last week was built specifically so this integration would be one line when Coinbase lands their update.

We will be watching the AgentKit releases. When it ships, we will run the full stack the same day and post the results.

The broader takeaway

x402 V2 is a real protocol in production with real services charging real money, and the tooling is still catching up. AgentKit's main branch is already there, and the gap is just a release cycle.

In the meantime, smart402 works with any wallet that returns an EVM address. If you are building x402 agents today using a raw EOA, a CDP wallet, Privy, or anything else, the integration is available right now. You do not need to wait for AgentKit to ship.

Get started at smart402.com or open an issue on GitHub if something feels rough.

Frequently asked questions

Why can't I use AgentKit's built-in x402 integration with Bazaar services right now?

coinbase-agentkit 0.7.4 on PyPI pins x402<2, but some Bazaar services now run x402 V2. The two are incompatible. Coinbase merged the fix (x402[requests]>=2.4.0) into their main branch in March 2026, but it has not shipped as a PyPI release yet. Until it does, the workaround is to bypass AgentKit's payment layer and sign x402 payloads directly with eth_account or any compatible signer.

Does smart402 work with raw EOA wallets as well as managed wallets?

Yes. Smart402Guard accepts wallet_address as a plain string in 0.2.0. It does not matter whether that address came from a CDP managed wallet, a Privy embedded wallet, a Turnkey server wallet, or a raw eth_account EOA. Any wallet that can return an EVM address works.

What did you find by running against mainnet instead of a test environment?

Three real issues: tx_hash was not flowing correctly into confirmed spend tracking, the Basescan V1 API we were using was causing issues, and the dashboard was underreporting confirmed spend as a result. None of these would have surfaced on testnet. We fixed all three before publishing this post.

What is smart402?

smart402 is a deterministic policy engine for x402 payments. It sits between your agent and any x402-protected API, evaluating every payment request against your configured rules before execution. No LLM in the decision path: same inputs always produce the same output, every time!

Previous post All posts