Breaking barriers: how interoperability will shape Web3 finance - Francisco Pinto
ETH Warsaw·Tue, Oct 7, 2025, 12:00 AM
A discussion about Web3 interoperability. 🧜🏻♀️ ETHWarsaw is a series of educational and entertaining events for an active community of blockchain builders, developers and enthusiasts with focus on Ethereum-related tech. Once a year, we organize a large conference and hackathon for the community in the center of the Polish capital with speakers from the best web3 projects and participants from all over the world. Follow ETHWarsaw on social media for the latest updates! X (Twitter): https://twitter.com/ETHWarsaw LinkedIn: https://www.linkedin.com/company/ethwarsaw Telegram chat: https://t.me/joinethwarsaw See you all at our events in Warsaw 🙌🏻
Transcript
okay and now for our next session we're going to talk about how interoperability will shape the world of web 3 finance and just a fun fact it was said at Fest this year in California that the world in web 3 for the year is guess what can anyone guess what the world for the year is in crypto anybody anybody interoperability yes he's got it right please welcome to the stage Francisco Pinto thank you thanks a lot everyone good afternoon everyone thank you for joining me here today uh I hope the conference has been good for you I'm surely enjoying it a lot so congrats here to the organization um it's always a pleasure to come back to Warsaw uh for such a nice event um so today we'll be breaking some barriers do you know that nine out of 10 web three payment apps still use centralized databases to store your data crazy right these are web three payment data uh uh payment applications um and when I say payment applications it's not just the payment ones uh everything related to financial operations um stuff like invoicing payments per se accounting expenses billing all that data all those applications on web3 I'm saying nine out out of 10 just in case but I don't know anyone that doesn't use a centralized application a centralized database um so today in order to talk a little bit more about that we are going to go through the promises or the premises of web tree we are going to we are going to talk a little bit about the status of the current payment Market inside of web 3 and why it's built this way and lastly we're going to talk a a little bit about request Network and how request network is creating the path for this uh more decentralized financial system on top of the blockchain Starting by the beginning right uh web 3 is something that we are going to discuss a lot but why do we even need web 3 maybe we should start with that um it seems like a lot of people forget it um web so since the beginning of of the internet web one you probably already heard this story but um web one is the it was the time where you could only consume data on the internet then web 2 came out and you started being able to create stuff and interact with data on the internet um but a problem then arised the problem is that a handful of players started controlling pretty much all the applications and traffic on top of the on top of the web and that's exactly what gave birth to the and gave uh and created the need for the web 3 um in order to sorry um that's exactly what gave the need to web 3 and we we the idea of web 3 came out with a lot of different promises the decentralization the ownership the interoperability web 3 was born to actually Empower individuals to actually own that data and we are not seeing that that that much on this space at least we um although we can get there we are still far and we still have a long path ahead of us and payment is definitely a super hyped use case in the last year it's been talked a lot Co coinbase is all over it with the summer campaign um and it's predicted to grow a lot in the next few years which makes a lot of sense because payments in crypto especially if you're talking about like cross border payments are way cheaper faster and easier than the traditional Finance right but payments are not only about the the transaction of value itself it they need to have some kind of contextual details in order for them to even not to be useful but to be even legal right you can't really especially if you're a company you need to have some kind of data attached to your payment stuff like invoices receipts um in order to prove the track record and to prove uh your accounts and that's where the issue uh comes in the blockchain doesn't really give you a way to create that data um you can do it but it will be costly and it will be scattered around different blockchains so so this this data uh which we are going to call um contextual data it's really hard to to for companies to kind of payment companies to store it in a decentralized way um just to add a note there that the contextual data is exact exactly what um what aners to the question why was this payment made while the blockchain only gives you the information of how was this payment made and I'm going to use like a small analogy to kind of explain uh the problem here and the current state of the financial operations in web 3 right now so I'm using the the applications as Islands because they are very siloed right now but I I I wanted to use Bridges next so Islands makes more sense um and if the status was this this would we would be good right every application is connected to the blockchain it doesn't have any other uh way of storage these are real apps and they are connected to the blockchain if I make a payment on application a I can see it on B but I don't have any way to store the the contextual transaction here if I if I need an invoice there's no way uh that I'm going to have it on that platform so applications started building this small blue things on uh each one of them um these are the centralized databases and this is where they store both the transactions that they do with the blockchain and the contextual data around that transaction the who is it for uh uh so payer pay um the description of the transaction currencies values everything starts being stored uh on this decentral on these centralized databases but the problem is that now the users they they use one application but they need especially at the stage we are on we don't have a lot of huge companies on web3 payments they need uh if I'm if I'm handling my finances in web3 I need to use multiple applications and that brings another problem because before everything was on chain I could interrupt inter I could bring my data everywhere that I wanted but now I have my data Silo on different is bance and applications in order to kind of go against this they built this so they started creating Bridges with other applications of that provide not the same value but uh the next step on the workflow so an application that that is is handling their finances now in web 3 has to use a couple of payment apps depending on whatever the the payments that she that he's doing uh an invoicing app and let's say an accounting app like a subledger they all need to exchange data because uh you need to the flow of data to end up in the accounting app for it to be then reported to the government or whatever tax reasons that uh uh that you need the data for um but the the thing is that what you actually what we actually created on top of the blockchain is just three web three web two companies that are doing transactions on chain these are web two companies they hold their data they don't they don't have they don't give you full open interoperability and you can you are kind of dependent on them now and you're kind of dependent on them because if a new app comes and you are let's say you are the the user of this the owner of this company that's using the current three apps and a new invoicing comes let's call it invoicing app 2.0 and you want to test it out for a couple months it has these new cool features that would be nice but your workflow is already built with these three apps and those the payment app and accounting app currently don't have a bridge to that app so you're you're you're already limited uh by the other apps that you're using wanting to create a bridge with that app and I mean yeah it's sure you can kind of download all the data move it there but then you're going to have to do that every time if they don't make the the bridge or um and are you going to go through all this cost just to test a new app that may be good but maybe not there's a very big barrier here and um and that this disincentivizes you to kind of test things and that's exactly how you you end up with monopolies like in web 2 so all this uh if you want to do in web 2 app like this fine but uh let's not call it web 3 because definitely it's not the thing is and why I uh we believe that most applications are building this apps this way uh and the even the the ones that started as web 3 because there's no good solution to kind of store the contextual data it's very hard to to uh store decentralized data on your own especially if you are like a startup right you have to worry about Runway you're not going to be building infrastructure as a payment app you're just going to use whatever is there and um what is there is uh and what is perceived as the more efficient way right now it's the web two way so they all ended up even the ones that started fully web 3 ended up switching to the web 2way in order to be competitive with the others the second problem is that as mentioned previously if you want to store all this data on the blockchain you really can't uh because you'll also be less competitive than the others you'll pay more it will be slow and it will be scattered around around multiple blockchains so that's exactly what we are trying to achieve with request network with request Network we are trying to build this decentralized financial database that can store your contextual data it allows you we we built a lot of tools for uh actually creating and storing the data um that you need to to complete the data of your of your payments we basically what we do is that we attach uh this data uh we create this data on ipfs we um we attach it to the payment and whenever you want to retrieve it it will retrieve both both uh both information both data structures to you um basically request network is um is the why that payment was made anything that that want that you want to know about what what that payment was for you can see it on request network uh the how was done it's on the blockchain and we aggregate the both so you can move for some from something that it's like this into something that it's more like this the the permission way for the permissionless way and you might AR you might argue that uh this this this image might give the idea that we are centralizing everything in request network but request network is open sourced and it has open data standards um the other image didn't really made uh justice to request Network by just adding one more uh application so I I I felt the need to create another one to show that you can choose from whatever pool of applications that are on top of it to handle uh your finances and uh the data is completely uh it's completely interchangeable between all of them in fact the big difference is that now you own your data instead of the the web to way where the data is stored on the centralized databases and you just access it now it's the other way around now you want the data and they just access it that's the the the biggest difference um um the first point about ownership is exactly that right you own your actual data the second point on privacy um request Network allows you to to add data that it's completely transparent so if you're a dow or something and you want to have completely uh transparent financials uh that's very good and we allow you to do that uh if you don't want that which is normal not a company normally doesn't want to have all the transactions public uh with the with the contextual uh data of what those were for uh like especially like invoicing and receipts being scrutinous every day would be a nightmare um so um you can have that privacy on request we can encrypt it the data for you before putting it on on the network we encrypt all the data with both the payer and the pay transaction uh um the payer and the the pay keys so only them can then access the data it's not possible for us or anyone else to access it without the other two agreeing on sharing that data um lastly we have interoperability and on that I mentioned that you can move your data freely uh uh across all the applications on top of request Network we also cover like 25 blockchains so you'll have all the data of that U and to kind of showcase interoperability a little bit more I'm going to show some demos of these new products we've been building to um to uh to help developers start their journey in request network but also to showcase the interoperability between different apps uh built on request Network um okay so this is these are exactly the apps I was talking about we have request checkout which simulates kind of a payment app we have request invoicing which simulates an invoicing app and we have request scan which is more like an Explorer for request Network you can see all the data there all the data from the network there it is you can only see the UN encrypted data of course um and it kind of simulates what an accounting app would do because an accounting app what will do normally or a subledger it will read all the data and kind of label it but it won't normally create new data so let's start with the invoicing one oh uh just a second okay all right so basically the all our our um uh comp um templates are built with web components so they are reusable you can just copy them you have that list there in here we have this um form for creating an invoice also as a web component that also gives you like a a quick preview of it and here we are going to use it for a quick example on a hacker kind of uh issuing issuing an invoice for the aaton so he want the Bounty of request Network he needs to send an invoice uh because we need an invoice in order to pay him and it it it gives that example with fake data of course um we have we covered a lot of chains uh in here by default we already have a lot but if you want to add more it's really easy uh for testing purposes it will use sapoia um as mentioned first place on the Bounty lucky guy um I wish I could speed it up a little bit um okay so basically this is what we'll see it's you it try to create the invoice you sign it so that the network knows for sure that it was your wallet that created this invoice you wait a couple minute a couple seconds and it's done so the invoice is created it's uh it's been persisted on on the request Network and you are now able to see it here the first one 1,000 FAU you switch switch to the payer wallet and you're you'll also see it here automatically and you just paid all right yeah this was new these were new wallets so you have to approve the transaction first right okay so this closes closes the first video all right transaction paid after that we have here the request checkout and it's on this one that will display the interoperability we've already created uh some invoices on the on the other video here we are kind of doing this is our playground you kind of can build the uh whatever payment uh checkout you need uh in this case we are doing a payment checkout for e waro um where you can add all the data you want this is all contextual data like the buyer info seller info will be used to for billing in case it's necessary um you put up these things we are putting here in hand but it can be easily passed by your front end you don't really need to uh have the users do this you can choose whatever currencies you want to accept and this is the experience of paying it it shows the Curren es that you chose the data that user the buyer submitted it does a a swap uh if you input the value in usdc in USD and you just pay it okay so the cool thing is that now you come to the invoicing template that it's not connected in anyhow besides request network uh to the this template here and you can see the invoice being created um and basically this is a very short video just showcasing the final result if if you plan to build something like this maybe we'll try to sell it to with foro um Okay so it's just adding more data and lastly we have Rec scan so if you want to see the network data at least the incre the the requests you'll only be able to see the unencrypted one but the payments you can see everywhere uh all of them because they are on the blockchain so all of them are public um yeah you can see every transaction here you can see all the the requests so it basically joins the blockchain data with the contextual data from request Network everything linked together all right so to close to close it I want to just to touch a little bit our core values it is um the interoperability we talked about in these templates ownership so we believe that everyone should own its own data at least have the chance to own it uh if they choose to to give it out that's that's fine by us but at least give that possibility to the end user and efficiency um it's it's something that's very important uh in a special way to us because we believe that web 3 ideals are very strong but we we don't think that web3 ideals will bring the mass adoption or like the next billion users that is currently being said um so if you building tools uh we are we are with the tools that we build we make sure that they are more efficient than the traditional ones while keeping the decentralization that's how we think we'll attract the the companies and the users um from from that from the traditional market and that's how we think that we'll be able to move from web 2 to web 3 The Current financial system um request network is sponsoring the Eaton if you're participating check out our bounties the the components that I just showed uh are part of these bounties so if you use them for something um uh that would be really cool uh we also have this grant program um we are open source if you ever want to kind of contribute uh to it we'll be very happy to help on anything and yeah just come join us um we are really um we we just we are really focused on this mission of making decentralized Finance so uh happy to to on board also with us anyone that wants to help um my name is Francisco I'm the protocol leader of request Network thank you woohoo can we get a round of applause for Francisco now is orist here is orist in the room yes fantastic why don't we have you set up and in the meantime you can ask Francisco one or two questions how about that do we have any questions for Francisco what would you like to know about any of what he said and by the way I did not know that so much of the data that we actually use in transactions is hosted on centralized platforms I feel very icky I feel lied to you know like when you go on a date with someone and they're really cool and then you find out they have a double life that's what I feel like currently so do you guys have any questions for Francisco yes I will bring you the mic hi I actually have two questions so of course first one is what's your business model uh and the second one is do you have an app for uh processing payroll um our business model is that we take a very small fee for for every data that you create on the network um but we are actually kind of uh at at for small startups we kind of abandon that fee until they reach a certain maturity um the second question was uh do you have any application for processing payroll you have one for pay actually the one that I showcased here on the checkout you can def you can use that for making actual payments yeah uh it was built more in a sense to be like a template so that people can bu on top and customize it but it can actually make payments yeah that's what it uh you you on the I didn't show on the video but there on the playground the the page that I show where I was tweaking the values if you customize it as you want in text you can just copy it after there's the a snippet of code behind it you can copy it put it in your website and it's working nice thank you very much oh thank you so much Francisco please give another round of applause for Francisco I'll just grab your mic
Automatic transcript — names and jargon may be misspelled.