DAPPCON 2025: Multisig in Motion: Analyzing Safe Data in Realtime Using HyperIndex - Denham Preen

DappCon 2025 · June 2025 · 42:07

Denham Preen presents multisig in motion at DappCon 2025, showing how real-time indexing tools can analyze Safe multisig wallet data as transactions happen. The talk situates the indexing approach within the broader wallets and analytics landscape institutions use to monitor treasury activity.

Speakers

Topics

From DappCon 2025, hosted by Dappcon Berlin.

Transcript

Cool. I'm there. Quick sound check. Sweet. All right. Gordon Albent Davcon 2025. Um, very excited to be here for the second year in a row. Today I'm chatting about multi-igs in motion. The workshop we're going to do is going to be a little bit interactive. Um, there will be some tools to play around with and my title is multi-igs in motion. Now uh specifically I've focused on uh safe data being the maybe blue chip de facto multi-IG wallet smart contract wallet.

Cool. Really excited to run through this nice intimate group. Let's dive in. A little bit about me just to kick things off. We've got a good amount of time. We should have enough time for um Q&A after. My name is Denim, pronounced like the jeans. I'm one of the co-founders of a project called Envio. Uh I'm a believer in the tech and not the hype train. I have an academic background in computer science. Um anarchist at heart and super grateful that my path led me on to being a developer. Um and probably been in the space since mainet gas prices allowed for a little bit more experimentation. I

think uh relevant to this talk a little bit more about me. I am a pulley holder, a ground style member and notably a safe guardian which means I partake in the active governance around safes. Um but that is the closest affiliation I have. Uh been passionate about the project for quite a while. Uh got involved with some smaller dev stuff early on. Um by builders for builders. Okay, a little bit of a boast uh slide, but I just mean to give us a little bit more credibility. We are a team of 10 uh mostly technical. We have uh built production systems for uh ourselves and some external things in the past being

kind of core dev teams hosting uh well deploying smart contracts that held well over hund00 million which is peanuts compared to safes. Uh, hats off. Very secure. Um, at least our software hasn't been hacked to date. Um, and yeah, we've spoken at a few different conferences around the world. Uh, I can see my co-founder there. He's I know he's also spoken at the World Economic Forum or at least in Davos. Cool. All right. So, too long didn't read. I'm going to chat a little bit about uh Envio the tooling and how we use it to build a real time data set and

with this data set we can query to get some interesting insights. Now we're going to do it kind of the way I did it. So it's going to be a path of exploring how I went through this process and I think there's some pretty interesting findings or at least things I did not know at all. I definitely think there's a lot more that can be done with the data to uh essentially find further more meaningful insights but this was just uh initial insight into how we can look at this this data. All right so data is fun data is really cool in the blockchain space because it's extremely public i.e accessible and what we've really focused on is making that uh public data a lot more easier to access by making it more

performant. Right? So I'm going to chat about the the data set itself uh and the tooling in order to to create this real-time data set. I'm going to chat about safe chain network distribution. Okay, so that's terrible framing but essentially the distribution of safes across different networks and kind of analysis on that. We're going to look at safe deployment activity trying to understand uh kind of safe adoption which I think was a really interesting insight into just to general chain adoption um and maybe a truer metric on kind of uh non a non-vanity metric on terms of ecosystem adoption for chains and then the last one is how safe are safes and again super secure at a smart

contract level but I'm more talking about how people are using safes today operationally uh tying into like how many owners, how many what's the threshold set uh and how they're actually being used. Cool. All right. Um so first off just to touch on why would somebody use a safe. All right. Um usually I mean there's a bit more to it maybe but here are some kind of highle notes on it. So they want extra security. All right. So you have better security than using something like an EO. you have the optionality of shared ownership and a big one is non-repudiation or repudiation because you've got uh better like way of sharing ownership over funds. Usually there's

recoverability. If there's a signer that gets lost, you can recover from that. And then I think a a less spoken one is actually flexibility. Um and it's ties into the fact that this is a smart contract that you can have additional smart contract logic uh tied into. So yeah, those are maybe some of the reasons why everyone wanted to use a safe and then uh out of interest who here is using metry. I hope everybody at this point being around the conference but uh metry is awesome. They've been using our tech. They index about 250,000 saves essentially and about 50 million events and this kind of scale that they needed did motivate our kind of uh product direction to being very scaled

driven. Um yeah the tool is really cool and pumped to be kind of a data provider into that but they were some of the motivation around uh exploring safes in more detail. All right just to break it down a little bit we have two core products we have hypersync and hyper index. Now hypersync uh it's important to note but most of what we're going to chat about is hyper index. Hypersync is this raw data engine beneath. It's kind of like a node. You can access RPC data. you can uh get this data but it's designed for getting data. In fact, my talk last year at DBcon was around hypersync and some of the uh nooks and crannies and some of the secret source to how that's so much faster. But if I have to be honest, I think one of the

biggest things just noted is blockchains weren't designed for big data. uh they were more f or nodes are more focused on consensus and as blockchains have gotten more and more data intensive having longer history uh it's become more and more important and we took a lot of web two techn modern database technologies and started applying it to the web 3 space cool so hypersync and then hyper index is maybe the framework that allows you to aggregate this raw data into information cool and we'll we'll go into that a little bit more detail all right so hypersync can be seen as the engine um that feeds feeds into hyper index as well. Um, but it can also be an engine that feeds into other tooling and we'll go into chain density for example and show you some data from that side. But

it can be accessed directly. It's just you're starting to go down lower levels of abstraction. Um, all right. We get to our first slide. I hope it is big enough to see what's going on. Um, this is the so pretty simple. This is safe token on Ethereum mainet and this chain density tool is used to look at uh transaction or event density over time. So the x-axis is um uh block numbers bucketed and the y- axis is the total number of transactions and then there's a nice cumulative line graph there too. All right. So, we look at this um first off and we can see two

big spikes. Um can anyone figure out what those two spikes might be? I think the first one's quite quite a given. Yeah, there we go. Um uh something to note. So, this is fetching the data from Hypersync. It's doing in real time. I just passed in the contract address. Uh it's really So, it took about 15 seconds to make this query, but can be quite nice to do much bigger contracts and stuff as well. Um this is specifically safe version 4. Should the oh sorry safe token the next one safe version 4. All right. Um we can see the two big spikes pretty self-explanatory as the airdrop was released and then at some point the

safe issuance or the governance around it was initially non-transferable and then there was a period it became transferable and we can see that spike. Cool. Let's go into a bit more into safe data rather than just safe token. All right. So again, I'm looking at a single contract. We will look at more kind of across multi networks, but uh again kind of interesting to see what's happening here. So um again, we see a big spike and I haven't quite figured it out exactly what that spike is. There is a correlating date which might be quite interesting. Um and so we can take a look at that closer. But the fiber hack, this is more of a kind of a

social engineering hack. Um, but we can see just there was a big jump of growth, which I can't fully explain why the massive growth was there, but we did see a dip after the fact. And this might be more uh might imply more about the fact that say if we're very good with their security measures that they implement in place they reduce the um the feature like what you could do on the UI as a precautionary measure and so this kind of dropup could be correlated with that. Um again really cool to see this data getting pulled really fast. Um this is the same contract again some smart devs at Nosis because or at safe because that's the same contract address

obviously using create 2 or just clever deployment implementations um and you can see that that again that by bit drop off in in activity um but soon recovered quite soon after cool again we're looking at safe token coming back to that uh graph and we can see the activity um kind of at the vibe hack it's a increase in volume all right not necessarily increase in price so there was uh let's say more activity around that time very likely because safe might have been a bit more in the news and there was some PR around it all right now we jump into the more exciting stuff so this is pretty dark on my screen I hope you can see it too this is the

first indexer I deployed okay and what it's indexing is all safes that get created so this is the first data data set I created and I've used all 17 uh safe wallet supported networks. So obviously safe's open source anyone can deploy. There's a cavit there's an 18th network which I didn't include which is x layer. I won't go into the details of it but um so I've got all these networks and you can see we've got uh 45 and a half million events. These are all safes being deployed right. So this is an initial safe data set and it's kind of indicative that there's about 45.5 million safes being deployed across

these networks and a little flex uh it took about an hour to deploy on our hosted service infrastructure which is about processing about 30,000 events per second which is to be honest on the high end of of our performance. Um, so this initial data set I looked at and then we can go into more kind of in-depth data set. Um, just to show you what that looks like in terms of the schema. If you're not familiar with code, don't stress. This is pretty simple. This is even just a simpler way of showing it. But this is the information points that I've abstracted from safe getting set up. All right. So we have an ID, a proxy, singleton chain ID because it's a multi-chain indexer and a version. So super straightforward. uh we can look at

the data across different networks. I just want to introd uh interrupt myself quickly. If anyone has any specific questions uh they're more than welcome to bring it up now or we can just bring it up at the end but there should be enough time to to go through different things. So this was the initial data set that I could answer ask some questions around. Okay. And this is the distribution across chains. Now, I didn't know that World Chain was the biggest deployer of safes. Okay, that caught me off guard and it naturally made me ask the question of why. Okay, and I spoke with Ian, the deell from World Chain. And of course, it's because the orb the account creations of wallets on World Chain are done with safes.

That's great. Interesting to see that's the biggest deployer of saves. Kind of makes sense. Anyway, so I knew that this wasn't this is maybe a bit of an outlier in the data set and so I looked at removing and go into that in a bit more detail. So um some initial interesting findings world chain accounts for about 59% of all serves created big users of got a meeting in a few minutes um world chain so this is the stats I got from the next deployment I'm cheating a bit in terms of the order but world chain accounts for 65% of all safes activity which does indicate more transactions to safes or events um then the other thing I kind came to realize is that there's a super

high um concentration of safes. So if we look at World Chain, Optimism and Polygon, they are by far the biggest environments where people have deployed safes. Um it's a permissionless environment. There could be a lot of uh unaccounted for or a lot of spam data that skews the set. Um but it was interesting to see that there's a quite a heavy concentration of those 50 million uh safes deployed. All right. Uh sorry last segment there between world chain optimism and polygon accounts for 96% of all safes created.

So quite heavy concentration for three networks across 17 networks. All right. Um I did another deployment and this is mostly to help me with the querying. I built another data set. I removed um world chain and the indexer that was indexing all safe events say all with a slight caveat was 430 million events and without world chain we came down to 150 million events. Um but through some simple filtering stuff we were able to to move data points uh we were able to eliminate like the world chain stats on it too.

All right. So this is what it looks like if we remove world chain. You can see it's starting to have a slightly better distribution. And then this is what it looks like if we remove both world chain polygon and optimism which may have perfectly accurate data. However, they do seem to skew the results enough that I thought let's uh analyze both with and without to try to get a better understanding of what's truly happening. And this I thought was a pretty good reflection of what true chain activity looks like. I think uh most I mean there's obviously a lot of vanity metrics around network adoption but safes are usually quite a let's say slightly power user thing um to to use

and I would say this fairly accurately flexed nois chain quite popular Ethereum mainets of course popular base popular and then some of the smaller chains like polyon zkm having less less traction avalanche chain was 3% And cool. Okay, now it's it's slowed down a little bit because we had a much larger data set, but a big uh nice data set to do queries on. And this data set was a little bit more complex. So I indexed all safes. So I'll go through the events we index, but this is the data set that I saved that I could query. Okay. So we've got uh we've got all the safes.

We've got the owners, we've got threshold for that safe and then successful and failed executions. So we can build some uh ask some questions. We can also ask questions about around the total gas um a safe has spent. And for example, if we wanted to see uh like highly active safes, we could query or filter by total gas spent being greater than a certain number. So like another way of maybe uh doing better data hygiene on on that uh data set. Then we have uh a lot of information on safe transactions. Um again we can do some interesting things. One of the things I did here which is very up for debate on whether it helps our our information is looking at execution

dates. So how many safes are quite active and whe do we look a year back or do we look uh two weeks back and we can bucket our data sets into different things. So this data set really great. Let me actually just do a little quick pause here and show you that this is actually live and querable. So, uh this is currently deployed. I'll share the the link at the end. Um however, you can also just go straight to the nvo.dev the explorer search safe and you can get this these different data sets. So, you can see I've got the three different deployments here. Interestingly enough uh since making the deployment we this was 150 I think from the screenshot. So

you can see it's indexing in real time this is ticking up as we get more data in it and I can actually come here and do the queries. So let's get safes the ID the chain ID um the threshold and total gas spent. I'm going to remove this. If this is looking a little bit too confusing for now, don't worry. We'll come back to I just want to show you that it's real and live and this data can be interpreted. All right, cool. So, what happens is this is what the the data schema looks like and it creates this this rows as it gets populated and this is

just a kind of thing so you can see that table tangibly on the data being saved and us being able to query it. All right, this again is going to look a little bit like code, but uh it was actually probably the easiest way to show this. These are the events uh related to safes that we're indexing. So, we're taking all these events and we plugging it into our our tool and saving that into our our database and uh we process them. So, super simple. If we have for example an added owner, we can update that safe and uh update the owners that are linked to it or they change the threshold etc etc. Okay. And I gave you a little example of it now

but here's an example of querying the data sets in a more complex way. So, this query I'll chat about in a little bit, but essentially I want to get an idea of of the number of safes that are um have a a higher threshold than just one. I it needs multiple signers, multiple uh people to sign a transaction. And I wanted to see how how if they were active in the last year. So, this execution date is if they've got a safe transaction that happened that was greater than the la a year ago today. So we get an idea of like active safes and uh the threshold and we can get a an idea of uh the count of that in relation to other things. So this is kind of how

I query it. This is an example of quering it locally. Slightly different GraphQL interface but pretty standard nice uh ways to query the data. Um and we come to a topic I thought was pretty interesting around kind of threshold. Um putting the multi and multisigs. Um, again, how safe are safes? I would say super safe from a security perspective, but we're looking at the actual usage. So, how safe are how are people using safes or uh what are the implications on there? And threshold ties into the number of signers needed to execute a transaction.

So, naturally, if you have a safe that's got two or four signers, the threshold there is two. You need two people to make to perform a transaction. uh and naturally the higher the threshold arguably the safer or more secure it is to make a transaction. However, it can be more um difficult to get a transaction through because you got to require multiple actors and it becomes a a coordination challenge. Cool. Okay. So, this beautiful visualization thanks to Excel is a simple table on the uh threshold of safes. Okay. So I think if we look here the first case there's about at the time I did this um I pulled

the data and you can see when we looked at the stat now it is much higher but there's about 45 million safes that have a threshold of one or more i.e. That's all all safes. Okay. And very very quickly after that, we get if you look at safes that have two or more signers, which is kind of the multi and multisig, we would expect it to be quite a bit higher, but the data is presenting as only 0.72% of safes that are deployed have a threshold of two or higher, which is pretty I mean, still pretty impressive.

I think it's maybe indicative that there's a lot of safes being deployed uh not for security measures. Um I think the safe team is really clever to be doing stuff like measuring total value that's get getting stored. I think that's a better northstar metric than what my data is implying. Again, I'm building the data set and answering questions as we go. Um the Okay, so we know world chain is linked to the orb. So we don't get the best results. So it's it's not going to be the most relevant for our data set. And as soon as I remove world chain from that query of who has greater than two threshold, we almost triple or double and a half um

the percentage of safes that have uh two or more signers. Great. You can see the difference between this number and this number is only about 252. So there's not a lot of secure safes on world chain or at least it's not being used for security largely in that regard. All right then again I can't give you exact reasoning for optimism or polygon but I thought it might be nice to remove those potential outliers and I think this highlighted number here is maybe a better reflection of what's actually happening. Again, uh it does seem lower than I would have expected, but about 15% of all safes in this scenario are have two or more signers. All right,

this has a lot of uh good questions to ask from it and maybe stuff we can do to improve our assumptions and and take a look at it a bit closer. Um because obviously safes are being used to custody funds. So what why are there such like outliers that are potentially skewing the data set? Cool. So this data has some implications. I would say take it with a pinch of salt. But um it implies that uh safes are used for more or they're not necessarily solely or majority used for security um or necessarily recoverability or I suppose threshold isn't tied to that or shared ownership. So maybe that's completely

inaccurate, but I think there's a large implication around flexibility. And I think this also kind of makes sense and correlates with what we've seen in more recent times with account abstraction. Uh flexibility of using smart contracts. It's uh gives you that program programmatic benefits. Um and we've seen it a lot with account abstraction. So quite cool to see that. That's actually a big and there's obviously a big push for account abstraction in safes the last year and a bit or since it's kind of come out or been popular because to be honest safes have always been a form of account attraction.

Um all right so we can go through some of the findings a little bit touch on it but uh these are some things we identified from looking at this data set and I'm going to go through some further questions we can ask the data set and maybe we can do a practical query into our existing data set um but the first finding was that by hack reduced safe usage I think this is semi expected because uh of the security measures safe put in place such as putting the um uh restricting the UI usage until things were a bit more uh clear and incrementally introducing that across other chains. World Chain is the biggest user of safes. Didn't know that

at all or at least they're the most the biggest uh users and deployers of safes. Um so interesting. Uh safe usage is very highly concentrated uh at least as the data implies. And this caught me off guard a bit and really uh motivated me to to maybe like u do some more data hygiene and uh make more assumptions into the data set to try prune it out a little bit more and get more meaningful answers. So I think there's a lot of um say bad data that's cues the results but however anyway 94 I think it was 96% of safe activities is on three of the 17 safe wallets supported networks. All

right and then the large majority whether there's good reason for not is that safes are not majority used for multi-signers. So there might be ownership or redundancy measures in place, but it's actually not heavily used for multiple signers in order to execute a transaction, but rather the programmatic benefits. At least that's what's implied. All right, further work. Um, I've touched on some of these in the talk. Um, but it would be great to to take the time and and go through the data in a little bit more detail, but that is to bucket the safes by thresholds and owners. I.e. We can do some analytics or questions around what the let's say the more secure wallets

are doing, how much is uh being stored there. Is there a correlation between uh value stored and number of signers? We'd expect it. You know, more money should be more secure. Um we could explore the difference in versions of saves. I think this might not be too exciting. We might just see what's expected that as the new versions have come out, we've seen a spike. But at the same time, I didn't expect to see what it I was looking at when I first started searching through the data. So I think there can be some unexpected results. It's worth doing an analysis on.

Um the analysis time periods to identify if type of safees has changed over time. I think I would love to get an idea of when account extraction became more popular whether we saw a big uptick in uh thresholds being lower or if that's not uh related at all. Um and then there's likely some bad data uh or it's permissionless. Anyone can deploy a safe um on networks that are more cheaper. You can say that the financial incentive to add a safe might be linked to trying to airdrop mining.

We've seen that quite a bit. Um and then we can also do some analysis based on what kinds of assets are actually stored in the safes. Um could prove for some interesting insights. Then I think another big question which I'd love to explore more which is kind of from the data or the results I was finding is whether uh safes are heavily used for cold or hot storage. So that active assumption I made, I don't think a year is the best reflection of a safe. If a safe or if if a safe's active, if a safe is um storing large amounts of funds, it's likely that it could only be doing transactions every few years. It's more of like a a storage cold storage vault.

Um so maybe there's some questions around the the act active period. Um redundancy ratios. Uh so this this ties into the ownership to threshold ratio um and effectively ties into security and like risk on how much redundancy is put into place. Um zombie safes I think this speaks to inactive safes and then uh it would be interesting to look at the actual signers and what their activities are. So for example, you'll see probably a healthy uh security measures to to add like dormant signers. So less active signers, but uh signers that are there for recoverability, i.e. break last keys

if all goes wrong. Um and to try analyze the actual user behavior of different signers. Cool. I've touched on a lot of uh safe data. I think there's a lot of questions to go into. I'd love to go through a practical example. Uh just to wrap up on the tooling I want to show you a little bit more about. So I've used the tooling specifically now for analyzing safe data, putting a data set together and then trying to ask a questions. Okay. But uh the tooling is tooling effectively. So it's designed to be used to uh answer kind of questions around different data sets. And there's been some really cool stuff that's been built on top of NVO. So, I just want to kind of show you some case studies on on

things that can be built. An example of that is Snub. If you know Revoke.cashe, uh Snub is like a multi-chain terminal tool for identifying if you've done unlimited approvals across different networks. Um that's built on top of Hypersync. It's super fast. Uh if you've used revoke cache, it's really cool as well, but it's not as multi-chain. And if you have a large if you have a or an address for example that's got a lot of history, it actually struggles to to pull that. Great news is they're actually starting to use S2. So hopefully that'll be a smooth experience. This is a headless block explorer. I say headless but not fully.

But it effectively just calls data from hypersync and it presents it as a in a UI. So there's no like pre-index data. It's just a block explorer. It's entirely using hypersync as its back end. Um we have log two and log rigregate another thing built on top of hypersync. Uh it's a terminal tool for analyzing event activity or uh distribution across an entire chain. So very quickly you can say give me the event count of uh all ERC20 transfers on mega test net and it'll spin up this cool graphic that you can look at. Uh, in fact, I can share my screen. So, let's do it.

I'm going to let's go log to ERC and let's do the example I gave. So, here you can see it's spinning up and it's scanning through the entire chain. It's going to be tweaky. We'll make it bigger. Um, and you can see we're processing huge amounts of events per second. Um, and it's slowly ticking up and it's not doing anything too fancy. It's just kind of giving us uh distribution of transfer events and approval events. Um, so early on there actually weren't many approval events probably because there weren't too many smart contracts. Um, and then logregate is a tool for it's very

similar to this. It does aggregation on events. So you can say what is the average USDC transfer on Sonic or what is the biggest it'll give you the aggregate information. Um so pretty useful in that sense too. Uh coming back to the slides chain density you checked it out sec I can share my screen. Um let's I don't know if someone has a contract or address in mind but I'm going to paste in whatever I pasted in before. I want to get event information or I don't know what network. I'm just going to click one of these pre quick example things. So we can look at the layers or let's op token. So this should be a little bit bigger because it's

obviously a lot of event activity and in real time. This isn't pre-indexed. It's going through hypersync and and counting all those events. So this will take a maybe a minute or two. I don't know exactly. So I'll let it run in the background and we can come back to the slides while it's going. Um there's uni. Great. Sorry, I thought I had to do everything pre. Uh here's a nice example of uh V4 data. You need to be V4 data. Uh it's real-time data, but it's um you can see all the activity happening. You can see the total stops increasing. You can see uh real time transactions happening. So this seems to be quite a bit of activity. People are trading

quite heavily. Uh maybe let's look at liquidity. I think this real-time liquidity is a bit slower. Cool. So, okay. So, it doesn't look like there's too many. Well, there we go. We got some things coming in, but really cool to see that stuff in real time. Also, obviously a chunky multi-chain index. So, you got all those different data points. Let's see if chain density is done. Yeah. Okay. So, it took 18 seconds. So, it wasn't too bad. But you can pass on any address on any uh hypersync supported network. We saw about 70 networks. Um, all right. And let's not waffle on too much. We can get to questions in a moment, but there's some really great feedback. Uh check it out on our landing sites. We really appreciate what people have to say. Uh

everything you're looking at on the landing sites, at least the publicly available stuff, but we do have an internal channel where we share this feedback and it's really motivating to to continue working on what we're doing. Um some resources and stuff to check out. Uh nvo.dev, dev. That's our site. You can check out the explorer, too. Uh, Invio_indexer is our Twitter account. I think it's on Firecast as YouTube. In fact, I'm Denim Pin on Twitter, Telegram, and might even be Discord. And then the this data set uh is actually still available. We I've got it hosting here, and you can click around and do some queries. Right now, uh, this shouldn't

be visible to you. Um, but because I'm I deployed it, I can see it. I don't really mind. People can go wild on queries on this. Um, and yeah, take a look at the data set, click around the playground, uh, get some data points. I don't know, safe transactions. I didn't didn't really look at the safe transaction data too much. Um and then yeah, just a little disclaimer, these figures offer directional insights but should be interpreted with caution. Additional context and deep analysis are needed to drive definitive conclusions. Um that being said, I think there's the data doesn't doesn't lie, but I think there's more factors to consider in showing what it what um what's actually happening. So to get more deeper insights.

All right. Should we go to some questions? I'll keep my screen share and we can it's a good question I suppose you can only look at signer behavior that got sorry the question was I know for the live recording was if we can look at serer behavior based on off-chain because we're looking at essentially onchain events and the maybe short of it is no that's not written to chain until it's executed. So we can't look at let's say pre-executed or failed uh signer behavior but we can look at maybe u you

know the time period between when a a signature is or like yeah how long it takes for certain signers to behave or is there a likeess it's probably quite like implied that if you've got two signers you have higher transaction throughput than uh if you got three or four signers or Yeah. Sign of behavior in relation to different things. You wouldn't be able to identify which signers. Yeah, I suppose you could you could kind of make an assumption if there's zero activity on a safe. No, you can't say who's dormant or not. Well, you'd argue maybe all of them are

dormant. But in the case where you have uh a wallet and every month this company is using it to action uh like bills and payroll things and you have um say two or four and two of those accounts are the ones that are signing every time you can make the assumption that the other two are dormant I would say. Yeah, but fair comment. We can't see what's not on chain. Yeah, but I suppose um there's probably some interesting insights to how the safe relayer operates. Cool. Are there any other questions?

Maybe around the tooling, maybe around the data set. Um, could it be possible to maybe make a distribution and say this safe signer has signed this many transactions across this many safes and then you can see like a heat map for who the most popular signers are. Something like that. Absolutely. Um, I think if we look at this code that could be quite interesting. Maybe there's a few kingpins who signing a lot of the transactions. What are they doing? True.

And you can maybe look at some collusion activity. I don't know why you would separate it, but hey. Um, if I look at the code here, so I showed it to you really simply, but we essentially have three files that we care about. It's the config, the event handlers, and the schema. So it would be pretty straightforward to simply say type ser give it an address um probably not a chain ID uh let's just see what AI has to give us and we could assign it would be an EOS so have the same chain ID per address we could save this information in a handler and

effectively I mean it's quite nice how this spins it up it's super quick with AI these days but you can see all the safe link to and you can see all the safe transactions that they've operated on. You can do queries like uh what is the number of transactions they've done for uh across like all networks. I don't know you can get interesting sign information too for sure. Yeah. Um yeah, I think there's some very interesting data points available. Um, this config is going to look slightly more complex than what I showed you, but there's really uh nice data points to to unpack.

How many how much has been spent on failed executions? I think we can answer that. We can answer that question right now. Um, let's see if we uh Yeah, sure. So if I want to look at let's take a look at the data set again. Uh execution failures. Oh, I think I've got the wrong I think I need to essentially index that data. Right now I'm not indexing the raw events. I'm just indexing it into specific things. But we can look at I don't know safe total gas spent.

Um let's take a look at that where total gas spent. Let's get the idea of it. Let's take a look at one of these in real. Let's order by total gas spent descending and let's see. So, obviously big data set. This isn't going to be too instant. Um, but once this question's answered, we can take the top one and try figure out what that is on a block explorer. For sure said chain ID. Um, let's give that a chance.

The other thing to note is to put uh I should put Okay, so it looks like we got an error there. Classic demo live demo. Um what I could do as well here is is add query optimizations which I haven't actually done for this but you see here when you add an add index it it'll index that and it'll make it better to query the data at least for comparison stuff. But cool. I'm not going to waffle on. Uh if there any other questions, give me a shout. Otherwise, happy to chat after this. I will be around for the rest of the event. We have a booth downstairs, so come chat to us. would love to unpack possible other use cases