!
Beta Environment Notice
TDM is currently in Beta. Exercise caution when handling assets. Use at your own risk.
Fast Export
Switch the current page to Markdown for fast agent reading, or download it as a .md file.
TDM is currently in Beta. Exercise caution when handling assets. Use at your own risk.
Fast Export
Switch the current page to Markdown for fast agent reading, or download it as a .md file.
# TDM Architecture Overview Summary: Official architecture guide for the current TDM developer stack. This page explains how the SDK, built-in CLI, MCP runtime, AgentPay guidance, Session Gas Tank, and public payment flows fit together today. Status: Documentation Topics: - TDM stack architecture - SDK design - CLI usage - MCP integration - AI agent payments infrastructure - authorize flow - seller settlement Packages: - tdm-sdk - bundled-mcp-runtime - tdm-agentpay
Learn how the current public TDM stack is organized: SDK and CLI workflows, documented HTTP requests for non-JS stacks, checkout and payment flows, and MCP-aware agent runtimes.
SDK with payment wrappers, payable resource helpers, and the built-in CLI.
Documented request and response contract, including authorization, registration, and payout-related endpoints.
Commands for setup, payable registration, funding, payout, stats, and related workflows.
Optional session-state checks for AI agent runtimes that need payment readiness signals.
Use tdm-sdk when you want the main SDK surface and the built-in tdm CLI in one package.
Add the bundled MCP runtime when an agent runtime needs session-state awareness before it decides whether to continue or ask the user to act.
Best for JS runtimes like Next.js, Hono, Elysia, Express, and Deno handlers.
Best for Python, Go, Java, Rust, C, and C++ using the public HTTP contract directly.
Best for agent runtimes that need session-state awareness and payment-readiness checks.
A Session Gas Tank is a prepaid runtime balance for one agent or session, so the agent can spend up to a fixed limit without ever getting open-ended access to the root wallet.
x402 is the machine-payment pattern around HTTP 402 Payment Required, where the runtime sees the price, pays through the TDM contract, and retries the request.
The important public property is simple: billing is off-chain per request, and the request coordinator serializes charge decisions before the response is released. That means 10 parallel agent calls do not get to race each other into a negative balance.
1. Agent calls a paid route or POST /authorize
2. Gateway sends the request through a single-threaded coordinator path
3. The active balance is checked atomically
4. Successful requests reduce balance one by one in strict order
5. Once balance is exhausted, the next queued request returns HTTP 402Public docs should describe the architecture in terms of developer surfaces and request flow: SDK and CLI setup, authorize checks, checkout and delivery paths, Session Gas Tank support, seller payouts, and optional MCP guidance.
Avoid hard performance promises, internal settlement mechanics, or unpublished security implementation details on public pages.