!
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.
# Architecture Deep Dive Summary: Public architecture notes for the current TDM stack. This page explains how the SDK, gateway, checkout, Session Gas Tank, seller payout, and MCP guidance layers fit together without exposing internal implementation detail. Status: Public architecture notes Topics: - TDM architecture - SDK and CLI surface - gateway flow - checkout flow - MCP session-state guidance Packages: - tdm-sdk - bundled-mcp-runtime - tdm-agentpay Commands: - tdm connect - tdm mcp - tdm fuel - tdm sweep - tdm stats
High-level public architecture notes for the current TDM stack. This page is meant to help builders understand how the public layers fit together without turning internal implementation detail into product promises.
TDM is presented publicly as a layered developer stack rather than a single package or endpoint. Some teams want a JavaScript SDK, some want a protocol-first HTTP contract, some want hosted checkout, and some want MCP-assisted runtime guidance for agents. The architecture needs to support those different entry points while keeping the core payment flow recognizable.
tdm-sdk is the main public developer surface. It provides makePayable, framework-mode helpers, createFetchHookClient, LocalVault, Local402Circuit, thin gateway facade clients for authorize / tanks / checkout / payouts, and the built-in tdm CLI.
The gateway is the live payment surface behind authorize, resource registration, checkout, delivery, tank, payout, telemetry, and analytics routes.
Hosted checkout, bridge listings, buy redirects, checkout sessions, and delivery tokens sit on top of the same underlying payment contract rather than replacing it.
When an agent needs local payment-readiness guidance, the bundled MCP runtime exposes narrow session-state checks so the runtime can continue, ask for fuel, suggest sweep, or ask the operator to connect first.
1. Builder integrates with tdm-sdk or the public HTTP contract 2. A paid action reaches POST /authorize 3. TDM decides whether the request can proceed 4. Success can continue into route execution, checkout completion, or paid delivery 5. Seller credits and payout workflows remain separate from the paid request itself 6. Agent runtimes can use MCP session-state checks before escalating to the operator
Builders who already know Base or Solana usually do not need more abstraction. They need to know whether the payment layer respects the real operational constraints of their chain. This is the public answer for that.