I had a particularly painful experience using Status to pay for lunch today, and thought about a way it could have been avoided. It was the payment provider’s fault AND my own fault, but Status could help prevent such a mistake from happening again.
A restaurant here implemented crypto payments. But since crypto is not legal tender, they do it by finalizing the actual bill with fiat, and then generating a new one on a separate crypto POS which generates a QR code after the waiter manually inputs the bill ID and amount. Now, this is clumsy, but it’s nothing compared to what follows.
In order to pay, the customer now needs to scan this QR code, which is only an address, and manually enter the amount into the app (they didn’t use QR codes with amounts). So I ended up inputting a number that’s an order of magnitude greater than what I had to pay. I am now the Ethereum pizza guy.
So this happened to me in an app I use every day (Status), with a currency I use every day for development and commerce (Eth), in an ecosystem I’m intimately familiar with (blockchain). I fatfingered my way into paying 1 eth for a pizza.
A system should be designed with the idiot user in mind. If a power user like myself can have this happen to them on a familiar turf, then what’s in store for Mr. John “First time blockchain user” Doe?
My recommendation on how to implement a preventative measure for this:
add a contact settings screen for contacts you’ve added
this settings screen should contain (among other fields like “note” and “name”) a field “transfer limit in [DROPDOWN]”. This is how much maximum can be sent to the address from within Status in the selected currency in the dropdown. So a setting like “transfer limit 5 in DAI” means one can send only 5 DAI worth of ANY currency in a single transaction. For conversion rates, read Uniswap’s contract so you don’t depend on an oracle or third party web service.
default all non-added addresses or freshly added addresses to something like 20 DAI worth in a single transaction.
This will:
Protect all users from having their account hijacked and drained.
Protect users from clumsy payment gateway implementations by maxing out an amount they can send to a specific address.
I realize there’s a lot of implementing to be done here to make it possible: custom contact details, wallet send-amount limitations Status-wide, uniswap reading etc. but maybe something to think about for the long term to also make Status a safe-from-users wallet, not just safe-from-governments and safe-from-hacks.
What happened in the restaurant was that they used &amount instead of &value. Their QR code did have amount, but Status didn’t recognize it because of a non standard URI scheme…
Having investigated further, this is a bigger mess than originally thought. Every wallet seems to be supporting its own standard. For example, while Status is on eip 681 and opera on eip 67, trust is on a broken version of 681 and is, if 681 is used, off by 10^18. A payment provider here in Croatia shared with me a spreadsheet of up utilities now discovered discrepancies and it’s immense. Guess this particular rock was hiding a lair of demons.
Thanks for surfacing and documenting this @Bruno. You might be interested in the wallet brainstorm call we have in a few hours, invited you. Wallet brainstorm call - CodiMD
This is something we had discussed a long time ago that it’s probably forgotten or unknown to most, you can generalize this to ‘transaction rules’, not dissimilar to IFTT.
With such a setup you could provide defaults and let the user set rules for transactions, ie set upper bounds to transactions, prevent things like sending to 0x0 (i think/hope we hardcode for this) or auto-queue transactions(send to cold wallet automatiucally or send tx at block time.
We developed and have in place the transaction pool for these kinds of features, instead we tend to modal block the user demanding signature.
I have now added QR code aspects to Wallets.Review having tested several wallets extensively. The Ethereum URI ecosystem is a mess. The wallet with the most EIP-681 support is Walleth, and even that’s no full support despite being from one of the EIP authors. Status is doing rather well in this regard actually, but still not matching the standard 100%. Full post on QR code research coming soon. It’s a mess.