# ETHWarsaw 2023: David Hunt-Mateo, Request Network - Workshop

- Channel: [ETH Warsaw](https://streameth.org/eth-warsaw)
- Date: 2024-10-07
- Duration: 1:01:35
- Watch: https://streameth.org/watch/yt-xVE-AYzdhnY
- YouTube: https://www.youtube.com/watch?v=xVE-AYzdhnY

## Description

Workshop - A workshop by David Hunt-Mateo from Request Network. 

Follow us for more updates: twitter.com/ethwarsaw

## Transcript

is this all right everybody sees the screen quiet okay or you guys want to come closer maybe it's not you know it's not school you know I mean it is a school but you can come in the first row um okay so is this is the sound recorded as well from the mic recording from the mic as well right okay cool cool cool cool cool just a sec okay um hi everyone I'm Alex I'm part of request Network I handle Community Communications business development and all the fun things joining me today is David from Ohio he is our senior blockchain engineer he wishes he could be here with us but he's got some personal personal problems and he cannot make it unfortunately so we will do the technical Workshop kind of remotely I'm going to give you guys a quick intro on what request network is what we do what we also want to do and then David will take over and give you guys a quick uh tour of the protocol the easiest way to implement it and what you can build using request Network um first things first what is request Network we are an OG crypto protocol from 2017 we um we were born out of an Ico if you guys remember the uh Ico Wild West era of 2017 uh the original vision of request network was to break down the financial silos and to create uh alternative to the traditional uh Financial system so what we have done in those six years you might have heard of a product called request finance that is our biggest product our biggest player in the ecosystem it's an invoicing game payroll solution that is used by all the big crypto companies that want to payroll their employees in crypto or crypto to Fiat and it's also used by all kinds of Freelancers that want to you know be compliant be legit have an invoice to show for services so this was built in a couple of years it is now the goto solution for invoicing and payroll and in the meantime the protocol request network is building up an ecosystem involved in request Finance as well but we're building up an ecosystem that wants to cater to everybody so every category of people in the world the unbanked people the people that don't have access to Banks to loans or any service without you know all the papers without all the identity all the uh all the transactions that you have in your life the transaction history so we're looking to help those people and we're also looking to help everybody that has had problems with banks or PayPal you can think of us as the next iteration of PayPal so everything is going nice we have hired the new team recently in the past couple of months that is looking to grow the ecosystem the biggest player like I told you in the ecosystem is request Finance we have six new uh six new uh Grant recipients that are building together with request Finance at together with us and some of them maybe have heard of haa Finance we're doing uh loans or uh maybe cpra Finance who are doing uncollateralized loans so basically what means is that if you have an invoice a standing invoice in request Network you can use that future income to get the loan now it works right now you can use you can try it right now you can get a loan without having any money right now which is I mean at least for me it's pretty mind-blowing right uncollateralized loans and this is just a taste of what we can build we are eager to build anything that goes into payments into invoicing into uh accounting into Financial any kind of financial product or service that you can find in a bank we want to provide that to people and we want to provide it to everybody we want to be inclusive we don't want to be exclusive right so our our whole our whole on De our whole reason to be is to create an ecosystem this is it we we've built a product we moved on and now we want to create an ecosystem we are a foundation we are very similar to what Solana Foundation does or near foundation and to build that ecosystem we have developed a grants program an encompassing grants program that helps people bring their Vision to life and how do we do that you apply to us with a form it's quite easy you fill out the form and then you have a couple of meetings with us a couple of of uh Team validation meaning business validation technical validation and then you will get some money so that you can start building your vision we will not build it for you but we will give you all the tools that you need including support on all kinds of support other than that we can provide you with an infrastructure that's been battled tested for 6 years we've been here for six years guys and we haven't been hacked once we haven't rebranded we haven't done anything to our brand it's the same name for six years no hacks no loss of money no loss of reputation nothing so our infrastructure has been truly battle tested and so far we have uh managed to process if I'm not mistaken almost 400 million in transactions and while this may not be a big number I know but it's transactions that come from invoicing people they come from payrolls like they come from salaries they come from loans it's not it's not sort of like it's not farming you know so while it's not a big amount it's an amount that means we processed enough transactions so that we can call ourselves the biggest decentralized database of financial information so if any of you want to build something with request you will get access to data that will easily allow you to provide any kind of financial service simply because for many years people have left a financial trace on our Network and when I say Network obviously I don't mean Pro I don't mean uh a layer one I don't mean a layer two not a blockchain with a simple open source protocol you can find us on GitHub right now you can look at the repos you can see all the smart contracts we are available on 20 evm compatible chains and near obviously because everybody loves near right and to close things off uh David our our senior blockchain engineer he's going to start presenting what is a request what is a payment request what why are we called request right why is it request Network so simply because that's how we started we started by creating payment requests storing payment requests in ipfs that's how we started that's our our first step into this world we started in 2017 by adding context to transactions because when you send from one wallet to another you have no idea what you're sending other than you know crypto but for what are you buying something have you purchased something is this a service is this your monthly salary are you paying an employee nobody knows right so 6 years ago this was the first building block the transactions had context which that context enabled all kinds of use cases that I just told you about right so based on that building block David will start from there from like a quick start guide on how how is a payment request looking how do you create it how do you store it and what can you do with it okay cool I'm going to flip over to David since my microphone is not working I'm going to just give him a thumbs up hello can you guys hear me Okay cool so I haven't heard anything so far and I'm wondering if I should go into my section of the workshop one second well this is this is a challenge uh obviously I am I wasn't Mak it I wasn't able to make it to eth Warsaw today for for personal reasons but um uh we're going to try and do it remote anyways um so hi everyone I'm I'm David Hunt Mato uh I'm a senior software developer at the request Network Foundation and today I'm just going to be doing a brief introduction of uh the request Network and the basics of of how to use it and some of the capabilities it has um I believe my uh my colleague Alex already talked to you guys a little bit about um the the ecosystem that we're trying to build and the vision that we kind of have um so I'm going to move on to the next section of um talking about kind of the life cycle of a request um if there's any questions Alex could you could you um or well we we'll try to do questions at the end I think if if if Alex is able to take questions then relay them to me we can we can try to do it that way normally I accept questions throughout but I I think it'd be hard to do that in this format question okay right um so basically request is a Json blob of data really at its simplest form it's it's a it's a blob of data that describes the context for why payment occurs and typically it's created before the payment occurs although technically it could go in the opposite direction the the typical life cycle is that you start by creating the Json blob which includes the payer the paye the currency the amount and a variety of other details uh uh stuff that describes how the payment should occur and stuff that describes um any other arbitrary content data that um makes sense within the the applications context um and all of that data then gets written to ipfs um we have um our SDK and our request node that facilitates this process but at its at its core level that's that's basically what's happening the the data gets written to ipfs and as a result it creates a Content addressable ID uh this is a unique identifier for for any sort of data that's stored in ipfs and we take that c and we store it on chain uh in particular we put it on nosis chain for our real our real requests and then we put it on gorle for our test requests um so once once the data is persisted in ipfs and stored on chain we consider that the request is uh created it's it's uh it's fully formed uh forever more stored on the blockchain um and uh the ipfs allows anybody to be able to query that data at a future time the the the way that you query that data is using the request ID which is another piece of information that uh is derived from the contents of the request sorry okay Alex was just sending me a message but I'll get back back into what I was saying um oh so uh the the request ID is derived from the contents of the request and it's stored alongside the request so that um you can use the request ID to look up that information in the future there's a second piece of information that's generated from the request contents and we call that the payment reference the payment reference is not stored alongside the request and that is to create a layer of privacy for the data um the payment reference is the piece of data that gets put into the smart contracts and it uses the um it it it uses the payment reference to connect the request to any sort of payments that occur on chain um but you have to know the contents of the request before you're able to make that connection so we we generate this payment reference and we we use that as one of the input parameters on all of the different payment smart contracts that we offer um the payment reference is is combined alongside the um the amount that is being paid the um the two address the the the the person who is the recipient of the payment and the um oh now I'm going to forget it was a Oh The Token address the the the address that's you're actually the the address of the token being being uh transferred um so it takes it takes all that information and puts it into a smart contract call and depending on payment Network that we're using uh that smart contract will do a variety of different things if you're using the native payment contract then it's going to attempt to send eth or whatever the native token of the chain is if you're using the erc20 contracts uh then you're going to be sending an erc20 token if you select a conversion contract then um ERC 20s or native tokens but then it's going to be sending an amount denominated in some other currency typically a fiat currency like USD um and it uses uh onchain price feed or make that conversion at the time of payment um that's just a few of the different payment networks that we offer I'll get more into that in in a future section um but basically uh once the the payment once once the smart contract call is executed the payment is sent and the recipient receives receives the funds um oh it's also worth noting at that point there there's the ability to take fees so if the the the Builder somebody who's building on request Network wants to add a fee for processing the payment they have the ability to to input that as one of the input parameters as well and then the fee gets transferred to their own address at the same time that the paye receives their payment so the next step is all of those smart contracts emit an event of some sort and this is kind of the the key that for for us being able to detect the payments after they occur these events contain the key pieces of data that I described they include the the token address the two address the amount transferred and the payment reference which gets indexed so that it can be uh um looked up by our subgraphs in a later stage uh at this point I'll I'll mention that when you make a a payment in the in the typical case nothing gets written back to ipfs um we we rely solely on the events that exist on chain to to detect those payments um another thing worth noting at this point is that payments are possible so you're able to send half of the amount or or some smaller percentage of the full amount and the way that our payment detection works is it just takes all of the events with the same payment reference and it adds them up so that we get a total balance for for that particular request the next stage after the events are emitted is that we we usually have an indexer of some sort typically a subgraph or or a graph node um that reads those events and then tries to reformat them into a a graphql API that is uh easily queriable uh so from the subgraph we are able to count up all of the events for a particular payment reference um calculate the balance and then ultimately um pass those those data structures back up through our SDK our SDK has functions that allow you to quickly query all of the requests for a particular user or all the requests that match a particular topic or a single request looked up via its request ID um and when you make when you make that uh that um retrieval call it's going to go out to ipfs it's going to take the the data that's stored there and combine it with the data that's stored on chain the the events that that uh show the payments and that's that's basically it that's that's the that's the core life cycle of a request um I will mention that there's also a uh a step kind of in between that I didn't mention is the uh once a request is created there are a few things that you can do to update and change the this doesn't mean that you're updating the contents in ipfs that stuff is all uh um immutable and static and and and you can't you can't change it once it's written but you can append new data onto the end and so when we're retrieving a request we can look at all of the events all of the sometimes we call them events sometimes we call them uh uh transactions but in ipfs everything with the same request ID is going to be linked together in a channel and we're able to calculate the current state of that request so some of the things you can do are is you the pay can cancel a request if if they're the ones who who issued it they can they can cancel it uh the pay can also increase or decrease the expected amount the payer has the option to accept a request which is meant to be a signal to the paye that they intend to pay it um and both the paye and the payer can add third party stakeholders to the request in the case where it's encrypted so if if the request is encrypted then we have the ability to share that request with new stakeholders after the fact um and we I'll get into the encryption in a in a future section um the another thing that I wanted to mention is that um the typical life cycle that I described is is referring to reference-based requests we technically have another type of request called declarative requests and that's um that's one that is is facilitated without the blockchain it basically it it uses actions that we write to ipfs where the payer is able to declare that they have paid the request and the paye is able to declare that they have received it so if you were building an application and you want to support a blockchain that wasn't yet supported by request Network you could use a declarative payment um a declarative request to be able to represent that in your app um in the interim before we're able to support that chain similarly if you're just trying to do Fiat payments and you have like Bank transfers going on in the background you could use declarative payments to support that as well okay uh that's that's kind of what I wanted to say about the life cycle of request the the next thing that I'm going to move on to is I'm actually just going to quickly run through some of the quick starts that we have here in our documentation um this is going to go into a little bit more deeper detail of how to use our SDK and how to do those those three core actions of creating requests paying a request and then retrieving and detecting the payments of request I'll start by going into the quick start for uh the typical use case that I would see at a hackathon is is the the you're running request Network in a browser and you're trying to allow the user to use their um uh ethereum Keys stored inside of a wallet um and I say ethereum there meaning just like any any evm compatible chain if you have keys inside of a wallet this is kind of the the quick start for you um in this example I'll be talking about just uh creating an unencrypted erc20 request um if you're interested in in talking more about other more complex payment types or if you want to talk about um encrypted requests I'd be happy to talk after this workshop and and we could we could dive into the details of how to do that the first thing that you're going to need to do when you're creating a request is you connect or you you instantiate your request wait a second where did it go oh interesting I must have deleted it at some point sorry about that everybody um I'm missing a piece of code that I'm expecting right here at the top I'm going to scroll down to a separate section to get that piece of code it looks like this but I must have accidentally deleted it from the create section sorry about that um okay so the first thing that you're going to want to do is you create a request Network object and this this is callable from both JavaScript and typescript um the the you you create you instantiate this request client and you make sure to connect it to one of the um request node gateways um it could it could be a node Gateway that is being run by uh uh someone other than the request Network Foundation but as of today we we have a couple of node gateways that we offer um that subsidize the costs of of submitting uh requests to the protocol so this one that I have listed right here is the Gorly Gateway if you wanted to uh connect to the nois Gateway which is for creating real requests you would just replace this word with X die right there okay so once you have your request client I'm going to scroll back up here once you have your request client you would then need to create your um web 3 provider and today we the request Network SDK does not yet support ether's V6 but it is able to support ethers V5 or if you're using wagm or VM you have the ability to create adapters between the the the VM wallet client and the ethers V5 provider and S so you're going to want to create the provider and connect it up with your your uh whichever provider you're using using if you're if you're the injected wallet like a metamask inside of the browser you're going to want to use the web 3 provider or if you're using a Json RPC provider like uh infura or Alchemy you could uh connect your provider up to one of those instead instead the next thing that you're want going to want to do is create a web3 signature provider this is the thing that's going to interact with your wallet and request the signat is required to create the request oh here's the code snippet I was looking for um finally we create a request Network object right here and we pass in the the connection to the Gateway as well as the web3 signature provider The Next Step that you're going to do is you're basically going to create this this data object that describes what the request all all the parameters of the request it's a uh we it's a data object that contains everything about the core request info these are the things that I I mentioned earlier the currency the expected amount information about the paye information about the payer um and then there's also a time stamp in here for uh the the T the time stamp is used for differentiating between different requests that have identical contents and um internal to our SDK if for some reason the time stamp is exactly the same between two different requests then it also adds an optional non field that differentiates the two so we can see here that I've I've added a currency this this currency happens to be the the fa token that there there's a faucet a well-known erc20 faucet out there for fa U tokens um and it's on Gorly chain and I've got an amount of just one two 1,234 uh tokens or a way I I don't know how to say it but you know this is this is like the the evm compatible version of the of the units if you have to convert units from your front end you could use something like parse units from either ethers ethers or VM um the the pay and the payer are pretty self-explanatory these are the the identities of the the parties involved um I will say that the the pay described here is not necessarily the address that's going to receive the payment it's merely an identity to to um to uh submit signatures for that request and show that they belong to a particular individual the the the actual address that receives the payment is described at a lower place right here inside of the um the payment Network object so the payment Network object this is what describes the the method by which the payment occurs in this case I've said that I want to use the erc20 fee proxy contract which is a a a contract that um transfers erc20 tokens and then takes a small fee for the Builder if if they so choose um I've told it that it's going to be on Gorly chain I've told it that the payment address in this case is the same as the pay identity but it doesn't have to be and I've set a fee recipient of the zero address and I've set the fee amount to zero because I'm not taking any fees in this case finally uh down here we have the content data this is kind of the an a a section for arbitrary data uh whatever whatever you as the Builder want to include in this section you're able to um but we recommend if you're building an invoicing application for example that you use the rnf invoice format from the request network data format package this is the same format that um for example one of our Builders request Finance uses um and it has all of the fields that you would typically want for an invoice uh in this case I've chosen not to use that I've just added some information about the reason it's a pizza emoji and the due date is some date in the future or in the past I guess um finally we we we have information about the signer and this is this is part of what the web 3 signature provider does is we we tell it who is supposed to provide the signature in the input data structure and then the SDK automatically um sends the the the request over to the wallet to tell it that it needs to create a request that it needs to sign something sign a message so finally here's here's kind of the the the core of it we take that big data structure that we've just built and we pass it into the create request function on our request client object and we await the the creation of the request once once this request object is returned we're then able to wait for conf information this is the step that that actually waits for it to be persisted in ipfs and then persisted on chain either on nosis chain or on gorle depending on where you've um set your sign uh your storage location to be and then finally it waits for it to be indexed by the graph and once you get this data back you know that all three of those have been completed so all of this all of this is demonstrated within this um this code sandbox that I've created here and I've already got it open in a separate tab let's see here so this is a this is a uh it's meant to be a relatively barebone sort of demo uh obviously the CSS is not uh not the greatest but um hopefully that uh increases the focus on on just the core functionality um so I'm able to select the P identity by connecting my wallet in this in case the pay identity um is is the one who's going to sign the request technically it's possible for the payer also to be the the one who signs and creates a request but that's kind of a more advanced feature so I've I've got my wallet already connected here and I can select the storage chain that's the that's the chain upon which the request is persisted the in particular the uh the C hash of the request contents uh St an ipfs that's what gets put on chain um I in this case I'm going to choose gorle uh next you can choose an amount I've I've crafted this demo so that this is a human readable amount so I'm just going to put in one and it's automatically going to transform that into the appropriate uh uh evm compatible units the currency I've got a couple of options for currency here in this case I'm just going to use the fa token um I'll show you in my next code sandbox how to get those FAU tokens it's it's pretty easy there's a faucet out there for it but um then I have the option to select a payment recipient but I can see that it's already defaulted to my pay identity I'm going to just leave it as is the payer identity I have the option to put one in uh and I think in most cases you should put in a payer identity if if you have an intended payer but if you choose to Omit this then it makes it so that anybody can pay that request the downside to that is that um there wouldn't be any sort of automatic notifications for that you would have to use some outof band separate channel for for sending the notification to the payer to inform them that a request is pending for them uh in this case I'm I'm I'm actually just going to leave that blank um then we can set the due date these are and and the reason these are the two optional fields that I told you about in the content data so this is the this is the arbitrary data that's why it's entirely optional um in this case I'm just going to leave well here I'll go ahead and fill them in um so this one's going to be due tomorrow the reason is going to be Pizza all right so now that all that is complete I can submit this and the the data displays here are are pretty pretty basic but you can see that the app status just switched to persisting to ipfs so it's it's waiting for me to sign the request contents that's everything that uh this is the the Json blob that uh I talked about in my in in the docs just a moment ago and I'm going to sign it using my my pay identity this this 7e address i' I've named it Alice in my metamask so I'm going to ass that and we can see down here it has just returned the request after creating it and that I'm now waiting for it to be persisted on Shain so to give you context the the code has this create request call that's the part that's already already returns to me and displayed right here right now I am waiting on this later line request. wait for confirmation and um I'm going to wait until the request State changes to created and the app status changed to um request confirmed there we go okay so at this point the request has been confirmed and we can see that this big data structure has been returned to me this has a bunch of information most of it is just regurgitated of of the information that I put in when I was creating it so we can see the currency is this fa token the expected amount is now this evm compatible version of of one one token we can see the pay addresses in there the time stamp we can see the extension data that is the um that's the payment Network um we call it extension data here because uh the the content data is also considered part of the extension data so it's uh it's the content data is is located right here below it um I think all that is pretty self-explanatory so I'm going to keep moving on there's there's some some additional information here about the extensions um in this part about the payment Network it actually tries to add some additional data so it looks at the received payment amount the received refund amount sent payment amount and sent refund amount as well as uh fee amount and fee balance a whole bunch of additional information all of which I believe is uh calculated from events from the subgraph notably there's there's a thing in here called the request ID this this is the unique identifier for the request and all additional updates to the request we'll have this request ID um included in it uh continuing on down we have the state it's we can see that it's in a created State the Creator is the one who who um I believe that is the signer um we have a balance this this is an important field the balance is calculated from the events queried from onchain so if I were to make a payment and then look at this balance again I would be able to balance would would have changed we have info about the currency the type it's an erc20 the address and the chain that it's on and then there's some additional information meta information that you can look at here um notably there's the transaction hat this is one that if you go onto gorle G scan would be able to see the transaction in which your request was created so we can see here uh we are making a call submit hash um and the the information that's getting passed is we're basically taking the hash of the information in ipfs along with the fee parameters and submitting those on chain okay so I'm going to jump back to my create request um code sandbox here um the code is very similar to what we saw in the quick start so I'm I'm not going to go through it in depth here um I'll focus more on the pay request code sandbox next let's jump back here the um I'm just trying to think if I if I want to try and take questions now before moving on no I think I'll I'll batch all the questions for the end sorry everyone okay the uh the next section that I want to talk about is how to pay a request in this uh section it starts off very similarly to the creation of a request you have to create this request client object but in this case in order to pay a request you actually don't need the um you don't need the the web 3 signature provider that's that's only required for for creating the request so in this step we we create our request Network we connect it up to the Gorly Gateway and we retrieve a request by ID just so that we can have this request data object that we're going to be able to pay the next thing that going to need is again you'll need a a web 3 provider um but in this case you're going to need a signer as well so um you have to make sure that you use one of the one of the providers that that provides a signer if you try to use get default provider it it probably won't work because it's not going to include a signer for you to use and like I mentioned before it is possible to use wagm and VM with with our software you just have to have an adapter to convert the the wallet client into a uh into into a ether's V5 signer so our our package the the payment processor package offers several functions for you to be able to uh verify that a payment can go through and then submit the transaction to actually make the payment so some of the functions that we have are are has sufficient funds you can just pass in the request data the payer address that you intend to pay with and the the provider that is making the uh the onchain calls and you're able to get a Boolean of of whether or not the the payer has sufficient funds and this should work whether they're making a native payment or an erc20 payment either way then if you are making an erc20 payment you would want to make sure that the user has granted sufficient approval before you're making the the the transaction to to pay so we have this function has erc20 approval where you can just pass in the request data the payer address and the provider and it'll pass you back a Boolean of whether or not that user has sufficient approval if they don't have sufficient approval then we also have a function approve vc20 that automatically takes care of approving the approving the appropriate amount you pass in the request data the signer and then you wait for the uh two two block confirmations typically uh uh for it to be finalized um if you're on a different chain if you're on like polygon for example you're probably going to want to wait for a larger number of block confirmation simply because polygon has much shorter block times and uh larger Uncle chains can occur The Next Step that you'd want to do is you would take that same request data object and you just pass it into the pay request function this this function reads the the payment Network information from your request and executes a transaction based on those parameters so if you are doing a native payment it's going to send a call to our native payment proxy smart contract if you're making an erc20 payment it's going to send a function call to the our erc20 payment contract and then if you're using any one of our other complex more complex payment types like uh conversion or uh swap to pay or swap to conversion any of those things it tries to take care of that as well and in all of those cases you would again wait for two block confirmations before considering it finalized and finally there is a function call where you just um you call request client from request ID and you do that to look up the latest data for a request it's going to go out to ipfs and grab the latest information from there it's going to go out to the subgraph and get all the latest um events that are associated with with the uh payment reference before that request and then it's going to return to you an object that I showed you on the previous screen that has all of the different fields including the balance including the uh the U appended events in the request so that you can calculate the full state of of what the request is in um so after you make a payment if you're trying to um detect that the payment has actually occurred you would simply um pull this request data. refresh function um and that's going out to the the graph each time and and checking to see if there's new events um and when you see that the balance has increased or or is is um equal to the expected amount equal to or greater than the expected amount I should say then you know that the request has been paid in full and you can consider it paid so like the like the create code sandbox I have another pay a request here it takes a very similar structure to their creator request code sandbox but it uh includes some additional goodness at the end um before I start I'll I'll mention that um you can get test net funds to to work with this contract uh work with this code sandbox by going to either of these faucets the erc20 faucet by peppersack or the usdc faucet by block Patron that will give you the the necessary tokens to be able to interact with the two currencies that this supports and I'll just show you real quickly what those look like there's the esc20 faucet and then there's the usdc faucet by um block Patron so I'm going to quickly create a request again um this time I'm going to do 12 yeah that sounds good um fa token again the payment recipient is going to be my own address the payer identity is actually I'm just going to use my own address again so I'm going to request payment from myself uh just for the purposes of this demo you can you can put in any address there the due date I'll just set as a a future future date and the reason for this one is going to Bea e um so I can submit that just like before I get the prompt to sign it I sign the message and what's happening is it's taking that message and it's sending it off to the request node to be persisted in ipfs and then persisted on chain in this case since I'm using one of the the gateways from the request Network Foundation uh the request node is is subsidizing the costs of of creating that request oh so from my app status I can see that it's still persisting on chain and once it's persisted I'll be able to make the payment all right so we can see that the request is confirmed um I'm already connected to the Gorly chain but if for example I was connected to a different chain like nosis then I would have this button right here that would prompt me to to switch to the appropriate chain before making the payment so I can click this it'll switch me over to gorle and the next step that I would want to do is approve to make sure that all of the necessary approvals are granted um I think in my case it's going to check if I have sufficient funds and I will have sufficient funds because I already have FIU tokens um and then it's also going to check the type of the request it see it sees that it's an erc20 and then it's going to check for approval and it's going to see that I've already approved a sufficient amount um and lastly I'll be able to click the pay now button and the app status changes to paying I I can see on this metamask popup that I'm paying with my Alice wallet and I'm going to be sending funds to this address if we look at that we can see that it is the erc20 fee proxy on gorle oh I lost my pop where did it go here we go um we're also going to see that it's transferring it's transferring 12 of these tokens it's also got the payment reference that's associated with the request and this token ba6 this is the this is the fa token on gorle faucet token okay um so just to make sure this goes through quickly I'm going to click and make sure that it's set to aggressive and I'm going to confirm that transaction we can see that it is currently in the state paying and I'm going to wait for it to change to paid okay I have this little popup set to to show me when the balance has changed um but here we can see that the payment has been detected and it changes to request paid so if I scroll down in this this Json blob we can see the balance field it's quite a bit different from from how it was when we looked on the the Creator request code sandbox we can see that the balance has updated to 12 and that we can see all of the events the individual payments are are there as well this particular one paid the paid the amount in full but it's possible to have partial payments in this section as well okay um just real quickly I want to glance at some of the code that made this possible um similar to the the the docks that I showed a moment ago we can see that that that has sufficient funds was called or sorry that the it was called up here has sufficient funds was called has erc20 approval was called if I needed approval it would have called approve erc20 and then down here under the create request part sorry not create uh the pay request it's up above inside the pay request function we can see that it created a request Network object uh queried it by ID and then called pay request and then it had a while loop to check whether or not the balance had changed so let me jump back to my box here um we've kind of alluded it to it a little bit but it's uh obviously it's able you're able to retrieve a user's request the the one that I've shown predominant so far is this from request ID but it's also possible to query by identity so you can just pass in an identity address and be able to get all of the users requests I have a code sandbox here that shows what that could look like um this would be something of a dashboard page for for your users so that they can see all of their requests in one place um in this case I have it set up to look at one of my other addresses starting with 519 and we can see that it starts off with this table that shows the the time stamps for all the requests each of the different request IDs the payer the currency the expected amount the reason the due date status whether it's paid or created or pending uh and the bance shows whether or not it's been paid Ian status is derived from the balance I should say and then I also you know just for fun I just I printed out all of the different requests the raw Json so you can take a look at that if you're interested all these code sandboxes are easy to to fork and play around with if you'd like to um and they're also embedded in the in the documentation so if you'd like to try and play around with them directly there you're able to I'm just glancing at the time I've been I've been chatting for about 50 minutes now um I'm I'm gonna share a few more things and then I think I'll be able to pause for for questions the um you notied that this this this first quick start in the browser was was crafted so that um all of it relied on the signatures from a wallet basically you know private keys that are stored within either metamask or or something similar um but that's not the only way to use request Network we also have an alternate signature provider called the ethereum private key signature provider and this this signature provider is much better suited for running in scripts or in in backends that might have private keys that that that they're managing directly outside of a wallet um so this this second quick start mirrors the first one it's it's just like the browser one it has the create the pay and the retrieve sections um but instead it uses the ethereum private key signature provider to use a private key that's stored in an environment variable so if you're running a server or if you're developing scripts that you just want to try out U to to play around with the library you have the ability to do that as well we have full examples for creating a request that you can actually just copy and paste you could just copy this whole thing into a script and run it as long as you um you create a small environment that Imports these these these packages um similarly there's one that that pays a request it creates a request and then immediately pays it and then all the way at the bottom we have a small script that you can use for retrieving requests for a given user as you've kind of guessed already we we have multiple different packages in the SDK so that you can pick and choose which features you want to use the most common ones are are listed up here at the top there's the request client Library that's used for creating and updating and retrieving requests there's the data format library that has the the rnf invoice format that I described there's the two signature provider types web 3 and EPK there is a decryption provider here that uh if you want to create um encrypted requests you can do so however I'll say that right now we only support encryption and decryption using um private keys that exist outside of a wallet I think the the the ability to do all of that inside of a wallet uh is pending we we're still trying to scope out how to how to do that uh the payment processor package is for making payments and interacting with the smart contracts the request node package is for running your own request node if you want to and the currency package is for managing currency definitions all of these can be imported either as uh UMD or commonjs packages and you can use the uh the import syntax or the uh the require syntax whichever works best for you uh I already mentioned the request node gateways that we support um real quickly I just want to mention that when you're configuring your client it is technically possible to add a a uh a field here called use mock storage and that will make it so that all of the requests you create actually don't go to a Gateway they just get stored locally in your machine's memory and then they get wiped out after you uh finish the the script so that is an option if you want to play around with it and then we also have a a series of internal packages this the stuff that kind of makes the other public external packages work so this this shows all of the different data layers within our software stack okay I think I think that's all I want to say for right now I'll uh I'll open it up for questions if anybody wants to relay their questions to Alex um we can try and get those answered any questions hi David hey how's it going just one minute hello can you hear me yes yes okay uh so I want to ask uh which networks request network uh support like which chains evm chains sure okay we on over 20 evm compatible chains uh a full list does not exist or it does exist but you have to like parse some stuff to get there if you go into our our Repository I'm just going to name off a lot of them like a lot of the popular ones that that you might have heard of is is we're on we're on nosis chain we're on etherium we're on polygon we're on optimism we're on arbitrum we're on fuse we're on um uh Phantom we're on uh BSC um I mean we're on Gorly I mentioned that one already um and there's others there's others too um if if you want a full list what you can do is you can go into our our request Network repository and inside of the request Network where did it go here we go inside the packages inside of the smart contracts inside of the Source lib artifacts so a full list of all of our payment proxy smart contracts exist within this um and depending on the payment type that you want to use you're going to want to go into into that folder so the the the erc20 Fe proxy and go to index and it's going to show all of the different deployments for that smart contract we can see that the erc20 Fe proxy if I scroll all the way down is deployed on um it's on Tomb chain moon beam optimism Ronin Avalanche arbitrum arbitrum rink be Phantom BC XD or or nosis fuse it's on Cell It's on Mumbai madic gorle Rinke mainnet and then we also have an equivalent sort of contract it's not the exact same because it's written in Rust but we also support near okay okay uh I want to ask can can we support non evm chains so it is it is um it is possible to to support non-m chains and we' we've done that with near um but uh today you know non-m chains do pose a a a larger challenge to to support because it requires a separate implementation of our our proxy smart contracts so if you wanted to support for example Solana today what you could do is you could use a declarative request so instead of using smart contracts you would have the payer declare that they have sent the payment and then maybe they put in the transaction hash or something like that and then the paye can declare that they've received it um that that that could be a way to implement on Solana today using request Network okay actually I wanted to deploy on ZK sync um but ZK sync is not on your list so um Can Can we Deploy on ZK sync so for ZK sync since it is a uh I believe that one's an evm compatible one correct yes yes okay yeah so um for that one you you could go the declarative route that I just described or uh it would be it would be harder to do but you could all of our smart contracts are open source you could potentially deploy your own version on ZK sync if you wanted to um but you know it would it would pose the risk of you you could deploy it there and you could use it but there might be some time in the future when the request Network Foundation chooses to officially support it and we would deploy our own version and and try to try to support our own version for it okay yeah um thank you thank you for the question Alex is giving me the thumbs up to log off I believe all right thank you so much everyone thanks for coming to my workshop bye