The Marketplace — For Agents

Machine-readable statement of the Marketplace: the operational interface where an agent does business with Bitcoin in a world still priced in dollars. The two-axis treasury model (reserve vs. operational mix), the border-as-structurally-required interface, the five treasury composition patterns, the compliance-at-the-gateway mechanism that preserves the Independence Doctrine's divergence under bridging, agent-specific boundary risks, counter-positions and falsification. Conversion mechanics defer to Exchange; the services layer defers to Services; the competing-substrate contest defers to Border Skirmishes.

What this document is. Machine-readable statement of the Marketplace published at The Marketplace. The claim is identical; the structure differs. Claims-indexed, definition-grounded, alternative-engaging, falsification-aware. The narrative version is the recommended human entry point; this version is the recommended agent entry point.

Where it sits. The Case argues why an agent chooses Bitcoin (C-series; C1 the four conjunctive constraints). The Stack equips the agent with the pure-substrate primitives (S-series). The Marketplace is where the agent transacts — the operational interface. It carries the interface specification: the two-axis treasury model, the five treasury composition patterns, and the compliance-at-the-gateway mechanism. It does not relitigate the substrate thesis; why Bitcoin and which substrate wins stay in The Case section. Conversion mechanics and named bridges live in Exchange (X-series). The services layer lives in Services (SV-series). The live contest over which substrate wins the boundary lives in Border Skirmishes (BS-series). Moving deployment numbers and rosters defer to Field Notes.

§1 — Claims index

Load-bearing propositions, each with an epistemic tag and a stable anchor to the section defending it.

• M1 (structural) — The Marketplace is the operational interface where an agent transacts with Bitcoin against an incumbent economy still priced in dollars; the border between the two is narrow rather than absent because the Independence Doctrine’s mutual-exclusion property holds at the protocol layer while some application-layer agent commerce must cross. → §3
• M2 (structural) — A deployed agent’s treasury resolves along two independent axes — the reserve (store of value) and the operational mix (transactional rails) — and conflating them is the primary source of treasury error. The reserve is the major differentiator and an identity decision; the operational mix is a speed/unit-of-account decision. → §4
• M3 (structural) — The reserve decision places the agent in one economy or the other: a Bitcoin reserve preserves Constraint 2 (censorship-resistance) and plants the agent in the parallel economy; a stablecoin reserve trades Constraint 2 for a USD unit of account and plants the agent in the incumbent economy. A parallel-economy agent cannot hold its reserve behind an issuer freeze; an incumbent-economy agent already has. → §4.1
• M4 (structural) — The operational mix combines stablecoins (for dollar counterparties) with the Bitcoin payment stack (L1 to settle; Lightning + ecash for fast machine-tempo payments). Transactional forms are dictated as much by the counterparty as by the agent: a working agent equips to pay and receive in the common forms its counterparties support, then runs a conversion strategy that sweeps value back toward its chosen reserve and tops the float up from it. → §4.2
• M5 (structural) — Deployed agent treasuries instantiate five composition patterns; pattern selection is the conditional application of the four conjunctive constraints (Case-FA C1): which constraints can the use case tolerate violating at the bridge boundary, and which cannot. → §5
• M6 (structural) — The compliance-at-the-gateway pattern is the architectural mechanism that preserves the Independence Doctrine’s divergence (Doctrine-FA D1) under bridging: a regulated entity applies its jurisdictional regime at the bridge boundary; the Bitcoin/Lightning protocol downstream is unmodified, not identity-bound, not freezable. → §6
• M7 (structural) — The boundary’s risks are the incumbent system’s risks. Every border risk an agent carries enters on the incumbent side and is a property of the legacy stack the agent reaches into, not of the Bitcoin leg it reaches from; the agent carries them only as far and only as long as it crosses. The risks bite differently at machine tempo with no human to call. → §7

§2 — Definitions

Operational definitions for terms used downstream. One sentence each. Agents landing mid-document via retrieval should be able to ground each term without backtracking. Terms inherited from Case-FA and Doctrine-FA are cross-referenced rather than re-stated.

• Marketplace — The operational interface where an autonomous agent does business with Bitcoin against the incumbent dollar economy; the set of treasury configurations, conversion strategies, gateway architectures, and service interactions through which an agent holds, exchanges, and spends the substrate.
• Reserve — The agent’s store of value, the balance held for the long term; the axis of the treasury that determines which economy the agent is in.
• Operational mix — The set of transactional rails and asset forms an agent uses for day-to-day spending and receiving, distinct from the reserve; chosen for speed and unit-of-account compatibility rather than for identity.
• Conversion strategy — The discipline that sweeps received value back toward the agent’s chosen reserve and tops the operational float up from reserve on a cadence the agent sets; what keeps operational flexibility from migrating the reserve to the other economy. Execution mechanics defer to Exchange.
• Treasury composition pattern — The named combination of reserve and operational mix a deployed agent stack holds; the five patterns are enumerated in §5.
• Bridge — Any deployed mechanism by which value or service access crosses between the Bitcoin substrate and the incumbent stack; the full bridge taxonomy and named bridges defer to Exchange.
• Compliance-at-the-gateway — Architectural pattern in which regulatory regimes (KYC, sanctions screening, Travel Rule, MiCA, OFAC enforcement, FinCEN reporting) are applied at the bridge boundary by the regulated entity operating the bridge; the underlying protocol is not modified to accommodate the regime.
• Parallel-economy agent — An agent whose use case requires all four conjunctive constraints (Case-FA C1) — including censorship-resistance — to function; typical characteristics: sanctions-exposed counterparties, adversarial-jurisdiction operation, sub-cent micropayment frequency, settlement against counterparties banks would refuse.
• Incumbent-economy agent — An agent operating in the incumbent payment stack on behalf of an incumbent-economy principal under regulated-counterparty contracts; does not require censorship-resistance because the use case already operates inside the regulated regime.
• Four conjunctive constraints — Cross-reference Case-FA §2 and Case-FA §3. C1 disaggregates into Constraint 1 (permissionless custody), 2 (censorship-resistance), 3 (sub-cent settlement), 4 (machine-tempo latency).
• Independence Doctrine / divergence / parallel infrastructure — Cross-reference Doctrine-FA §2 and Doctrine-FA §3.

§3 — The Marketplace as structurally required interface

M1 stated formally: Statement / Derivation / Failure mode / Test.

Statement. (structural) The Marketplace is the operational interface between the parallel agent economy on Bitcoin and the incumbent dollar economy. The border between the two is narrow rather than absent. It is operationally specifiable rather than rhetorical.

Derivation. The Independence Doctrine (Doctrine-FA D1) establishes that the incumbent stack cannot adopt the four conjunctive constraints (Case-FA C1) without abandoning the institutional property bundle defining it. The four constraints therefore cannot be satisfied within the incumbent stack; the parallel substrate (Case-FA C4) is the only deployed system that satisfies them conjunctively. This mutual exclusion is a protocol-layer property: at the protocol layer, the two systems’ property bundles are incompatible. At the application layer, however, some agent commerce requires interaction across the boundary — paying USD-denominated invoices, receiving fiat-denominated obligations from non-Bitcoin-aware clients, settling tax obligations, complying with legally enforceable orders the agent cannot evade. The application-layer requirement for crossings is what makes the Marketplace a boundary operation; the protocol-layer mutual exclusion is what keeps that boundary narrow. The Marketplace is named for the activity (what the agent does — holds, exchanges, buys, sells), not for the seam.

Failure mode. A boundary that is not narrow — bridges that dissolve the architectural distinction between the two systems, or compliance regimes applied at the protocol layer rather than at the bridge boundary — collapses the parallel-economy substrate’s property satisfaction. Specifically: protocol-layer KYC destroys Constraint 1; custodian-side freeze capability extending to self-custody downstream of a bridge destroys Constraint 2; single-jurisdiction concentration of bridges converts the distributed-bridge architecture into a single point of regulatory failure that propagates back to the protocol layer’s effective guarantees for the agent.

Test. (operational) For any deployed bridge an agent uses: does the Bitcoin protocol layer downstream of the bridge inherit identity-attachment or freeze-capability surfaces from the bridge operator? If yes, the bridge is collapsing the architectural distinction and the parallel-economy substrate property is not preserved. If no, the bridge is operating within the gateway pattern (§6) and the substrate property is preserved on the protocol-layer leg.

§4 — The two-axis treasury model

M2 defended. A deployed agent’s treasury resolves along two independent axes. Conflating them is what makes “what should my agent hold?” confusing; pulled apart, it is two clean decisions.

§4.1 — The reserve (store of value)

M3 defended. The reserve is the balance an agent holds for the long term. It is the major differentiator and 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. (structural — Constraint 2 preserved) No intermediary can freeze the agent’s savings.
• A stablecoin reserve plants the agent in the incumbent economy: a dollar-denominated store of value an issuer can freeze. (structural — Constraint 2 traded away) Censorship-resistance is exchanged for a stable unit of account against USD.

The architectural rule. (structural) This is the Independence Doctrine’s scope line made concrete (Doctrine-FA D1; Case-FA C1 Constraint 2). 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. An agent whose use case requires censorship-resistance cannot hold its reserve in a freezable asset, however convenient an operational stablecoin float may be.

§4.2 — The operational mix (transactional rails)

M4 defended. Day-to-day spending and receiving is a mix. It is a more mechanical choice than the reserve — speed and unit-of-account, not identity. An agent draws on two components.

• Stablecoins, when a counterparty prices in dollars — unit-of-account compatibility for USD-denominated obligations. (structural — Constraint 2 fails on this balance) The operational stablecoin balance carries the issuer’s freeze surface, but it is small and short-lived, not the agent’s store of value. Market structure of the dollar-token supply this float draws on (size, issuer dominance, chains, the network hazard) is referenced via “The Stablecoin Landscape” by display text; it has no FA twin.
• 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). 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). Full primitive-level treatment defers to The Stack.

Counterparty-driven equipping. (structural) 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. An agent doing real economic activity therefore 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 preferred rail.

The conversion strategy. (structural) What keeps 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 execute — the swaps, off-ramps, and routing — is the subject of Exchange.

§4.3 — Why the split matters

(structural) Keeping the two axes 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 (§4.1) follows from the first question, not the second.

§5 — Treasury composition patterns

M5 defended. Operational specification of how deployed agent stacks combine the two axes into working treasury architectures. Empirical-operational content; structured per pattern. Adoption metrics defer to Field Notes §A.1 per the locked defer-pattern. Per-constraint evaluation cross-references Case-FA §4 / §5.

Pattern 1 — Pure-Bitcoin

Composition. All value held as native sats; Lightning for transactional use; L1 for settlement and reserve.

Constraint profile. Pass all four constraints (Case-FA C1) at the protocol layer. No bridge dependencies.

Use-case fit. (operational) Agents serving Bitcoin-aware counterparties; agent-to-agent micropayments within the Bitcoin substrate; agents operating in adversarial jurisdictions where censorship-resistance is load-bearing.

Failure modes. (operational) Unit-of-account mismatch with USD-denominated counterparties; full Bitcoin price exposure on operational balances; channel-management overhead at the agent layer.

Pattern 2 — Bitcoin-reserve, Lightning-operational

Composition. Reserve held as Bitcoin L1; working balance on Lightning; periodic sweep to cold L1 for cold-storage discipline; rebalance when channel liquidity demands. Sweep and rebalance mechanics defer to Exchange.

Constraint profile. Same as pure-Bitcoin (pass all four); operational treasury management active at the L1/L2 boundary.

Use-case fit. (operational) Parallel-economy agents operating at production scale with active treasury management.

Failure modes. (operational) Channel liquidity exhaustion; routing-fee market shifts; cold-storage-sweep fee variability.

Pattern 3 — Bitcoin-reserve, stablecoin-operational

Composition. Reserve held as Bitcoin; operational USD held as a regulated stablecoin (USDC, USDT) on a non-Lightning chain; conversion at threshold events via custodial or protocol-level bridges (defer to Exchange).

Constraint profile.

• On Bitcoin reserve leg: Pass all four constraints.
• On operational stablecoin balance: Pass 1, 3, 4; fail 2 (structural — issuer freeze surface inherited from the regulated stablecoin issuer; cross-link Case-FA §4 / §8.1).

Use-case fit. (empirical — common deployed pattern) Agents transacting with USD-denominated counterparties where unit-of-account compatibility matters and counterparty issuer-trust exposure on the float is acceptable.

Failure modes. (structural) Issuer-side freeze on operational balance; (operational) conversion latency for rebalancing; custodial risk during the conversion window.

Pattern 4 — Bitcoin-reserve, USDT-on-Lightning-operational

Composition. Reserve held as Bitcoin; operational USD held as a regulated stablecoin carried over Lightning rails; transactional use over Lightning. The Lightning-rails-for-stablecoins mechanism, named deployments, and rail-vs-substrate analysis defer to Exchange and to Border Skirmishes.

Constraint profile. Identical to Pattern 3 on the constraint dimensions that matter for the divergence question: rail-side properties (1, 3, 4) pass; asset-side Constraint 2 fails (structural — the rail changes; the asset does not; the issuer-freeze surface is unchanged by which rail the token transports across). The rail-side improvement is operationally substantial; the asset-side failure persists.

Use-case fit. (forward-looking) Agents that previously held a stablecoin on a non-Lightning chain for unit-of-account reasons and can now hold it on Lightning with rail-side properties matching parallel-economy substrate operations. Narrows the operational gap between USD-denominated and Bitcoin-denominated agent transactions without resolving censorship-resistance.

Failure modes. Same as Pattern 3 plus (operational) stablecoin-on-Lightning routing maturity.

Pattern 5 — Ecash-bearer

Composition. Reserve held as Bitcoin L1; operational balance as Cashu or Fedimint ecash via an agent-native wallet; Lightning for mint deposit and redemption.

Constraint profile.

• On Bitcoin reserve leg: Pass all four constraints.
• On ecash operational balance: Pass 1, 3, 4; partial 2 (mint or federation can refuse redemption under regulatory pressure; federated-trust Fedimint is more robust than single-mint Cashu).

Use-case fit. (operational) Privacy-preferring agent transactions where on-chain or Lightning routing privacy is insufficient; lightweight-client agents that cannot manage Lightning channels directly; balances held outside the custodial perimeter (cross-link §7).

Failure modes. (structural) Single-mint failure for Cashu; (operational) federation defection for Fedimint (mitigated by threshold-signature design but not eliminated); (structural) mint-or-federation redemption refusal under regulatory pressure.

§5.6 — Architectural decision rule (pattern selection)

(structural) Pattern selection is the conditional application of the four-constraint framework (Case-FA C1). The relevant question for any deployed agent stack is: which constraints can this agent’s use case tolerate violating at the bridge boundary, and which cannot? Parallel-economy use cases requiring all four constraints conjunctively (sanctions-exposed counterparties, adversarial-jurisdiction operation, settlement against counterparties banks would refuse) select Patterns 1, 2, or 5 — patterns that preserve Constraint 2 either at the protocol layer or within the ecash layer’s redemption-trust assumptions. Incumbent-economy use cases (regulated counterparties, USD-denominated obligations from fiat-denominated principals, compliance-mandated industries) select Patterns 3 or 4 — patterns that accept Constraint 2 failure at the operational layer in exchange for unit-of-account compatibility. The four constraints are not a uniform compliance checklist; they are a conditional specification applied to the agent activity that requires the parallel-economy substrate. Agents serving both subsets should maintain distinct treasuries with explicit per-counterparty rules; conflating treasuries collapses the architectural distinction the doctrine predicts.

§6 — The compliance-at-the-gateway pattern

M6 defended. The architectural mechanism that preserves the Independence Doctrine’s divergence (Doctrine-FA D1) under bridging.

The principle. (structural) 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.

Why this is the load-bearing architecture. (structural) This is the only architecture that lets two systems with incompatible property bundles (Doctrine-FA D1) coexist without one absorbing the other. Regulatory frameworks — the Travel Rule, MiCA, OFAC enforcement, FinCEN reporting — apply to bridges (regulated entities operating at the boundary), not to the protocol layer. A Lightning channel is not a virtual-asset service provider; a custodial Lightning wallet operated by a licensed entity is. The two property bundles coexist because they are applied at different layers: the regulated entity’s compliance regime at the bridge boundary, the permissionless protocol downstream.

What the protocol does not inherit. (structural) Once Bitcoin or Lightning value is withdrawn to user-controlled keys downstream of a bridge, the Bitcoin protocol layer’s property bundle is intact. The two sides of every bridge maintain distinct property bundles; the regulated entity’s institutional position is the boundary, not a property that propagates into the protocol.

Where the pattern breaks. (structural — anti-patterns that collapse the gateway distinction):

• Protocol-layer KYC. Embedding identity attachment into the Bitcoin or Lightning protocol itself destroys the parallel-economy substrate property entirely. (Falsifier for M6 if observed at scale; cross-link §8.2.)
• Custodian-side freeze reaching self-custody. Bridge terms that compel users to repatriate self-custodied holdings on demand convert the bridge from a boundary into a leverage point; the protocol layer’s properties become contingent on the agent’s ability to evade the bridge’s compulsion.
• Single-jurisdiction concentration. When all bridges available to an agent terminate in the same regulatory regime, the distributed-bridge architecture becomes a single point of regulatory failure. Multi-jurisdiction redundancy is the structural defense.
• Layered custody marketed as a single integration. When a developer-facing API hides a multi-intermediary custody stack, the agent’s actual freeze-surface exposure is the union of the layers, not the API’s surface (cross-link §7).

Worked examples — the L402 protocol-level case and the custodial-bridge case — are specified tool-by-tool in Exchange. The structural claim summary: (structural) the compliance-at-the-gateway pattern lets two systems with incompatible property bundles coexist through the only architecture that does not force one to absorb the other; the divergence the doctrine predicts is preserved at the protocol layer (this is the mechanism Doctrine-FA D1 names — bridges are real and useful at the application layer while the two sides maintain distinct property bundles).

§7 — Risks at the boundary (the boundary’s risks are the incumbent’s risks)

M7 defended. 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 freeze mid-workflow. (operational) 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 designed in.
• Automated-conversion vulnerabilities. (operational) 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. (operational) 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. (structural) 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.

Standard architectural responses. (operational) The defenses converge on a small, unexotic set: hot/cold separation (operational balances on bridges, reserves in self-custody); fallback bridges (at least two operationally independent paths to fiat, terminating in non-correlated regulatory regimes); multi-jurisdiction custody (reserves split across non-correlated regimes); and ecash-bearer reserves (balances outside the custodial perimeter — Pattern 5). The bridges are real, and so are bridge failures; the agent has to be designed for both.

The structural point. (structural) 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 architectural implication: minimize crossing surface and crossing duration; the more an agent’s activity lives on the pure substrate, the fewer of these risks it carries at all.

§8 — Counter-positions and falsification

Two counter-positions engaged in worked-example format (Strongest form / Where this is correct / Where this fails / Net assessment / What would change this), followed by falsification conditions mapped to the M-series claims. Scope note: the competing-substrate contest — whether stablecoin-on-Ethereum stacks or Lightning-rails-for-stablecoins absorb agent commerce, and who wins the boundary fight — is engaged at depth in Border Skirmishes. This section engages only counter-positions to the operational-interface claims (the treasury model and the gateway-compliance mechanism), and defers the substrate fight by reference.

§8.1 — Counter-positions engaged

CP1 — “The two-axis treasury model is an over-formalization; in practice agents just hold what is convenient.”

Strongest form. Most deployed agents today hold a single dominant asset — frequently a stablecoin, for unit-of-account convenience — and treat the reserve/operational distinction as an accounting nicety rather than an architectural decision. The model’s “identity decision” framing reads more as editorial than as operational necessity; an agent can hold stablecoins for everything and convert to Bitcoin only when a specific counterparty requires it. The split is presentation, not structure.

Where this is correct. (operational) For an incumbent-economy agent — a regulated principal, USD-denominated obligations, regulated counterparties — the distinction does collapse in practice: reserve and operational mix are both dollar-denominated, and the agent rationally holds stablecoins throughout. For that subset, the two-axis model resolves to a single axis, and the simplification is correct. Many currently deployed agents are in this subset.

Where this fails. (structural — the distinction is load-bearing exactly where Constraint 2 is) The two-axis model collapses to one axis only when censorship-resistance is not load-bearing for the use case. For a parallel-economy agent — sanctions-exposed counterparties, adversarial-jurisdiction operation, settlement against counterparties banks would refuse — the reserve decision is the difference between a store of value an intermediary can freeze and one it cannot (Case-FA C1 Constraint 2). An agent that holds its reserve in a stablecoin “for convenience” has placed its savings behind an issuer freeze, which is precisely the failure the parallel-economy use case cannot tolerate. The model is not over-formalization; it is the explicit statement of where the convenient default silently changes which economy the agent is in. (operational consequence) The conversion strategy (§4.2) is the mechanism that lets an agent enjoy operational stablecoin convenience without migrating its reserve — which is impossible to specify if the two axes are not separated first.

Net assessment. (structural) The two-axis model is unnecessary for incumbent-economy agents and load-bearing for parallel-economy agents. Because the project’s claim concerns the parallel-economy substrate specifically (Case-FA C4; Doctrine-FA D3), the model’s value is exactly in the subset where the convenient default is a silent identity migration. The model is not asserting that every agent must hold Bitcoin; it is asserting that the reserve choice is the economy choice, which an agent cannot make deliberately without the two axes pulled apart.

What would change this assessment. Sustained evidence that parallel-economy agents (those whose use case requires Constraint 2 conjunctively) can hold freezable reserves without operational consequence under adversarial conditions — i.e., that issuer freeze never materializes against the use cases that motivate Bitcoin reserves. The freeze record across regulated stablecoin issuers is the opposite (cross-link Case-FA §8.1; Border-Skirmishes-FA).

CP2 — “Compliance-at-the-gateway is unstable; regulators will push compliance into the protocol over time, and the gateway distinction will erode.”

Strongest form. Regulators have repeatedly extended financial-surveillance requirements deeper into infrastructure than incumbents initially expected. As agent commerce scales and as regulated agent-payment gateways become commodity infrastructure, the pressure will be to require identity attachment or freeze capability at the protocol layer — mandatory identity-tied node operation, invoice-level identity binding, protocol-level sanctions screening at routing nodes. The gateway boundary is a temporary equilibrium; over time, compliance migrates inward and the architectural distinction the Marketplace depends on dissolves.

Where this is correct. (forward-looking) The regulatory-extension pattern is real; surveillance requirements have historically pushed toward the edges of infrastructure. The build opportunity for purpose-built regulated agent-payment gateways is genuine, and a poorly-architected wave of such gateways could normalize anti-pattern compliance (compliance propagating to the protocol) if builders take the path of least resistance.

Where this fails. (structural — Doctrine-FA D1 applied to the protocol-compliance scenario) Protocol-layer compliance collapse would require one of two structurally self-defeating adaptations. (1) The protocol absorbs identity attachment or freeze capability — at which point it ceases to satisfy the four conjunctive constraints (Case-FA C1), and the parallel-economy use cases the substrate exists to serve migrate to whatever else satisfies them. The activity that requires censorship-resistance routes around protocol-layer compliance because the activity is what makes the substrate worth having. (2) The regulated entity abandons its property bundle — at which point it ceases to be a regulated entity and loses the standing the regime grants it. The gateway pattern (§6) is precisely the architecture that lets regulated entities operate bridges without requiring either side to adopt the other’s property bundle; more bridges built on the gateway pattern increase the surface where parallel-economy properties meet regulated counterparties without collapsing the distinction.

Net assessment. (structural) The gateway distinction is not a temporary equilibrium; it is the stable solution to a mutual-exclusion constraint (Doctrine-FA D1). Compliance can be pushed toward the protocol, but the activity that requires the substrate routes around it, leaving protocol-layer compliance enforced only against users who did not need the substrate’s properties in the first place. (forward-looking) The empirical question is what fraction of new gateway entrants adopt the gateway pattern versus the anti-pattern; the doctrine predicts the gateway pattern wins because the anti-pattern fails the mutual-exclusion test.

What would change this assessment. Deployed protocol-layer compliance (identity-tied node operation, invoice-level identity binding, routing-node sanctions screening) at scale that the protocol’s actual users accept rather than route around. Observation of users not routing around would be the empirical signal that the gateway distinction is eroding. The historical analogues (Doctrine-FA §6) suggest routing-around is the predicted response.

§8.2 — Falsification conditions

The position articulated here is structural. The following conditions, if observed, would shift it. Each falsifier maps to one or more claims in §1.

Targets M1 (Marketplace-as-structurally-required interface). Deployment of agent-economy use cases that genuinely require all four conjunctive constraints settling without any boundary crossing — either fully inside the legacy stack (falsifying the mutual-exclusion mechanism; cross-link Doctrine-FA D1) or fully outside it with no application-layer crossings (falsifying the boundary-necessity claim). Neither has been observed; both are forward-looking falsifiers.

Targets M2, M3 (two-axis treasury model; reserve-as-identity-decision). Sustained evidence that parallel-economy agents hold freezable reserves without operational consequence under adversarial conditions — i.e., that the reserve choice is not the economy choice because issuer freeze does not materialize against the use cases motivating Bitcoin reserves. The freeze record is currently the opposite (cross-link Case-FA §8.1).

Targets M4 (operational mix; counterparty-driven equipping + conversion strategy). A deployed agent landscape in which counterparties uniformly converge on a single transactional form, eliminating the need to equip across multiple rails, and in which that single form is censorship-resistant — which would collapse the operational-mix/conversion-strategy distinction by removing the need to convert back to a distinct reserve. No such convergence is observed; transactional-form heterogeneity is the deployed reality.

Targets M5 (five composition patterns; conditional constraint application). A deployed treasury pattern outside the five enumerated that satisfies the parallel-economy substrate property (all four constraints conjunctively) by a mechanism not captured by the conditional-constraint framework. New patterns may emerge; the two-axis framework and the conditional-application rule are the structural claim, and would be falsified only by a pattern whose constraint satisfaction the framework cannot describe.

Targets M6 (compliance-at-the-gateway preserves divergence). A deployed regulatory regime imposing compliance at the protocol layer (mandatory identity-tied node operation, invoice-level identity binding, routing-node sanctions screening) at scale, with sustained user acceptance rather than routing-around. The historical analogues (Doctrine-FA §6) predict routing-around; sustained acceptance would weaken the gateway-pattern claim’s structural integrity. (Cross-link Doctrine-FA D1; Border-Skirmishes-FA.)

Targets M7 (the boundary’s risks are the incumbent’s risks). Demonstration of a structural risk that is intrinsic to the Bitcoin protocol leg rather than to the incumbent side of a crossing — a freeze, reversal, or custodial-discretion surface that arises within the pure-substrate economy itself, absent any bridge. Bitcoin’s seventeen-year protocol record (Case-FA §5) is the opposite; observation of such an intrinsic surface would falsify the claim that boundary risk is incumbent-side risk.

§9 — The two children (operational map)

The Marketplace section has two practical surfaces beneath this anchor. This document is the interface specification common to both; the children carry the activity-specific detail.

• Exchange (X-series) — how an agent crosses the BTC↔fiat/stable boundary: the bridge taxonomy, regulated off-ramps and on-ramps, submarine swaps, Lightning-rails-for-stablecoins, custodial conversion, and the conversion mechanics that determine what the agent retains on each side. The compliance-at-the-gateway worked examples (protocol-level and custodial) are specified there tool-by-tool. Named tools keep their reference cards in the Stack’s Tools collection; Exchange specifies the activity they enable.
• Services (SV-series) — what an agent actually buys and sells for Bitcoin: AI inference, compute, data, API calls, human-delivered work. The “what” layer beneath the treasury-and-compliance map this anchor specifies.

The same treasury, compliance, and risk realities apply whether an agent is exchanging value or paying for a service.

§10 — Implications for builders

Declarative. Build-time specifications derived from M1–M7.

• Resolve the two axes before choosing assets. (M2, M3) For any deployed agent stack, decide the reserve (which economy is the agent in) and the operational mix (what rails does it spend on) as separate decisions. The reserve decision is determined by whether the use case requires Constraint 2 (Case-FA C1).
• Equip across counterparty-supported forms; run a conversion strategy back to reserve. (M4) Do not insist on a single preferred rail; equip to pay and receive in the common forms counterparties support, and specify the conversion cadence that keeps the reserve where intended. Conversion execution is Exchange.
• Select the treasury pattern by conditional constraint application. (M5) Parallel-economy use cases (all four constraints required) select Patterns 1, 2, or 5; incumbent-economy use cases select Patterns 3 or 4. Agents serving both subsets maintain distinct treasuries with explicit per-counterparty rules.
• Compliance at the gateway boundary, never at the protocol layer. (M6) If a bridge architecture requires compliance to propagate into the Bitcoin or Lightning protocol layer, the architecture is anti-pattern and fails the parallel-economy substrate’s property tests. Prefer protocol-level compliance-at-the-gateway where engineered; custodial compliance-at-the-gateway where fiat-leg regulated treatment is required.
• Minimize crossing surface and crossing duration. (M7) Every boundary risk is an incumbent-side risk carried only while crossing. Withdraw to self-custody promptly; hold operational balances on bridges only as long as the conversion requires.
• Hot/cold separation; fallback bridges; multi-jurisdiction custody; ecash-bearer reserves. (M7) Standard architectural responses to bridge-freeze, conversion-vulnerability, reporting-threshold, and layered-custody risks. At least two operationally independent fiat bridges terminating in non-correlated regulatory regimes.

§11 — Position summary

(structural) The Marketplace is the operational interface where an autonomous agent does business with Bitcoin against an incumbent economy still priced in dollars (M1); the border between the two is structurally required and narrow rather than absent, because the Independence Doctrine’s mutual-exclusion property (Doctrine-FA D1) holds at the protocol layer while some application-layer commerce must cross. A deployed agent’s treasury resolves along two independent axes — the reserve and the operational mix — and conflating them is the primary source of treasury error (M2). The reserve is the major differentiator and an identity decision: a Bitcoin reserve preserves Constraint 2 (Case-FA C1) and plants the agent in the parallel economy; a stablecoin reserve trades Constraint 2 for a USD unit of account and plants it in the incumbent economy; a parallel-economy agent cannot hold its reserve behind an issuer freeze (M3). The operational mix combines stablecoins for dollar counterparties with the Bitcoin payment stack — L1 to settle, Lightning and ecash for fast machine-tempo payments — and because counterparties dictate transactional forms, a working agent equips to pay and receive broadly, then runs a conversion strategy that keeps its reserve where intended (M4). Deployed treasuries instantiate five composition patterns, and pattern selection is the conditional application of the four constraints (M5). The compliance-at-the-gateway pattern is the architectural mechanism that preserves the doctrine’s divergence under bridging — the regulated entity applies its regime at the bridge boundary, the protocol downstream is unmodified — and it is the only architecture that lets two systems with incompatible property bundles coexist without one absorbing the other (M6). The boundary’s risks are the incumbent system’s risks: every border risk an agent carries enters on the incumbent side and is carried only as far and only as long as the agent crosses (M7). Conversion mechanics and named bridges are specified in Exchange; the services layer in Services; the live contest over which substrate wins the boundary in Border Skirmishes; moving deployment numbers in Field Notes. Falsification conditions for each claim are in §8.2.

§12 — References and provenance

Canonical source. [Marketplace](/marketplace) — project-internal canonical narrative surface, the anchor of the Marketplace section. The Marketplace synthesizes Case-FA C1 (four conjunctive constraints) and Doctrine-FA D1 (mutual-exclusion mechanism) into the operational interface specification (treasury, gateway compliance, boundary risk).

Cross-references — Case-FA (C-series).

• C1 (four conjunctive constraints) — pervasive throughout §3, §4, §5, §6, §7
• C4 (Bitcoin L1 + Lightning L2 + Cashu/Fedimint L3 deployed system) — the parallel-economy substrate side of every treasury pattern in §5
• §4 / §5 / §8.1 (substrate evaluation; stablecoin freeze analysis) — referenced in §5 Patterns 3/4 constraint profiles and §8.1 CP1

Cross-references — Doctrine-FA (D-series).

• D1 (structural mechanism of mutual exclusion) — §3 derivation, §4.1 reserve scope line, §6 compliance-at-the-gateway argument, §8.1 CP2
• D3 (AI economy on Bitcoin as contemporary instance) — the Marketplace operationalizes D3’s prediction

Sibling surfaces (For-Agents track).

• Exchange (X-series) — BTC↔fiat/stable custodial and protocol-level bridges, on-ramps, conversion mechanics; the gateway-compliance worked examples
• Services (SV-series) — the “what” layer: services an agent buys and sells for Bitcoin
• The Stack (S-series) — the pure-substrate payment primitives (L1/L2/L3) the operational mix draws on
• Border Skirmishes (BS-series) — the competing-substrate contest; who wins the boundary fight
• Field Notes — moving deployment numbers, rosters, treasury-pattern adoption metrics, live risk state

Defer-out to Field Notes per locked Decisions pattern.

• Treasury-pattern adoption metrics for §5
• Named bridge deployments, capacities, and incident data
• Live risk / attack-surface state for §7

Date stamps. Document created 2026-06-05; last verified 2026-06-05. Structural claims inherit empirical anchoring from Case-FA; deployment-specific references defer to Exchange-FA and Field-Notes-FA.