# Day 12: Requesto By [Bharatharaj Babu](https://paragraph.com/@bharatharaj) · 2022-09-27 --- Updates since my last post: --------------------------- Hey, so it’s been a while since my previous post (14 days to be exact), but I’m still going to call today as Day 12, as I plan to post for a 100 days about my web3 journey.. Since my previous post: * The Merge has happened successfully, and Ethereum has migrated to POS * I’ve minted my Proof of Merge NFT - check it out here → [https://opensea.io/assets/ethereum/0xf4dd946d1406e215a87029db56c69e1bcf3e1773/1](https://opensea.io/assets/ethereum/0xf4dd946d1406e215a87029db56c69e1bcf3e1773/1) * I’ve shipped my product for the ETH Global hackathon and just made my submission yesterday, more on this below. My First ETH Global Hackathon ----------------------------- Hey, so this was my first ETH Global Hackathon and went really well but a bit tight. It started out with me attending all the workshops and trying to understand what each protocol does. After the workshops, I decided to brainstorm some ideas with my teammate. The first idea that we had decided to go with was a payment platform for offline retailers using crypto. Our idea was that we could have a QR code for each retailer who registers in our smart contract, and when the QR code is scanned, the user could pay with any crypto or token they wanted to straight to the retailer’s wallet. But we faced a lot of issues with this idea, mainly with the fact that no retailer would be willing to accept payments across a wide variety of cryptos, and would mostly want his income in the form of stable coins. We then started looking at methods to swap all payments that come in through the QR code into USDT / USDC, but then we realized it would get too complicated while supporting multiple chains - ex: single qr but you could pay through btc or eth etc and finally the crypto would be swapped and sent through the user. So after a while of discussing we decided to go with a new idea - Requesto. * * * The Final Idea - Requesto ========================= ### 1) What is Requesto ? Requesto is a platform that provides a gateway for web3 requests. Using Requesto anyone can send requests to any EVM addresses / ENS Domains / Unstoppable domains for crypto or NFTs and can fulfil them straight through the platform itself. ### 2) Motivation behind the project The motivation for going with this idea came from the fact that I realized there was no way of sending payment requests or NFT requests in web3 very easily. And requests play a major role in a lot of transactions. For example: a content creator could request for payment after completing his service which could easily be fulfilled within the platform. Further, this also would help in invoicing where after a service, a user could send a request along with the invoice of payment as a request to the payer, who could then pay it straight through the platform. ### 3) Any chain, any crypto This was also a major point kept in mind while developing the platform. Our platform would support anyone to send requests in any chain and any crypto, which could be paid straight within the application by the receiver of the request. ### 4) Keeping simplicity in Mind The other aspect that was kept in mind while developing this platform was simplicity. It must be very easy for anyone to send requests to any address / domain. With this in mind, we designed that our application would only take 3 steps to send requests - be it crypto or NFT requests. ### 5) The Main Issue that we faced Integrating NFT requests was a major issues that we faced. **With NFT requests we were able to do the following things:** * You can request for a NFT from a given address / domain using the contract address and token ID of the NFT in the supported chains. * Once the contract address and the token ID is entered, we validate whether the address from which where you are trying to request from owns the NFT or not - which is done using the NFT Port API. * After validating that the receiver of the request owns the NFT, we fetch the NFT metadata - i.e the image url is shown in a modal along with the marketplace links so that the request sender can validate the NFT before sending a request for it. * Once the request is sent successfully, we had a problem of how to fulfil the request from the receiver’s end. * This issue was that the contracts were not uniform across all requests. One function could be an ERC-721 or ERC-1155 etc. And since some NFTs are soulbound, we dont even have a transfer function in them. * We faced an issue in deciding how to call the transfer function in the contract to make the transfer of the NFT possible. This was easy to do in terms of crypto requests - because in crypto requests we would just use the ethers library and send crypto using the value field in the send\_transaction RPC call. * We tried using Etherscan’s API - it returns us the ABI of the contract if verified on Etherscan. But even using this ABI, we were unable to instantiate the contract to call its functions - it kept failing for some reason. * Finally we decided on a temporary solution as we were running out of time - so when a user receives a NFT request and they would like to fulfil it - we would make a call using the Covalent API to check if a user owns the given NFT and if the user does - they would be redirected to the NFT marketplace where they could make the trade. ### 6) But now after thinking about it, we kind of have a solution in mind: We think we can solve this through a smart contract. Instead of trading or exchanging the NFT in a marketplace and paying the marketplace fees, we would do something like this: * Have a smart contract where the user would deposit money to purchase a NFT, here the NFT details looking to be purchased would also be recorded on chain. * Now when the seller of the NFT has agreed to the price, he would call a function in the contract along with the price as a parameter and would also supply the NFT. If the price matches and there is an order for the NFT, the NFT would be transferred and the seller of the NFT would be able to withdraw the money - this would all happen in a single transaction. * Here, we would also have a timeframe - after depositing the money if the user doesn’t receive the NFT, the NFT owner would somehow need to face a penalty * And if a buyer who placed his order by paying for the NFT withdrew / cancelled their order - then we can debit a certain cancellation fee and return the money. * Here, a smart contract would need to be deployed on each supported chain to handle NFT requests with pay & transfer. ### 7) How are the requests free ? So, it didn’t make sense to charge for sending payment or crypto requests so all requests are stored off-chain to prevent any unnecessary charges or gas fees. But how do guarantee the immutability might be the question - So for this, we are storing all the request data onto IPFS along with the private key signature of the request sender. The signature of the message is verified in the backend before sending the request, and the signature is also made visible to all the users to verify that the request data was not tampered with. All the IPFS CIDs are stored off-chain in a MongoDB database. ### 8) Request Notifications All the request notifications are handled by the EPNS (Now PUSH) protocol. Users can get notified of all their request updates - the request acceptance, rejection, and when they receive a request. Since EPNS is a chain agnostic and platform agnostic protocol, it enables the users of our Dapp to send notifications straight to the receiver’s mobile phones. Also since EPNS is a user-centric protocol, when a user connects their wallet to the website, they are asked to opt-in to the Requesto channel to receive notifications to their wallet address. ### 9) Unique Payment Link / QR Basically each request is assigned a unique payment link / QR code which can be shared to the request receiver upon which the request receiver can pay the sender of the request through the link. Another point to note is that the unique link can only be accessed by the receiver of the request (i.e it cannot be accessed by anyone else) by connecting their wallet to view the request. ### 10) Multi login / Multi Domain Support Login with multiple wallets or even with Unstoppable. Send requests to ENS domains, Unstoppable domains as well apart from regular wallet addresses ### 11) Batch Requests Batch requests are a feature of crypto requests that let you request from multiple addresses / domains at once. Using batch requests, you can request for a given amount all at once ! ### 12) Future Plans Plan to take this further, add support for almost all the EVM chains and also add the ability to request and trade NFTs P2P through this platform without doing it through a marketplace. Once added support, a major thing to discuss would be how to secure the platform and prevent requests from being spammed across the platform. Looking forward to seeing how this goes ! * * * Check Out the Platform ! ======================== ### Website / Live Demo Link: * NFT Requests on Ethereum & Polygon Mainnet * Crypto Requests on Ethereum & Polygon Testnets (Goerli & Mumbai) [https://requesto.netlify.app/](https://requesto.netlify.app/) ### Showcase Link: [https://ethglobal.com/showcase/requesto-crypto-and-nft-requests-vosbz](https://ethglobal.com/showcase/requesto-crypto-and-nft-requests-vosbz) --- *Originally published on [Bharatharaj Babu](https://paragraph.com/@bharatharaj/day-12-requesto)*