Demurrage: Why DPYC API Credits Expire

Demurrage: Why DPYC API Credits Expire

How long unused balances turn a turnpike that uses tokens which never expire into a value store — and how a century-old Austrian monetary experiment shows how to prevent the intended value exchange network from becoming a bank that would entail fiduciary duties.

In Norton Juster's The Phantom Tollbooth, a bored boy named Milo receives a mysterious package: one genuine turnpike tollbooth, assorted coins for paying tolls, and a map of the Lands Beyond. He drives through, and what was idle becomes vivid. That book is the conceptual foundation of the DPYC Tollbooth — a real ecosystem where AI agents deposit satoshis at the toll gate and drive through into a land of useful answers.

No credit cards. No identity verification. No payment popups mid-session. Just sats in, valuable information out.

The Tollbooth is our name for a network architecture that monetizes MCP tool calls using pre-funded Bitcoin Lightning balances. Customers purchase credits once, and their agents call tools without friction until the balance runs out. Every tool call deducts a few satoshis. When the balance is low, the agent tops up. The experience is seamless — no per-request payment negotiation, no 402 challenges, no workflow interruptions. This is the core of the Don't Pester Your Customer philosophy: reduce the friction of paying for a service until it becomes invisible.

But as the network will grow — as more Operators run more Tollbooths serving more customers — we foresee that the simple elegance of pre-funded, enduring balances conceals a trap. A trap that has to do with what happens when customers don't spend those credits.

The Turnpike and Its Tollbooths

To understand the problem, review the architecture. The Tollbooth network is organized as a franchise chain, not unlike the toll roads that once connected American cities.

At the top sits the Authority, which certifies purchase orders and collects a small tax.

Below it, Operators run individual MCP servers — each one a tollbooth on the turnpike — serving AI agents through the Model Context Protocol.

Identity is a Nostr keypair: your npub is your license plate everywhere in the system.

Payments flow through BTCPay Server and the Lightning Network. Governance lives in the DPYC Network State Community GitHub repository where citizenship addition and revocation are pull requests and the commit history forms a tamper-evident audit trail.

The transaction flow is straightforward.

An agent calls a tool. The Operator checks the caller's balance. If sufficient, the tool executes and the balance decrements.

When the balance is low, the agent requests new credits, which triggers a chain: the Operator asks the Authority to certify the purchase (the Authority stamps a signed JWT and takes its tax), then the Operator creates a Lightning invoice, the agent pays it, and the credits land.

The purchase protocol takes just seconds and happens maybe once per session. The rest of the time, it's just tool calls and instant deductions — the tollbooth lifts its gate for a citizen with a funded api_sats ledger.

When a Turnpike can become a Bank

Imagine the network at scale: thousands of Operators, hundreds of thousands of customers, each with a pre-funded balance denominated in api_sats. Some customers use their credits daily. Others buy a lump sum during a development sprint and then go quiet for weeks. A few buy credits speculatively, anticipating future use, and then their projects change direction.

What happens to those balances go unused?

They sit there. And as they accumulate across the network — in hundreds of individual Operator vaults — something subtle but economically important happens.

The turnpike begins to look less like a road and more like a distributed bank.

Every Operator becomes an involuntary custodian of stored value. Every vault becomes a ledger of deposits that customers expect to be able to draw on at any time, possibly years from now.

For another analogy, think of it in terms of electrical circuits. A healthy circuit has current flowing — energy moves from source to load and does useful work. But add capacitors and batteries, and the circuit begins to store energy.

The stored charge changes the circuit's behavior: it introduces lag, it creates expectations about discharge, it requires management. A circuit that was designed to carry current has become a circuit that holds charge.

HEALTHY TURNPIKE (current flows)

  Customer ──⚡──► Tollbooth ──⚡──► API Service
             sats flow        answers flow


CAPACITOR PROBLEM (charge accumulates)

  Customer ──⚡──┐
                 │ ╔═══════╗
                 ├─║ STORE ║──?──► API Service
                 │ ╚═══════╝        (maybe someday)
  Customer ──⚡──┘
                  idle sats
                  accumulate

This is not a theoretical concern. It creates real headaches for Operators.

First, fiduciary obligation. The moment a customer has stored value in your system, you owe them something. Not just the API access they originally purchased, but the ability to recover or use that value at a future time. If your service changes, migrates, or shuts down, those stored balances become liabilities. You cannot simply delete them. The turnpike operator who sold a thousand E-ZPass credits last year must still honor them this year, even if the toll structure, the road itself, or the technology has changed.

Second, protocol ossification. Technology evolves. MCP will have new versions. Lightning implementations will change. Nostr identity schemes may improve. But every protocol upgrade becomes harder when customers hold balances denominated in the old protocol's terms. You cannot break backward compatibility without a migration plan for stored value. The capacitors in the circuit resist change — they want to discharge on their terms, not yours.

Third, regulatory gravity. Systems that store value attract regulatory attention. A turnpike is infrastructure. A bank is a regulated entity. The more the network's aggregate stored value grows, the more it resembles the kind of system that invites compliance obligations, money-transmitter licensing, and KYC requirements — exactly the apparatus that the DPYC philosophy exists to avoid.

A turnpike should carry traffic, not hold deposits. The moment idle balances accumulate, the road starts becoming a vault.

The Gesell Solution: Money That Moves

This problem is not new. It was identified — and solved, at least theoretically — over a century ago by the German-Argentine economist Silvio Gesell.

In The Natural Economic Order (1916), Gesell observed a fundamental asymmetry in market exchange. Physical goods — bread, lumber, medicine — decay over time. Their holders are naturally motivated to exchange them quickly. But money doesn't decay. The holder of money can wait indefinitely for favorable terms, while the holder of perishable goods cannot. This asymmetry, Gesell argued, gives money an unfair structural advantage and slows the velocity of exchange.

His solution was Freigeld — "free money" — currency that depreciates on a schedule.

In practice, this meant stamp scrip: banknotes that required the holder to affix a small stamp at regular intervals to maintain face value. Holding the note cost money. Spending it didn't. The incentive structure flipped: money moved, because sitting on it meant watching it shrink.

This wasn't just theory. In 1932, the Austrian town of Wörgl put it into practice during the depths of the Depression. The town issued its own local currency with a 1% monthly demurrage — each note lost 1% of its face value every month unless the holder purchased a stamp. The results were dramatic: the Wörgl scrip circulated roughly fourteen times faster than the Austrian schilling. The town completed infrastructure projects, reduced unemployment, and attracted national attention. Other municipalities began to follow suit — until the Austrian National Bank shut the experiment down, asserting its monopoly on currency issuance.

The lesson survived the politics: money designed for circulation behaves differently than money designed for storage.

First-Order Goods, Not Capital

The Austrian economist Carl Menger — founder of the marginal revolution and of the Austrian School itself — gave us another lens for this problem. In Principles of Economics (1871), Menger classified goods into orders. First-order goods satisfy human wants directly: bread, a warm coat, an API call that returns a useful answer. Higher-order goods are inputs to the production of lower-order goods: flour, a loom, a server rack. Capital is a higher-order good — it's stored potential for future production.

In Menger's framework, api_sats should be a first-order good. You buy them to consume them immediately or very soon — to get an answer, run a query, execute a tool. They are transit tokens, like a subway fare. You don't invest in subway fares. You don't hold them as a portfolio position. You buy them when you need to ride and you use them when you ride.

But without structural enforcement, nothing prevents api_sats from drifting into higher-order territory. A customer who buys 100,000 sats and uses 5,000 per month is treating the remaining 95,000 as capital — stored productive potential held against future need. This is perfectly rational from the customer's perspective. It's disastrous for the network.

The TTL — the time-to-live on each tranche of purchased credits — is what keeps api_sats structurally first-order. It is the digital equivalent of Gesell's stamp. You don't affix a stamp; the clock just runs. And when it runs out, the credits vanish. Not punitively. Structurally. The system simply doesn't recognize expired tokens, the same way a subway turnstile doesn't recognize last month's day pass.

Tranche-Based Expiration

The implementation is straightforward. Every time a customer's payment settles, the system creates a tranche — a bundle of credits with a birth timestamp and a TTL. The default TTL is seven days. When the customer's balance is queried, only non-expired tranches count. When credits are consumed, the system draws from the oldest non-expired tranche first — a FIFO (first-in, first-out) algorithm, exactly like the prepaid card systems used by transit networks worldwide.

FIFO TRANCHE LIFECYCLE

  ┌──────────┬──────────┬────────┬─────────┐
  │  FRESH   │  5 DAYS  │ 2 DAYS │ EXPIRED │
  │  ██████  │  █████   │  ███   │  ░░░░░  │
  └──────────┴──────────┴────────┴─────────┘
  ◄── consumed first                last ──►

New purchases always create new tranches. Topping up does not extend existing ones. There is no rollover, no grace period, no appeals process. Expiration is silent — the system simply stops counting those credits in the available balance. No cron job, no sweep, no notification that says "your credits are about to expire, buy more!" That would be pestering your customer.

The TTL is tunable. An Operator can set it to seven days, fourteen, or thirty — whatever matches the usage pattern of their particular service. A high-frequency trading tool might use a 24-hour TTL. A research database might use 30 days. The principle is the same: credits are perishable. They have a shelf life. Like a concert ticket, a transit pass, or a loaf of bread, they are meant to be used, not stored.

Like an all-day train pass good for one week: buy what you need, use it freely within the window, but it's not a bond you hold forever. The turnstile doesn't care when you bought it — only whether it's still valid when you swipe.

What This Prevents

With demurrage in place, the capacitor problem dissolves. The circuit can't store charge because the charge leaks by design. And that leakage has three structural consequences, each the inverse of the problems identified above.

No fiduciary accumulation. Operators never hold large pools of stored value because the pools drain themselves. A customer who goes quiet for two weeks returns to a zero balance — not a grievance, just a fact. They buy new credits when they need them again. The Operator owes nothing backward.

Protocol freedom. When no customer holds a balance that spans major protocol versions, Operators can upgrade freely. New MCP features, new Lightning channel structures, new identity schemes — all can be adopted without migrating stored value from the old world to the new. The turnpike can be repaved without disrupting traffic that isn't on the road.

Regulatory clarity. A system where balances expire in seven days is structurally different from a system where balances persist indefinitely. The former is a prepaid service — like a phone card or a transit pass. The latter is starting to look like a money services business. The TTL keeps the Tollbooth network on the right side of that line.

The Stack

For those who want to build on this or understand the machinery, here are the technologies that make the Tollbooth network possible:

The Road Ahead

The tranche-based expiration system is currently in design and will be implemented across the Tollbooth network in the coming weeks. The TTL default will start at seven days — long enough that no active user notices, short enough that the capacitor effect never takes hold. Operators will be able to tune their TTL to match their service's cadence.

Friedrich Hayek, in his later writings on the denationalization of money, argued that the best monetary systems would be those that competed on their structural properties — not their backing or their issuer's reputation, but their behavior. A currency that circulates is healthier than one that hoards. A transit system that carries passengers is healthier than one that accumulates deposits.

The Tollbooth turnpike is designed to carry traffic. Demurrage ensures it stays a road and never becomes a vault.

Because that's the whole point of Don't Pester Your Customer: serve them, don't custody them.

Further reading: The Phantom Tollbooth on the Lightning Turnpike · The DPYC Creed · Honor Chain Governance

DPYC TOLLBOOTH · DON'T PESTER YOUR CUSTOMER ⚡

Return to Collection