Migrate from CDP

Solvador and the Coinbase Developer Platform (CDP) facilitator both implement the standard x402 v2 facilitator interface. In practice that means migrating comes down to swapping the facilitator client in your resource server. Your routes, prices, schemes, CAIP-2 network identifiers, and receiving address all stay as they are. Your paying clients change nothing: the 402 flow they see is identical before and after.

What changes

Nothing changes at the protocol level: requests still carry "x402Version": 2, networks are still CAIP-2 identifiers like eip155:8453, the exact scheme works the same way, and the lifecycle is still /verify first, /settle after.

1. Create a Solvador API key

Sign in at dashboard.solvador.com with Google or GitHub, open the API Keys tab, and create a key. This one key replaces the CDP key pair, and there is no request signing involved.

2. Swap the facilitator client

Before, with the CDP client from @coinbase/cdp-sdk/x402:

import { x402ResourceServer } from "@x402/core/server";
import { createCdpFacilitatorClient } from "@coinbase/cdp-sdk/x402";

// Reads CDP_API_KEY_ID and CDP_API_KEY_SECRET from the environment
const facilitator = createCdpFacilitatorClient();

const server = new x402ResourceServer(facilitator);

After, with a standard HTTPFacilitatorClient pointed at Solvador:

import { HTTPFacilitatorClient, x402ResourceServer } from "@x402/core/server";

const auth = { "X-API-Key": process.env.SOLVADOR_KEY! };

const facilitator = new HTTPFacilitatorClient({
  url: "https://api.solvador.com",
  createAuthHeaders: async () => ({
    verify: auth,
    settle: auth,
    supported: {},
  }),
});

const server = new x402ResourceServer(facilitator);

Everything downstream of the facilitator client stays untouched: paymentMiddleware, your routes object, and your scheme registrations. payTo is just a receiving address, so you can keep settling to the wallet you already use, including one that CDP provisioned for you.

Rolling back is the same two lines in reverse. Both clients implement the same interface, so you can keep the old construction behind an environment switch during the cutover.

If you used createX402Server

The CDP SDK’s high-level createX402Server provisions a CDP server wallet and wires up the facilitator in one call. With Solvador you bring your own receiving address instead. Declare your routes with an explicit payTo (any address you control, including the wallet CDP created for you) and pass in the facilitator client above. The quickstart shows the complete Express setup.

3. Remove the CDP credentials

Once traffic settles through Solvador, remove CDP_API_KEY_ID, CDP_API_KEY_SECRET, and CDP_WALLET_SECRET from the resource server’s environment, and uninstall @coinbase/cdp-sdk if nothing else imports it. Keep them if the same service still uses CDP wallets for signing or for client-side payments.

4. Verify the cutover

1. Request a paid route without a payment and check that the 402 response lists your requirements unchanged.
2. POST /verify a signed payment with your new key. Verification consumes no quota, so this works before you pick a plan.
3. Settle a real payment. The Free plan includes 10 settlements per month, which is enough to prove the integration end to end. Watch it appear in the dashboard.
4. Query GET /supported and confirm every scheme and network pair you rely on is listed.

Differences to plan for

• Testnets. Solvador settles on mainnet only. Keep staging pointed at a testnet facilitator, such as the CDP development environment or https://x402.org/facilitator, and point production at Solvador. Unmetered verification plus the Free plan’s settlements cover end-to-end tests against mainnet.
• Bazaar listings don’t carry over. The CDP Bazaar and Solvador’s discovery catalog are separate indexes. Your resource re-enters the catalog on its first verified payment that echoes the bazaar extension. No manual submission needed.
• Gasless approvals. Solvador sponsors the one-time Permit2 approval for permit()-capable (EIP-2612) tokens such as USDC through the eip2612GasSponsoring extension. Tokens that support neither EIP-3009 nor EIP-2612 need one approval paid by the payer.

What you gain

• Ten more mainnets: Optimism, Avalanche, Celo, Linea, Unichain, Monad, Robinhood Chain, NEAR, the XRP Ledger, and Starknet. Each one is a single line added to your route’s accepts.
• upto and batch-settlement on all 11 EVM networks, for metered pricing and high-frequency micropayments.
• Settle idempotency: send a payment-identifier with every settle and retries become safe by construction.
• Unmetered XRPL: settlements on xrpl:0 never count against your quota, on any plan.