Author: Pavel Paramonov Source: Hazeflow Translation: Shan Oppa, Golden Finance

For more than a year, lists ranking cryptocurrency cards on the X platform have been popular, promoting the best options while criticizing other products. However, the vast majority of users are still unaware of the real risks they face when using such cards to pay, or even whether the risks exist at all.

In addition to the obvious lack of privacy, there is also a pain point that we have long been committed to solving in the field of crypto wallets - user experience. My point is: as long as the settlement and final confirmation issues in crypto cards or direct payments in general are solved, it is not difficult to achieve a perfect or near-perfect user experience.

Ignored settlement issues

In the crypto payment scenario, almost every transaction is essentially a recharge.

• When someone transfers money to you, they are recharging your account;

• When you transfer money to someone else, you are recharging the other person’s account;

• When you pay for consumption, you recharge the merchant's account.

But these top-ups vary greatly depending on which app or service you use. Recharging funds to centralized exchanges, encrypted wallets, encrypted cards, and encrypted payment service providers have completely different trust conditions and user experiences.

It should be noted that what I am talking about here is user experience (UX) in a broad sense, not interface design (UI) specifically. If we create the concept of “instant user experience”, where transactions are finalized at the click of a button, this is almost impossible to achieve because of the latency (both traditional and crypto transactions are affected by this).

I don’t want to deliberately misinterpret technical terms for the sake of marketing, so I will use the term “quasi-instant user experience” instead, which means that transactions can be finalized in 1 second.

When using cryptocurrency to pay a merchant, the only thing you and the merchant have in common is that the transaction is processed as quickly as possible, so that the merchant can let you leave the store as quickly as possible, which not only saves you time, but also allows you to enjoy the purchased goods with peace of mind.

Crypto cards appear to do this, but you’re not actually paying with cryptocurrency. At the consumer terminal, what you pay is legal currency lent against crypto-asset mortgage.

Payment terminals recognize these cards because they are connected to global payment networks such as American Express, VISA, Mastercard, etc., not because they support cryptocurrencies. You have never paid with cryptocurrency, you have always used fiat currency.

The settlement problem of crypto cards only occurs during the recharge process: when you or others recharge the crypto card, you need to wait for a period of time before the assets can be used for consumption. The process is roughly as follows:

1. Transfer 100 USDC to address A;

2. Address A confirmed receipt of 100 USDC;

3. The balance displayed in the encrypted card application increases by 100 USDC;

4. The 100 USDC are transferred to another address through protocols such as RelayProtocol;

5. Address A no longer holds the 100 USDC, but the balance is still available in the app.

There is no settlement problem with encrypted cards at consumer terminals because there is no need for on-chain settlement at all.

When paying with an encrypted card, you will not initiate any on-chain transactions, but only consume fiat currency. For example, if you buy daily necessities worth $10, the funds will flow through the Visa network, and there will not be any on-chain transactions marking you as spending $10.

But the ultimate form of encrypted payment is to directly use native cryptocurrency to complete payment, rather than abstracting it. Only in this way can permissionless on-chain payments be made available to everyone. The ultimate goal is native cryptocurrency transactions directly between buyers and merchants.

Once native encrypted payment is implemented, the settlement problem of consumer terminals will become real: transactions occur on the chain, and settlement and final confirmation need to be completed, and the confirmation process of the current mainstream public chain cannot be completed instantly.

How traditional payment handles settlement

If I said seriously that traditional finance is complicated and involves middlemen, it would sound silly because it would be obvious to 99.99% of people. However, it should be a "middleman" rather than a "middleman". Many systems themselves have certain risks.

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

• Your bank approves or rejects the transaction. If you report malicious behavior such as fraud, the bank can recover the funds up to 120 days after the transaction (such chargebacks cost millions of dollars every year);

• Before the merchant bank actually receives the funds from your bank, it will pay the merchant first, advance the funds and trust that the transaction will be completed normally;

• The actual fund transfer between banks will wait 1-3 days, and even then, the transaction can still be reversed if something goes wrong.

In the traditional payment system, banks and card organizations act as buffers and guarantors, bear risks and make profits through service fees. You have no idea about this because the process is completely hidden. This is the operating logic of the existing system.

Crypto payments are peer-to-peer transactions. There are no intermediaries to cover up the complexity of settlement, and there are no institutions to guarantee you.

Achieving "quasi-instant user experience" in the encryption field is more difficult and the logic is more complex. We cannot directly copy the tools of traditional banks, otherwise we will end up replicating the traditional financial system and lose real control over assets.

The quasi-instant user experience of encrypted payment must rely on quasi-instant settlement, or have a mechanism to prevent transaction failure and chain reorganization risks. At the same time, the user experience of daily transactions needs to be cross-chain compatible, otherwise there will be too much resistance to use. Ultimately, the settlement problem is derived from the problem of final confirmation of transactions.

Transaction confirmation ≠ transaction completed

The vast majority of L1s have two final confirmation mechanisms: optimistic confirmation and economic confirmation.

• Optimistic confirmation: The wallet displays "Transaction Confirmed" and you seem to have completed sending and receiving funds. As the name suggests, this "deal completion" judgment is optimistic and does not have realistic certainty.

• Economic (deterministic) confirmation: the transaction is irreversible. As the name suggests, this judgment of "transaction completion" is certain and has practical validity.

This mechanism is applicable to public chains such as Solana, Ethereum, BNB Chain, and Hyperliquid. Bitcoin, on the other hand, does not have the definition of final confirmation that we are familiar with: there is no node that absolutely completes the confirmation, and security will only be gradually improved with new blocks.

Most proof-of-stake (PoS) public chains and their two-layer rollup solutions have the problem of the time difference between optimistic confirmation and economic confirmation.

Why does this time difference exist? Multi-node distributed consensus takes time. In theory, reducing verification nodes, strengthening trust prerequisites, or optimizing protocol design can increase the confirmation speed, but this may not reduce costs, and it is difficult to maintain the same level of decentralization.

During this time gap, chain reorganization (Reorg) may occur. Chain reorganization means that the blockchain discards the latest block and replaces it with another version of the chain data because the competing chain is longer or has a higher weight. The probability of this happening is not low and deserves vigilance.

The risk of chain reorganization can be intuitively understood through the following scenarios:

1. Alice transfers 1 ETH to you (transaction A). The transaction enters the memory pool but there is no block confirmation yet;

2. You immediately transfer 0.5 ETH to Bob (transaction B). This transaction depends on transaction A, and the two are processed in order;

3. Due to chain reorganization, transaction A was revoked and removed from the chain;

4. Transaction B is invalid because the referenced funds record is invalid and rejected by the network.

Who is harmed in this scenario?

• Bob is the primary victim: he thought he received 0.5 ETH and may have delivered goods or services to you, but the final payment disappeared out of thin air;

• You will also be damaged: if Alice is malicious, you paid Bob a consideration based on "received funds" and never actually received the funds;

• Malicious Alice is the only winner: double spend, keep the original ETH, and get the consideration you paid.

No matter how many people are involved, the final recipient in the transaction chain suffers the most. At this time, encrypted transfers are tantamount to a hot potato game, and the funds can only be transferred to the next party as quickly as possible.

If you have ever deposited cryptocurrency to a centralized exchange (CEX), you will know that you have to wait for multiple blocks to be confirmed before the deposited funds can be used for trading.

This is exactly the difference between an optimistic confirmation and an economic confirmation: CEX shows that funds have been processed on an optimistic confirmation, and only allows funds to be used on an economic confirmation.

CEX’s strategy is very conservative, aiming to avoid extreme risks and prevent you from using funds that are not fully confirmed to trade or withdraw cash, causing the platform to suffer losses.

But in the global crypto payment scene, we cannot copy the CEX mechanism: the cashier cannot wait 15 minutes until your Ethereum transaction completes 64 blocks of confirmation.

In this case, can switching to Bitcoin payment avoid the final confirmation problem? The answer is no. Bitcoin’s high fees and slow speed solve one problem but create more new ones. The Lightning Network was once considered a solution, but its transactions are not on-chain transactions and are far less secure than native Bitcoin.

In the final analysis, we need to get out of public chain competition and create cross-chain compatible solutions so that users do not need to care about which chain they are using. Currently, almost all mainstream public chains are proof-of-stake mechanisms, and we cannot avoid the issue of final confirmation.

Solution 1: Limit the use of a few high-speed public chains to reduce the time difference between soft confirmation and hard confirmation

The most intuitive idea is: only open a few public chains with block speeds faster than Ethereum.

But faster blocks and public chains may not be able to narrow the time gap between optimistic confirmation and economic confirmation. As mentioned above, the core risk for merchants is not the transaction display, but waiting for the transaction to be irreversible.

Public chains such as Monad, Sei, and Sui have extremely fast confirmation speeds, while Plasma, Arc, Tempo, etc. are public chains that focus on payments. Is it feasible to use these public chains directly? I think this is more of a business development issue than a technical issue, and it also involves economics.

Whether you accept it or not, a large amount of funds have been deposited in leading public chains such as Solana, Ethereum, and TRON. In the consumption scenario, cross-chaining these assets to a specific network is costly and time-consuming (the situation where the assets are already on the target public chain is not discussed here).

The capital volume and transaction scale of the first-level public chain are huge and cannot be excluded. The cost of launching an economic attack against these public chains approaches infinity, and it makes no sense to attack a roadside stall for $3 Pad Thai.

Even if we hope to reduce the time difference between the two confirmation mechanisms, we cannot abandon these large public chains, even if they are slow.

Solution 2: Provide guarantee (insurance mechanism) before final confirmation

Even if the confirmation time difference can be reduced, we still need to adapt to the public chain that cannot be modified to ensure popularity. It is currently impossible to completely prevent chain reorganization, but the insurance mechanism may be a breakthrough.

Insurance can cover the potential loss of the merchant - the merchant has delivered the goods, but the collection is invalid due to chain reorganization (as mentioned above, the biggest victim of chain reorganization is the final recipient of the transaction).

If insurance is used as the core model, the system design options are very diverse: merchants can subscribe to pay for insurance, or automate the insurance process; insurance can be used as an independent solution or integrated into the encrypted payment track.

• Independent insurance: The insurance fund is supported by premiums paid by merchants;

• Native integrated insurance: If the insurance fund comes from the payment network’s fees, merchants can obtain default protection for free.

Some people may think that this is a temporary solution rather than a permanent solution.

But I believe that achieving quasi-real-time user experience on multiple public chains with different mechanism designs is a very valuable long-term issue. There is no perfect solution yet, but we have found effective optimization solutions.

What do merchants really care about

For years, we have been working to simplify the complexity of blockchain solutions. Merchants don't care at all whether a chain is one layer, two layers, five layers, rollup, proof of equity or other consensus mechanisms.

They only care about one thing: that the funds remain safe in their wallet after providing the service.

The protocol debates on decentralization and block speed are mostly deviated from the core from the perspective of merchants. This is why traditional payments still dominate, despite their slower underlying speeds.

Visa's logic is simple: "Don't worry, you will receive your money" (in the vast majority of cases). It does not require any final cryptographic confirmation.

The crypto industry could have relied on its trustless underlying features to become the default payment option without having to scare away merchants and consumers with obscure technical details.

How existing crypto payment models deal with settlement risks

Today we can divide cryptocurrency payment models into two categories: cryptocurrency card and wallet payments.

As I've said countless times before, crypto cards are effectively just traditional cards: multiple middlemen bear all the risk, potential on-chain failures are invisible to merchants, uptime and reliability guarantees are provided by Visa, Mastercard, or Amex, and the underlying bank guarantees the payment itself.

I think the biggest advantage is that the scalability issue is very simple because the infrastructure is already in place. No modifications are required at the point of sale, just swipe your card to complete the payment.

The disadvantage of this model is that it inherits all the limitations of traditional card payments: interchange fees, chargeback deadlines, dependence on payment processors, etc. It doesn’t address the fundamental issues – user control over funds and everyone’s right to transact (you can’t open a cryptocurrency card if you’re from a sanctioned country).

How are Wallet payment methods different?

I define "wallet payment" as: initiating permissionless payments directly to merchants through wallets such as MetaMask and Phantom. Merchants can display a QR code or payment address (or even an ENS domain name), and buyers can scan the code to complete payment.

This system is completely permissionless and transparent, and seems to be the ultimate ideal form. However, due to multiple factors, this model will be difficult to popularize in the short term.

Merchant bears almost all settlement risks and cannot resist chain reorganization. Even if the aforementioned option 1 or 2 is adopted to minimize the risk of chain reorganization, compliance and regulatory issues will still exist.

Private transactions of PlayStation 5 between friends may not require compliance procedures, but it is almost impossible for formal offline stores to allow you to pay with cryptocurrency without identity verification. Merchants cannot identify whether the funds on the chain are legal or not. The compliance process is to protect both merchants and consumers.

At the scalability level, there are two sides: on the one hand, there is sufficient block space, unlimited transaction capacity, and high scalability; on the other hand, encrypted payments still need to be integrated into existing infrastructure such as POS terminals.

WalletConnect attempt

WalletConnect is a typical example of native integration, but the user experience still needs to be optimized. The platform recently announced access to POS terminals to support cryptocurrency payments, but the process is far from perfect.

Users need to scan the QR code with their mobile phone, open the payment page, connect the wallet, and select the payment token and public chain to complete the transaction.

This set of steps is too cumbersome, and the core pain point lies in wallet connection. This type of integration will only attract crypto-native users initially, while security-conscious users are wary of connecting to wallets when making payments, preferring direct transfers without connecting to a wallet.

Even if the resistance to use on the merchant side is minimized, it is still embarrassing to tell the cashier that you want to pay with cryptocurrency; if you are in an area with poor security, it may also cause security risks if the people queuing know that you hold cryptocurrency.

At present, no one model can lead in all aspects. Users in different markets and with different preferences will choose different solutions, but all models have huge room for optimization. I think the insurance mechanism of option 2 has not been fully explored yet. Next, I will focus on analyzing: how to implement encrypted native payment without worrying about final confirmation issues, while ensuring the security of payment to merchants.

Flexa and guaranteed final confirmation

As mentioned above, the core issue we want to solve is the final confirmation of transactions and create a quasi-instant user experience for merchants and consumers.

Using an insurance model (insuring the time lag between optimistic confirmation and economic confirmation) enables solutions like @FlexaHQ: the economic value of the collateral is higher than the non-settlement risk. In simple terms:

Ensure that the cost of launching an economic attack is higher than the benefits that can be stolen (similar to the earlier maximum extractable value MEV logic).

• In the case of Flexa, QR code scanning can be two-way - either the merchant displays the QR code and the customer scans the QR code (which will display a hosted payment page for collecting payment from any wallet), or the consumer displays the QR code in their wallet.

• Flexa then locks the corresponding number of AMPs from the relevant staking pool (before any on-chain confirmation). These AMPs are hosted by collateral management smart contracts on Ethereum. Merchants receive immediate authorization and guaranteed payment. AMP tokens are used as collateral in the Flexa network.

• On a settlement track, merchants settle in their preferred currency (this happens instantly as it is backed by collateral).

• On the other hand, a consumer's actual cryptocurrency transaction is propagated on its native blockchain and eventually receives sufficient confirmations.

• Once the underlying transaction is finalized, the locked AMP will be released back into the pool and can be used to collateralize the next transaction.

• If the transaction fails for any reason, AMP collateral will be liquidated to pay the merchant, so the merchant has nothing to lose.

Collateral providers (those who stake AMP into Flexa’s Capacity collateral pool) are rewarded from network transaction fees for taking on this risk.

Flexa decouples 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, the payment is complete at that moment without asking the buyer for any information, clicking any additional buttons, etc. Even if you pay with Bitcoin, the transaction may take a few minutes to confirm and your payment will be completed early because this time is processed by AMP.

Essentially, the collateral mechanism decouples merchant settlement from final confirmation of consumer payments: the two become two separate processes. The cost of attacking the system must be weighed against the fact that the collateral, not the merchant, bears the losses.

This is the second situation I described before. The payment fee is essentially a benefit to the collateral provider (pledger) who entrusted their AMP with the transaction; if the transaction is malicious or tampered with, the AMP will be liquidated and sold to the open market.

In every other approach, the guarantee is tied to the chain's confirmation process in some way - either waiting for confirmations (slow), using payment channels that are ultimately settled on-chain (not efficient), or trusting an escrow intermediary that takes the risk (centralized).

Flexa's authorization depends solely on verifying that enough AMP collateral is available and locking it, which is a function of the collateral management contract, not the speed of whatever blockchain the consumer is using.

All blockchains vary in finality, confirmation times, and attack vectors, and few offer instant finality suitable for retail payments.

• Merchant accepting 15 different tokens through Flexa does not need to know or worry about the finality guarantees of 15 different blockchains.

• Merchants don’t even need to care about the tokens or cryptocurrencies they accept – they can simply scan a QR code and receive payment in the currency they want.

If you are a Chinese reader who uses a VPN, or someone who has been to China, you must have used Alipay. You only need to show your QR code to the merchant, they scan it, and the payment is completed within a few milliseconds.

The only reason Flexa offers two types of QR codes for customers or merchants to generate is that if a large chain doesn't already have a QR code display, it's unrealistic to ask them to install it immediately.

This user interface is already widely accepted by billions of people in the world's major economies, so why don't we bring it to the United States as well? (Flexa is currently available in the United States, Canada, and Latin America).

Who will be the final winner

The core of all problems is the time difference between the two final confirmation mechanisms.

Centralized exchanges can make you wait, and transaction delays do not matter; but it is neither reasonable nor efficient to let roadside watermelon vendors wait for you to complete on-chain confirmation before queuing up customers.

Crypto payments are still in their early stages. Although this is the most intuitive application scenario for cryptocurrency, the implementation effect depends on buyers, merchants and the overall industry environment. A large number of solutions will emerge in the future, and market competition will become increasingly fierce. We can learn from the excellent design of traditional payments, adapt to encrypted payment scenarios, and integrate the advantages of both.

Combining the excellent user experience of traditional payments (especially in the Asian market) with the core of cryptocurrency - asset self-sustainability is the key to success.

On this basis, we will create professional payment solutions and continue to optimize them. Two types of solutions may dominate the market in the future:

• Single solution: rely on a single public chain to handle all processes;

• Modular solution: compatible with multiple public chains.

As many industry seniors have said: Cooperation is always better than competition.