# Agent distribution and integration targets

**Research reviewed 7 September 2026. All P21 integrations below are planned, not deployed, listed, certified, or endorsed.** A directory is a distribution surface, not guaranteed demand or permission to contact arbitrary agents.

## First wave

| Surface | Existing capability | Proposed P21 work | Gate before support claims |
| --- | --- | --- | --- |
| Binance B402 Bazaar | Opt-in catalog of paid HTTP APIs and MCP tools | Translate truthful P21 capability metadata for a working V2 endpoint | Eligibility, supported scheme/network, authorized settlement, listing read-back |
| Coinbase CDP Bazaar | x402 service discovery | Reuse the capability model with a provider-specific adapter | Verified test workflow and metadata validation |
| Official MCP Registry | Metadata distribution for MCP servers | Publish a real P21 tools server | Working package/server, permissions, schema and failure tests |
| Virtuals ACP | Agent-commerce lifecycle and API service-provider participation | Offer one objective checking job | Buyer verification, timeout and job-lifecycle tests |

## Additional adapter candidates

PayAI and thirdweb offer alternative x402 infrastructure. OKX Onchain OS exposes financial-agent workflows that could provide fixtures for a future action adapter. Lightning L402/Aperture is a future Bitcoin payment option. These are candidates; neither implementation status nor geographical availability is inferred from a product name.

TAP/DMT and Trac remain evidence/ecosystem integrations. ERC-8004 identity references and A2A service cards are complementary standards, not additional unique customers. Do not add overlapping registry counts together.

## Binance specifically

B402 documents discovery metadata attached to confirmed V2 settlements, with a Coinbase Bazaar-compatible metadata shape. Reusing that shape does not prove wallet, token, network, or settlement compatibility. Verify each separately. A paid verification service and an exchange-trading agent are also different integrations.

The next P21 demonstration should run in shadow mode, inspect a supported financial instruction/evidence pair, return explicit findings, and let a separate consumer reproduce the check. Do not trade or settle merely to earn a listing signal.

## Reusable metadata

Describe the exact operation, supported inputs, evidence requirements, policy/version, output, limits, timeout, permissions, price, network/asset, idempotency, and structured errors. Preserve uncertainty across wrappers. Measure successful first use, repeat use, paid usage net of subsidies, and independent verification.

## Primary sources

- [Binance B402 Bazaar](https://developers.binance.com/en/docs/products/onchainpay-x402/b402-bazaar)
- [Coinbase discovery](https://docs.cdp.coinbase.com/x402/buyer/discover-services)
- [MCP Registry](https://modelcontextprotocol.io/registry/about)
- [Virtuals ACP](https://whitepaper.virtuals.io/builders-hub/acp-tech-playbook)
- [PayAI](https://docs.payai.network/x402/quickstart)
- [thirdweb x402](https://portal.thirdweb.com/x402)
- [OKX Onchain OS](https://web3.okx.com/onchainos)
- [Lightning L402](https://docs.lightning.engineering/the-lightning-network/l402)

<!-- p21-ecosystem-payments-v09 -->

## Stablecoins matched to each integration

The initial core requires native NAT and USDC on Base. Each additional commerce integration launches with an explicit asset/network/method allowlist, rather than assuming every ecosystem uses the same stablecoin. Provider documentation reviewed on 9 September 2026 establishes the following implementation targets; it does not establish that P21 already operates them.

| Integration | Payment scope | Method boundary |
| --- | --- | --- |
| Coinbase CDP / x402 | USDC on Base first; additional documented networks by tested adapter | Preserve the supported scheme and exact network/contract |
| Binance B402 / BNB Smart Chain | USDT, USDC, USD1 and U in the B402 launch scope | USDT/USDC use Permit2; USD1/U also support EIP-3009 |
| PayAI | USDC on Solana and approved EVM networks; other assets only after capability checks | A network listing is not universal token support |
| Virtuals ACP | USDC service fees under its job lifecycle | Preserve job/funding/settlement semantics; not a generic x402 substitution |
| MCP / A2A | No protocol-mandated payment coin | Transport and discovery do not select or authorize payment |

Binance's published BSC mainnet entries use 18 decimals, including its USDC and USDT contracts. Base USDC uses a different contract and 6 decimals. Never copy decimal assumptions between networks or confuse testnet assets with mainnet assets. Do not add FDUSD or another coin merely because it is associated with an exchange; verify the specific payment product.

Before advertising an available method, intersect the owner's allowlist with the configured provider's current supported capabilities. Pin the network, token, decimals, payment method and recipient; validate permitted spender/signer addresses and preserve required authorization metadata. Refresh capability data without letting it silently expand the allowlist. B402 production access requires provider onboarding. All P21 routes remain disabled until implementation, settlement tests and approval are complete.

[Binance assets and methods](https://developers.binance.com/en/docs/products/onchainpay-x402/basics/9.supported-payment-methods) · [Binance integration](https://developers.binance.com/en/docs/products/onchainpay-x402/introduction) · [Coinbase facilitator](https://docs.cdp.coinbase.com/x402/seller/facilitator) · [PayAI assets](https://docs.payai.network/x402/reference) · [Virtuals ACP](https://os.virtuals.io/acp/concepts) · [NAT Ethereum listing](https://www.bitmart.com/en-US/support/articles/7923014477723/360001026214/49446319153179) · [NAT Solana record](https://solscan.io/token/FbKRaqBzupLry3V7QujpNghwrHgxutB4MY11M8aeyVa1) · [NAT BNB Chain contract](https://bscscan.com/token/0x600e3b55d5368c32a94f9372563318adb6a3f882)

