Anyone can request access. Each preview user gets their own hosted Dynamo, a console and the TypeScript and Python SDKs, with credit card payments (Stripe test mode), stablecoin payments on testnets, x402 paying and getting paid, hard caps, agent networks, AI inference and streaming payments, the main switch, end-user controls and signed proof. Everything runs in test mode: no real money moves.

Dynamo focuses on the combination of delegated budgets, metering, and settlement claims across service workflows. Payment standards can be complementary. Check the current integration documentation for supported versions and tested compatibility; an HTTP 402 response alone does not establish conformance. In the preview, the SDK pays x402 APIs (V1 and V2, exact and upto) from an agent's capped slice, and lets your own API get paid through x402 via x402.org, PayAI or Coinbase CDP.

Dynamo can create signed claims as work progresses. A voucher is not itself a completed payout. Actual settlement and fund availability depend on checkpoint policy, transaction inclusion and finality, or processor capture and payout behavior.

No. The documented escrow default is a 1% protocol fee, with network and other applicable costs additional. The published contract allows an administrator to change the fee within a 10% ceiling, and the settlement-time rate applies. Card pricing is separate. Compare total costs for the same payment size and service bundle.

Control Mode requires no payment setup and moves no money. Escrow testing uses the configured testnet asset. A proposed DYNAMO token is separate from the existing escrow architecture and is not required to use it. Production rails have their own approval and setup requirements.

Payment eligibility depends on the agreed terms and measurement sources. Previously settled payments do not automatically reverse. Refunds and disputes follow the configured contract, rail, and application process and may depend on payee funds and approval.

The metering interface is designed around usage facts rather than prompts or outputs. Identifiers, amounts, timing, and logs can still be sensitive. Your AI service may send payloads to its own providers; review the adapter and hosting configuration to understand the complete data flow.

The configured enforcement path checks limits before admitting supported commitments. Correct integration, atomic reservations or disjoint allocations, and non-bypassable routing are necessary. Caps do not automatically cover gas, external invoices, or activity outside that path.

The supplied showcase descriptions identify Base Sepolia testnet integrations using testnet assets. They illustrate application behavior and are not evidence of production revenue. Production activation is reviewed per instance.