Someone pays for your lunch in exchange for crypto
You have crypto and want to pay for lunch. The restaurant accepts local currency through a bank QR code. Someone else has a local bank account and wants to buy crypto.
QR Pay explores how to connect the two. The other participant pays the restaurant directly, and you release the agreed crypto to them. They earn a fee for providing the payment. You know the total price before confirming.
The first proposed test is in Vietnam, using supported bank QR codes. The draft is for small purchases, provisionally up to the equivalent of 100 USD. This is a proposed limit; the payment service is not running yet.
How a payment would work
- 01
Scan the QR code
Check the account and amount. Enter the amount if the code does not include it.
- 02
Choose an offer
The network would find someone who wants to buy your crypto. You see the full price before accepting.
- 03
Lock the crypto
The agreed amount is held in escrow for this order.
- 04
The shop receives local currency
The other participant’s phone bot would make the bank transfer and send a signed record.
- 05
Confirm receipt
Once the shop confirms it has received the money, you authorise the release of crypto to the other participant.
CryptoCustomer → escrow → provider
Local currencyProvider → shop
In this design, the shop would not need to install anything. A normal payment ends when you confirm that the shop has received the money.
What still needs testing
The draft uses phone bots, AI-assisted repairs to their bank adapters and independent LLM nodes to assess disputes. None of these mechanisms has been experimentally verified yet.
How can we verify a payment?
Only a signed record from the bot assigned to the order would be accepted. A signature alone does not prove the shop actually received the money.
What if the evidence is inconclusive?
More models examining the same material cannot replace missing evidence. The draft allows for an unresolved dispute. How the money would ultimately be settled in that case is still an open question.
What happens after a change or an outage?
We need to test whether the bot can operate a supported banking app and recover after an outage without paying the same order twice.
This is a concept. Payment automation, escrow and arbitration have not been tested. Privacy and resilience are design goals; complete anonymity and uninterrupted operation are not guaranteed.
The next step
Simulate one order without real money. Then test the bot with one Android configuration and banking app, followed by dispute tests with known outcomes.
Full proposal and public discussion ↗