Alpaca clears 94% of tokenized US equity volume. Ondo, Dinari, Backed all route through them. Single-broker dependency is fine for an MVP. It's a structural risk for the next phase.
Every tokenized US equity in production today routes through Alpaca Securities. Ondo Global Markets, Backed Finance's xStocks, Dinari, Anchored Finance, and most newer entrants. Same broker-dealer underneath. Alpaca itself reports holding 94% market share of tokenized US stocks and ETFs, with $480M in tokenized assets under custody.
It's not a coincidence. Alpaca shipped the first developer-friendly broker-dealer API for global fintechs, then layered an Instant Tokenization Network on top. They built the picks and shovels. Everyone else, sensibly, bought them.
The next phase isn't going to look like this. Concentration is fine when the category is small. It becomes a structural risk when the category becomes systemically important. And tokenized US equities are on a path to systemic importance much faster than most builders are pricing in.
The single-broker risk has three parts.
Operational. Brokers have outages. Ledger reconciliation issues. Software releases that break webhook delivery. The 2024–2026 era has been quiet on broker-side incidents because the volume is still small. At $1B+ tokenized AUC across the ecosystem, an Alpaca-side outage takes the entire tokenized US equity market offline simultaneously. There is no failover.
Commercial. A single upstream broker is a single counterparty in the pricing negotiation. As the broker's market power grows, the take rate moves in their favor. Every fintech that built on top of a single payments processor learned this lesson. Every fintech that built on top of a single payment-orchestration vendor learned the next-order version of it.
Regulatory. A single broker is a single regulatory exposure. If FINRA flags a clearing relationship for any tokenized-stock-specific reason, every downstream tokenizer freezes simultaneously. Concentration risk becomes regulatory contagion risk in this category.
Two prime brokers is harder to build than it sounds. Surface-level "we have multiple brokers" claims are usually empty in this category. The implementation reality is worth describing because it tells you which vendors actually mean it.
At the order-routing layer, every mint or redeem has to route to the broker with better execution for that specific security at that specific moment. That's not load balancing. It's smart-order-routing with broker-specific quirks. Alpaca's fractional handling. IB's market-hour constraints. Settlement-cycle differences for less-liquid names. Fee schedules that vary by ticker.
At the reconciliation layer, a token issued against an IB-custodied share and one issued against an Alpaca-custodied share need to be fungible from the user's perspective. That requires a unified ledger that abstracts the broker-side custodian, with redemption logic that can fulfill from either side. Most multi-broker claims fall apart here. They're really "we have an Alpaca relationship and a backup IB account we don't actually use."
At the corporate-actions layer, dividends, splits, mergers, and tender offers are handled differently by every broker. A unified corporate-actions engine that normalizes events across IB and Alpaca is non-trivial to build. It's also the only way to give downstream developers a consistent API surface.
At the regulatory layer, each broker imposes different KYC pass-through requirements, different jurisdictional permissions, different reporting cadences. A two-broker stack absorbs the complexity instead of pushing it onto the fintech.
The honest framing on settlement. The broker-exchange leg of any tokenized US equity transaction settles T+1 against DTCC, regardless of which broker custodies the underlying. Tokenization changes how the user experiences settlement. It doesn't change how DTCC settles. The broader category sometimes muddles this, and the credibility of every tokenizer depends on the distinction holding up under scrutiny.
What the user sees is instant. What the user's fintech sees on its books is instant. The broker-exchange leg is industry standard. None of these claims contradict each other. All of them require careful language.
If you're evaluating tokenized US equity infrastructure, single-broker dependency is fine for an MVP. It's a risk for a production stack you intend to scale to millions of users or hundreds of millions in AUC.
The broker-redundancy question isn't "do you have two brokers." It's "what happens when broker A has an outage at 2pm on a Tuesday." If the answer is "we degrade to a backup we haven't tested," you have one broker.
Settlement claims should be tested. Ask any infrastructure provider exactly which leg is instant and exactly which leg follows DTCC timelines. The vendors that can answer crisply are the ones whose architecture is real.
The two-broker architecture is harder to build, harder to operate, and the differentiator we're most interested in stress-testing with design partners.
