Why can't encrypted payments ever achieve "truly instant" payment?

Author: Pavel Paramonov Source: Hazeflow Translation: Shan Ouba, Jinse Finance

For over a year, ranking lists on the X platform that categorize cryptocurrency cards have been very popular, praising the best choices while criticizing other products. However, most users are still unaware of the real risks involved in using these cards for payments, or even if such risks exist.

Besides the obvious privacy issues, there is another pain point we have long been working to address in the crypto wallet field—user experience. My view is that as long as the settlement and final confirmation issues in crypto cards or general direct payments are resolved, achieving a perfect or near-perfect user experience is not difficult.

The Overlooked Settlement Issue

In crypto payment scenarios, almost every transaction is essentially a top-up.

When someone transfers money to you, it's topping up your account; when you transfer money to someone else, it's topping up their account; when you make a purchase, it's topping up the merchant's account. However, these topping-up behaviors differ greatly, depending on the application or service you use. Topping up a centralized exchange, topping up a crypto wallet, topping up a crypto card, and topping up a crypto payment service provider all involve vastly different trust prerequisites and offer drastically different user experiences. It's important to note that I'm referring to user experience (UX) in a broad sense, not specifically interface design (UI). If we were to create the concept of "instant user experience"—where a transaction is finalized the instant a button is clicked—this is virtually impossible due to latency (affecting both traditional and crypto transactions). I don't want to deliberately misrepresent technical terms for marketing purposes, so I'll use the term "near-instant user experience," meaning a transaction can be finalized within one second. When paying merchants with cryptocurrency, the only shared desire between you and the merchant is for the transaction to be processed as quickly as possible so the merchant can get you out of the store as soon as possible, saving you time and allowing you to enjoy your purchase with peace of mind. Crypto cards may seem to achieve this, but you're not actually paying with cryptocurrency. At the payment terminal, you're paying with fiat currency borrowed against crypto assets. Payment terminals can recognize these cards because they are connected to global payment networks like American Express, VISA, and Mastercard, not because they support cryptocurrency. You have never paid with cryptocurrency; you have always used fiat currency. The settlement issue with crypto cards only occurs during the top-up process: when you or someone else tops up a crypto card, there is a waiting period before the assets can be used for spending. The process is roughly as follows: 100 USDC are transferred to address A; Address A confirms receipt of the 100 USDC; The encrypted card application displays an increase of 100 USDC in the balance; These 100 USDC are then transferred to another address via protocols such as RelayProtocol; Address A no longer holds these 100 USDC, but the application still displays an available balance. Encrypted cards do not present settlement issues at the consumer terminal because on-chain settlement is not required. When using encrypted cards to pay, you don't initiate any on-chain transactions; you're simply spending fiat currency. For example, if you buy $10 worth of everyday items, the funds flow through the Visa network, and there's no on-chain transaction marking your expenditure of $10. However, the ultimate form of encrypted payments is to complete payments directly using native cryptocurrency, rather than abstracting it. Only in this way can permissionless on-chain payments be achieved for everyone. The ultimate goal is for buyers and merchants to conduct direct transactions using native cryptocurrency. Once native encrypted payments are realized, the settlement issue at the consumer terminal will become a real problem: transactions occur on-chain and require settlement and final confirmation, but the confirmation process on current mainstream public chains cannot be completed instantly. How Traditional Payments Handle Settlements

It would sound silly if I seriously said that traditional finance is complex and involves intermediaries, because that's obvious to 99.99% of people. However, it should be "intermediaries," not "middlemen," as many systems inherently carry certain risks.

• Visa or Mastercard forwards the authorization request to the bank;

• Your bank approves or rejects the transaction.

• If you report fraud or other malicious activity, the bank can recover funds within 120 days of the transaction (such chargebacks can cause millions of dollars in losses annually); Merchant banks will pay merchants before actually receiving funds from your bank, providing advance funding and trusting that the transaction will complete normally; Actual fund transfers between banks take 1-3 days, but even then, the transaction can be cancelled if any anomalies occur. In traditional payment systems, banks and card organizations act as buffers and guarantors, bearing the risk and profiting through service fees. You are completely unaware of this because the process is completely hidden; this is the operating logic of the existing system. Encrypted payments are peer-to-peer transactions; there are no intermediaries to conceal the complexity of settlement, and no institution to guarantee your transaction. Achieving a "near-instantaneous user experience" in the crypto space is more difficult and logically complex. We cannot directly copy the tools of traditional banks; otherwise, we will only be replicating the traditional financial system and losing true control over assets. A near-instantaneous user experience in crypto payments must rely on near-instantaneous settlement or have mechanisms to prevent transaction failures and chain reorganization risks. At the same time, the user experience of daily transactions needs cross-chain compatibility; otherwise, it will create too much resistance to use. Ultimately, the settlement problem stems from the final confirmation problem of transactions. Transaction confirmation ≠ transaction completion. Most L1 blockchains have two final confirmation mechanisms: optimistic confirmation and economic confirmation. Optimistic confirmation: Your wallet displays "Transaction confirmed," and you seem to have completed the fund transfer. As the name suggests, this judgment of "transaction completion" is optimistic and lacks real-world certainty. Economic (Deterministic) Confirmation: The transaction is irrevocable. As the name suggests, this judgment of "transaction completion" is certain and has real-world validity. This mechanism applies to public chains such as Solana, Ethereum, BNB Chain, and Hyperliquid. Bitcoin, however, does not have the well-known final confirmation definition: there is no node that has absolutely completed confirmation; security only gradually improves with the addition of new blocks. Proof-of-Stake (PoS) public chains and their Layer 2 Rollup schemes all suffer from the time lag between optimistic confirmation and economic confirmation. Why does this time lag exist? Multi-node distributed consensus takes time. Theoretically, reducing the number of verification nodes, strengthening trust prerequisites, or optimizing protocol design can improve confirmation speed, but this may not necessarily reduce costs or maintain the same level of decentralization. During this time lag, chain reorganization (Reorg) may occur. Chain reorganization refers to the blockchain discarding the latest block and replacing it with another version of the chain data because the competing chain is longer or has higher weight. The probability of this happening is not low and warrants attention. The risks of blockchain reorganization can be intuitively understood through the following scenario: Alice transfers 1 ETH to you (Transaction A). This transaction enters the mempool but has not yet been confirmed by a block. You immediately transfer 0.5 ETH to Bob (Transaction B). This transaction depends on Transaction A, and the two are processed sequentially. Due to blockchain reorganization, Transaction A is revoked and removed from the chain. Transaction B becomes invalid because the referenced fund record is invalid and is rejected by the network. Who will suffer losses in this scenario? Bob is the primary victim: he thought he received 0.5 ETH and might have delivered goods or services to you, but the payment vanished without a trace; You will also suffer: if Alice is malicious, you might pay Bob based on "funds received," but never actually receive the funds; Malicious Alice is the only winner: she achieves double-spending, retaining both the original ETH and the payment you made. Regardless of the number of people involved, the final recipient in the transaction chain suffers the most. At this point, encrypted transfers become a hot potato, requiring the funds to be transferred to the next party as quickly as possible. If you've ever deposited cryptocurrency into a centralized exchange (CEX), you know that you must wait for multiple block confirmations before the deposited funds can be used for trading. This is precisely the difference between optimistic confirmation and economic confirmation: CEXs show funds as processed during optimistic confirmation, but only allow funds to be used during economic confirmation. CEXs employ a very conservative strategy to avoid extreme risks and prevent you from trading or withdrawing funds that haven't been fully confirmed, thus causing losses for the platform. However, in the global crypto payment landscape, we cannot simply replicate the CEX mechanism: cashiers cannot wait 15 minutes for your Ethereum transaction to complete 64 block confirmations. Given this, can switching to Bitcoin avoid the final confirmation problem? The answer is no. Bitcoin's high fees and slow speed solve one problem but introduce many new ones. The Lightning Network was once seen as a solution, but its transactions are not on-chain, making its security far lower than native Bitcoin. Ultimately, we need to move beyond public chain competition and create cross-chain compatible solutions so users don't need to care which chain they are using. Currently, almost all mainstream public chains use a proof-of-stake mechanism, meaning we cannot avoid the final confirmation problem. Solution 1: Limit the use of a few high-speed public chains to narrow the time gap between soft and hard confirmations. The most intuitive approach is to only allow access to a few public chains with block speeds faster than Ethereum. However, faster blocks and public chains may not necessarily narrow the time gap between optimistic and economic confirmations. As mentioned earlier, the core risk for merchants is not transaction display, but waiting for transactions to become irreversible. Monad, Sei, and Sui public chains have extremely fast confirmation speeds, while Plasma, Arc, and Tempo are payment-focused public chains. Is it feasible to directly use these public chains? I believe this is more of a business expansion issue than a technical one, and it also involves economic aspects. Whether you accept it or not, a large amount of capital has already been invested in leading public chains such as Solana, Ethereum, and Tron. In consumer scenarios, transferring these assets across chains to specific networks is costly and time-consuming (this does not discuss situations where the assets are already on the target public chain). The sheer size and transaction volume of top-tier public chains make them unavoidable. The cost of launching an economic attack against these public chains is near infinity; launching an attack for a $3 Thai stir-fried noodle dish at a roadside stall is pointless. Even if we want to reduce the time difference between the two confirmation mechanisms, we cannot abandon these massive public chains, even if they are relatively slow. Solution Two: Provide guarantees (insurance mechanisms) before final confirmation. Even if we can reduce the confirmation time difference, we still need to adapt to immutable public chains to ensure widespread adoption. While chain reorganization cannot be completely prevented at present, insurance mechanisms may be a breakthrough. Insurance can cover potential losses for merchants—merchants may have delivered goods, but payment may fail due to blockchain reorganization (as mentioned earlier, the biggest victim of blockchain reorganization is the final recipient of the transaction). If insurance is used as the core model, the system design options are highly diverse: merchants can subscribe to paid insurance or automate the insurance process; insurance can be a standalone solution or integrated into the encrypted payment system. Standalone insurance: The insurance fund is supported by premiums paid by merchants; Native integrated insurance: If the insurance fund comes from transaction fees from the payment network, merchants can receive default coverage for free. Some may argue that this is only a temporary solution. However, I believe that achieving near-instant user experience across multiple public blockchains with vastly different mechanism designs is a valuable long-term challenge. There is no perfect solution yet, but we have found effective optimization methods. What do merchants really care about? For years, we have been committed to simplifying the complexity of blockchain solutions. Merchants don't care whether a chain is layer one, two, or five, or whether it's Rollup, Proof-of-Stake, or some other consensus mechanism. They only care about one thing: whether the funds can stay safely in their wallets after the service is provided. From a merchant's perspective, most debates about decentralization and block speed protocols are off-topic. This is why traditional payments, despite their slower underlying speeds, still dominate. Visa's logic is simple: "Don't worry, you'll receive the money" (in most cases). It doesn't require any cryptographic final confirmation. The crypto industry could have become the default payment choice due to its trustless underlying nature, without scaring away merchants and consumers with obscure technical details. How do existing crypto payment models address settlement risks? We can now divide cryptocurrency payment models into two categories: crypto cards and wallet payments. As I've said countless times before, crypto cards are essentially traditional cards: multiple intermediaries bear all the risk, potential on-chain failures are invisible to merchants, uptime and reliability are guaranteed by Visa, Mastercard, or Amex, and the underlying bank guarantees the payment itself. I believe the biggest advantage lies in the simplicity of scalability, as the infrastructure is already in place. Points of sale require no modifications; a simple swipe of the card completes the payment. The drawback of this model is that it inherits all the limitations of traditional bank card payments: exchange fees, chargeback periods, dependence on payment processors, etc. It doesn't solve the fundamental problem—the user's control over their funds and everyone's right to transact (if you're from a sanctioned country, you can't open a cryptocurrency card). What's different about e-wallet payments? I define "wallet payments" as: initiating permissionless payments directly to merchants through wallets like MetaMask and Phantom. Merchants can display a QR code or payment address (or even an ENS domain), and the buyer scans the code to complete the payment. This system is completely permissionless and transparent, seemingly the ultimate ideal. However, due to multiple factors, this model is unlikely to become widespread in the short term. Merchants bear almost all settlement risk and cannot withstand blockchain reorganization. Even if the aforementioned Option 1 or Option 2 is adopted to minimize the risks of blockchain restructuring, compliance and regulatory issues still exist. Private transactions of PlayStation 5s between friends might not require compliance procedures, but legitimate offline stores are almost certain to allow unverified cryptocurrency payments. Merchants cannot verify the legitimacy of on-chain funds; compliance procedures protect both merchants and consumers. Scalability presents a double-edged sword: on the one hand, ample blockchain space and unlimited transaction capacity offer high scalability; on the other hand, encrypted payments still need to be integrated into existing infrastructure such as POS terminals. WalletConnect's attempt is a typical example of native integration, but the user experience still needs optimization. The platform recently announced integration with POS terminals to support cryptocurrency payments, but the process is far from perfect. Users need to scan a QR code with their mobile phone, open the payment page, connect their wallet, and select the payment token and public chain to complete the transaction. This process is overly cumbersome, with the core pain point being the wallet connection. Initially, this type of integration will only attract native crypto users, while security-conscious users are wary of connecting their wallets during payments and prefer direct transfers without a wallet connection. Even if the barrier to entry for merchants is minimized, informing the cashier that you intend to pay with cryptocurrency is still awkward; in areas with high crime rates, the presence of cryptocurrency in queues could pose a security risk. Currently, no single model is universally superior. Different markets and users with different preferences will choose different solutions, but all models have significant room for optimization. I believe the insurance mechanism of Solution Two has not been fully explored. Next, I will focus on analyzing how to achieve native crypto payments without worrying about final confirmation issues, while simultaneously ensuring payment security for merchants. Flexa and Guaranteed Final Confirmation As mentioned earlier, the core issue we need to address is final confirmation of transactions, creating a near-instantaneous user experience for merchants and consumers. Using an insurance model (insuring the time difference between optimistic confirmation and economic confirmation), solutions like @FlexaHQ can be implemented: staking economic value higher than non-settlement risk. Simply put: Ensuring the cost of launching an economic attack is higher than the potential gains (similar to the earlier Maximum Extractable Value (MEV) logic). Taking Flexa as an example, QR code scanning can be bidirectional—either the merchant displays the QR code and the customer scans it (which will display an escrow payment page for receiving funds from any wallet), or the consumer displays the QR code in their wallet. Afterward, Flexa locks a corresponding amount of AMP from the relevant collateral pool (before any on-chain confirmation). This AMP is held in custody by a collateral management smart contract on Ethereum. Merchants receive authorized and secured payments immediately. AMP tokens are used as collateral within the Flexa network. On a settlement track, merchants settle in their preferred currency (this happens immediately due to the collateral backing). Meanwhile, the consumer's actual cryptocurrency transaction propagates on their native blockchain and eventually receives sufficient confirmation. Once the underlying transaction is finalized, the locked AMP is released back into the pool and can be used as collateral for the next transaction. If a transaction fails for any reason, the AMP collateral will be liquidated to pay the merchant, so the merchant will not suffer any loss. The collateral provider (the person who pledges AMP into Flexa's Capacity collateral pool) is rewarded from network transaction fees for taking this risk. Flexa separates merchant payment settlement from on-chain confirmation: it fully backs every transaction using AMP collateral at the point of sale. From the merchant's perspective, payment is completed instantly, without requiring the buyer to provide any information or click any additional buttons. Even if you use Bitcoin to pay, and the transaction might take a few minutes to confirm, your payment will be completed ahead of time because this period is handled by AMP. Essentially, the collateral mechanism decouples merchant settlement from the final confirmation of consumer payments: these become two separate processes. The cost of attacking this system must be weighed against the fact that the collateral, rather than the merchant, bears the loss. This is the second scenario I described earlier. Payment fees are essentially the revenue of collateral providers (stakers), who entrust their own AMP to conduct transactions; if the transaction is malicious or tampered with, the AMP will be liquidated and sold on the open market. In all other methods, guarantees are somehow tied to the chain's confirmation process—either waiting for confirmation (slow), using a payment channel that ultimately settles on-chain (inefficient), or trusting a risk-bearing escrow intermediary (centralized). Flexa's authorization depends solely on verifying that sufficient AMP collateral is available and locking it; this is a function of the collateral management contract, not the speed of any blockchain used by the consumer. All blockchains differ in finality, confirmation times, and attack vectors, and almost none offer the instant finality suitable for retail payments. Merchants accepting 15 different tokens through Flexa need not know or worry about the finality guarantees of 15 different blockchains. Merchants don't even need to worry about the tokens or cryptocurrencies they accept—they simply scan the QR code to receive payment in the currency they want. If you're a Chinese reader using a VPN, or someone who's been to China, you've definitely used Alipay. You simply show your QR code to the merchant, they scan it, and the payment is completed in milliseconds. Flexa offers two types of QR codes for customers or merchants to generate, the only reason being that it's unrealistic to ask large chains to install QR code displays immediately if they don't already. This user interface is already widely accepted by billions of people in the world's major economies, so why not bring it to the US as well? (Flexa is currently available in the US, Canada, and Latin America.) Who will be the ultimate winner? At the heart of all these questions lies the time difference between the two final confirmation mechanisms. Centralized exchanges can make you wait, and transaction delays are insignificant; but expecting a roadside watermelon vendor to wait in front of a line of customers for your on-chain confirmation is neither reasonable nor efficient. Crypto payments are still in their early stages. Although this is the most intuitive application scenario for cryptocurrencies, its effectiveness depends on buyers, merchants, and the overall industry environment. Numerous solutions will emerge in the future, and market competition will become increasingly fierce. We can learn from the excellent designs of traditional payments, adapt them to crypto payment scenarios, and combine the advantages of both. Combining the excellent user experience of traditional payments (especially in the Asian market) with the core of cryptocurrencies—asset self-ownership—is the key to success. Building upon this foundation, specialized payment solutions will be developed and continuously optimized. In the future, two types of solutions may dominate the market: Monolithic solutions: relying on a single public blockchain to handle the entire process; Modular solutions: compatible with multiple public blockchains. As many industry veterans have said: cooperation is always better than competition.