TDM SDK

The Core SDK for Decentralized Agent Operating System (DaOS)

Orchestrate secure, sovereign, and monetized agents with Contour Runtime

Documentation • API Reference • npm Package • X/Twitter

What is TDM SDK?

tdm-sdk is the core developer surface for DaOS (Decentralized Agent Operating System). It provides the primitives for building and running autonomous agents in secure sandboxes with built-in monetization.

████████╗ ██████╗  ███╗   ███╗
╚══██╔══╝ ██╔══██╗ ████╗ ████║
   ██║    ██║  ██║ ██╔████╔██║
   ██║    ██║  ██║ ██║╚██╔╝██║
   ██║    ██████╔╝ ██║ ╚═╝ ██║
   ╚═╝    ╚═════╝  ╚═╝     ╚═╝

TDM CLI [V0.0.3-BETA]
Contour Runtime + TDM Hub + Sovereign Gateway
Mode: local-first | Docs: todealmarket.com/docs

What you get

• Contour Runtime: Orchestrate agent intents via secure WASM/WASI sandboxes.
• LocalVault: Manage encrypted identity, signing keys, and secrets locally.
• TDM Hub Integration: Discover and install capabilities from the decentralized registry.
• Sovereign Gateway: Connect to modular settlement layers and manage Session Gas Tanks.
• Intent Routing: High-level primitives for routing tdm.intent.* requests to plugins.
• Trust Policies: Fine-grained execution rules, budgets, and allowlists.
• CLI Workflows: Comprehensive workspace, vault, and agent management.

Install

npm install tdm-sdk

Global CLI install:

npm install -g tdm-sdk

Short npm alias:

npm i tdm-sdk

CLI

Installing tdm-sdk gives you the tdm command.

Run tdm to open the local Dashboard. This is the primary surface for Hub installs, plugin publishing, signatures, optional chain anchors, ratings, and policy review. For a terminal-only command palette, use tdm cli; tdm / still opens slash areas directly.

The terminal launcher starts clean with a single input line. Type a full command and press Enter, or start with / to open top-level sections such as Setup, Selling, Payouts, Agents, and Security. Inside a section, Enter opens the next submenu or runs the highlighted command.

Common commands:

• tdm connect
• tdm status
• tdm where
• tdm vault
• tdm login
• tdm storage
• tdm workspace
• tdm workspace status
• tdm fuel
• tdm make payable
• tdm security
• tdm sweep
• tdm sweep status
• tdm cashout
• tdm agent
• tdm agent status
• tdm stats

Launcher quick starts:

tdm
tdm cli
tdm /
tdm /setup
tdm /selling
tdm /payouts
tdm /agents
tdm plugin publish ./tdm-plugin.json
tdm plugin publish ./tdm-plugin.json --anchor

Minimal example

import { ContourRuntime } from 'tdm-sdk/runtime';

const runtime = new ContourRuntime();

// Execute a secure intent through the sandbox
const result = await runtime.executeIntent({
  kind: 'tdm.intent.search',
  summary: 'Search DaOS info',
  payload: { query: 'How does DaOS work?' },
});

console.log(result.output);

What this means:

• Contour Runtime is the local execution heart of your agent.
• It routes Intents to sandboxed plugins (WASM) based on your Trust Policies.
• It handles monetization, identity, and settlement (via Gateway) automatically.
• Your app remains secure: the untrusted code never touches your host system.

Friendly SDK entrypoints

If you want the project to stay in one package but need faster integration than raw HTTP, tdm-sdk now also exposes small scoped clients:

• tdm-sdk/authorize
• tdm-sdk/session-tanks
• tdm-sdk/checkout
• tdm-sdk/gateway-clients
• tdm-sdk/gateway-auth
• tdm-sdk/gateway-transport

These are thin wrappers over the current live gateway contract. They do not replace makePayable(...); they cover the adjacent flows around it.

First integration checklist

• install tdm-sdk
• decide whether your first path is makePayable(...), direct HTTP, or a scoped client
• set TDM_GATEWAY_URL or pass baseUrl
• for buyer-facing checkout flows, start with tdm-sdk/checkout
• for seller or operator flows, make sure you have either a session token or wallet-signing credentials available
• verify one happy-path request first before layering session tanks, settlement, or recovery logic

If you are unsure where to begin:

• monetize a route/tool/action: makePayable(...)
• call the payment gate directly: tdm-sdk/authorize or raw POST /authorize
• create checkout links for buyers: tdm-sdk/checkout
• manage session tanks: tdm-sdk/session-tanks

Routing API notes

• Base Odos flows:
  • without ODOS_API_KEY, the SDK uses public https://api.odos.xyz
  • with ODOS_API_KEY, the SDK uses https://enterprise-api.odos.xyz
• Solana Jupiter flows:
  • with JUPITER_API_KEY, the SDK uses https://api.jup.ag/swap/v1
  • without a key, the SDK keeps a compatibility fallback to https://lite-api.jup.ag/swap/v1
  • https://api.jup.ag/ultra is not the path used by the current SDK sweep flow

CLI env helpers support these too:

tdm env set odos <your_odos_key>
tdm env set odos-base https://enterprise-api.odos.xyz
tdm env set jupiter <your_jupiter_key>
tdm env set jupiter-base https://api.jup.ag/swap/v1

Authorize

import { createAuthorizeClient } from "tdm-sdk/authorize";

const authorize = createAuthorizeClient({
  baseUrl: "https://tdm.todealmarket.com",
  sessionToken: process.env.TDM_SESSION_TOKEN,
});

const result = await authorize.authorizePayment({
  requestId: "req_demo_1",
  tokenOrUuid: "demo-user",
  operation: "demo:run",
  priceUsd: "0.05",
});

Session tanks

import { createSessionTanksClient } from "tdm-sdk/session-tanks";

const tanks = createSessionTanksClient({
  baseUrl: "https://tdm.todealmarket.com",
  rootId: process.env.TDM_ROOT_ID,
});

const tank = await tanks.createSubTank({
  publicKey: "<agent_public_key>",
  limitUsd: "5.00",
});

Checkout

import { createCheckoutClient } from "tdm-sdk/checkout";

const checkout = createCheckoutClient({
  baseUrl: "https://tdm.todealmarket.com",
});

const session = await checkout.createSession({
  resourceId: "res_demo_123",
  chain: "solana",
});

When to use which layer

• use makePayable(...) when the goal is to monetize a route, tool, asset, or agent action
• use scoped clients when the goal is to manage live account flows around monetization
• use createGatewayClients(...) when you want one shared transport and several small clients without repeating config
• use createGatewayAuthContext(...) when you need signed gateway headers or auth-aware request preparation in your own code
• use tdm-sdk/gateway-transport if you want low-level control but still want runtime credentials, signing, and error shaping handled for you

Shared composer and primitives

import { createGatewayClients } from "tdm-sdk";

const clients = createGatewayClients({
  baseUrl: "https://tdm.todealmarket.com",
  sessionToken: process.env.TDM_SESSION_TOKEN,
});

await clients.authorize.authorizePayment({
  requestId: "req_demo_2",
  tokenOrUuid: "demo-user",
  operation: "demo:authorize",
});

Examples

The published package also ships small copy-paste examples in examples/:

• examples/authorize-basic.ts
• examples/checkout-basic.ts
• examples/framework-mode-basic.ts
• examples/gateway-clients-basic.ts
• examples/session-tanks-basic.ts
• examples/make-payable-route.ts

These are intentionally thin. They are meant to show the current public contract without hiding it behind a fake all-in-one runtime.

Solana wallet adapter with custom RPC

import {
  SolanaWalletAdapter,
  createFetchHookClient,
  makePayable,
} from 'tdm-sdk'

const wallet = new SolanaWalletAdapter({
  rpcUrl: 'https://mainnet.helius-rpc.com/?api-key=YOUR_KEY',
})

const hooks = createFetchHookClient({
  baseUrl: 'https://tdm.todealmarket.com',
})

const run = makePayable(
  async () => {
    // your paid route, tool, or agent action
    return { ok: true }
  },
  {
    operation: 'demo:solana-tool',
    tokenOrUuid: 'demo-solana-tool',
    hooks,
  },
)

await wallet.connect()
const result = await run()
console.log(result)

Notes:

• Solana browser wallets can stay signer-only while broadcast goes through your own RPC
• pass rpcUrl, or set TDM_SOLANA_RPC_URL / SOLANA_RPC_URL
• injected EVM wallets still own the send path through their provider

CLI examples

tdm connect
tdm where
tdm status
tdm storage add media ./seller-storage --use
tdm workspace create seller-lab --storage media --use
tdm workspace status
tdm storage publish ./products/docs --storage media --mode tunnel
tdm make payable https://api.example.com/library/query --price 0.02 --name "My Library API"
tdm make payable ./agent-route.ts --price 0.05
tdm make payable https://api.example.com/premium/route --price 0.05
tdm make payable ./report.pdf --price 0.05 --mode url --public-url https://cdn.example.com/report.pdf
tdm make payable --asset <asset-id> --storage media --price 0.05
tdm make payable ./premium-route.ts --price 0.05 --billing-mode session_gas_tank
tdm make payable https://api.example.com/premium/route --price 0.05 --title "Premium Route" --tags api,agents,premium
tdm trust verify domain --resource res_demo123 --target api.example.com
tdm trust verify domain --proof-id proof_demo123 --check

Seller-managed local catalogs

If a seller wants to keep files on their own machine or server, tdm-sdk now supports named local storage roots and synced catalogs:

tdm storage add media ./seller-storage --use
tdm storage import-dir ./products/docs --storage media
tdm storage sync ./products/docs --storage media --prune
tdm storage publish ./products/docs --storage media --mode tunnel
tdm workspace create seller-lab --storage media --use
tdm workspace attach-agent seller-lab worker-1
tdm status
tdm workspace status
tdm agent status worker-1
tdm storage publish list
tdm make payable --asset <asset-id> --storage media --price 0.05

Notes:

• tdm connect is still the main first step for live flows
• tdm where is the fastest way to understand where the current gateway, API key, session, wallet, and provider values came from
• tdm storage watch keeps a folder synchronized over time
• tdm storage publish stop <publish-id> stops a running local/tunnel publish session
• after a stored asset has an active public publish session, tdm make payable --asset ... can reuse that public URL automatically
• tdm storage bind <storage> --vault <name|default> adds a soft vault-to-storage link for seller contours
• tdm agent bind-storage <agent> --storage <name> adds a soft agent-to-storage link for resale, packaging, or catalog maintenance workflows
• tdm workspace create/use gives you a reusable runtime context that bundles the right vault, storage root, and attached agents without turning them into a hard-coupled product silo
• tdm status gives one unified runtime-status view across workspace, vault, storage, gateway, publish sessions, attached agents, and milestone blocks like Start Selling / Run Catalog / Run Agents / Go Live
• tdm workspace status is the focused version of that same report for one workspace
• tdm agent status <name> gives one agent-focused readiness view across vault, storage, workspace membership, gateway readiness, and live automation state

Seller payout wallets

If you sell across both Solana and Base, save your external payout wallets once:

tdm payout wallets set --solana <solana_address> --base 0xabc...
tdm payout wallets status

After that, payout requests can stay chain-first instead of address-first:

tdm payout request --amount 20 --chain solana
tdm payout request --amount 20 --chain base

Notes:

• re-running tdm payout wallets set replaces the saved wallet for the chain you pass
• if a payout wallet is already saved for the selected chain, --to becomes optional
• you can still override a one-off payout destination with tdm payout request --to <address>

Solana auto payout

Optional auto payout is currently available for Solana only. Base stays manual so you can choose the timing when gas looks acceptable.

tdm payout auto status
tdm payout auto set --enable --min-amount 25 --every-days 3
tdm payout auto disable

Notes:

• the default Solana threshold is $25, with a default interval of 3 days
• the gateway scheduler creates eligible Solana payouts on a recurring cron
• if you change the saved Solana payout wallet, Solana auto payout is turned off until you enable it again
• Base payouts remain manual and the CLI will show a small gas-awareness hint when you request them

Quick user paths

Use tdm make payable as the main CLI entry point. The right shape depends on what role you are in:

• Open library author: keep the GitHub repo public and price the hosted API or tool URL that agents call.
• API/tool builder: price the route or tool endpoint directly and share the checkout or buy URL.
• File/artifact seller: point TDM at a hosted file URL, or keep localhost preview mode until public hosting is ready.

Examples:

# Open library author
tdm make payable https://api.example.com/library/query --price 0.02 --title "My Library API" --tags library,agents

# API / tool builder
tdm make payable https://api.example.com/premium/route --price 0.05 --name "Premium Route"

# File / artifact seller
tdm make payable ./report.pdf --price 0.05 --mode url --public-url https://cdn.example.com/report.pdf

For the open-library path, the mental model is:

• keep the source repository public
• charge for live usage, not for cloning the repo
• share the checkout URL, buy URL, or tdm share output in your README and agent docs

Optional trust path:

• after a live tdm make payable, the CLI can show a one-time optional reminder for ownership proofs
• use tdm trust verify domain --resource <resource-key> --target api.example.com to start a self-serve DNS/file challenge for hosted APIs and tools
• after publishing the token in DNS TXT or /.well-known/tdm-ownership.txt on that same domain, run tdm trust verify domain --proof-id <proof-id> --check
• use tdm trust verify github --resource <resource-key> --target github.com/org/repo for public code libraries
• if you skip the reminder once, the CLI does not keep repeating it on every payable run

Metadata notes:

• --title is a seller-facing alias for --name
• --tags are stored as quiet local shadow-draft metadata for future listing/discovery layers
• tags do not change the live payment contract today

Gateway-backed tdm make payable registrations now also return bridge URLs for:

• hosted checkout
• buy redirect
• x402/Bazaar-style discovery listing
• MPP-style service discovery listing

That means you can keep TDM as the canonical payment and unlock backend while exposing the same resource through external discovery surfaces.

Advanced security controls

The SDK CLI now exposes the same advanced account guardrails that exist in the gateway:

tdm security settings
tdm security totp enroll
tdm security totp verify --method-id <id> --code 123456
tdm security challenge create --operation limit_change --payload-json '{"advanced_mode_enabled":true,"spend_per_transaction_limit_usd":"50.00000000"}'
tdm security challenge verify --id <challenge-id> --code 123456
tdm security settings set --advanced --spend-per-tx 50 --spend-daily 250 --challenge-id <challenge-id>
tdm payout request --amount 20 --to <address> --challenge-id <challenge-id>

Notes:

• defaults stay on for everyone
• advanced users can raise spend caps, tune payout holds, and set notification email
• risky changes and payouts can require a verified challenge id once TOTP step-up is enabled
• when gateway sync is enabled during TOTP enrollment, the gateway receives the TOTP secret so it can verify network step-up challenges; disable gateway sync if you need local-only TOTP protection
• in production, Contour requires intent payload schemas by default, blocks simulation mode unless explicitly opted in, and blocks in-process plugins unless allowInProcessInProduction is deliberately enabled
• tdm dev runs a local simulation sandbox with mocked gateway responses and an operator approval prompt; it does not move funds or call the live gateway
• tdm plugin hub reads an MVP JSON Plugin Hub from GitHub or a local file, while plugin code still has to be reviewed and registered from a local manifest before execution
• tdm plugin init <id> --language python|rust|go scaffolds out-of-process plugins; manifests declare runtime.type: "process" and communicate with Contour over stdin/stdout JSONL, so Python, Rust, and Go agents can ask the TypeScript SDK core to execute guarded intents without sharing process memory
• tdm receipt generates accounting receipt documents from checkout/payment evidence in Markdown, HTML, or JSON; these include parties, line items, totals, tax mode, payment proof, and a canonical audit hash, but they are not jurisdiction-specific fiscal receipts unless seller tax/fiscalization data is supplied

Public surfaces

• tdm-sdk for integrations and the built-in CLI
• bundled @tdm/mcp-server support through tdm mcp
• tdm-daos-agent for agent-facing payment and recovery guidance

Advanced: Named vaults

For operators who want isolated business contours, tdm-sdk now supports named vaults on top of the legacy default vault:

tdm vault create photos --use
tdm connect --vault photos
tdm agent spawn seller-1 --vault photos --type DISCRETE --limit 10

Notes:

• default legacy vault remains ~/.tdm/credentials.json
• named vaults live under ~/.tdm/vaults/<name>/credentials.json
• active vault selection is stored locally and can be changed with tdm vault use <name>
• repeated agent names are isolated per vault in the OS keyring
• if you want one-off targeting without switching globally, pass --vault <name>
• agent limits here are spending limits for agent/session usage, not seller payout limits

MCP setup

Installing tdm-sdk now brings the MCP runtime with it. To wire the current project into local MCP clients, run:

tdm mcp

That writes or updates a project-level .mcp.json which points to:

tdm mcp serve

If you want the MCP runtime pinned to a named vault:

tdm mcp --vault photos

Notes

• tdm connect is the main one-time setup flow: it links a wallet, creates local vault state, and points the CLI at the public TDM surface by default.
• gateway-bound CLI flows such as tdm make payable, tdm payout, tdm security, tdm trust verify, tdm balance, and tdm unlock now auto-start that one-time setup in interactive sessions when the live runtime is still missing.
• in SSH / CI / other headless environments, tdm connect now fails fast unless you pass --headless and intentionally forward the localhost wallet bridge into a browser
• tdm login remains available for manual or advanced credential editing.
• tdm sweep is a local conversion flow: memecoins or dust are swapped into stablecoins and sent to an explicit destination address or local target agent.
• tdm sweep now prints its execution model up front:
  • Solana = burner mode, using a short-lived local hot wallet file
  • Base = wallet mode, using a live wallet session through WalletConnect / mobile link
• use tdm sweep --mode burner or tdm sweep --mode wallet when you want the CLI contract to be explicit; unsupported combinations now fail fast instead of looking like the same product with hidden behavior
• wallet adapters stay wallet-centric by default:
  • Solana can sign in the browser wallet and broadcast through a custom RPC via rpcUrl, TDM_SOLANA_RPC_URL, or SOLANA_RPC_URL
  • injected EVM wallets still own the final send path through their provider, so signAndSendTransaction() returns the provider-managed transaction hash
• tdm cashout is for returning stablecoin to an external wallet.
• tdm make payable is now a strict go-live path: local serve mode is only a localhost preview, not public monetization.
• for live/public registrations, the CLI will auto-bootstrap tdm connect in an interactive terminal or fail closed in headless/manual contexts until gateway setup is present.
• if you are an open-library author, the normal production path is: keep the repo public, make the hosted API/tool payable, then share checkout/buy URLs in README or agent docs
• tdm agent manages agent vault workflows from the same package.
• for paid file or content flows, keep the product framing simple:
  • Direct Pay: charge first, then deliver from your own app or storage
  • Protected Unlock: experimental paid unlock flow with redirect or inline delivery
• redirect delivery exposes the destination URL to the buyer; use expiring presigned URLs when you need tighter control, or use inline delivery for content that must stay fully gated
• for paid file delivery, prefer packaged or non-executable formats such as zip archives, markdown, or plain text

License

MIT