Skip to main content

Multi-Issuer Stablecoin Fungibility: Why USDC-Only Infra Breaks for B2B

How USDC, USDT, EURC, and PYUSD clear at par across orchestrators like Bridge, BVNK, and Eco, and where MiCA already forces issuer substitution in 2026.

Written by Eco
Multi-Issuer Stablecoin Fungibility

In retail crypto, picking a single stablecoin works. In B2B, it doesn't. Your supplier holds USDT on Tron, your treasury sits in USDC on Base, your European subsidiary needs EURC for MiCA reasons, and your enterprise customer pays in PYUSD because PayPal is their AP system. Single-issuer infrastructure forces every one of these counterparties through a swap, and that swap costs basis points, time, and reconciliation headaches.

Multi-issuer fungibility is the design choice to treat USDC, USDT, EURC, PYUSD, USDe, and other regulated dollar tokens as interchangeable $1 units at the settlement layer, while preserving issuer identity for compliance and accounting. It is the difference between a payments network and a wallet.

What does stablecoin fungibility actually mean?

Stablecoin fungibility is the property that two different issuer tokens redeemable for the same underlying unit (one US dollar) clear at par inside a settlement system, so the sender can pay in any accepted token and the receiver gets the token they want without manual swap steps. Fungibility lives at the protocol layer, not the wallet UI.

True fungibility has three components. First, pricing parity: the system quotes 1 USDT and 1 USDC as the same $1, with slippage absorbed internally. Second, atomic substitution: the orchestrator can fulfill a USDC request using USDT inventory in one transaction, no two-step swap. Third, accounting transparency: the ledger still records which issuer token funded which leg, because auditors and the GENIUS Act care.

Why does B2B settlement need multi-issuer fungibility?

B2B flows are bilateral with mismatched preferences. A 2025 Fireblocks survey of 425 enterprise treasurers found 71 percent hold more than one stablecoin and 49 percent regularly receive a stablecoin they did not request. USDC-only rails force these counterparties to bridge or swap before they can transact, which adds 5 to 30 basis points per leg and breaks straight-through processing.

Consider an invoice flow. A logistics company in Singapore holds USDT on Tron (cheap, deep liquidity in Asia). Its US customer pays in USDC on Base (compliance-blessed, integrated with their NetSuite). A USDC-only provider sees a $50,000 invoice and routes the customer's USDC through CCTP V2 to Tron, then forces the recipient to redeem off a USDC float that may or may not exist on Tron. A multi-issuer provider routes the customer's USDC into a Base liquidity pool, draws USDT out on Tron from inventory, and settles at par. The customer still wrote USDC. The recipient still received USDT. The orchestrator absorbed the swap.

The B2B cost case is concrete. PayPal's PYUSD enterprise customers, BVNK's payouts network, and Bridge.xyz's settlement API all cite single-token-rail friction as the reason they built multi-issuer logic before they built anything else. See our deeper comparison in Circle Gateway vs Multi-Issuer Routing.

How does onchain infrastructure deliver fungibility today?

The original fungibility primitive is the Curve 3pool, launched 2020, which pools USDC, USDT, and DAI in a Stableswap invariant that treats all three as near-par dollars. As of May 2026, Curve's stable pools hold roughly $1.8 billion in TVL across DAI, USDC, USDT, USDe, crvUSD, GHO, and FRAX, with typical slippage under 2 bps for trades up to $1 million. Uniswap V3 and V4 added concentrated-liquidity stable pools that compress slippage further at the cost of LP complexity.

Onchain pools solve the swap mechanics but not the orchestration. A B2B payment is not just a swap, it is route selection, chain choice, gas abstraction, compliance check, sanctions screen, retry logic, webhook firing, and invoice reconciliation. That orchestration layer sits offchain, on top of pools.

How do orchestrators abstract fungibility offchain?

Offchain orchestrators take a settlement intent ("pay supplier X $50,000 by end of day") and decompose it into the cheapest, fastest combination of token, chain, and route. They quote against multiple stablecoin issuers, route through CCTP, LayerZero, Hyperlane, Curve, or internal float depending on cost, and present the result as one balance to the customer.

Bridge.xyz (acquired by Stripe in October 2024 for $1.1 billion) was explicitly built on multi-issuer logic. Its API lets a developer accept any of USDC, USDT, EURC, or PYUSD and pay out any of them, with Bridge absorbing the FX and slippage. BVNK runs a similar offering for European corporates, with deep EURC and EURI rails. Eco's intent-based architecture treats stablecoin selection as a routing parameter, with the protocol auto-picking the cheapest issuer token per leg.

For the policy-engine layer that sits between intent and execution, see Stablecoin Policy Engine: Compliance at Execution Time.

What about regulatory fungibility, where MiCA already broke USDT?

Two tokens may be economically fungible and legally non-fungible. The MiCA regulation took full effect December 30, 2024, and ESMA classified USDT as a non-compliant asset-referenced token because Tether had not secured an EMI license in any EU member state. Binance, Crypto.com, Coinbase EU, and Kraken delisted USDT spot pairs for EU users during Q1 2025. USDC, EURC, and EURI retained compliance. PYUSD's EU status remains under review as of May 2026.

This is regulatory fungibility, or its absence. From a B2B operator's view, an EU subsidiary cannot legally hold or receive USDT through a regulated venue, even if a Singapore counterparty is happy to pay in it. The orchestrator must know which token is acceptable for which jurisdiction, and substitute on the fly. A USDC-only provider sidesteps the problem by refusing USDT entirely, which loses the Asia flow. A multi-issuer provider takes the USDT in Singapore, swaps to USDC or EURC before it crosses into the EU compliance perimeter, and credits the EU subsidiary in a MiCA-clean token.

The US picture is converging. The GENIUS Act, signed into law in 2025, requires payment stablecoin issuers to be either insured depository institutions or federally chartered nonbank issuers with 1:1 reserves in cash or short-dated Treasuries, and grants the OCC primary supervisory authority. Tether has signaled intent to launch a US-regulated entity in 2026. If that lands, regulatory fungibility between USDC and USDT improves in the US even as it diverges in the EU.

Could regulators force issuer unification?

The risk scenario every multi-issuer architect tracks: a regulator concludes that competing stablecoin issuers fragment monetary policy transmission and mandates a single approved issuer per jurisdiction. The Bank for International Settlements has published research on this concern. The Fed's 2024 staff paper on stablecoin singleness raised the question explicitly. If the GENIUS Act's implementing rules tighten and only two or three issuers qualify, the US dollar stablecoin market could effectively consolidate without explicit unification.

For B2B operators, the hedge is to build infrastructure that does not depend on any one issuer's regulatory survival. Multi-issuer orchestration is itself the hedge. If Tether loses its US license tomorrow, a multi-issuer rail routes around it. A USDC-only rail does not need to route around anything, but it also cannot absorb a Circle-side incident the way a multi-issuer one absorbs an issuer-specific freeze. See the issuer-by-issuer breakdown in Stablecoin Issuer Risk Compared.

USDC-only providers vs multi-issuer providers

Provider

Issuers supported

Native swap layer

MiCA coverage

B2B focus

Circle Mint / CPN

USDC, EURC

CCTP V2 (same-issuer cross-chain only)

Yes (USDC, EURC both compliant)

USDC-native enterprises

Bridge.xyz (Stripe)

USDC, USDT, PYUSD, EURC

Internal liquidity + Curve

Partial (drops USDT for EU flows)

Multi-token API

BVNK

USDC, USDT, EURC, EURI, PYUSD

Internal float + DEX

Yes, EMI licensed

European corporates

Stripe stablecoin financial accounts

USDC (primary), expanding

Stripe FX + Bridge backend

USDC-only path for EU

SMB and platform

MoonPay enterprise

USDC, USDT, PYUSD

OTC desk

Partial

Card-to-crypto onramp

Conduit

USDC, USDT, EURC

Curve + Uniswap routing

Yes for EUR rails

LatAm and EU payouts

Sphere

USDC, USDT, PYUSD

Internal netting

Limited

Recurring B2B billing

Eco

USDC, USDT, USDe, USDC.e, USDT0, EURC

Intent solver across Curve, CCTP, Hyperlane

Yes via EURC routing

Multi-chain B2B settlement

The split is clear. Circle's own products optimize for issuer purity and regulatory blessing. Bridge, BVNK, and Eco optimize for issuer flexibility and B2B reach. Stripe straddles both via the Bridge acquisition. Compare the deeper routing tradeoff in CCTP V2 vs Liquidity-Networked Routing.

What should a B2B operator look for in 2026?

Three filters cut through the noise. First, does the provider quote a single settlement price across multiple issuer tokens, or does it expose the swap as a separate step with separate fees? Second, does the provider hold an EU EMI or equivalent license, or does it sidestep EU flows entirely? Third, does the API let you specify issuer preference per counterparty, or does it force a global token choice?

If your business sits inside one jurisdiction with one banking partner and one customer profile, USDC-only is fine. The moment you cross a border, add a counterparty preference, or absorb regulatory ambiguity, multi-issuer orchestration stops being a feature and becomes table stakes.

Methodology and sources

Curve and Uniswap TVL: DeFiLlama, retrieved May 2026. MiCA classification and exchange delisting timeline: ESMA guidance December 2024, exchange public statements Q1 2025. Bridge.xyz acquisition price: Stripe press release October 2024. Fireblocks enterprise treasurer survey: Fireblocks State of Stablecoins 2025 report. GENIUS Act provisions: enacted statute text, 2025. Provider feature matrices: each provider's public documentation as of May 2026.

Related reading

Did this answer your question?