--- title: "Stablecoin API SLAs and settlement finality explained" description: "Stablecoin API uptime numbers cluster near 99.9% for a reason: most providers measure API acceptance instead of the point where money becomes final and spendable." date: "2026-08-28" category: "payments" faq: - q: "What's the difference between an SLA and a settlement guarantee for a stablecoin API?" a: "An SLA measures whether the API responds and how often it stays up. A settlement guarantee is about when the recipient can spend the money, with no reorg risk left. A provider can hit 99.9% uptime on every call while the underlying transfer still takes minutes to clear, because the 99.9% almost always tracks submission, not the point where the transaction becomes final." - q: "Why do so many stablecoin API providers publish an SLA close to 99.9%?" a: "Most of them measure the same narrow thing: whether an API call was accepted and a transaction was submitted. Whether that transaction reached economic finality is a separate question that most SLAs never answer. Once the industry standardizes on the easiest metric to hit, providers with very different architectures land in a similar range, which makes the number a weak signal for comparing them." - q: "What do T1 and T2 mean in stablecoin settlement?" a: "T1 is the span from API acceptance to onchain submission, the point where a 200 response and a transaction reference come back. T2 is economic finality: the point at which the transaction can no longer be reversed by a chain reorganization, so the recipient can spend the funds. Published SLAs almost always cover T1 unless a provider states otherwise." - q: "How long does a stablecoin FX quote stay valid before it expires?" a: "It depends on the provider, and there is no industry standard. Circle publishes a hard number for this: quotes come back in under 500 milliseconds, and once a trade is created, the ten-minute signature window is a documented commitment, not a market default. Other providers publish shorter or looser windows, so the number should be confirmed in writing rather than assumed to match Circle's." - q: "Does a stablecoin payout settle at the same speed in every country?" a: "No. Settlement speed on the fiat leg depends mainly on the local payment rail; the stablecoin conversion itself typically clears in seconds. Corridors with real-time payment rails, like PIX in Brazil or SPEI in Mexico, settle in minutes once the onchain leg clears. Corridors without that infrastructure settle same-day or the next business day even when the crypto side finished instantly." - q: "What should a developer ask a stablecoin API provider before integrating?" a: "Whether the published SLA measures API acceptance to submission or acceptance to economic finality, how long a quote stays valid and who absorbs slippage if the market moves inside that window, what the settlement time is for the specific corridor being built against instead of a platform average, and how the integration should handle a settlement webhook that arrives more than once." --- An SLA percentage and a settlement guarantee are two different promises, and most stablecoin API providers do not say which one they are quoting. A vendor can publish 99.9% uptime and still leave a recipient waiting minutes, or longer, for money they can spend, because the percentage usually covers a narrower window than the one that matters to the recipient. For background on the full flow a stablecoin API handles, see [what is a stablecoin API](/resources/more/what-is-a-stablecoin-api). ## Every stablecoin API's SLA page says roughly the same number BlindPay does not publish a single blended uptime number, because averaging every corridor into one figure hides the gap described below. Line up a handful of other stablecoin infrastructure providers, though, and their advertised SLAs sit in a narrow band. [Fireblocks' own site commits to 99.9% uptime](https://www.fireblocks.com/blog/how-we-meet-institutional-standards-insurance-compliance-security/), with roughly 99.97% actually delivered month to month. A third-party comparison table estimates Bridge and BVNK's negotiated enterprise SLAs land in that same range, though neither company posts the figure publicly, and puts Circle Mint and Crossmint close to 99.9% as well. Conduit's public tier sits at 99.5%, with a higher figure reserved for its enterprise add-on. Most of these numbers come from [a single third-party comparison](https://eco.com/support/en/articles/15232572-best-stablecoin-settlement-apis-2026-sla-guarantees-audit-trails-and-reconciliation-compared) rather than each company's own contract language, so the exact decimals are indicative and have not been checked against every provider's actual agreement. Companies running different architectures and different custody models converge on nearly the same headline figure. That convergence is the tell. Uptime measures whether the API answers a request, not how fast money moves or how final it is once it arrives, and a system can drop almost no requests while still making a recipient wait. When every provider clusters around the same three or four nines, the number stops distinguishing anyone, and what is actually being measured behind it matters more than the digits. ## What is the difference between T1 and T2, and which one is a provider promising? Most published SLAs measure the span between an API call being accepted and a transaction being submitted onchain: call that T1. A request goes out, an accepted status and a transaction hash come back, and the clock stops there, which says nothing about whether the transaction is done. Economic finality, T2, is the point where reorg risk has cleared and the money is unreversibly available to whoever is supposed to receive it. On most chains T1 happens in a second or two. T2 can take meaningfully longer, and the gap between them is where a support ticket gets opened: the dashboard says success, the recipient says nothing has arrived. This distinction is rarely spelled out on a pricing or SLA page. An accepted API response with a transaction hash is a technical acknowledgment, not a settlement guarantee, so if a provider does not say which one its SLA covers, the safe assumption is T1. It is the cheaper thing to measure and the one that makes the uptime number look best, since submission almost never fails even on the days downstream confirmation stalls. A lot of published reliability numbers answer "did the API work" while implying "did the payment happen," and those are not the same question. ## How long does an FX quote stay valid? Settlement speed is one number worth interrogating. Quote validity is another, and it gets less attention than it should. [Circle's StableFX documentation states that quotes are generated across competing market makers in under 500 milliseconds](https://developers.circle.com/stablefx/concepts/technical-guide), and once a trade is created from a quote, both sides get a ten-minute window to submit signatures before it expires. That is a specific, written number a developer can hold Circle to. Most competitors are not nearly that explicit. A widely repeated secondary claim puts typical quote staleness across stablecoin APIs somewhere between 15 and 60 seconds, but that figure traces back to an aggregator comparison rather than each vendor's own documentation, so it reads more as a general sense of the market than a commitment any one company has made in writing. No other provider has been found to state its window this plainly in public documentation, though one may exist in materials that have not been published. FX moves inside that window whether or not the provider discloses it. If an integration shows a customer a rate, waits on confirmation, then submits, and the quote has expired or gets re-priced on execution, someone absorbs the difference. Who that someone is should be established before a customer notices the number that settled does not match the number they saw. ## Why does a payout on one corridor settle faster than another on the same rail? A blended, platform-wide SLA hides something a corridor-level number would show plainly: the stablecoin leg of a payment is rarely the bottleneck. The fiat off-ramp is. A payout into Mexico or Brazil rides SPEI and PIX, both real-time payment rails, so once the stablecoin conversion clears, the recipient's bank account sees the funds within minutes. A payout riding a corridor without that same real-time layer can settle same-day or the next business day even when the onchain leg finished in seconds. The provider and the underlying token do not change between corridors, and neither does the published SLA, but the wait time differs by close to a full day depending on which currency it lands in. For the full mechanics of a cross-border payout, see the [stablecoin payments guide](/resources/more/stablecoin-payments-guide). Checking corridor by corridor instead of trusting a platform average matters: a company can be honestly reporting 99.9% uptime while the thing that actually matters, how long a specific payout to a specific country takes, is set by the local rail and has nothing to do with the API's own performance. That gap is easier to see across corridors on the [global payments](/global-payments) page, and in more detail on a single route like [USDC to BRL](/usdc-to-brl). ## What to ask before integrating A few questions cut through most of what a sales deck will not volunteer. Does the published SLA measure API acceptance to onchain submission, or acceptance to economic finality? How long is a quote valid, and who absorbs the difference if the market moves inside that window? What is the settlement time for this specific corridor, separate from the average across everything else the platform supports? And when a settlement webhook arrives twice, which [most providers' at-least-once delivery models allow for](https://eco.com/support/en/articles/15182330-stablecoin-webhooks-and-real-time-event-streaming-provider-integrations), does the integration correctly ignore the duplicate instead of double-processing it? BlindPay quotes and settles named corridors: BRL, MXN, ARS, COP, and USD/EUR, so these are not hypothetical questions there either. Rates come from live FX rather than a table refreshed on a schedule, and there is no pre-funding sitting idle in a nostro account. The settlement time quoted is corridor-specific, not a blended figure covering a fast rail and a slow one at once. Virtual account and payout details, along with the KYB and transaction-monitoring model behind them, are in the [docs](/docs/getting-started/overview) and on the [compliance page](/compliance). The account infrastructure itself is covered on [virtual accounts](/virtual-accounts). Ask for a live quote on a specific corridor through [blindpay.com/contact](/contact) and compare the number against the SLA percentage quoted elsewhere.