Stream It or Miss It: Building a Live On-Chain Activity Monitor for Gnosis Pay

Transcript

Y hello guys. Oh wow, this is loud. I'm actually loud. So maybe I should just skip this a bit further. Thank you for joining such huge numbers. I'm impressed. U I'm honestly impressed. I'm not ironic. Um I know there is a little attendance at at these things, but um I think it's nice because it's a lot of people that want to build stuff. So welcome and thank you for for coming and listening. Um we put already the the dashboard up. So as the title says we are going to talk about uh live data on chain coming from Nosis Pay and um I'm curious does any of you use this Nosis Pay? Do you guys Yeah. Nice. Have you had any recent activity in the last 30

days? We No. Okay. Then you are not not one of these guys here. Um but yeah before I start to give you like a very brief context um we at Vena do data engineering for uh cryptonative uh teams. We have worked mostly with Maker Dell or Sky as you might know it. And we have covered a bunch of things from governance operations to payments, treasury operations, whatnot. And we realized there was no one single source of true for data obviously like we had a bunch of queries on on June and so on, but we couldn't look at everything.

And uh I always found this interesting like we are living in this space where everything is verifiable yet we cannot all look at the same source of truth and comment on it. So um we started building this this kind of dashboards. I think they have two type of usage. One is for transparency for the end users but I believe these should be a must have for any single DI protocol out there as well. Um yeah because it it can help you a lot with alerting whenever something uh weird happens you can you can catch those quite easily. Um so yeah we started from uh the fact that obviously Nosis pay writes every single card uh spend uh safe top up IBAN transaction um

on a public chain. So there is million of transactions. Uh they're all permanent and and verifiable yet there is no uh real time watchable uh from outside their team. Um so yeah this is what we are going to we are going to cover today. Uh obviously the the proof is uh on on chain. It's effectively invisible uh to anyone else. Um and the fix in our opinion is not another internal analytics tool. It's a public proof of work. Uh a ticker where you can watch all the transactions as they land. Uh rolling counters um and the point is to make all of these visible for for the users. We don't have one feed but two feeds in here and obviously we can build

further. Um but we wanted to differentiate between the first part that's mainly live spends and the the funding side. Uh and the reason for this is because we are looking at two different usage uh user types here and uh while we are not going to do a lot of live demoing today um we just want to walk you through a bit like what was our our thinking around it um how did we um where did we start right like where did we start to have all this information as well as touch a bit upon uh what kind of um friction points or pain points we discovered uh across the way and as my colleague Pixel did most of this work I think it's more than fair to let him

talk about it so I'll hand over to him to to walk you through the dashboard thanks Saba so first of all I would like to start with what was the starting point for this dashboard so everyone of us sits on X and is reading a lot of tweets about uh card processors and so on. And there was that uh strange uh tweet where someone wrote that one of the biggest card payments had huge volumes and he knew no one who used that card provider. So we thought that would be interesting to see this like in real

time. And this is like this graph shows you like what where the card payments in the last uh last hour. And we see that uh we had like 30 uh 370 67 transactions with a total amount of almost 60k and there were 305 different users. All this data is u is read on chain based on uh on spend events emitted by the spend by noisy space pay spent model also. So this is the first row here and below we have like the

volume of the user topups of their cards that which are also is open data from the nosis chain which were based on the transfer event that uh entered user uh nosis account and we have here like some table with latest funding. We see that these events are not quite uh frequent. We have like 10 in the last day. And yeah, here is the current live data from the last hour. So we can see in on each of these rows like the

currency breakdown for all users in the last uh hour. So uh to make a small summary of the first part. So we have two surface surfaces that we are looking into this feed. First one is lifespans and the second one is uh funding meaning where the money came from. And uh these source are classified by Ibans or they are labeled by cow swap uh topups or bridging from other chains or the same chain like we can I think I can show you here is

we see that the most of the topups are like IBNS but Uh yeah, if we peek a bit in the history, we will see that for example, this transaction was a top up using LiFi uh bridge. Okay, wait for it to to load. Yes. Yeah. So, this is all data history. So there were that this wasn't a crosschain swap, but it was a Wi-Fi bridge uh from the from the noises chain.

Okay. And uh yes. Okay. And now I will walk you through the architecture of our this uh small uh uh dashboard. So we have uh first of all noisy chain where all the events are published and for the live feed that you see on the screen we are um collecting the spend events and uh this we are using this uh we are using hyper client in order to make the sync uh into our database. We use a for this

specific demo we used superbase posgress database. We have our own back end uh in uh next JS and we use uh it in order to aggregate the data which we are displaying in this front end. And uh of course in order to display data you are interested mostly on the data on the top of the chain. So the data like for two days ago is unchanged. For this specific exercise, we didn't uh took into considerations re reworks, chain reworks uh because uh each of those uh

spend events even if it gets in uh other block it uh it still remain on chain and it is subtracted from the no pay user account and uh Yeah. So as I said before the main uh main part of our dashboard is the indexer which looks like uh some big part of infrastructure but it's not because the uh hyper client from the from the endoc covers almost all our use cases and we use a cursor that is picking the

latest block number from our database table and uh we just sync the data that we are using for displaying live changes only after that specific block number and uh yeah maybe I should explain a bit about the spend event anatomy. So usually the data that you can find on chain contains four fields on the event. One of those is the asset which can be uh the equivalent of euro or USD or USD or GBP. And if you look at the uh the dashboard, you see that most of

the transfers are like euro. This uh this blue uh tiles and this green one are green ones are USD and this yellow is the GBP uh expense. So GBP for example is quite rarely uh used or was used in the in the last hour. And uh one more thing is that we are use we are filtering the data from the blockchain based on u event signature and not the emter because from the last uh security incident with the uh delay model. We woke up in the

morning and we saw that we see no transactions on the chain and we understand that okay we know we all know what happened but at the same time the contract that emitted these transactions went was changed and we just uh switched it and uh yeah this is how the data gets in our system and is displayed on the on the surface and Uh yeah so some facts about the events. So on nosis each block is produced in one in once in 5 seconds. So the speed of writing the blocks is not uh not so high. So we

don't have to maintain like highly performant uh infrastructure. So for our example we use the free tier of NVO hyperclient a small micro superbase instance and uh a versal serverless architecture. So it's uh it's doing it work uh let's say one very cheap cost and uh yeah maybe yeah let's I said I said about spend architecture we can look into the logs here so yes this is the spend event you

see this is the asset address. This is the account that spent the amount you saw before and this is the vault. One important thing about uh the onchain traceability is the fact that you see the user that did the spend but you don't see where those money actually uh you don't see the merchant exactly and uh yeah because all the the spend get into some centralized uh nosis vault which is forwarded further Okay. So,

let's go back to the Yeah. And we already saw the the recent findings. So, these are topups of the the user accounts. uh how we are uh collecting or how we are monitoring this type of uh event. So we are looking mostly for the transfer event on the on the chain on the which has as a recipient one of the nosis safe addresses. Uh currently we are monitoring all the transfers and uh just filter them by destination but you can do this using hyper client in a most in

a more efficient way just by uh filtering directly and not looking into each transfer and but at the current volumes uh and the our architecture work uh work work just fine and uh related into the labels of the topups. So, uh these are not uh some labels that you can get from the events. You have to uh manually take uh each event and uh based on the event long you can classify them. So you see

that here we have mostly IB bands but there are also some events that are classified as others. So this could be just a transfer between two noises users and uh yes and for this things so we so that the recent finding are like quite rare rare events and in this case we used just some uh cursor that is just uh expanding by

interval like in this case we have 24 hours, 7 days or 30 days which and you see the frequency of the funds is like one in in a few hours. So in this case you don't have to make like very frequent polls in order to read one event per hour which is not the case for uh for the live spending because these events are like can be a like a few events in a single minute. So we poll once in 15 seconds. But uh this can be done even more frequently but I I don't think it makes sense to

make it more frequently than 5 seconds when a single noises block is produced. And uh as I've mentioned before we are currently um looking for the finding only on the accounts that uh already did some spendings because you have the spend account in the in the spend event and you just filter the transfer events with the destination of that account. Of course, we can do this even for the users that uh didn't made a spend any time based on the

account created event uh emitted by the delay module. And uh yeah that this will expand the the funding events a bit more but not by a big margin and yeah I think this was more most of the architecture that we described. So yeah on the front end side we use uh like react with uh recharts for the for these charts but in the rest it's it's

basic react components and uh yeah so I can try to do a quick summary on the architecture. Uh so the indexer is just a watermark loop. So you always uh pick the new events from the top. You don't have to reiterate over the events from the last hour each time you do this update. And uh the labeling the for the topups is something manual that uh we are just taking individual events and just look up for the path uh from

where that those uh funds came from. Yeah, I think that's all on the architecture side. Uh I can show you the so all this code that which is extracted from our uh production code you can find in the inner repo which I guess it's in our presentation. Maybe I can switch to it but it's on the nosis pay monitor GitHub account.

Yeah. So as a final thought uh so the proof of this uh activity is always on chain but it's not always displayed. So in order to see this transparent so the transparenc transparency is there you just have to build a tool to see it. Yeah. Uh so if there are any questions. Yes please. >> Yes.

transaction. >> Yeah. >> Yeah. You you have some events on the vault that uh you each spend event is sent to. So you'll see the most of the events are like out or are in in that vault. But you'll see like some uh outflow events that can be refunds, can be cashbacks. Yeah, we didn't include this in this specific dashboard, but uh we looked into it.

Any other questions? >> Okay. Yeah, the GitHub repo is on the screen. Uh, also I think I I forgot to mention about the pricing. So, we saw that all the pricing we displayed in USD. We don't store that price anywhere. It's just live feed data from Coin Gecko and we just transform that uh on the fly.

Yes. Yes. Let me switch back here. >> Yeah. is you. >> Yeah, it's just Monarium minting one of those uh those three tokens. >> That bit of labeling is something that we do, right? So if it's Monarium, we know it's IANS. If it's cow, like we the labeling is a a categorization internally that we put on top of >> I can show you here. So this is like a

more static dashboard but you can see here are like some types of funding. We see here that we have like DEX fundings or Monero which are like those that you saw before. We could we see cross bridges. Uh there was at some point a big activity on swapping funds on cow swap and yeah we there are also a lot of uh different findings the types of findings that we just didn't labeled before and uh yeah you can see here like this is the

entire history there are like 3.3 million of spend events overall in the history of nosis pay they have different so almost 38k users but you can see this uh spike in new users when they switched the user addresses after the recent incident. So yeah, also we have another small dashboard which just monitors diagnosis treasury holdings.

So you can see these holdings and also have a separate tab with the allocations in different protocols like spark or uh balancer but this is static static data we don't monitor it real time and it I don't think it really makes sense to have it like one minute uh breakdown for This any other question?

Yeah. Thank you.