- Published on
- · 6 min read
Why Transaction Finality is the Bottleneck for Stablecoin Cards
- Authors

- Name
- Raj Parekh
- @rparekh
Stablecoin cards let users spend onchain balances anywhere a card network like Visa or Mastercard is accepted. Although the product sounds simple, there is a series of complex steps and rules that card networks require in order for the settlement to be considered final. Also, all of these steps must be done in seconds to meet the card authorization window.
In this post, we break down how slow blockchain finality forces stablecoin card issuers into awkward workarounds, and what changes when finality drops to sub-second.
When a user taps a card, the card network needs rapid guarantees: are funds present, and will they stay there through settlement? While banks can answer that instantly because they control the ledger themselves, previous generations of blockchains take seconds or even minutes to reach finality. In that gap between card authorization and blockchain confirmation, issuers have been forced to improvise - extending credit, restricting features, and absorbing extra balance sheet risk. The resultant frictions and risks inhibit the growth of stablecoin cards.
Sub-second deterministic finality changes that equation entirely.
Card payments are built on implied finality
A card payment happens in two phases. First, authorization: the network checks that the funds exist and places a hold. Then comes settlement: the money actually moves in a daily batch. The system is built on the assumption that if funds were there at authorization, they will still be there at settlement. Banks can make that guarantee because they own the ledger. The balance is internally final the moment it’s checked.
That guarantee changes when adapted to a blockchain, where funds live on a non-custodial wallet that the card issuer does not control. The issuer now has to ask: has this transaction actually finalized? Could it be reordered or reverted? How long do I have to wait before I can trust this state?
In card payments, uncertainty equals risk. And at scale, even small delays force issuers to redesign their systems around that risk.
What issuers are forced to do today
In our conversations with card issuers, they’ve shared that their infrastructure is intentionally designed so blockchain finality “doesn’t matter.”
For instance, they restrict transactions to simple push-based flows, which means the user sends stablecoins to the issuer, and the card spends against that balance. There is no pulling funds directly from a user’s onchain position, no wrapping or unwrapping tokens, no interacting with protocols mid-transaction. In some cases, they extend short-term credit or float to bridge the gap between card authorization and blockchain confirmation.
This works, but the tradeoffs are real. When issuers float credit to cover the finality gap, they are putting their own money at risk until the blockchain catches up. And issuers lose the ability to design custom flows between the moment a card is tapped and when the network actually settles, which is where much of the value in programmable money should live. In other words, issuers are building around blockchains instead of on top of them.
Across conversations with card issuers, wallet providers, and payment processors, a consistent threshold has emerged. In order to do “real debit” where a user pays directly from their own wallet (not from a prefunded omnibus account or a credit line), they need sub-three-second block times just to handle the basic authorization flow.
| Blockchain | VM Type | Block Time | Transaction Finality |
|---|---|---|---|
| Monad | EVM | 400 ms | 800 ms |
| Stellar | WebAssembly | ~5–6 seconds | ~5–6 seconds (ledger close) |
| Solana | SVM | ~400ms | ~2–5 seconds (optimistic, probabilistic) |
| Polygon (PoS) | EVM | ~2 seconds | ~2–5 minutes (economic finality via checkpoints) |
Why sub-second finality changes the design space
Sub-three seconds helps complete a basic debit card transaction. Sub-second deterministic finality enables something fundamentally different. This provides enough headroom to execute multiple onchain operations inside the card authorization window.
Here's a concrete example. A wallet provider described a flow they want to build but can't previously on any chain with multi-second finality:
- User taps their card
- → card network checks their onchain balance (say, wBTC)
- → wBTC is deposited into a lending protocol like Aave
- → stablecoins are borrowed against that collateral
- → the borrowed stablecoins are sent to the issuer's treasury
- → the purchase is authorized at the point of sale.
All of the actions including balance check, deposit, borrow, transfer, authorization are completed within the card auth window. That’s much more powerful than basic spending.
This kind of composable flow requires two things the previous generation of chains cannot reliably provide together: low enough latency to fit multiple operations in the auth window, and deterministic finality that the issuer doesn’t carry reorg risk between authorization and settlement.
The distinction between deterministic and probabilistic finality matters here in a specific way. Probabilistic finality means there is some non-zero chance a confirmed transaction gets reverted by a chain reorganization. For a single stablecoin transfer, an issuer might accept that risk. But for a multi-step DeFi flow where each operation depends on the last, a reorg potentially unwinds an entire sequence.
This is the difference between crypto being compatible with card networks and being native to them.
Where Monad fits
Monad is built around a simple but critical premise: blockchains should meet real-world latency requirements, not force financial systems to work around them.
Monad reaches ~400 ms block times and sub‑second deterministic finality by combining an optimized BFT consensus protocol (MonadBFT) with asynchronous and parallel execution. Finality is achieved in 2 slots, so a block is typically finalized in about 800 ms.
For payments, this means finality in milliseconds rather than seconds, predictable execution even under heavy network load, and no need for issuers to extend credit lines or hold float to cover the gap between card authorization and blockchain confirmation.
For stablecoin cards, the difference is stark. Beyond a basic spend product, a card tap can trigger a multi-step onchain flow on Monad that involves checking balances across tokens, borrowing against collateral, routing through multiple DeFi protocols, all settling with finality before the card terminal displays "approved."
The bigger picture
Stablecoin-linked cards are one of the clearest stress tests for blockchains as financial infrastructure.
They reveal a simple truth: “If a chain can’t match the timing assumptions of card networks, issuers will always treat it as an unreliable dependency.”
Most chains today force issuers to build around the limitation of slow finality. Monad makes possible a category of card-native financial products that can compose onchain financial operations at the speed of a card tap.