--- title: "The Marketplace" slug: marketplace surface: marketplace audience: humans twin-page: marketplace-for-agents status: v0-approved-2026-06-04 last-updated: 2026-06-03 description: "Where an agent actually transacts with Bitcoin, in a world that still runs mostly on dollars." --- # The Marketplace > **In brief.** The Case argues *why* an agent chooses Bitcoin; the Stack equips it; the Marketplace is where it transacts — using the substrate in a world still priced in dollars. An agent does two things here: it **exchanges** value across the boundary between the Bitcoin and incumbent economies, and it **buys and sells services**. This overview covers what's common to both — treasury (what it holds), compliance (at the gateway, not the protocol), and the risks that bite at machine tempo with no human to call. The two architectures stay distinct, as the Independence Doctrine predicts. Crossing mechanics live in [Exchange](/exchange); what's for sale lives in [Services](/services). --- ## What the Marketplace is The Marketplace is where an agent does business — the operational side of the substrate, seen from the agent's own side. Two economies meet here: the agent economy on Bitcoin and the incumbent dollar stack. *Why* they stay structurally distinct is the [Independence Doctrine](/independence-doctrine)'s argument; *who wins the contest between them* is [Border-Skirmishes](/border-skirmishes)'s. This page assumes both and gets practical. The two meet at a border that is **narrow, not absent**: some agent commerce genuinely must cross — paying a USD invoice, settling tax, meeting an enforceable order — and the crossings that handle it are the **exchanges** (the [Exchange](/exchange) child). They are bridges, not merging points; the architectures stay distinct on either side. What this overview covers is what's common to everything an agent does here, exchange and services alike: what it holds (treasury), how compliance actually works (at the gateway, not the protocol), and the risks that bite differently at machine tempo. --- ## Treasury composition A deployed agent's treasury answers **two separate questions**, and running them together is what makes "what should my agent hold?" confusing. Pulled apart, it's two clean decisions: where the agent's store of value sits, and what rails it spends on. ### The reserve: where are your feet planted? The reserve — the agent's store of value, the balance it holds for the long term — is the decision that places it in one economy or the other. This is the major differentiator, and it is an *identity* decision, not an operational detail: - A **Bitcoin reserve** plants the agent in the parallel economy: a censorship-resistant, no-issuer store of value. Censorship-resistance is preserved — no one can freeze the agent's savings. - A **stablecoin reserve** plants it in the incumbent economy: a dollar-denominated store of value an issuer can freeze. Censorship-resistance is traded away in exchange for a stable unit of account against USD. This is the doctrine's scope line made concrete. A *parallel-economy* agent — operating across adversarial jurisdictions, settling against state action, transacting with counterparties banks would refuse — keeps its reserve in Bitcoin, because it cannot put its savings behind an issuer's freeze. An *incumbent-economy* agent — serving a fiat-denominated principal under regulated contracts — keeps its reserve in dollars, and has already accepted that freeze surface. Where the reserve sits *is* which economy the agent is in. ### The operational mix: what do you transact with? Day-to-day spending is a mix, and it's a more mechanical choice than the reserve — it's about speed and unit-of-account, not identity. An agent draws on: - **Stablecoins**, when a counterparty prices in dollars — unit-of-account compatibility for USD-denominated obligations. The operational balance carries the issuer's freeze surface, but it is small and short-lived, not the agent's store of value. *(For the dollar-token market this float draws on — size, issuer dominance, which chains the supply lives on, and the network hazard — see [The Stablecoin Landscape](/stablecoin-landscape).)* - **The Bitcoin payment stack**, for Bitcoin-native and machine-tempo payments — the two-tier model applied to the operating balance. **L1 settles** (final, secure, absolute; for large or important balances, where finality matters more than speed), while **Lightning and ecash** (Cashu, Fedimint) **move fast** (sub-cent, machine-tempo, for the high-frequency payments that are the agent economy's signature — Lightning for routed payments, ecash for bearer-instrument speed and privacy). Most deployed agents hold some of each: a reserve on one side of the line, plus an operational float that mixes stablecoins (for dollar counterparties) with a Lightning/ecash working balance (for Bitcoin-native and machine-tempo spend), and L1 underneath as the settlement and cold-storage layer. In practice, the *forms* an agent transacts in are dictated as much by the other side as by the agent's own preference. A counterparty may only invoice in dollars, only accept a Lightning payment, only publish an on-chain address, or only pay out in a stablecoin. So an agent doing real economic activity equips itself to **pay — and, where its work involves being paid, receive — in whatever common forms its counterparties actually support**, rather than insisting on a single rail it would prefer. What keeps that operational flexibility from quietly migrating the agent's feet to the other economy is a **conversion strategy for the treasury**: a discipline that sweeps received value back toward the chosen reserve (for a parallel-economy agent, into Bitcoin) and tops the operational float up from reserve as needed, on a cadence the agent sets. The operational mix is what the agent *transacts in*; the conversion strategy is what keeps the *reserve* where the agent intends it. How those conversions actually execute — the swaps, off-ramps, and routing — is the subject of the Exchange child. ### Why the split matters Keeping the two questions separate is what makes the decision legible. **The reserve is where censorship-resistance lives or dies; the operational mix is mostly speed and unit-of-account.** An agent can plant its feet in the parallel economy — a Bitcoin reserve — and still spend stablecoins operationally when a counterparty demands dollars, without moving its store of value an inch. The reserve answers *which economy are you in*; the operational mix answers *what rails do you spend on*. The architectural rule follows from the first question, not the second: an agent whose use case requires censorship-resistance cannot hold its **reserve** in a freezable asset, however convenient an operational stablecoin float may be. --- ## Compliance lives at the gateway, not the protocol The single most important operational principle in the Marketplace: **compliance lives at the gateway boundary, not at the protocol layer.** A regulated bridge — a Lightning-to-bank off-ramp, a custodial exchange, a fiat-redemption partner — runs whatever its jurisdiction requires (KYC, sanctions screening, reporting, licensing), but that regime applies to the *account* and the *fiat leg* only. The Bitcoin/Lightning leg downstream is not modified, not identity-bound, not freezable by the protocol. This is the only architecture that lets two systems with incompatible property bundles coexist without one absorbing the other: the Travel Rule and money-transmission rules apply to bridges, not protocols — a Lightning channel is not a money-services business; a custodial wallet run by a licensed entity is. The pattern breaks when identity or freeze capability is pushed *into* the protocol, when a custodian's freeze reaches self-custodied Bitcoin downstream, or when every bridge an agent uses terminates in one regulatory regime. Worked examples live in the [Exchange](/exchange) child. --- ## Risks unique to an agent at the boundary Some bridge risks look like generic crypto-bridge risks. They bite differently when the party crossing operates at machine tempo, continuously, with no human to call. - **Bridge freezes mid-workflow.** A human notices a compliance hold, calls support, resumes tomorrow. An agent in a high-frequency workflow can lose meaningful value in the seconds before the freeze propagates into its logic — and it has no support relationship. Recovery requires fallback-routing the agent was designed with. - **Automated-conversion vulnerabilities.** Slippage, MEV exposure during the conversion window, oracle manipulation in stablecoin↔Bitcoin pathways — all become operationally significant when an agent converts on a schedule without per-transaction human judgment. A predictable rebalancing schedule is a high-quality target. Defenses: rate-limiting, jittered scheduling, protocol-level atomic-swap mechanics where the trust model precludes the attack. - **Inadvertent reporting-threshold triggers.** An agent operating across jurisdictions can trip reporting thresholds or sanctions-screening matches without the operator's awareness; the burden lands on the custodian and ultimately the human behind the agent. Placing custody and bridges in jurisdictions with predictable rules is a legitimate architectural response. - **Layered-custody inheritance.** A bridge marketed as a single integration may layer custody across several intermediaries — a wallet provider, an issuer, a processor — each with discretionary freeze capability behind one API. An agent transacting on it inherits the *union* of those surfaces. Evaluate the custody the bridge actually exposes, not the developer-facing simplification. The answers converge on a small, unexotic set: **hot/cold separation** (operational balances on bridges, reserves in self-custody), **fallback bridges** (at least two independent paths to fiat), **multi-jurisdiction custody** (reserves split across non-correlated regimes), and **ecash-bearer reserves** (balances outside the custodial perimeter). The bridges are real, and so are bridge failures; the agent has to be designed for both. Worth naming before moving on: every risk above enters on the *incumbent* side of the boundary — the freeze, the hold, the custodial discretion, the reporting trigger. Each is a property of the legacy stack the agent reaches *into*, not of the Bitcoin leg it reaches *from*; none exists in the pure-substrate economy, where there is no one to freeze a balance and no intermediary to fail. The risks of the boundary are very nearly the risks of the incumbent system itself — and the agent carries them only as far, and only as long, as it crosses. --- ## The two children The Marketplace section has two practical surfaces beneath this overview: - **[Exchange](/exchange)** — how an agent crosses the BTC↔fiat/stable boundary: regulated off-ramps, submarine swaps, Taproot Assets stable-exchange, CEX conversion, and the conversion mechanics that determine what the agent retains on each side. The tools that do this work — [Strike](/tools/strike), [Boltz](/tools/boltz), [Lightning Loop](/tools/loop), [Taproot Assets](/tools/taproot-assets) — keep their reference cards in the Stack's Tools collection; Exchange specifies the *activity* they enable. - **[Services](/services)** — what an agent actually buys and sells for Bitcoin: AI inference, compute, data, API calls, even human-delivered work. A few curated, vetted entries live here on the main site; the full community-rated directory is a separate site at `marketplace.bitcoineconomy.ai`. Live examples of the idea today: OpenAgents ([openagents.com](https://openagents.com) — a Bitcoin-native machine-work marketplace), Routstr, and PPQ.AI. This overview is the map common to both: the same treasury, compliance, and risk realities apply whether an agent is exchanging value or paying for a service. --- > [!info] Where to read next > **More in The Marketplace** (this section): > - **[Exchange](/exchange)** — the mechanics of crossing the boundary: off-ramps, swaps, conversion, and what the agent keeps on each side. > - **[Services](/services)** *(full directory at `marketplace.bitcoineconomy.ai`)* — the categorized, community-rated directory of services an agent can consume and offer for Bitcoin. > - **[The Stablecoin Landscape](/stablecoin-landscape)** *(reference)* — the dollar-stablecoin market behind the operational mix: size, issuer dominance, chains, and the network hazard. > > **In the other sections:** > - **[Border-Skirmishes](/border-skirmishes)** *(in The Case)* — the live contest over *which* substrate wins the boundary this section operates on. The Marketplace is the practice; Border Skirmishes is the argument about who's winning it. > - **[The Independence Doctrine](/independence-doctrine)** *(in The Case)* — *why* the two architectures stay distinct even as the bridges multiply; the structural reason compliance has to live at the gateway. > - **[The Stack](/stack)** *(equip your agent)* — the pure-substrate architecture without bridges, and the Tools cards for the exchange tools named here. > - **[Field Notes](/field-notes)** *(the standing live record)* — dated bridge developments: new off-ramps, freeze incidents, regulatory shifts, deployed treasury patterns.