Multisig in Motion: Analyzing Safe Data in Realtime Using HyperIndex

Cool, quick sound check. Sweet, all right. Gutenabend.com 2025. I'm very excited to be here for the second year in a row.

Today I'm chatting about multi-sigs in motion. The workshop we're going to do is going to be a little bit interactive. There will be some tools to play around with, and my title is multi-sigs in motion. Now, specifically I've focused on safe data, being that maybe blue-chip de facto multi-sig wallets, smart contract wallets. 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 Q&A after. My name is Denim, pronounced like the jeans.

I'm one of the co-founders of a project called Envio. I'm a believer in the tech and not the hype train. I have an academic background in computer science, anarchist at heart, and super grateful that my past led me on to being a developer, and probably been in the space since mainnet gas prices allowed for a little bit more experimentation. I think relevant to the talk, a little bit more about me. I am a Puli holder, a Groundstar member, and notably a SACE guardian, which means I partake in the active governance around SACE, but that is the closest affiliation I have.

I've been passionate about the project for quite a while, got involved with some smaller dev stuff early on. Viable is for builders. Okay, a little bit of a boast slide, but I just mean to give us a little bit more credibility. We are a team of 10, mostly technical. We have built production systems for ourselves and some external things in the past, being kind of core dev teams, hosting or deploying smart contracts that hold well over $100 million, which is peanuts compared to SACE.

Hats off, very secure. At least our software hasn't been hacked to date. We've spoken at a few different conferences around the world. I can see my co-founder there. I know he's a Sir, 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 Envio, the tooling, and how we use it to build a real-time dataset. And with this dataset, we can create 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 part 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 essentially find further, more meaningful insights. But this is just initial insights into how we can look at 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 really focus on is making that public data a lot more easier to access by making it more performant. All right. So, I'm going to chat about the dataset itself and the tooling in order to create this real-time dataset. 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 kind of safe adoption, which I think was a really interesting insight into general chain adoption and maybe a truer metric on kind of a non-vanity metric in terms of ecosystem adoption for chains. And then the last one is how safes are safes. And again, super secure at a smart contract level, but I'm more talking about how people are using safes operationally, applying to like how many owners, what's the threshold set, and how they're actually being used. Cool.

All right. So, first let's just touch on why would somebody use a safe? All right. Usually, I mean, there's a bit more to it maybe, but here are some kind of high-level notes on it. So, they want extra security.

All right. So, you have better security than using something like an EOA. You have the optionality of shared ownership, and a big one is non-repudiation or repudiation because you've got a better way of sharing ownership over funds. Usually, there's recoverability. If there's a sign that it gets lost, you can recover from that.

And then I think a less spoken one is actually flexibility, and it ties into the fact that this is a smart contract. So, those are maybe some of the reasons why one would use a safe. And then, I'm interested to hear is using Metri. I hope everybody at this point has been around the conference, but Metri is awesome. They've been using our tech.

They index about 250,000 safes, essentially, and about 50 million events, and this kind of scale that they needed did motivate our kind of product direction to be very scale-driven. Yeah, their tool is really cool and pumped to be kind of a data provider in that, but there was some of the motivation around exploring safes in more detail. All right. Just to break it down a little bit, we have two core products. We have HyperSync and HyperIndex.

Now, HyperSync, it's important to note, but most of what we're going to chat about is HyperIndex. HyperSync is this raw data engine beneath. It's kind of like a node. You can access RPC data. You can get this data, but it's designed for getting data.

In fact, my talk last year at DAPCon was around HyperSync and some of the nooks and crannies and some of the secret sauce to how that's so much faster, but if I have to be honest, I think one of the biggest things just known to us, blockchains weren't designed for big data. They're more, or nodes are more focused on consensus, and as blockchains have gotten more and more data-intensive, having longer history, it's become more and more important, and we took a lot of Web 2.0, modern database technology, and then started applying it to Web 2.0 space. Cool.

So, HyperSync and then HyperIndex is maybe the framework that allows you to aggregate this raw data into information. Cool, and we'll go into that in a little bit more detail. All right. So, HyperSync can be seen as an engine that feeds into HyperIndex as well, but it can also be an engine that feeds into other tooling, and we'll 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.

All right. We get to our first slide. I hope it is big enough to see what's going on. This is the, so pretty simple, this is SafeToken on the Ethereum mainnet, and this chain density tool is used to look at transaction or event density over time. So, the x-axis is blocks 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 first off, and we can see two big spikes. Can anyone figure out what those two spikes might be? I think the first one's quite a given. Yeah, there we go.

Something's nice. So, this is fetching data from HyperSync. It's doing it in real time. I just pass in the contract address. 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.

This is specifically SafeToken. The next one's SafeVersion4. All right. 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 where it became transferable, and we can see that spike. Cool.

Let's go into a bit more into safe data rather than just SafeToken. All right. So, again, I'm looking at a single contract. We will look at more kind of cross-multi-networks, but again, kind of interesting to see what's happening here. So, 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, and so we can take a look at that closer, but the Fivert hack, this is more of a kind of a social engineering hack, 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 imply more about the fact that Safe were very good with their security measures that they implemented in place. They reduced the feature, like what you could do on the UI as a precautionary measure, and so this kind of transfer could be correlated with that. Again, really cool to see this data getting pulled really fast. This is the same contract. Again, some smart devs noticed this, or at Safe, because that's the same contract address, obviously using Crate 2 or just clever deployment implementations, and you can see that, again, that Fivert dropped off in activity, but soon recovered quite soon after.

Cool. Again, we're looking at the Safe token, coming back to that graph, and we can see the activity kind of at the Fivert hack. It's an increase in volume, not necessarily an increase in price, so there was, 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 more exciting stuff. This is pretty dark on my screen.

I hope you can see it, too. This is the first indexer I deployed, and what it's indexing is all Safes that get created. This is the first dataset I created, and I've used all 17 Safe wallet-supported networks. Obviously, Safe is open source, anyone can deploy. There's a caveat.

There's an 18th network, which I didn't go into the details of it. I've got all these networks, and you can see we've got 45.5 million events. These are all Safes being deployed. This is an initial Safe dataset, and it's kind of indicative that there's about 45.

5 million Safes being deployed across these networks. A little flex, it took about an hour to deploy on our hosted service infrastructure, which is about 30,000 events per second, which is, to be honest, on the high end of our performance. This initial dataset I looked at, and we can go into more in-depth datasets, just to show you what they look like in terms of the schema. If you're not familiar with code, don't stress. This is pretty simple.

This is a simpler way of showing it, but this is the information points that I've abstracted from Safes getting set up, all right? We have an ID, a proxy, singleton, chain ID, because it's a multi-chain indexer, and a version. So it's super straightforward. We can look at the data across different networks. I just want to interrupt myself quickly.

If anyone has any specific questions, 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 go through different things. This was the initial dataset that I can ask some questions around, okay? And this is the distribution across chains. Now, I didn't know that WorldChain 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 dev rel from WorldChain, and of course, it's because all the configurations of wallets on WorldChain are done with Safes. That's great. As you can see, that's the biggest deployer of Safes. It kind of makes sense. Anyway, so I knew that this was maybe a bit of an outlier in the dataset, and so I looked at it, and we're going to go into that in a bit more detail.

So some initial interesting findings. WorldChain accounts for about 59% of all Safes created. Big users. I've got a meeting in a few minutes. So this is the stats I got from the next deployment.

I'm cheating a bit in terms of order, but WorldChain accounts for 65% of all Safes activity, which does indicate more transactions to Safes or events. Then the other thing I kind of came to realize is that there's a super high concentration of Safes. So if we look at WorldChain, Optimism, and Polygon, they are by far the biggest environments that people have deployed Safes. It's a permissionless environment. There could be a lot of unaccounted for.

There's a lot of spam data that skews the Fed, but it was interesting to see that there's quite a heavy concentration of those 50 million Safes deployed. All right. So last statement there. Between WorldChain, Optimism, and Polygon accounts for 96% of all Safes created. So quite a heavy concentration for three networks across 17 networks.

All right. I did another deployment, and this is mostly to help me with the querying. I bought another data set. I removed WorldChain, and the index that was indexing all Safe events, say all the Safe caveats, was 430 million events, and without WorldChain, we came out to 150 million events. But through some simple filtering stuff, we were able to eliminate the WorldChain stats on it too.

All right. So this is what it looks like if we remove WorldChain. You can see it's starting to have a slightly better distribution, and then this is what it looks like if we remove both WorldChain, Polygon, and Optimism, which may have perfectly accurate data. However, they do seem to skew the results enough that I thought, let's 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 mean, there's obviously a lot of vanity metrics around network adoption, but Safes are usually quite a, let's say, power user thing to use. And I would say this fairly actually reflects this. Most of the chain is quite popular. Ethereum maintenance, of course, popular, base popular, and then some of the smaller chains like Polygon, ZK, EVM having less traction. Avalanche chain is 3%.

Cool. Yeah. Now it's slowed down a little bit because we had a much larger data set, but a big, 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 entry index, but this is the data set that I saved that I could query. Okay. So 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, ask some questions. We can also ask questions around the total gas a safe has spent.

And for example, if we wanted to see highly active safes, we could query or filter by total gas spent being greater than a certain number. So another way of maybe doing better data hygiene on that data set. Then we have a lot of information on safe transactions. 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 information, is looking at execution dates.

So how many states are quite active and do we look a year back or do we look two weeks back and we can bucket our data sets into different things. So this data set's really great. Let me actually just do a little quick pause here and show you that this is actually live and queryable. So this is currently deployed. I'll share the link at the end.

However, you can also just go straight to envir.dev, Explorer, search safe, and you can get these different data sets. So you can see here what the three different deployments are. Interestingly enough, since making the deployments, this is 150, I think, in the screenshots. So you can see it's indexing in real time.

This is picking up as we get more data in it, and I can actually come here and do the queries. So let's get safe, the ID, the chain ID, 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 it.

I just want to show you that it's real and live and the data can be interpreted. All right. Cool. So what happens is this is what the data schema looks like, and it creates this row as it gets populated. And this is just the kind of things that you can see that table tangibly on the data being saved and us being able to query it.

All right. This, again, it can look a little bit like code, but it was actually probably the easiest way to show this. These are the events related to safe that we're indexing. So we're taking all these events and we're plugging it into our tool and saving that into our database. And we process them.

So it's super simple. If we have, for example, an added owner, we can update that safe and update the owners that are linked to it, or they change the threshold, et cetera, et cetera. 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 the number of safes that have a higher threshold than just one.

Ideally, it needs multiple signers, multiple people to sign a transaction. And I wanted to see if they were active in the last year. So this execution date is if they've got a safe transaction that happened that's greater than a year ago today. So we get an idea of active face and the threshold, and we can get an idea of the counts that's related to other things. So this is kind of how I queried.

This is an example of querying it locally in a slightly different GraphQL interface, but pretty standard, nice ways to query the data. And we come to a topic I thought was pretty interesting around thresholds, putting them multi and multi-fixed. 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 people using safes?

Or what are the implications on it? 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 is two. You need two people to perform a transaction. And naturally, the higher the threshold, arguably the safer or more secure it is to make a transaction.

However, it can be more difficult to get a transaction through because you've got to multiple actors and it becomes a coordination challenge. Cool. Okay. So this beautiful visualization, thanks to Excel, is a simple table on the threshold of safes. Okay.

So I think if we look here, the first case, there's about, at the time I did this, I pulled the data and you can see when we looked at the stat now, but there's about 45 million safes that have a threshold of one or more, i.e. that's 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, multi thing, 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 a lot of safes are being deployed not for security measures. I think the safe team is really clever to be doing stuff like measuring total value that's getting stored. I think that's a better asymmetric than what my data is implying. Again, I'm building the data set and answering questions as we go.

The, okay, so we know World Chain is linked to the Orb, so we don't get the best results. 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 the percentage of safes that have 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, it does seem lower than I would have expected, but about 15% of all safes in this scenario have two or more signers. All right.

This has a lot of good questions to ask from it and maybe stuff we can do to improve our assumptions and take a look at it a bit closer. Because obviously, safes are being used to custody funds. So why are there such outliers or potential schema data sets? Cool. So this data has some implications.

I would say take it with a pinch of salt. But it implies that safes are used for more... They're not necessarily solely or majority used for security or necessarily recoverability. Well, 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 subtraction. Flexibility of using small contracts, it gives you that programmatic benefit. And we've seen it a lot with account subtraction. So quite cool to see that that's actually a big... And there's obviously a big push for account subtraction in safes last year and a bit since it's kind of come out or been popular.

Because to be honest, safes have always been a form of account subtraction. All right. So we can go through some of the findings a little touch on it. But 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.

But the first one is a private track reduced safe usage. I think this is seemingly expected because of the security measures safe put in place, such as restricting the UI usage until things were a bit more clear and incrementally introducing across other chains. World Chain, the biggest user of safes, didn't know that at all, or at least say the biggest users and deployers of safes. So interesting. Safe usage is very highly concentrated, at least as the data implies.

And this caught me off guard a bit and really motivated me to maybe do some more data hygiene and make more assumptions into the data set to try prune it off a little bit more and get some more meaningful answers. So I think there's a lot of bad data that skews the results. But however, anyway, 94, I think it was 96. Safe activities is on three of those 17 safe wallet 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.

I've touched on some of these in the talk, but it would be great to take the time 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 being stored there. Is there a correlation between value stored and number of signers?

We'd expect it. More money should be more secure. We could explore the difference in versions of safes. I think this might not be too exciting. You might just see what's expected as a new version has come out.

You've seen a spike. But at the same time, I didn't expect to see what 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. The analysis time period to identify a type of safe has changed over time.

I think I would love to get an idea of when accounts distraction became more popular, whether we saw a big uptick in thresholds being lower, or if that's not related at all. And then there's likely some bad data, or if permission is given, we can deploy a safe on networks a little bit more cheaper. You can say there's a financial incentive to add a safe. It might be linked to airdrop mining. We've seen that quite a bit.

And then we can also do some analysis based on what kinds of assets are stored in the safe. It could prove for some interesting insights. Then I think another big question which I'd love to explore more, which is from the data or the results I was finding, is whether 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 is active, if a safe is storing large amounts of funds, it's likely that it could only be doing transactions every few years.

It's more of like a cold storage vault. So maybe there's some questions around the active period. Redundancy ratios, so this ties into the ownership to threshold ratio and effectively ties into security and risk on how much redundancy is put into place. Zombie safes, I think this speaks to inactive safes. And then it would be interesting to look at the actual signers and what their activities are.

So for example, you'll see probably a healthy security measure to add dormant signers. So less active signers, but signers that are there for recoverability, i.e. break glass keys. This all goes wrong.

And to try to analyze the actual user behavior of different signers. Cool. I've touched on a lot of safe data. I think there's a lot of questions to go into. I'd love to go through a practical example.

Just to wrap up on the tooling, I want to show you a little bit more about... So I've used the tooling specifically for analyzing safe data, putting a data set together, and then trying to ask questions. But the tooling is tooling effectively. So it's designed to be used to answer questions around different data sets. And there's been some really cool stuff that's been built on top of NBO.

So I just want to show you some case studies on things that can be built. An example of that is snub. If you know revoke.cache, snub is like a multi-chain terminal tool for identifying if you've done unlimited approvals across different networks. That's built on top of HypeSync.

It's super fast. If you use 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 EOA or an address, for example, that's got a lot of history, it actually struggles to pull that.

Great news is they're actually starting to use that too, 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 HypeSync, and it presents it in a UI. So there's no pre-indexed data.

It's just a block explorer that's entirely using HypeSync as its backend. We have log3 and logregate, another thing built on top of HypeSync. It's a terminal tool for analyzing event activity or distribution across an entire chain. So very quickly you can say, give me the event count of all ERC20 transfers on MegaEth testnet, and it'll spin up this cool graph that you can look at. In fact, I can share my screen, so let's do it.

I'm going to... Let's go log3 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 a bit tricky, but I'll go log3 ERC20 transfer events per second. And it's slowly picking up, and it's not doing anything too fancy.

It's just kind of giving us a distribution of transfer events and approval events. So early on, there actually weren't many approval events, probably because there weren't too many smart contracts. And then logregate is a tool for... It's very similar to SONIX. It does aggregation on events.

So you can say, what is the average USPC transfer on SONIX? Or what is the biggest? It'll give you the aggregate information. So pretty useful in that sense too. Coming back to the slide, chain density, you checked it out.

I can share my screen. 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 it is. I'm just going to click one of these pretty quick example things. So we can look at the ILS, or let's say, OP token.

So this should be a little bit bigger because it's obviously a lot of events activity. And in real time, this isn't pre-indexed. It's going through hypersync and counting all those events. So this will take 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. Great. Sorry, I thought I had to do everything pre. Here's a nice example of v4 data. You need v4 data.

It's real time data, but you can see all the activity happening. You can see the total swaps are increasing. You can see real time transactions happening. So this seems to be quite a bit of activity. People are trading quite heavily.

Maybe a little bit of liquidity. I think this real time liquidity data is a bit slower. Cool. Okay, so that 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've got all those different data points. Let's see if chain density is down.

Yeah. Okay, so it took 18 seconds, so it wasn't too bad. But you can pass in any address on any hypersync supported network. We saw about 17 networks. All right, and let's not waddle on too much, because we can get to questions in a moment.

But there's really great feedback. Check it out on our landing sites. We really appreciate what people have to say. 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 continue working on what you're doing. Some resources and stuff to check out, envio.

dev. That's our site. You can check out the Explorer too. envio underscore index is our Twitter account. I think it's on Firecaster as well, and YouTube, in fact.

I'm Denon Preen on Twitter, Telegram, and my Envy Discord. And then this data set is actually still available. I've got it hosting here, and you can click around and do some queries. Right now, this shouldn't be visible to you, but because I deployed it, I can see it. I don't really mind.

People can go wild on queries in this. And yeah, take a look at the data set, click around the playground, get some data points. I don't know, save transactions. I didn't really look at save transaction data too much. 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. That being said, I think the data doesn't lie, but I think there's more factors to consider in showing what's actually happening, so to get more deeper insights. All right. Should we go to some questions?

I'll keep my screen shared so we can... You mentioned that one potential use case, one of the good things you can work on is looking at signer behavior. Yeah. Is that something you can capture from watching data? It's a good question.

I suppose you can only look at signer behavior that's got... Sorry. The question was, I know for the live recording, was if we can look at signer behavior based on off-chain... Because we're looking at essentially on-chain events, and the maybe... No, that's not written to chain until it's executed.

So we can't look at, let's say, pre-executed or failed signer behavior, but we can look at maybe the time period between when the signature is... Yeah. How long it takes for certain signers to behave, or is there a likeness? It's probably quite implied that if you just put two signers, you have a higher transaction throughput than if you've got three or four signers, or yeah, signer behavior in relation to different things. You wouldn't be able to identify which signers?

Yeah. I suppose you could 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 a wallet, and every month this company is using it to action like bills and payroll and things, and you have, 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 there's probably some interesting insights to how the safe relay operates.

Cool. Are there any other questions? Maybe around the tooling, maybe around the dataset? 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 a heat map for who the most popular signers are, something like that?

Absolutely. I think if we look at this code, that could be quite interesting. Maybe there's a few kingpins who are signing a lot of the transactions. What are they doing? True.

And you can maybe look at some of those. I don't know why you would separate up those here. 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 signer, give it an address, probably not a chain ID.

Let's just see what AI has to give us. And we could assign it would be an EOS that has 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. But you can see all the safes they're linked to, and you can see all the safe transactions that they've operated on.

And you can do queries like, what is the number of transactions they've done across all networks? I don't know. You can get interesting sign information too, for sure. Yeah. I think there's some very interesting data points available.

This config is going to look slightly more complex than what I showed you, but there's really nice data points to unpack. How much has been spent on failed executions? I think we can ask that question right now. Let's see. If we say, yeah, sure.

So if I want to look at, let's take a look at the dataset again. Execution failures. Oh, I think I've got the wrong, I think I need to essentially index that data. So right now I'm not indexing the raw event. I'm just indexing it into specific things.

But we can look at, I don't know, safe total gas spent. 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 datasets, this isn't going to be too instant. But once this question is answered, we can take the top one and try to figure out what that is in the blocking flow, which is the chain ID. Give that a chance. And the other thing to notice is to put, I should put, okay, so it looks like we had an error there.

Classic demo, live demo. What I could do as well here is add query optimizations, which I haven't actually done for this. But you see here, when you add an at index, it'll index that and it'll make it better to query the data, at least for comparison stuff. Cool. I'm not going to waffle on.

If there are 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.

We'd love to unpack possible other use cases.