Instant Crypto Payments Don't Exist — Why & How to Fix It
Tier lists ranking crypto cards have been popular on X for over a year, they praise the best options and criticize the rest. Yet most users still don’t realize the real risks they face when paying with these cards, or if any risks even exist.
Besides the obvious lack of privacy, there is something that we have been fixing in crypto wallets for ages — user experience. My theory is that achieving perfect or near-perfect UX is easy when you cover the problem of settlement and finalization in crypto cards or direct payments in general.
The Settlement Question is Overlooked
In the context of crypto payments, we can say that literally every transaction is a top-up.
When someone sends you money, they top up your account.
When you send someone money, you top up their account.
When you pay for something, you top up the merchant’s account.
But those top-ups are actually quite different from each other and depend on which application or service you use. Topping up a CEX, topping up a crypto wallet, topping up a crypto card, and topping up a crypto payments service: those are all different top-ups with different trust assumptions and completely different UX.
Be aware that here I’m talking about UX in general, not UI (user interface) in particular. If we coin the term “instant UX,” which means that transactions are finalized at the exact time you click the button, it’s almost impossible because we have such a thing as latency (which applies to both traditional and crypto transactions).
I don’t want to manipulate technical terms for marketing, so I’m gonna use the “near-instant UX” term, which means you can finalize your transaction in under 1 second.
If you pay a merchant with crypto, there is only one outcome that you and your merchant want: the operation must be processed as fast as possible, so the merchant can let you walk out of the store to save your time and to let you to enjoy the stuff you bought.
It is possible when you use a crypto card, because you’re not actually paying with crypto. At the point of sale, you pay with fiat money borrowed against your crypto.
Payment terminals know how to work with those cards because they’re connected to global payment networks like Amex, Visa, or Mastercard, not because they accept crypto.
You never paid with crypto, you use fiat money.
The problem of settlement exists in crypto cards only at the point of top-up — when you or someone else tops up your crypto card, you have to wait some time before the assets become spendable. The process looks something like this:
Send 100 USDC to address A.
Address A confirms it received 100 USDC.
100 USDC is shown in the crypto card application.
100 USDC is routed to another address using something like @RelayProtocol.
Address A no longer holds 100 USDC, but the application shows that you have that money.
In crypto cards, the problem of settlement at the point of sale doesn’t exist, because there’s nothing to be settled!
When you pay with a crypto card, you don’t send or initiate any onchain transactions: you spend real money. If you buy $10 worth of groceries, this $10 goes through Visa. There is no onchain transaction marking that you have spent exactly $10.
However, the end game is using real crypto to pay for things, not abstracting it away, because only that way can you have permissionless onchain payments available to everyone. The end game will be native crypto payments between buyer and merchant.
So in this case, we do indeed have the problem of settlement at the point of sale, because the transaction is onchain and subject to settlement and finalization, which do not happen instantly on the blockchains that are used the most today.
How Traditional Payments Handle Settlement
I would sound stupid if I said with a serious face that traditional finance is complicated and involves middlemen, because it’s obvious to 99.99% of people. However, it’s “middlemen”, not “middleman”, a lot of systems carry their own portion of risk:
Visa or Mastercard relays the authorization to the bank.
Your bank approves or denies the transaction. Bank can claw the money back up to 120 days after the deposit if you report fraud or something malicious (such chargebacks can cost millions annually).
The merchant’s bank pays the merchant before it has actually received the money from your bank. It’s fronting the cash and trusting that the other side of the transaction will follow through later.
The actual money movement between banks doesn’t happen until 1–3 days later, and even then, the transaction can still be reversed if something goes wrong.
In traditional payments, banks and card networks act as a buffer or safe place, they take on those risks and charge fees (make money) for providing this service. You never care about it, because it’s hidden — that’s how systems work.
Crypto payments are peer-to-peer, they don’t have middlemen to hide the complexity of settlement. There is no one to make promises and defend you.
Achieving “near-instant UX” here is different, it’s more complicated. We can’t just take tools from traditional banking and import them into crypto, because then we end up with traditional banking again, where we don’t really own our money.
Near-instant UX for crypto payments must have near-instant settlement, or some mechanism that protects against failed or reorganized transactions. I’d also say that the UX must be network-agnostic for everyday transactions, otherwise, it has too many frictions.
However, the settlement problem is a consequence of the problem of finalization.
Confirmation Does Not Mean Completion
A fundamental feature of most L1 blockchains is having two types of finality, optimistic and economic.
Optimistic finality happens when you see in your wallet “your transaction is confirmed” and have either sent or received the funds. As the name suggests, it’s optimistic to say that you received or sent your money completely — it’s not yet realistic.
Economic (deterministic) finality happens when your transaction is non-reversible. As the name suggests, it’s deterministic to say that you have received or sent your money completely — it’s realistic.
That only applies to blockchains like Solana, Ethereum, BNB Chain, or Hyperliquid. For example, Bitcoin doesn’t have a definition of finality that we got used to. There’s no moment where a transaction is absolutely final, it just becomes progressively more secure with each additional block.
But in most cases, proof-of-stake blockchains and rollups built on top of them have the same problem. The problem is the time difference between optimistic finality and economic finality.
Why does this gap in time happen? Distributed consensus across many nodes takes time. Faster finality can theoretically be achieved with fewer validators, stronger trust assumptions, or more complex protocol design, but it doesn’t mean it will be cheaper or that it will keep the same level of decentralization.
During this gap in time, reorganizations (reorgs) can happen. A reorg is when the blockchain throws out one or more recent blocks and replaces them with a different version of history, because a competing chain turned out to be longer or heavier. Being reorged has more chances than getting ADL’ed on 10 October, so this is something to keep in mind.
Why are they dangerous? Well, let me show a very high-level scenario:
Alice sends you 1 ETH (Transaction A). It appears in the mempool but has zero confirmations.
You immediately send 0.5 ETH from that to Bob (Transaction B). This transaction depends on Transaction A existing, so they are processed sequentially.
Transaction A gets reversed (dropped from the chain due to a reorg).
Now Transaction B is also invalid, because it references outputs that no longer exist. The network rejects it.
Who gets hurt in this scenario?
Bob is the primary victim. He thought he received 0.5 ETH from you and may have already provided you goods or services in exchange. Now his incoming payment has vanished.
You are hurt if Alice was attacking you. You gave Bob something of value based on funds you thought you had but never actually received.
Alice (if malicious) is the only winner — she double-spent, keeping both her original ETH and whatever you gave her in exchange.
You can imagine a scenario with fewer or more people, but the final receiver in this chain of events ends up being hurt the most. So sending transactions here is literally like playing a hot potato game: throw funds to the next person as fast as possible.
If you have ever deposited crypto into a CEX, you know that you have to wait for multiple block confirmations before you’re able to trade the money you’ve deposited.
That’s exactly the difference between optimistic and economic finality. When optimistic finality is reached, a CEX will show you that your funds are processed. When economic finality is reached, a CEX will show you that your funds are available to spend.
CEXs are actually pretty conservative here, because they want to prevent the worst-case scenario where you might have already traded those funds or withdrawn other assets against that balance, so the CEX ends up taking a loss.
In the context of global crypto payments, we can’t just copy the CEX mechanism, because hey, the cashier is not gonna sit here and wait 15 minutes until your 64 Ethereum blocks are confirmed.
So after all of that, can’t we just use Bitcoin for payments then if it mitigates this finality problem? Well, no, because Bitcoin is very expensive and slow. It kills one problem, but it adds multiple other ones. Lightning Network was kind of like a solution back in the day, but transactions weren’t onchain anyway, it’s not as secure as using Bitcoin.
At the end of the day, we want to escape chain wars and have a network-agnostic solution, so people don’t care which chain they’re using. As almost every single blockchain right now is proof-of-stake, we’ve got to care about finality — we can’t escape it, unfortunately.
scenario 1: make people use a single chain or only chains that are fast and minimize the time between soft and hard finality.
One of the initial thoughts that pop up is what if we made available only a handful of chains that have faster block times than Ethereum or something similar.
Faster blocks and faster blockchains don’t necessarily mean that the gap between optimistic finality and economic finality is thinner. As I mentioned earlier, a merchant’s risk is not for a transaction to pop up, but for waiting for that transaction to become irreversible.
But there are also chains with really fast finality like Monad, Sei, or Sui, or even chains specifically focused on payments like Plasma, Arc, or Tempo. Can’t we just use them? I think it’s more of a BD problem than a technological problem, but also an economic problem.
Whether you like it or not, a lot of funds are already parked on giants like Solana, Ethereum, and even Tron. Bridging them to specific rails at point of sale can be either expensive, time-costly, or both (I’m not talking about scenarios where you already have funds on those chains).
With the amount of capital and volume on major L1s, you can’t exclude them from the race. The cost of an economic attack or other malicious activity is trending towards infinity, and it would be shameful to try to attack the grandpa who sells $3 pad thai at the side of the road in Thailand.
As much as we want to minimize the gap between optimistic and economic finalities, we can’t get rid of the money giants, even if they’re slow.
scenario 2: issue some kind of guarantee before finalization (insurance).
Even if we can minimize the finality gap, we still have to work with chains that we can’t modify to ensure accessibility for everyone. We can’t completely escape reorgs at the moment, but what if we have insurance?
Insurance can cover potential losses for merchants who sold their goods, but whose payment later got reorged (as we remember, the people who suffer the most from a reorg are end receivers in the supply chain).
If we take insurance as the final model, there are tens of ways we can design such a system — whether merchants will pay for this insurance on some subscription basis or this process will be automated. Insurance can be either a separate solution or a native part of crypto payment rails.
If it’s separated, it’s pretty clear that the insurance fund is backed by money paid by merchants for this facility.
If it’s a native part of payment rails, it is more interesting, as insurance can be a default protection for free for merchants if the insurance fund is filled with money from fees the payment rails are already making.
There are a lot of different options to think about. Someone might call it treating the symptom instead of the disease.
I would argue that near-instant UX across many chains with completely different mechanism design is like cancer in a positive way. It’s unsolvable yet, but we’re already finding amazing treatments.
What Merchant Really Cares About
We’ve been fixing the problem of complexity of blockchain solutions for many years already. A merchant doesn’t care whether a chain is L1, L2, L5, a rollup, proof-of-stake or proof-of-anything.
They care about one thing: can I be sure that my money will stay in my wallet after I provide them the service?
Protocol debates about decentralization and block times mostly miss the point from a merchant’s perspective. It’s also why traditional payments still dominate despite being slower underneath.
Visa says: “you’ll get paid, don’t worry” (in majority of the cases).
They don’t have any cryptographic finality or anything.
Crypto, as an industry, has an opportunity to not say anything and be the trustless, go-to option fundamentally, but at the same time we don’t need to scare merchants and buyers away by telling them all of that geeky stuff.
How Crypto Payment Models Handle Settlement Risk
We can divide crypto payment models nowadays into two categories: crypto cards and wallet payments.
As I said countless times before, crypto cards are literally just traditional cards: multiple middlemen absorb the whole risk, potential onchain failures are invisible to merchants, uptime and reliability guarantees are provided by Visa, Mastercard, or Amex, underlying banks provide guarantees of payment itself.
I would say that the biggest advantage here is that the scaling question is pretty straightforward, because the infrastructure is already here. There are no modifications needed at the point of sale, you just tap the card and that’s it.
The tradeoff is that this model inherits every limitation of traditional card payments: interchange fees, chargeback windows, processor dependency, etc. It doesn’t fix the fundamental problem — user custody and the right for everyone to transact (you can’t open a crypto card if you’re from a sanctioned country).
Are wallet payments different?
I define “wallet payments” as fully permissionless payments made from your wallet like Metamask or Phantom directly to merchants. Merchants can display a QR code or payment address (maybe even an ENS domain), and buyers can use that to pay.
This system is fully permissionless and transparent, and it sounds like an end game, right? Yes, but... due to several reasons, this exact scenario is very unlikely to happen anytime in the future.
The merchant absorbs nearly all settlement risk and is not protected from reorgs in any way. Even if we use scenario 1 or scenario 2 from the previous sections where reorg risk is minimized or almost completely eliminated, there is still such a thing as compliance and regulation.
Sure, your friend might sell you their PlayStation 5 without any legal stuff, but if you go to an official store, it’s unlikely they will let you buy it with crypto without any verification beforehand. No merchants know how to tell if they’re dealing with dirty onchain money, so this is eventually their protection and your protection to make sure no one steals anything.
The question of scaling is two-sided: yes, it’s very scalable, we have millions of units of blockspace, infinite transactions, IBRL. But crypto payments still need to be integrated in some way into PoS terminals or similar infrastructure.
Attempts of WalletConnect
One of the examples of native integration, but not optimized UX at the moment, is WalletConnect. They have recently announced their integration with PoS terminals, where you can pay with your crypto, however, the UX is far from perfect yet.
You have to scan the QR code with your phone, open the payment page, connect your wallet, choose the token you’re paying with, choose the network, and only then is your payment processed.
These are a lot of steps, but the main concern is connecting your wallet. These integrations will be used by crypto guys at first, so people who care about security are pretty paranoid about connecting their wallet for payment, when there could be another option of just sending it without connecting the wallet.
Even though UX friction from the merchant side is minimized, imagine telling them you will pay with crypto, or if you’re from a less safe country, imagine hearing some people in line say that you have crypto.
No single model dominates across all dimensions, which is fine — every market has different solutions where different users with different preferences use different solutions. But there is huge room for improvement for every model.
I believe that scenario 2 with insurance hasn’t really been covered anywhere, so next I want to focus on the part where we can have crypto-native payments and not care about finality, but just ensure merchants that they will receive the money.
Flexa & Guaranteed Finality
As I said before, the core problem we want to fix is finality and bringing “near-instant UX” for merchants and buyers.
If we take the insurance model (where the gap between optimistic finality and economic finality is insured), we can have a model like @FlexaHQ — putting up economic value that exceeds the risk of non-settlement. Or simply put:
“Guaranteeing that the cost of an economic attack is greater than the value that can be extracted (classic MEV conversations back in the day).”
In Flexa’s case, the QR code scan can go both ways — either the merchant presents the QR code and the customer scans it (which renders a hosted payment page for soliciting payments from any wallet), or the consumer presents a QR code from within their wallet.
After that, Flexa locks a corresponding amount of AMP from the relevant collateral pool (before any onchain confirmations). This AMP is held in escrow by a collateral manager smart contract on Ethereum. The merchant receives an instant authorization and guaranteed payout. AMP token is used as collateral in Flexa network.
On one track, the merchant gets settled in their preferred currency (this happens immediately because the collateral backs it).
On another track, the consumer’s actual crypto transaction propagates through its native blockchain and eventually reaches sufficient confirmations.
Once that underlying transaction achieves finality, the locked AMP is released back into the pool and is now available to collateralize the next transaction.
If the transaction fails for any reason, the AMP collateral is liquidated to cover the merchant’s payout, so the merchant loses nothing.
The collateral providers (people who have staked AMP into Flexa’s Capacity collateral pools) earn rewards from network transaction fees for taking on this risk.
Flexa separates merchant payment settlement from onchain confirmation: it fully backs each transaction with AMP collateral at the point of sale.
From the merchant’s perspective, the payment is finalized at this exact moment, there is no reason to ask the buyer anything, click any additional buttons, etc. Even if you pay with BTC and the transaction can take minutes to confirm, your payment will be done beforehand, since that time gap is covered by AMP.
Basically, the collateral decouples merchant settlement from consumer payment finality: these become two independent processes. The cost of attacking the system must be weighed against the fact that the collateral bears the loss, not the merchant.
This is scenario 2 that I described earlier. Fees from payments are essentially yield for collateral providers (stakers) who delegate their AMP, and if the transaction was malicious or reorged, AMP is liquidated and sold into the open market.
In every other approach, the guarantee is somehow tied to the chain’s confirmation process — you either wait for confirmations (slow), use a payment channel that eventually settles onchain (not efficient), or trust a custodial intermediary who absorbs the risk (centralized).
Flexa’s authorization depends only on verifying that sufficient AMP collateral is available and locking it, which is a function of the collateral manager contract, not the speed of whatever blockchain the consumer is paying with.
All blockchains have different finality properties, different confirmation times, and different attack vectors, hardly any of them provide instant finality suitable for retail payments.
A merchant accepting 15 different tokens through Flexa doesn’t need to understand or worry about the finality guarantees of 15 different blockchains.
Merchants don’t even need to care about the tokens they accept or the crypto aspect at all — they just scan the flexcode and receive the payment in their desired currency.
If you’re a Chinese reader with a VPN or someone who has been to China, you have used Alipay, where you just show your code to the merchant, they scan it, and the payment is completed within milliseconds.
The only reason why Flexa offers both types where either customer or merchant generates QR code is because it’s not realistic to ask big enterprise chains to up and install QR code displays if they don’t already have them.
This UI is already widely accepted among billions of people in the largest economies, so why wouldn’t we bring it to the USA as well? (Flexa is currently available in the USA, Canada, Latin America).
Who will be winning?
All of the issues come down to problems with the gap between two types of finality.
CEXes ask you to wait. For CEX, you can afford to wait to trade, but expecting a watermelon seller to wait for you while there’s a line of 10 other people who also want to buy watermelons would be weird. Weird and simply unoptimized.
Crypto payments are still in that early stage. Despite the fact that these are seemingly the most obvious use cases for crypto, a lot depends on the buyer’s side, the merchant’s side, and the overall environment in which all of this is happening.
There will be many solutions, there will be a very competitive market, but what we can do is look at and take the best from models that exist in traditional payments, and try to adapt them for crypto payments — taking the benefits from both approaches.
If we take the benefits of traditional payments in terms of UX (especially in Asia) and combine that with self-custody (which is the most important thing of crypto), we will be winning.
We take it, build specialized payments, and optimize them. In terms of optimization, two types of solutions could dominate: fully monolithic (where we simply use one chain and it handles everything) and modular (allow a lot of chains).
As many great people have said, collaboration always beats competition.
This research is part of a Hazeflow collaboration supported by the Amp Grant Program, with the sole goal of educating more people on the crypto payments landscape and the solutions available in this space.