[English]Exploring Request Network: Decentralized Payment Requests(去中心化支付系统)

Transcript

okay okay now uh wait a minute people are rushing in okay okay let's start uh hello everyone uh I'm Kelly from dep learning we are designed for developers with basic skills to step into blockchain D development where they can get close to defy nft Dow crypto projects we hope we could not only give Junior developers an executable and simplest blockchain D learning role map but also present Advanced developers with a platform for communication and

cooperation today we're so honored to have divid from request Network to give us a sharing about request Network now let's now without further Ado let's welcome David to now hi David hello everyone um thank you so much for for the intro um like like you said I'm I'm David um I also go by mantis clone online if you ever see that um and I'm a senior blockchain engineer at request Network and uh so what I'm going to talk about today is um just kind of an introduction of what request network is uh I'm going to do um a little bit of intro on um the

technologies that we're built on top of uh I'm going to talk a little bit about the ecosystem that we're trying to build and the typical use cases that we think that request Network could be used for uh and then from there I'll dive a little bit more into some of the the way the architecture and the way that our protocol Works under the hood um and then I'll cap it all off with some information about our our grants program um as well as our our upcoming we're we're we're planning to to expand the team in in the near future so I'll talk a little bit about that um let me share my screen so you guys can see what I'm looking at let me know when you can see it it should be a picture of just Rick

West Network's logo yes it's clear oh perfect perfect and then I'll just move this out of the way ex excuse me um okay so yeah uh request network uh what is it first of all uh request network is a protocol for storing payment requests um it solves the core problem that um blockchain transactions when they when they're sent from one person to the other um they're missing context about why that payment occurred uh we can see that the person who sent the funds and we can see the or

rather not the person but the address that sent the funds the address that received and the amount in the currency but we don't have any idea of like was this a payment uh that had a due date uh are are there deeper identities involved here what were the line items that that the was actually being purchased or sold what was this payment for um and so that's that's what we store in request Network we we provide a a stack of of decentralized Technologies to make that additional uh context possible um and so what would you want to build with with a primitive like that uh we we imagine that there's a few different uh use cases that that this uh concept

would lend itself well to and those include on the input side the the accounting apps invoicing apps or payment apps um these are the types of apps that create invoices or create requests that that they're they're interfaces for end users to go in and and um um look at their own identity look at all the requests associated with their own identity but then also create new requests to other identities where they say I I want you to pay me uh 5 usdc or or 10 eth or something like that um and then on the on the read side on the output side um we have a variety of other apps that would probably want to consume that sort of data the the

additional context that users are storing this could be used for um excuse me this could be used for for risk assessment in the creation of a credit score um a protocol would probably want to be able to uh read whether or not a user is paying all of their invoices on time before the due dates that's something that would feed into a credit score um this would also be interesting information for liquidity providers somebody who's trying to do or or lenders lenders lenders and liquidity providers because they need a way to to underwrite their Investments to to to to try and figure out if the if the payers in the interactions are likely to pay in the future so that they can they can

properly assess the risk associated with with um lending uh we might also see this for for insurance protocols or for fundraising protocols who would also want to get that sort of underwriting information uh we also imagined that this sorts this sort of context to data would be useful for automated compliance tools or automated auditing tools or or um automated tax reporting tools or or or even just Personal Finance Management um this the invoice information that is stored in inside a request Network could be used to power parts of these other apps of course they they would pull in data from other sources as well but um we're just one piece of the puzzle so as you can see this our our

our stack what it what allows is uh it creates like a standard a standard data format for um other projects to store uh payment information and then for other apps to read it so so we believe that our system creates a kind of um uh more ownership for the end user we we we believe that that it allows them to take ownership of their financial data and and grants them the choice to um use the platforms that work best for them uh they they can they can use One invoicing app in our ecosystem for some amount of time and then maybe they

decide that a different invoicing app has a better user interface or or has better um support or better it looks better or whatever whatever you know floats their vat um they could take all of their in data from the original invoicing uh platform and Port it into the new platform seamlessly using request Network as a shared data storage medium um so from there you're probably wondering what what makes all of this all of this work um and the the short answer is that we're we're basically built on top of three primary Technologies we we use Smart contracts for um storing our uh hashes of our data so that it there's there's a permanent

record that the data was stored um we also store the actual request contents inside of ipfs excuse me um we use the graph uh subgraphs for for indexing onchain events and then we use another set of smart contracts for for um payments basically it's it's just a thin wrapper around a typical transfer with the exception that it it adds an event that can be indexed and tracked by our our payment detection system and so that's that's kind of what you can see on screen here um there's there's a few primary uh operations that request Network supports you can create a

request you can in the middle here you can update a request it's not shown on this diagram but it is possible to update requests after they're created um you can pay a request and then uh uh uh and then finally you can retrieve a request or detect a payment uh um after after the payment's occurred um and this this diagram in front of you kind of shows you the life cycle uh by which that happens uh when you're creating a request you would create like a a blob of of Json data and and the core pieces that would be in there include the payer identity the pay identity the currency that you're transacting in uh and the amount

the expected amount that should be paid and so once you have that data kind of formatted you would want to uh use our SDK to you you would just call a single call like create request but what that does under the hood is that it writes your data into ipfs and then it takes the content ID the content addressable ID from ipfs and it writes that on chain uh uh our store smart contracts are deployed on a few different chains but the primary one is is nosis chain that's that's kind of the canonical place for for writing these hashes to show that a request is in fact valid um we also have a couple of test

net deployments on gorle as well as sepolia um and then one of the things that um is included in the ipfs data is something that we call a request ID and that's a unique identifier for later looking up look looking at the that that particular request if you wanted to look it up by ID you would use the request ID but uh along with the request ID oh I should mention that the request ID is is U it's it's derived from the contents of the request so if any piece of data within the request changed then the ID would be different as well so uh uh another piece of data that's generated out of this is is

something that we call a payment reference and a payment reference is very similar to a request ID um in in the fact that it uniquely identifies a request but it's different in the way that we just we we don't store it inside of ipfs it's not something that you can look up the request by instead a payment reference is something that is used in the payment stage um the payment reference is derived from the contents of the request the same way the request ID is but uh it's a it's a one-way hash so you can't you can't go the other direction and and what that does is when we when we pay the request we use the payment reference as an input to the smart contract call and inside the smart contract when item

emits the event that allows us to detect the payment it includes the payment reference in that event and that's kind of what ties the payment to the request in ipfs uh so I I I I I kind of talked about it a little bit we we have the ability to pay a request through one of our smart contracts um and I'll just say at this I I'll explain it more later but for now I'll say that we have a lot of different um payment smart contracts available there's there's a variety of different payment types that I'll get go into more in detail later um but so so when when the payment occurs the the event is emitted and that event contains a few key items including the the currency that is being

transacted the recipient of the of the payment the amount that is being paid and the payment reference uh that gets indexed so that we can um we can index it inside of our subgraphs uh we have a payment subgraph that that um will track all of the different payments that occur against a particular payment reference and um by doing by by allowing multiple payments we we we basically allow uh uh partial partial payments for request so when you're when when the payer is paying their request they can they can optionally pay um increments smaller amounts instead of the full amount if they s choose

um so uh the last thing that you would want to do is that you're able to retrieve a request as well as detect a payment and what that involves is kind of you simultanous queries to do two different parts you you you look into ipfs to get the request contents and then you ask the graph to give you the current balance the amount that has been paid towards that request so far and then the our SDK will will merge those two data pieces together and pass you back a Json object that that has all of the information merged together and that's kind of the whole life cycle uh you can imagine with the retrievals you could build a dashboard page that shows all of the different invoices associated with a particular

identity uh for the payer request you could have like a payment page with a button that says pay pay now or like pay amount and you can have like a a field that lets you select the amount and then the create a request you you could imagine that um because there's many different payment types uh there's many different configurations when when creating a request and I I'll dive into those a little bit more later excuse me um how am I doing on time I think I've got I've spent 20 minutes so far how long is this presentation again hey sorry D I have a question oh yeah sure uh can you can we get the the uh our data from uh the graph and think why

need we put the data on ipfs I think you can get all the data from it the graph do you think so so yes yes so um our we have a storage subgraph that indexes our our our um simultaneously it it indexes our our hashes that go on chain as well as the data in our ipfs cluster or our ipfs Network so um it uh yes the short answer is yes if if the request is unencrypted if it's a non-private request you would have the ability to use the subgraph directly to uh query the data um that said uh our our stored subgraph today is not um we're working

on getting it publicly hosted somewhere but for right now we we don't have a public link to it uh so in the meantime you would have to use our SDK to um access the contents of a request but but that is something that we're working on fixing in the future oh okay I see does that answer your question yes I see thank you perfect thanks excuse me um okay so uh the next topic that I want to talk about is is kind of the the idea of a request node and the our request Network SDK and how those two kind of operate together

um the request Network SDK is a is a compilation of a variety of different packages that are are are purpos built for different different use uh uses in our protocol um but but it's it the primary two that you would want to focus on are the request client and the payment processor basically the request client has high level functions for creating requests as as well as retrieving requests and then the payment processor has the the lower level functions for paying a request requ EST some of which are integrated into the request client but others of the more advanced ones you have to go to the payment proc processor directly um and it is possible to create a request interact directly with the

smart contracts interact directly with ipfs all through the SDK from the front end from from a client side um that is possible however what we've seen from our Builders is that uh to ease the user experience many of them would prefer to take care of some of the some of the signatures and operations on the back end um and so what we did was we created a something called a request node uh the request node takes care of persisting requests uh and retrieving requests for you and it also provides a way to uh for the for the platforms for the builders in our ecosystem to subsidize the costs

of creating a request on behalf of the end user and so that's that's kind of two of the the the main reason why the request node exists is to kind of offload some of the persistance as well as uh offload the costs of of persisting the protocol fees but so basically you would use the request client to create and retrieve requests you would send messages to the request node uh the request node will then talk with the request network ipfs network um it will persist requests and retrieve cids um then the our storage subgraph is going to be able to index new documents inside of our request ipfs Network as well as index

events from our storage smart contracts on nosis chain and it returns all of those pieces of data back to the request node um the request node also allows you to um query data from our payments subgraph and we we have a separate payment subgraph for for each chain um and it serves as kind of a a an indexing layer on top of the the the payment smart contracts that that we use to execute the payments um I think I I think the only thing I want to mention here is that the there's the uh you probably guessed that that I mentioned that there is a protocol fee

and and on that topic I'll mention that we have a a wre token our req W token um and the role that that plays in our ecosystem is that uh it costs a small amount of wreck every time a request gets created and technically uh our since our storage is on nosis chain uh we actually collect the the protocol fee in in xdi um and then the XI gets bridged to main net swapped for wreck and then the wreck gets burned and and so you can guess B the based on that tokenomics scheme uh the W token its primary value proposition is that it it prevents spam and it it is a

deflationary token so the the total Supply is kept and every time a request gets created the total Supply decreases and that drives value to the other tokens um You probably heard me say earlier that um if if you want to read data out of our storage sub gra um it would have to be unencrypted data uh Public public requests um we imagine that that is probably the easier option for Builders to implement but not necessarily the the end goal we assume that most of our Builders are probably going to want to implement private requests at some point because the typical end user doesn't

want all of their invoices to be um entirely public uh you'd rather have the the line items and the identities of the individuals involved to be uh private so what our our protocol supports is is the ability to encrypt and decrypt the contents of a request before it gets written into ipfs um and the way that we do that is actually very similar to https if if you're familiar with the https protocol um basically we have like a channel key that that encrypts the contents of the data this is an A A symmetric key meaning that it's the same key for encrypting and decrypting um and the reason we use a symmetric key for that is because the the encryption operations

are are relatively cheap to execute in terms of processing power whereas uh uh asymmetric encryption is much more costly um but so once we have the encrypted Channel data we then take a copy of the channel key and encrypt it with each of the stakeholders public keys and so uh we we write that encrypted Channel key alongside the encrypted data uh by doing that that means that anytime uh a stakeholder of that request later retrieves the encrypted data they can use their private key to decrypt the the channel key and then they can use the channel

key to decrypt the contents of the request and so uh this the image on screen right now is showing the encryption side and um here is another image that shows the decryption side we can see that the stem number one the user uses uh that they they retrieve the encrypted AES key they use their private key to decrypt it they get the AES key and then the AES key is used to decrypt the contents of the request and we can see the request contents returned to the user here okay um that was actually the that was that was all of the um the lower

level um uh description of how the protocol Works um what I'm going to do next is um what do I want to do I want to talk about I want to talk about some of the um the different payment types that we support I I I had mentioned it earlier in the presentation and um I actually don't have a slide for it but uh what I'm going to try and do is I'm going to show you our docs real quick can you ever everybody see this well enough how do you guys feel about dark mode I could switch to light mode if you prefer uh I think it's good it's good okay um okay I'll go back to dark mode because that's that's fine okay so um right now what I'm I'm on our supported

chains page inside of our docs and the reason I want to show you this is It's because it it shows a lot of the different payment types that we support so um you can imagine when you're making a payment there's a few different variables that that can come into play you might be doing a native token payment so on on ethereum that would be eth or on polygon that would be uh madic um or you might be doing an erc20 transfer that's those are any of the other tokens that are built on top of uh the native chain um those are kind of the two very very basic types um but there's uh there's other types that we've come up with um one of them is is what we call uh like a we can't see it

very well here but it's a conversion payment I can't get it to wrap any better but um a conversion payment is something that we um uh uh we basically denominate the request in one currency but the payment is actually settled in a different currency and so what the the common use case for this is that um invoices are typically denominated in some sort of Fiat value because that's what accounting systems typically rely on uh so I could create a request for USD but then the the actual payment could be executed in usdc and the way that we implement this is with a a onchain um price feed Oracle data

feed by using that data feed at the moment of payment we can do a price conversion and ensure that the end user the the paye receives exactly the amount in USD or they they would receive an amount of usdc that equals the value of the USD that they requested does that kind of make sense uh that's that's one of our most common um payment types because like I said it it plugs in well with the existing uh accounting World on top of that we also have the ability to do batch batch uh conversion payments so and and this this particular type uh this includes um other the basic

erc20 and uh uh um Native payment types as well so you can batch a variety of different payments Al together in one single transaction that's super useful for pay payers who are going into their invoicing platform and instead of paying each invoice with a separate transaction they can just initiate a single transaction to pay all of them at once um we also have a few uh more interesting payment types we we have a swap to pay um this one is uh uh this one allows you to execute a swap immediately before sending the final token to the to to the paye um I think that one's pretty self-explanatory um I'll move on to the next one we also have a swap to

conversion that kind of compa uh uh combines the previous two you would execute a swap to a cryptocurrency but then the invoice is still denominated in USD so uh the that would be if for instance if somebody wants to pay die but the recipient wants to receive usdc but then they the invoice is denominated in USD uh so the the swap to conversion is what would support that um here's another interesting one we we support something called transferable receivables um and uh that's a fancy way of saying like a an invoice nft basically what we do is we take our our request contents uh uh

rather we we we create the request in ipfs but then we create a reference to it as an nft on shade and this nft is uh it has a a contract call on it called um pay owner um so basically whoever holds the nft is the is the uh address that will eventually receive the payment and what that allows the the paye to do is they they could they could create this request um and and it it becomes a representation of their future income but then they can use that as collateral to lend against so that they can have income today instead of waiting 30 or 60 or 90 days for their invoice to be paid um in certain parts of the world they

call this operation in uh invoice factoring or invoice financing um something along those lines um so we we think that's a really cool use case and that's why we believe that uh lenders uh can be a a a major part of our ecosystem as well uh we also have an escrow so if uh uh if you're familiar with escros it's like uh it flips the pay Paradigm on its head instead of the instead of the paye requesting funds and then the payer sending it directly the payer hosts funds into an escrow to show that they are ready and willing to pay and then the paye you know does whatever work or provides whatever service and then uh the escrow pays the the paye when when

the work is completed um so we we have an escrow contract that that we support on several different chains um and then I'll I'll skip the rest of these the rest of these are kind of our more primitive contracts but those the the the ones that I've described are kind of our major uh payment types um there's one that I skipped uh one more uh we we also support uh superf fluid streaming so if you wanted to create a request for a super fluid stream uh and then the pay would receive a constant stream of of uh of um of tokens every uh every block then that that is something that we support as well uh but the the reason it's not listed on this page is because we we

just use the superf fluid smart contracts as is without much modification okay uh jumping back to my my presentation uh I I I I already I have a slide up on on screen right now that's basically just a link to our docs uh you can see it here and I'll I'll I can I can send out these um these slides after after the presentation if you guys like um you can find all sorts of great great stuff in our docs uh basically a lot of the stuff I talked about today is in our get get started section but we have um more in-depth U references to our our our SDK we also have several guides about how to do various things in our protocol um and we we uh even have a an FAQ page that's

that's what I want to talk about next so there's there's a bunch of things about our protocol that people typically gets tripped up on so if there's anything that you're that you're confused about our FAQ page is an excellent resource to try and learn uh uh what what the mistake or what the um what the confusion might be um I encourage you guys to check it out and um what's my next slide [Music] um oh here uh there's one more thing that I wanted to do before I I move on to the end of my presentation uh we have a we have a quick start and um the quick start um shows you the basics of how to how to set up uh create a request pay a

request and then retrieve that request from request Network um and all of it's kind of uh I can I can dive into this you guys you guys are a relatively technical crowd right so I I'll dive into this um basically when when you're creating a request um you would want to start by uh instantiating an ether's V 5 provider um uh we also technically support WGME or VM on the creation side but when it comes to payments uh for the payment side we we have to have to use the ether's V5 for now we're working on on getting up to date with some of the

other more popular libraries um uh so basically you would you would create your provider and you would inject that into what we call a web3 signature provider and this is this is a an object that's basically um going to allow the request Network SDK to pop up the little you know metamask uh uh popup or whatever other uh uh uh popup that that that you're configured with um uh we're compatible with like if if you use wag me on this stage you could um you could uh use a variety of other different wallet providers as well um but that's that's what allows you to sign the contents of the request before you create it that's that's what attributes it to the the person who

creates the request so once you have your web3 signature provider you would inject that into a request Network object and uh like I described before the typical use case is to connect that to a request node Gateway um and we have a we have a page here in our docs that has the links to both of those we've got one on gorle right now and one on um nosis chain um and so once you have your request Network object you would craft the the creation parameters um I kind of laid this out in my life cycle diagram earlier you would you would set up the currency you would set up the expected amount in machine readable units you would have the paye identity the payer identity optionally that you don't necessarily need that um

and you would have the time stamp in there as well and then some of the uh some of the other pieces are the the payment Network this this parameter is what defines the way that the payment is going to be executed in this case you can see it's using the erc20 fee proxy which is basically uh a simple erc20 transaction that takes an optional fee on the top and and sends it to some address um uh we can see here that the payment address this is the address that will actually receive the payment and it's important to note here that the payment address is not necessarily the same as the pay identity address they are both ethereum addresses um and they can be the same but um we we we

differentiate them so that you can have a single identity to which all of your requests are associated that's that's your identity but then you could potentially have multiple addresses that you receive payments on so that's that's the the reason for the differentiation there um we also have a field in here for Content data and that's that's an arbitrary data piece that that you could put any any piece of Json data into um this is where you would put the stuff like you know uh uh information about the p or the payer like their address or their tax number or or you could also put in um line items if if you're building an invoice or if you're doing um uh something that has a has a due

date we would recommend putting a due date in there all of that stuff would go in the content data uh we actually have a standardized invoice data format that we re recommend that people use because it's uh it's used by request Finance one of our largest Builders and it's uh it's it's really got pretty much everything that you would want in an invoice um um and then finally we have the signer the signer is the one that is that is attesting that this invoice contents is correct and it's going to be either the paye or the payer and so finally that there's a simple U function in there in our SDK called create request you're just going to take these parameters and pass it into it and it's going to pass you back

a request object um and this request object is not necessarily finalized when it when you first receive it there's another uh function you'd have to call uh wait for confirmation uh and and this is what's going to wait for your your ipfs data to be written it's going to wait until the the CID is written on chain and it's going to wait until the um the onchain event is indexed by our storage subgraph and once those three three things are um finished you'll receive a a response from this from this method and so I've got I've got some code sandboxes for for doing this it looks like my my my create one might not be working right now but I'm hoping that my pay request one is um we'll keep on

scrolling down here the the the payment side is very similar uh we're going to create uh a connection to the request node Gateway um we're going to retrieve a request by ID uh we're going to get the contents of that data that's what this get data thing is and that's just a it's it's not actually making a a call it's it's just unwrapping a piece of data uh uh locally on the client side um but then once you do that you you you get your ether's V5 provider again um you would check that the user has sufficient funds before they they try to attempt the payment uh then if it's in the case of an erc20 you can um you can check for erc20 approval and and these

two functions right here has sufficient funds and has erc20 approval those are just convenience functions that are SDK supports um obviously there's many different ways that your projects could build this uh functionality you don't have to use our SDK for this but you know it makes it easier um and then finally we have this pay request function and this this high level function basically just takes in the request data figures out the appropriate payment type and then sends the um transaction to the appropriate um smart contract to execute the payment and so this this this highlevel function makes it really easy to execute whatever payment the the user is is Desiring if it's a batch payment or if it's a um uh a conversion payment or a a erc20

payment it'll it'll just figure it out and so finally you can um uh what we have is this request. refresh function um when you're waiting to see if a request has been paid you would basically just pull that function and when when you see that it is uh uh the the balance uh exceeds the expected amount then uh that is your indic that the request has been paid uh you can tell that this is a very flexible sort of way of doing this the balance could be less than but less than the expected amount but greater than zero in the case of a partial payment or

it could technically even be above like you could you our smart contracts are are flexible so you know that they that it is possible to overpay a request um okay luckily it looks like my my create and pay a code sandbox is working so I'll I'll cap off my my presentation here with a quick demo of what this could look like let's see if this this will load up excuse me uh you can see the um the code over here on the left the

the primary file is the the page page. TSX and we can see that it's got it's it's it's a long file it's got It's got a lot of the code I just described um in in more detail but what I really wanted to show was the um the actual execution of the demo so we can see I've got a simple form here um I've got the field for for creating a request and then down here I've got stuff for paying a request and then all the way at the bottom I've got stuff about the ACT uh the request State so what I'm going to do first is I'm going to connect my wallet and I'm going to use metamask for this demo okay so it's G to automatically

reconnect me somewhere um so I've got my my address connected for this demo I'm going to create um I'm going to create a real request so I'm actually going to use the nosis gateway to create this request actually you know scratch that I'm going to use the I'm going to use the test Gateway for today I'm going to create a test request um and uh the the only required fields are the the amount so I have to specify that I'm going to send um two and the currency that I'm going to send is something called an FAU uh a faucet token this is just a fake token on on gorle that you can get for free um and then for this demo I'm going to leave the payment recipient as my own address uh you can see it's here it's

the 70 um so when the payment occurs it's actually just going to loop back through the smart contract back to my own address um the payer identity I'm going to leave blank for this one because um it's only optional um the due date is also optional but I'll I'll go ahead and set a value of tomorrow and the reason I'm just going to put in uh pizza so I'm going to submit that and the first thing that it's going to do is it's going to prompt me for a signature um I have a few plugins uh for for protecting me from stuff so I'll just click through those really quickly but after they're gone uh a popup for metamask should appear and what we're going to see here is

the we can see the contents of the request basically we have the currency we've got the value or sorry the the the expected amount we've got the um the extension data which includes both the content data and the payment extension the the pay the payment networ and we can see that I'm using the payment Network erc20 fee proxy contract uh you can see that the fee address was set to zero with a zero fee amount and that the payment recipient is going to be my own address we can see that the payment's going to occur on gorle um that this is the creation of the request uh we can even see stuff like the Builder ID I'm creating this using request Network created with code sandbox uh the due date is in there and

the reason is pizza and then the pay identity that I'm paying it to is my own address right here and the time St so all this looks good I'm going to go ahead and sign it and uh once I signed it uh the this request info at the bottom got populated and we can see that it's pending right now it is in the process of persisting the um the transaction on chain uh I didn't scroll fast enough what it did before this was it was actually persisting in ipfs for a brief moment but that operation tends to be pretty quick uh so I'm going to wait until the request state turns to created I think that's what I'm waiting for

here oh uh sorry request confirmed that's that's that that is the indication that the request has been confirmed but the request state is still pending because I haven't paid it yet that's that's what it is okay so I can scroll back up here uh in the payment section I can see that I'm connected to ethereum right now uh so I have a button here for quickly switching over to to the Gorly chain because that's where the payment should occur and of course my metamask is still super zoomed in so I'm going to I'm going to unzoom that out real quick um so I'm gonna I'm G to switch networks and now we can see that I am on we can see that I'm connected to gorle um so from there I I can see that

I need to issue an approval um or sorry no I I I check if I need approval so it's checking if the payer has sufficient funds uh it's it says that I have sufficient funds it's checking if the request uh is approved uh I have sufficient approval so I don't need to do an approval transaction today um and so then the the pay now button appears I can click that and we can see that the status changes to paying uh I can go to uh I'm going to just try and Goose this make it make it go faster we can see that I'm I am calling a function transfer from with reference and fee that's one of the functions on our

payment smart contract so I'll confirm this and we can see that the status is paying and we're going to wait um I wish this was bigger uh the part that I really want to focus in on is the the state as well as the balance okay right here here so when the balance increases to the amount that was expected and when the state changes from pending to um sorry no the state isn't going to change it's just the balance that's going to change but when the balance changes that's when my indication that

the the request has gone through okay so the balance we can see that the payment was detected my my Json here reloaded and if I go to the balance we can see that the balance is two two two tokens as as expected okay so that's that is my demo you can tell that I I I I did all three operations I created I paid and I retrieved um uh and just to since I'm at 50 minutes now let's just go ahead and wrap that up um we have a grants program so if any of you guys are interested in building any of these sorts apps accounting apps invoicing apps payment

apps or automated compliance automated auditing lending or or risk assessment any of those feel free to apply to our grants program um you can find it at this URL on screen um and I'll also briefly mention that we are planning to hire another uh developer uh sometime soon so but we haven't we haven't posted the job job requisition yet so when when that happens take a look at our careers page uh is right here it's just uh keep an eye on this um and when it when it pops up feel free to uh apply so that is uh that is it thank you

all very much um I'll uh I'll open it up for questions there if if anybody has any cool cool cool okay uh thank you David we have we indeed to have some questions as you can see in the chat box oh I haven't been watching I'm sorry the first is what are the advantages of request Network compared to traditional Payment Systems can you can you hear me yes I can hear you okay so what are the advantages of request number compared to traditional Payment Systems um yeah I

think the the main advantage that I would mention is that um the the the requests and the invoices um are stored in in a a decentralized way where the the user owns that data so I think that the like I mentioned at the top of the presentation the primary value ad that we provide is that we provide additional context to basic transactions um I'll add on to that that um over time we've developed a few sort of uh uh more complex payment types um and so uh I would say that we're we're ahead of the curve as far as supporting uh the payment types that a payment processor

would need to would need to support um uh I don't know of any other payment um platforms that that support this the same variety of of payments that request network does cool cool cool and the second question is how's the security of payment requests ensured on the request Network sure okay so so the security of a payment request um there's there's a few different layers there there's the um the Integrity of it the the fact that it it it it it hasn't been tampered with and the way that we ensure that is using signatures basically that the signature applies to the entire request contents and it's applied at the moment of

creation on the client side by the user the end user um and so that request then gets stored into ipfs um and it's impossible to change the contents of it after that point without also changing a few things it would change the request ID it would change the Cid in ipfs uh and it would invalidate the signature so I I think that's the all of those things is what leads to the security of it um I'll also say that by by storing it in ipfs um we we we have the ability to have multiple different nodes um storing complete copies of of the request uh history and and so that creates redundancy in the data um and

then uh finally I'll mention that the uh security can also be talked about in terms of like privacy the privacy of the data and and we offer like I mentioned the the encryption mechanism for for encrypting that data and ensuring that only the stakeholders who have the right to to view it and ownership over it can can actually see it do does that answer the security question yes I think so perfect and here are another two questions one is from pacle and our uh he is our core member and he asked are there any def5 projects integrated with request um yes yeah so we we we do have some projects integrated with request

Network the most prominent one that you might have heard of is request Finance is a it's a project that was actually built by the same core team that originated request network but then they decided to spin off and create their own platform for for issuing crypto invoices and uh they're they're celebrating a very exciting Milestone just just at the end of this year of of having processed over $500 million worth of uh of uh of crypto payments so it's a very exciting milestone for them um the that we have other grantees within our ecosystem that are currently working on building um some of the ones that uh uh I can mention off the top are uh uh Bezos Bezos is building an like a invoice

factoring platform um we also have Huma and cpra uh Huma Finance is I could type it in the chat here it's um all three of those are building sort of lending products um we also have um sorry we we we have a lot of ongoing Grant applications so I I want to be careful not to mention ones that are not finalized um but uh we we have we have other grantees we also have a job job market places um there there's a there's one called Joba Joba network is building like a freelancing platform and they're

using request Network for invoicing um forgive me there's others but I I at the risk of of mentioning something I shouldn't I I'll leave that there but we have we have uh over over 10 different grantees in our pipeline right now so uh lots of exciting stuff going on at every Quest Network yes that sounds really exciting and the last question is will request Network take uh account abstraction into consideration in the future development account abstract ction I I think the short answer is yes I I I the honest answer is I'm still

trying to wrap my head around account abstraction and its its um implications for our our Network um based on my understanding is that they they the basic primitive of an account abstraction wallet is a smart contract right and and so we we would need to be able to um accept signatures from a smart contract as opposed to signatures from an EA um and uh the short answer is yes that we are we are thinking about that um today as far as I know you can't create you can you can pay a request using a multisig um or any other account

abstraction wallet but I I'm not 100% convinced that it's possible to create a request using a multi-sig or an account abstraction wallet so we basically we we have to we have to figure out how to handle the signatures in that case um definitely definitely part of our consideration possibly not supported today um we're still looking into it cool cool I think that's the end of the question I do see I do see a couple more that I I'd be open to answering um one of them was uh the payment network name gorle why not use chain ID here uh so the answer to that is um because we actually support non evm chains as well um we have a few

payment smart contracts that are deployed on near and and if you're familiar near does not have a chain ID the same way that evm compatible chains do um and so that's that has evolved as as a a valid reason to keep our our payment Network names admittedly back when we first developed this maybe chain ID would have been a better choice but um but uh for now since we're we're now targeting non evm chains it seems like a valid Choice as well um and then there was another question are there any institutions aspect in the invoice um yes yeah so I I mentioned that content data field um it is possible to put any amount of

information about the pay identity and the payer identity in there if you so choose it could it could be like the the business address or the business phone number or it could be the tax identification number for for a business um you could put any of any of that sort of stuff in the content uh data field does that answer the question I think so okay I think there let me see okay I think there is no more questions yes now okay let's wrap up the meeting thank you so much David thank you so much we have a lot of content here and we hope that we can have more

connection in the future okay have a good day thanks thank you so thank you thanks everyone bye goodbye