DYNAMO — THE AI AGENT FINANCE AND ECONOMIC LAYER
The finance and economic layer for the AI agent economy. Meter any work by the second — tokens, seconds, bytes, calls — settle it per signed voucher, and get paid as it delivers. Sub-cent economics, no chargebacks, no billing stack to build.
x402-compatible · non-custodial on every rail · your payloads never leave your machine
A simulated week: a builder monetizing an MCP tool — metered per call, settled per voucher, paid as work delivers.
WHY DYNAMO
For developers building AI services, the urgent questions are the same everywhere: how do I charge per use, how do I get paid now, and how do I keep what I earn. Dynamo is the layer that answers all three — natively, for agents.
Money moves to you inside each settle — call by call, episode by episode. Not an invoice, not a payout schedule, not thirty days. Your earnings are signed, final, and yours the moment the work is delivered.
Integer micro-USD metering with no fixed per-transaction tax: ≈1.32% all-in on a $0.50 job, versus 62.9% by card (2.9% + 30¢). Micro-pricing becomes a product feature instead of an impossibility — and the fee on the token rail is 1%, not a marketplace's 20–25%.
x402-compatible challenges, EIP-712 signed vouchers, scoped agent credentials, budgets that fan out across a whole network of services. Programmable payment logic on the token level — not a checkout page.
MULTI-AGENT BUDGETS
Per-call rails, session rails, and escrow tools all reason about a single payer and a single payee. Real workflows fan out: an orchestrator hires a dozen services at once. Dynamo is built for that shape — one budget, many streams, all metered and capped together, refused at the money layer the instant a cap is reached.
Split once, enforce everywhere — per child, per branch, and across the whole network at once.
SLA-gated — degraded units are never paid for.
Revocable mid-task, without touching the rest.
Past the cap: HTTP 402. Nothing reaches upstream.
Carve a parent budget into per-agent allowances. Caps hold per child, per branch, and network-wide under concurrency.
Dozens of parallel streams reconcile into a single auditable record: what each agent consumed, when, what it cost — to the second.
Cut any child stream instantly without touching the rest. The orchestrator stays in control of the fleet while work is running.
STREAMING SETTLEMENT
Discrete payments are all-or-nothing. A metered stream reacts to reality second by second. Every control below settles on objective, verifiable facts — latency percentiles, error rates, availability, unit counts — never on anyone's opinion of the output.
Tie payment to a live SLA. When the service drops below the agreed bar, the stream throttles or stops on its own. SLA-failed units are never paid for.
If a stream degrades halfway through, refund the seconds after it broke — not the whole thing, not nothing. Buyer made whole first, from held funds.
A cap stops the total. Rate detection stops the runaway — the moment an agent burns faster than its authorized envelope, before the ceiling is even reached.
If a long-running stream drops, billing stops at the last settled second with a provable stop-point. Nothing stranded, nothing double-charged.
SHOWCASE — BUILT ON DYNAMO
The first businesses built on Dynamo: they get paid per delivered unit — and every job runs under a cap made of money, so a runaway pipeline can't spend past what the user paid. Both are code-complete applications running the escrow rail on testnet, with the same SDK and the same rules the docs describe.
Type a few keywords; an LLM pipeline writes a schema-enforced design document, builds a self-contained Phaser 3 game, and a headless browser plays it for real — pressing keys, reading game state, verifying every promised mechanic — while a bounded, separately-capped repair loop fixes what fails.
dynamo-receipt-v1, reconciled three ways against the vault's own records.Type up to ten keywords, pay in stablecoins, receive a series of ~30-second episodes: a series bible fixes characters, palette, and tone across every episode; each shot is rendered, then metered — a failed shot never costs the episode.
Both applications run on the escrow rail against Base Sepolia testnet today — real contracts, testnet stablecoins. Mainnet money rails activate per instance after external security review. Sources: codebase-reviewed developer descriptions of bytecardinal/WordsToGames and bytecardinal/WordsToVideos.
GET PAID
Your own dedicated instance, provisioned by hand while we're early. You run only the open client — your code and your customers' payloads stay on your machines.
One form. A person stands up your isolated instance — own process, own database, own keys — and verifies it before you get the URL and tokens. takes a minute · instance within about a day
monetize() on an MCP tool, a gateway plugin on LiteLLM/Kong/APISIX, or the SDK in front of any API. Fine-grained metering by the second, the call, or any unit you deliver. one command, or a few lines
Per-voucher settlement to your account, a signed receipt for every unit, and nothing between you and your earnings but 1%. The same rail answers every buyer's budget — so you get paid by card-funded buyers when the card rail opens. the proof is the demo
Capping your own agents' spend instead? Same instance, one command: npx @dynamoprotocol/guard up — a hard spending cap in front of any OpenAI-compatible tool.
FUNDING MODES
Budgets, allowances, caps, hard stops, revocation, and signed vouchers behave identically across every funding mode. Moving from a free trial to real money is a one-line change — not a migration, not a different product.
The complete protocol with no payment setup: develop, test, and prove your integration end-to-end against the exact machinery the money rails run. Free permanently — and when you flip to a money rail, nothing about your code changes.
A card authorization backs the buyer's budget; you're paid by split transfer as work delivers, from buyers who never touch a wallet. Money stays inside a licensed, audited payment institution — Dynamo never holds funds, never sees card numbers.
Self-custodied contract escrow: sub-cent metering, 1% on the token rail, no chargebacks, no admin keys over anyone's funds. Live on Base Sepolia testnet today — mainnet activates after external security review.
Non-custodial on every rail: Dynamo never takes possession of funds, never operates stored-value balances, never converts between fiat and crypto. Card and stablecoin rails are enabled per instance, after external security review — never by default.
USE CASES
Start with the agent economy — the buyer building today. The same streaming engine reaches much further.
GPU time and token-by-token inference with a hard ceiling and an SLA gate per job.
An agent on a live market or sensor feed pays while subscribed — and stops the instant it unsubscribes.
One agent hires several others for a long task and streams payment against scoped, capped, revocable allowances.
APIs, data, and compute by the second instead of a monthly tier nobody fully uses.
Watch 90 seconds, pay for 90 seconds. And because settlement ties to objective delivery facts, a feed that buffers bills less.
Pay-as-you-play access, instant in-game purchases, and payouts flowing the other way: one pot split across players, creators, and platform.
Live audio, music, tipping, bandwidth, energy — anywhere value should flow only while it's being delivered.
PROOF, NOT PROMISES
The client, plugins, and conformance kit are Apache-2.0 and public. The boundary between open and closed is machine-verified on the exact published bytes.
A public 12-check suite verifies any implementation — including ours — and emits a signed report. npx @dynamoprotocol/conformance-kit
Each code sample in the docs runs in CI against a live core. What you read is what runs — the build fails before a rotten sample reaches you.
A recreated $47,000 runaway loop stopped at $63 · an evidence bundle verified offline through 71 checks, with no network · 20+ property suites at 10,000 randomized runs each · decision parity across four plugins in three languages.
FAQ
They move money one payer to one payee. Dynamo settles payments across a network of agents — one budget split across many, metered and capped together, reconciled into one session. It stays x402-compatible, so it adds the multi-agent and streaming layer rather than replacing the standard.
No. Every instance runs Control Mode today: the complete enforcement engine — caps, rate envelopes, anomaly stops, revocation, signed vouchers — with no money anywhere and no payment setup of any kind. Card and stablecoin rails are enabled per instance when you need them. The objects are identical across all three, so moving to a money rail is a one-line change rather than a migration.
Settlement is tied to objective facts — latency percentiles, error rates, availability, unit counts — signed and attested, never a subjective judgement of output quality. SLA-failed units are never paid for, degraded streams refund to the attested break-point with the buyer made whole first, and a declared holdback window separates captured from final. Recourse is built into the rail rather than promised in a policy.
No. The guard and the SDK run on your machine and verify credentials offline; what crosses the wire to your instance is metering facts only — stream ids, unit counts, amounts, signatures. Prompts, completions, and payloads never leave your environment. Real money, when you enable a money rail, moves only inside a licensed payment institution or a self-custodied on-chain escrow — never through Dynamo.
Agents are the first buyer, but the engine is general. The same per-second streaming and budget-splitting powers pay-per-second video, pay-as-you-play gaming with player payouts, live audio, and metered human-facing APIs.
The finance and economic layer for the agent economy — built for the builders of it.