Stablecoins moved $32 trillion in onchain settlement volume in 2024, and the companies that profit most are not the issuers on the headlines — they are the layers above and below. The stablecoin infrastructure stack has five of them: issuers mint the dollars, rails carry them between chains, orchestrators decide which rail and in what sequence, custodians hold the keys, and apps turn the whole thing into a user experience. A team building on stablecoins interacts with each layer whether they realize it or not. This guide is the neutral taxonomy — who does what, where the boundaries really are, and which layer is the one most teams under-invest in.

If you are evaluating stablecoin infrastructure for a production integration, read this alongside the stablecoin orchestration pillar and the companion piece that names the leading stablecoin infrastructure providers. Those cover the "who" — this piece covers the "what" and the "why" of the layering itself.

Treating stablecoins as a single category — like "SaaS" or "CRM" — leads to bad vendor selection. A finance team that needs programmable settlement starts comparing Circle to Stripe to Fireblocks and ends up with a procurement meeting that goes nowhere, because those three companies sit on three completely different layers of the same stack. Each is irreplaceable in its role and has nothing to say about the others' roles.

The correct mental model is the one internet infrastructure professionals use. Nobody compares Cloudflare to AWS to Stripe. They stack. The stablecoin industry is maturing into the same shape, and the teams that notice early get to compose rather than lock in. For a deeper treatment of how multi-layer stacks emerged in traditional payments, see stablecoin payment rails in 2026.

The five layers, bottom to top:

Each layer has a different revenue model, a different regulatory posture, and a different set of competitors. Comparing across layers is a category error. Comparing within a layer is where real vendor selection happens.

Issuers are the easiest layer to name and the one most new entrants over-weight. They print the stablecoin. The market is an oligopoly — Circle (USDC), Tether (USDT), Paxos (USDP, PYUSD, USDG), Ethena (USDe), Agora (AUSD), Frax (frxUSD) cover the overwhelming majority of circulating supply. USDC alone had a circulating supply of roughly $61 billion in mid-2025. USDT is larger.

Issuer economics are straightforward: hold the dollar reserves, invest them in short-duration Treasuries, pocket the yield. Circle reported roughly $1.7 billion of revenue in the twelve months preceding its 2025 IPO; almost all of it was reserve yield.

What issuers do NOT do:

Issuers do make architectural choices that constrain every layer above them. Circle built Cross-Chain Transfer Protocol (CCTP) specifically so USDC could move natively between chains by burning on the source and minting on the destination — no wrapped representation. Tether's deployment model is different on every chain. These choices ripple up. For more on how issuer choices shape routing, see USDC vs USDT cross-chain infrastructure.

Rails are the cross-chain primitives — the actual mechanism that moves value or a message from chain A to chain B. The industry calls them "bridges" but that term is loaded. A rail is not an app; it is a protocol that other protocols ride on.

The rail roster in 2026:

Rails do one job well: they carry a message or mint/burn event. What they do not do is choose themselves. A rail has no opinion about whether it is the right one for a given payment — it just does the job if asked. For a full comparison of rail characteristics, see cross-chain messaging protocols.

A production stablecoin team that integrates directly with a single rail couples itself to that rail's failure modes, liquidity profile, and roadmap. That is why the layer above rails exists.

Orchestrators are the most recently-defined and most underappreciated layer in the stack. Their job is to turn a user's intent — "I have $100K in USDC on Base, I want to settle $100K in USDT on Arbitrum in under a minute" — into a sequence of rail operations that produces the outcome. Pricing, rail selection, solver coordination, finality management, and refund handling all live here.

Orchestration is what teams build in-house for three months, give up on, and then integrate. The in-house version fails because the matrix of chains times stablecoins times rails times slippage times solver availability is combinatorial. No internal team keeps the table updated at the velocity the market moves.

The 2026 orchestrator roster, ranked by scope:

The distinguishing question to ask an orchestrator: "What happens when the chosen rail is slow or fails?" An orchestrator that owns the answer — through solver competition, rail fallback, or atomic revert — is operating at the orchestration layer. An orchestrator that shrugs is operating as a bridge aggregator with extra steps.

For the competitive landscape, see our list of the top intent-based routing protocols, and solver networks for stablecoins for the execution-side detail.

Custodians hold the private keys that authorize stablecoin movement on behalf of institutions. This is the most regulated layer and the one with the highest baseline operational standard. A fund, a treasury team, or a regulated payment company does not sign transactions with a hot wallet — it routes them through a custodian whose role is key security plus policy enforcement plus audit trail.

The 2026 custodian roster includes:

Custodians rarely move stablecoins directly — they hold the key, and the orchestrator or app triggers the actual transaction through the custodian's API. In a modern stack, the call sequence looks like: app calls orchestrator, orchestrator proposes a transaction, custodian signs it per policy, the signed transaction hits the rail, settlement lands. This separation is what makes the system auditable and compliance-ready. For how the key-policy layer interacts with execution, see stablecoin compliance tools for 2026.

The app layer is the surface a real human or a real business interacts with. Apps turn the complexity of the four layers below into a button: "Pay supplier," "Top up wallet," "Settle invoice," "Off-ramp to USD." This is where the branding is, where the acquisition economics are, and where most of the non-infrastructure venture capital goes.

The app layer is also the most fragmented. Examples clustered by use case:

Apps almost never build their own rail or their own orchestrator. The correct integration pattern is: pick a custodian for key security, pick an orchestrator for cross-chain execution, pick an issuer partner if you need direct mint/burn, and focus your own engineering on the user experience.

A real payment flow in 2026 — say, a marketplace paying a cross-border supplier in USDC on Arbitrum when the marketplace's settlement balance is USDT on Ethereum — touches every layer:

Six layers participate; the marketplace only writes integration code against two — its custodian and its orchestrator. Everything else is the orchestrator's problem. That is the whole point of the layering. For the full production integration pattern, see the cross-chain stablecoin transfer checklist.

Each layer has a different defensibility. Naming them makes vendor selection sharper:

The highest lock-in is at the custodian layer. The highest switching-cost benefit comes from choosing an orchestrator that abstracts multiple rails, because it absorbs rail-level lock-in on your behalf. The lowest lock-in is at the app layer — which is why app-layer venture economics are so brutal.

Three patterns come up repeatedly in stablecoin infrastructure evaluations:

Pattern one: building rail-direct. A team integrates directly with CCTP because it is the most trustworthy rail for USDC. Then they add Hyperlane for non-USDC routing. Then they add LayerZero for an OFT stablecoin. Twelve months later the integration surface is five rails and 2,000 lines of custom routing code that no one wants to maintain. The orchestration layer exists to absorb exactly this code. See stablecoin routing vs bridges for the framing.

Pattern two: treating a custodian as an orchestrator. Fireblocks has transaction-signing APIs and a broad chain list, so a team builds their cross-chain logic inside the custodian. This works for single-chain flows, breaks for multi-chain atomic ones, and hits a wall when the custodian's signing latency interacts with rail finality. The correct factoring is: orchestrator plans, custodian signs.

Pattern three: treating an app as infrastructure. A B2B buyer thinks Stripe Crypto is a rail because it has developer-facing APIs. Stripe Crypto is an app; under the hood it uses Bridge (which uses orchestrators and rails). That is fine, but if the buyer's needs change to atomic cross-chain settlement, Stripe is the wrong layer to ask.

Most teams shop this stack top-down: they start with apps, then ask about integrations, then discover custody, then discover rails. The inverted (correct) sequence is bottom-up:

Teams that shop bottom-up pay for the right layers and do not over-spend on the wrong ones. Teams that shop top-down buy what the app vendor bundles, which is usually a compromise at every layer below.

A rough sense of where value sits in 2026, aggregated from public disclosures:

The orchestration layer is the smallest of the five by revenue capture today, and probably the largest by growth rate, because it is the most recently defined and the one being asked to do more every quarter as new chains launch. That is also why treating it as a seat-of-the-pants category is the single most common stack-design error in 2026.

Eco is an orchestration layer. It is not a rail — it integrates CCTP, Hyperlane, LayerZero, Polymer, and native settlement as its substrate. It is not a custodian — it returns transactions for signing rather than holding keys. It is not an app — it has no end-user payment brand of its own. It is the execution network that routes intents across 15+ chains using a unified stablecoin orchestration layer, with Routes as the developer surface (CLI, SDK, API) and Native Route, Hyperlane Route, and other settlement modes as the fulfillment paths.

For teams evaluating orchestrators for a production stablecoin integration, the stablecoin orchestration pillar is the place to start.

Market structure over the next two years will stress-test each layer in a different way. The tells we watch for:

If you are integrating once and holding for five years, weight these tells more than any specific feature comparison. Infrastructure stacks that look well-composed on paper sometimes fall apart in the wild because a single layer hits a ceiling. For a longer-term settlement-layer view, see stablecoin settlement platforms in 2026 and stablecoin liquidity networking.

What is the stablecoin infrastructure stack?

The stablecoin infrastructure stack is the five-layer model — issuers, rails, orchestrators, custodians, apps — that describes how stablecoins are minted, moved, routed, secured, and surfaced to end users. Each layer has distinct vendors and a distinct role. Together they compose into a single production payment flow.

Is an orchestrator the same as a bridge?

No. A bridge (or rail) moves value between two specific chains. An orchestrator sits above multiple rails, picks the right one for a given intent, manages solver competition, and handles finality. The stablecoin routing guide covers the distinction in detail.

Do I need a custodian if I use an orchestrator?

For institutional scale yes. The custodian holds keys and enforces signing policies; the orchestrator composes the transaction the custodian signs. They are complementary layers, not alternatives. Retail apps sometimes combine the roles in a single managed wallet.

Which layer has the most vendor lock-in?

Custodians, because key migrations are multi-quarter projects. Rails have moderate lock-in if integrated directly, but low lock-in if abstracted behind an orchestrator. Apps have the least lock-in because users follow UX.

How does this map to Eco's product?

Eco operates at the orchestration layer. It does not issue stablecoins, does not run a rail, does not hold keys, does not build end-user apps — it routes intents across rails on behalf of apps, with custodian signatures. For product specifics, see What is Eco Routes.