The problem Crypto PoS solves

There are QR-code based services to speed up transactions, but sometimes scanning QR codes can be tricky. Taking inpiration from Web2 finance, I developed a contact-less-based crypto payment service. In this way the data is shared using near-field communication (NFC). I implemented two different protocols:

1. Card emulation mode: this is the exact opposite of how a credit card works. In this case, the PoS will share address, chain id and amount with the phone, that will then process the transaction. The PoS will then listen for on-chain transactions before confirming the payment (I'm using BlockScout's API for this)
2. Carrying around the phone can't always be convenient. Having just an NFC card to tap-to-pay is much more convenient (and battery-free). That's why I developed a smart contract that lets users to fill up a balance and every time the card is tapped part of the balance will be moved from one account to the other. This smart contract is not secure. Since my NFC card is not a smartcard, I can't sign the transaction, so I'm basically sharing my private key with the PoS. The only way to make this smart contract secure is to develop a custom smartcard, but this is not easy since the technology is proprietary by NXP.
   To make tax declaration easier, I'm using DBForest to store all transactions and zkverify to create a zero-knowledge-proof of the whole money transfered, this way I should just tell the government "I handled X money and this is the zk proof of my database containing all transactions".
   I currently support Optimism Sepolia, Ethereum Sepolia, Celo Alfajores, cUSD ERC20 (on Celo Alfajores) and Zircuit Testnet for making transactions.
   The PoS chooses which chain and price and the phone will automatically switch to the right network. In case I pay via Ethereum Sepolia, I will also display ENS information, so that the PoS can be fully trusted (if I see the wrong ENS I know something has been compromised).
   Invoices can be created using Request Network.

Challenges I ran into

Implementing noir was tricky. Thankfully the mentors have been really supportive and I have been able to deploy a working solution. The only "workaround" I had to implement is that this kind of zk-proof is really complex: it compiles a rust code into a circuit (similar to VHDL for FPGA design), so all types have to be of strictly rigorous sizes. The problem is that to store a transaction hash I need 256 bits, so I had to split the hash into 8 different parts to be able to make use of zkVerify's technologies. I also had some issues compiling a cli tool needed to generate the zk-proof, basically my computer runs Ubuntu 22.04 and the only operating system able to compile that tool is Ubuntu 24.04. I solved using a Docker container.
Another problem I ran across is that the NFC reader I bought (just before leaving to Poland) doesn't natively support card emulation mode. To get it working was a lot of pain and a lot of low-level codes to be sent through PCSC protocol.
The last issue is the smart contract part, which currently is not the safest possible idea. I still chose to deploy it to have a backbone of what future developments of this project can look like. In the repository I also put a more complex smart contract that is trying to do asymmetric encryption (similar to credit cards), but since I ran out of time I couldn't implement it. My idea was to generate the challenge, then sign it using a Python script and use my phone to write the signed challenge on a tag before scanning it and sending such information back to the smart contract (those operations can be handled directly by a smart card, but I currently don't have an SDK for them). The problem I faced was that not all ECDSA functionalities are available in Solidity and that key size in Python and Solidity are different, thus increasing complexity when having to check for digital signatures.
I also had problems with ENS, since I'm using raw HTML for my web app and all examples are made for React or TS.