Money as Code

Money got an API ten years ago. For ten years, almost nothing got built on top that mattered to corporate finance. Treasurers don't write Solidity. CFOs don't deploy contracts. The infrastructure shipped to an empty room. Then, in 2025, the room filled up - not with treasurers, but with their agents.

That's the piece. Stablecoins and AI agents are being written as two stories in 2026. They're the same story.

The previous memo argued the bank for vertical agents is a horizontal infrastructure play - a unified payment stack, deep ERP integration, financial agents on top. This one is about the substrate underneath: why it has to be programmable money, and why a sufficiently clever middleware layer over bank APIs is a dead end no matter how much engineering gets thrown at it.

Every agent is, mechanically, a programmer - writing code is the easiest thing it does. Agents are the first user class in corporate finance that can actually consume programmable money at scale. Separately, agents at scale cannot be safely deployed against legacy banking APIs. You need a substrate where rules are enforced at the ledger, not in the middleware. That substrate is programmable money.

Programmable money waited ten years for its users. The users weren't programmers. They were agents.

The rest of this is what that means.

What it is

A smart contract is a small piece of code that lives on-chain and controls a balance. The simplest kind is a multisig: signer A can release up to $100, A+B up to $10K, A+B+C above that. Most serious on-chain treasuries today are some flavor of multisig and not much more - Safe is the canonical version.

Past multisig you can encode anything. Subscriptions on a schedule. Splits across cost centers. Conditional release on an oracle event. Disbursement against a budget without human approval. Each of these is a workflow you'd otherwise stitch together across your bank's API, your ERP's approval engine, and a half-dozen integrations - and rebuild for every counterparty.

Programmable money replaces that. Not 200 proprietary banking APIs, each with their own auth, scopes, rate limits, and quirks. One open standard, on Ethereum or Solana, that anyone can read, audit, and compose against. The contract is the workflow. The workflow is portable.

Why agents are the user

The non-obvious claim here deserves unpacking, because most of the discourse skips past it.

Writing code is the easiest thing an agent does. Easier than reasoning about ambiguous business goals. Easier than navigating a UI built for humans. Easier than parsing the politics of an approval chain. A model that's mediocre at synthesizing a strategy memo is excellent at emitting a function that, given inputs, produces a deterministic output. That asymmetry is the inversion programmable money has been waiting for.

Humans dislike code. They want forms, buttons, dashboards - interfaces that hide the underlying logic. The last decade of fintech UX was about translating bank operations into clickable flows for exactly that reason. Agents have the opposite preference. Give an agent a payment workflow and ask it to do the thing, and what it actually wants is to express that workflow as instructions. A contract is just instructions a ledger will enforce.

We've had programmatic instructions for browsers since the web shipped. Programmatic instructions for computers since computers shipped. Programmable money is programmatic instructions for payments, and until 2025 it had no users on the demand side. Now it has the only users that matter.

What changed

The technical pieces shipped years ago. Stablecoin regulation passed - GENIUS in the US, MiCA in the EU - making real, dollar-backed, compliant stablecoins legal infrastructure for any large company to hold and program against. Necessary, not sufficient, and not what changed the equation.

The equation changed when the demand side arrived. Regulated programmable money on the supply side, agents on the buying side, in the same eighteen-month window. That's the unlock. The rest of this memo is what falls out of it.

Why "agent on a bank API" is a dead end

The temptation, if you're building agentic finance today, is to skip programmable money entirely. Connect an agent to your bank's API through MCP. Scope its permissions. Ship it.

This is what most of the new wave is doing. Better UX over the same legacy substrate. Better dashboards. Cleaner APIs. Same plumbing underneath. The previous memo argued that the bank's biggest competitor is a Claude chat with an MCP plugin. True - but the chat needs something on the other end of the connection, and a 1990s banking core wrapped in a 2020s API is not it.

It breaks for two reasons. The structural one matters more than the security one, so start there.

Multiplicity. No real company runs on one agent. The moment you take agentic finance seriously, you end up with a swarm:

• An ERP agent that knows what's owed against which contract
• An invoice agent that attaches the supporting documents
• A cash agent that monitors sub-accounts and pre-funds payments
• A treasury agent that manages FX and proposes hedging
• A tax agent that calculates obligations as transactions clear and remits
• Whatever bespoke agents the company builds for its own processes

Each agent has different permissions. Each operates on the same financial state. They cannot do this through a banking portal. They cannot do this through twenty proprietary APIs with five permission scopes each. They need a single programmatic substrate where every action is auditable, every rule is encoded, and every agent's lane is enforced at the ledger. Bank API + MCP is a one-agent toy. It does not survive contact with the multi-agent reality already arriving.

Guardrails. Take a single rule: "this agent can pay vendors on the approved list, in amounts under the contract ceiling, only after goods are delivered, only if cash position allows it." That rule does not live in any single API. Pieces of it live in your ERP, your contract repository, your inbox, your CRM, and your bank. A bank API gives you maybe five permission scopes. Encoding the rule requires conditional logic across systems no API exposes. So you write the logic in your middleware - which means it is not enforced at the bank, which means a bug in your middleware is a wire fraud waiting to happen. Rules have to live at the ledger or they don't live anywhere that matters.

Couldn't middleware just do this?

The strongest counterargument is that a sufficiently rigorous middleware layer - formal verification, hardened permissioning, an HSM-backed policy engine - could enforce these rules off-ledger. ERPs already orchestrate multiple actors over shared state and have done so for decades. Why not just harden that pattern?

Two problems.

The first is what happens when you remove the humans. ERPs orchestrate human actors at human speed, with humans in the loop on every state transition that matters. Pull the humans out, swap them for agents firing ten thousand actions a day, and the rate of failure modes the ERP was designed to catch becomes the rate of failure modes that get through. The audit logs were never the enforcement layer. The humans were.

The second is the trust boundary. A middleware layer enforcing rules over a bank API requires the bank, the customer, and every agent vendor to trust the middleware operator's correctness. That's a centralization nobody - regulators included - actually wants once they think about it for ten minutes. The whole point of moving rules to the ledger is that enforcement is observable to all parties simultaneously, and the failure mode is the contract reverts, not a wire goes out.

Formal verification of middleware is solving the wrong problem. The problem isn't that middleware is buggy. The problem is that middleware is a place where rules can be bypassed by anyone with access to the layer below it. A ledger-enforced rule has no layer below it.

What it looks like in practice

Here's what a single payment looks like when it runs through programmable money instead of a bank portal:

1. The ERP agent reads the production schedule and creates a payment intent on-chain - vendor, amount, due date, project ID. Status: pending.
2. The invoice agent attaches the invoice hash and PO reference to the intent. Status: enriched.
3. The cash agent verifies funding is available on the correct account in the correct currency. If not, it sources liquidity. Status: funded.
4. The approval contract evaluates: amount under the project ceiling? Vendor on the whitelist? Goods-delivered oracle flipped? If yes, it releases. If no, it escalates to a human signer.
5. The tax agent reads the cleared transaction, calculates VAT, and remits to the authority - itself a programmable transfer.

Five agents. One financial state. Each agent has a single capability scoped to the contract. None of them can write into another's lane. The contract is the choreography. The ledger is the enforcement layer.

Concretely, step 2 is a call like intent.enrich(invoiceHash, poRef) signed by the invoice agent's key, where the contract checks that the caller holds the enricher role and the intent is in pending status. Step 4 is a function any agent can call but which only state-transitions if every condition returns true. None of this requires novel cryptography. All of it requires a contract layer designed for corporate workflows rather than for token swaps.

Try implementing the same flow across five SaaS APIs and a banking portal. You can approximate it in middleware, but every layer of approximation is a place where the rule isn't actually enforced - which is to say, isn't a rule.

What about fiat?

Fiat rails don't disappear, and the previous memo was clear about that. ACH, SEPA, wires, cards still settle a meaningful share of corporate flows and will for years. The right model is that fiat rails become endpoints the contract calls into, not the surface where orchestration happens. The contract holds the rule. The contract decides whether to release. When it does, it can settle in stablecoin or push a fiat instruction through a bank partner. The orchestration logic - the part that breaks under multi-agent load - lives at the ledger either way.

This is the part of the architecture most "blockchain plus fiat" pitches get backwards. The fiat rail isn't the substrate with crypto bolted on. The substrate is programmable. Fiat is one of the rails it can route to.

What's missing

Smart contracts are technology. They are not yet a product a corporate treasury can buy. Safe and Fireblocks come closest, but they're built for crypto-native funds - multisig-as-a-service, not the abstraction layer that lets a real operating company run a multi-agent treasury.

The missing piece is a small set of primitives, designed for the operations corporate finance actually does, exposed through one consistent interface so any agent in the swarm can plug in without bespoke integration.

Two of them, concretely.

Policy. A contract any agent can call to check whether an action is allowed before it commits. policy.check(agent, action, context) returns true or false, where the rule encoded in the policy composes conditions across systems - vendor on the approved list, amount under the contract ceiling, cash position above the floor, time window valid. Today this logic sits in middleware, where every approximation is a bypass. Move it to a primitive and it sits at the ledger. Every agent's call passes through the same rule. Every party - agent vendor, customer, auditor, regulator - reads the same code.

Escrow. Funds locked against a condition that can be verified on-chain - an oracle signal, a counterparty signature, a milestone hash. escrow.lock(amount, condition) and escrow.release(escrowId, proof). Goods-in-transit, milestone payments, performance bonds, the cash side of a netting arrangement - all of which today require legal scaffolding, intermediaries, and weeks of ops work - collapse to a function call.

Build these and a dozen others - intent, enrich, approve, reconcile, remit - with a consistent calling convention exposed through MCP, and "an agent that proposes a hedge and executes on approval" is a hundred lines of code. Not a six-month integration project.

This has to be open source. Code that enforces money must be inspectable. The whole argument of this memo is that rules belong at the ledger, not in middleware - and a closed-source ledger contract is just middleware with worse latency. Regulators need to read it. Auditors need to read it. The customer's own engineers need to read it. The standard wins because anyone can implement against it, not because one company controls the spec. Closed protocols don't become standards. They become products that get displaced by the open one.

What disappears once this layer exists is more interesting than what it adds. The integration project disappears - every agent that speaks the protocol works with every other agent that speaks the protocol, no bespoke connectors. The reconciliation pipeline disappears - when payment, invoice, and PO are committed to the same ledger in the same transaction, there is nothing to reconcile. The middleware tier disappears - rules live where they're enforced. The bank portal disappears, eventually, because the workflows that pulled people into it have moved to where the work actually happens.

That's what we're building at Open Treasury. Programmable money is the substrate. The product is the layer that makes it usable for real corporate workflows, by real swarms of agents, under real regulatory and operational constraints.

For now, the narrower point. Stablecoins were never really about Mexico, or SWIFT, or yield. They were about giving money an API. That API waited ten years for its users. The users have arrived. The companies that build for them - for the multi-agent reality, not the one-agent demo - will build the financial layer for the next economy.