build a proof of concept of payment for conferences

[guylouis]

we are being asked often to use this technology to enable payment on crypto conferences with keycards

one could build the full system as a proof of concept with the tech from this repo

Status browser feature to support card taps has not been maintained so best route would be to build a POS app instead

One can consider using Status L2 since it's gasless!

[vpavlin]

This obviously keeps coming up, but I am thinking whether this is something we want to encourage - isn't it the same thing as if e.g. Ledger suggested "to pay, just plug in your HW wallet to a random computer"?

I explained to people who asked that crypto is different - you only tap/insert your credit card to the terminal because you trust a) the terminal vendor to not fool you b) your bank to revert the TX in case someone actually does. The benfit of using crypto is that you don't have to trust the other device - all you need is an address (or some other info to construct the TX) and then tap/sign the TX and send it from your - trusted - device - no need to tap someone else's

With Keycard Shell it would be slightly different as you could review the TX and only show the signature QR and then the POS app could submit it on chain - but with gasless Status Network not even that is needed and you can easily submit it by yourself eliminating a lot of risk and trust.

I am no sure whether it is a better approach to give people what they ask for or use the opportunity to educate them why that would be dangerous:)

Let me know if I am completely wrong:D

[guylouis]

You're absolutely right and that's the whole point of this repo. It shows a concept of payment network where the terminal doesn't need to be trusted (or not fully trusted which means that the risk you take by using it is capped programmatically by a smart contract).

To be clear, in this payment scenario it's not the main keycard applet which is used, but keycard cash applet (which is present on every keycard we manufacture) and which uses another keypair and doesn't need a PIN or secure channel to operate.

In this proof of concept the scenario is like this

• a merchant runs a point of sales as a dApp on status app (this should be revised since status mobile browser - which had a js api to accept taps - is not being maintiained)
• a user taps his card
• no PIN is asked
• the user funds are on a smart contract wallet that holds stable coins on a fast and low gas (gasless :)?) EVM chain. This smart contract only accept transactions below a treshold that the user defines himself

Not everything is resolved for now especially in terms of UX, but building small scale concepts using this tech will advance building a broader system