These contracts are deployed to the mumbai network. (polygon test network)
Serveway manages the private key of the wallet in the App, so the user's address is managed separately from the server. However, when exchanging user information through Bluetooth, mutual transactions are made with user information registered in the server, so the server must also store the user's address information. Therefore, it is necessary to register the address information generated by the App to the server, and at this time, only the address information that owns the private key, not the address of another person, must be requested to be registered. For this function, we utilize the ERC-1271 (Standard Signature Validation Method for Contracts) standard contract. (https://mumbai.polygonscan.com/address/0x563699d8798A654ec60A8F7720Fe8a0037ce69ae#code) First, the user signs a specific message with his/her priavateKey. It requests wallet registration while passing the values of v, r, and s extracted from the signature, the corresponding message, and its own uuid to the server. Then, the server can get the signer address by making a query call to the sigVerifier contract for the received msg, v, r, and s values, and since the user's address has been verified, it is stored in the server.
Tokens were created according to the ERC-20 standard as a commodity used for seat exchange in Serveway. (https://mumbai.polygonscan.com/address/0xA6f00218efb6c0Fe4C53d01b2195e09A1E1a8523#code) Here, the permit function of the ERC-2612 (Permit Extension for EIP-20 Signed Approvals) standard is added as an extension function. ERC-20 tokens have become ubiquitous in the Ethereum ecosystem, and I think approve and transferFrom are the most important functions here. However, there is a downside to using these features. Many users do not know why the main coin (ETH, MATIC) is needed to transfer tokens, and there are a lot of inconveniences that arise here. This is acting as a stumbling block in the influx of users to the blockchain. ERC-2612 can complement this well, and was added as an extension of the SEAT token. Through this, users can transfer tokens to other users without MATIC, and even when using DEX, the inconvenience of having to transfer MATIC separately to their wallet for approval at first can be eliminated. The function to transfer tokens without MATIC will be implemented with a daily limit (5 times) per user, which can be changed later.
The zkp function has been implemented so that users can prove that they belong to a specific group (age 65 or older, gender, etc.) without exposing their sensitive information to the outside world. (https://mumbai.polygonscan.com/address/0xDA218c923bcA169169D4aD0576653a223a3A4E04#code) To do this, a notice must be given to the App first so that users can request registration if they belong to the group. In the request method, the user signs a specific message with his private key and sends his address and sigMessage to the server. When a request comes in to the server, the server determines whether the user is valid for a known group based on the registered user information, writes the user's address and sigMessage as a tuple in the circuit, and creates zkp. The users registered here are separately managed by the server, and after distributing the zkpVerifier contract, the wasm file and the final_zkey file are provided to the registered users to download so that they can create their own proof. Then, users who requested registration have the right to request the above file after a certain period of time, download the file, and generate a proof through their own address and the signed value of the specific message created at the time of the first request. You can prove it without revealing information. The zk protocol used is non-interactive zero knowledge zk-SNARKs, and the snarkjs library was used.