Jim Cousins GRTiQ Podcast The Graph Indexer Wave Five and Member of The Graph Council

GRTiQ Podcast: 01 Jim Cousins

Episode 01: An interview with Jim Cousins with Wave Five, an active Indexer at The Graph. In addition to being one of the first Indexers involved in the project, Jim serves as a member of The Graph Council, which was formed by The Graph Foundation to be a governing body responsible for balancing the interest of core stakeholders as The Graph moves towards total decentralization. The conversation with Jim covers a range of important topics, from the relationship between Indexers and Delegators, to the basis for that 28-day “thaw period,” the recent debate regarding GIP2, and the much-anticipated move of the protocol from the testnet to the mainnet.

The GRTiQ Podcast owns the copyright in and to all content, including transcripts and images, of the GRTiQ Podcast, with all rights reserved, as well our right of publicity. You are free to share and/or reference the information contained herein, including show transcripts (500-word maximum) in any media articles, personal websites, in other non-commercial articles or blog posts, or on a on-commercial personal social media account, so long as you include proper attribution (i.e., “The GRTiQ Podcast”) and link back to the appropriate URL (i.e., GRTiQ.com/podcast[episode]). We do not authorized anyone to copy any portion of the podcast content or to use the GRTiQ or GRTiQ Podcast name, image, or likeness, for any commercial purpose or use, including without limitation inclusion in any books, e-books or audiobooks, book summaries or synopses, or on any commercial websites or social media sites that either offers or promotes your products or services, or anyone else’s products or services. The content of GRTiQ Podcasts are for informational purposes only and do not constitute tax, legal, or investment advice.


We use software and some light editing to transcribe podcast episodes.  Any errors, typos, or other mistakes in the show transcripts are the responsibility of GRTiQ Podcast and not our guest(s). We review and update show notes regularly, and we appreciate suggested edits – email: iQ at GRTiQ dot COM). The GRTiQ Podcast owns the copyright in and to all content, including transcripts and images, of the GRTiQ Podcast, with all rights reserved, as well our right of publicity. You are free to share and/or reference the information contained herein, including show transcripts (500-word maximum) in any media articles, personal websites, in other non-commercial articles or blog posts, or on a on-commercial personal social media account, so long as you include proper attribution (i.e., “The GRTiQ Podcast”) and link back to the appropriate URL (i.e., GRTiQ.com/podcast[episode]).

Welcome to the GRTiQ Podcast. Today I’m speaking with Jim Cousins with WaveFive, an active Indexer at The Graph. In addition to being one of the first Indexers involved in the project, Jim serves as a member of The Graph Council, which was formed by The Graph Foundation to be a governing body responsible for balancing the interest of core stakeholders as The Graph moves towards total decentralization. My conversation with Jim covers a range of important topics, from the relationship between Indexers and Delegators, to the basis for that 28-day thaw period, the recent debate regarding GIP2, and the much-anticipated move of the protocol from the testnet to the mainnet. I started the conversation with Jim by asking how he first got involved in cryptocurrency.

That’s a long time ago, that would have been back in 2012 was when I first saw Bitcoin. And it was a Slashdot, if you can remember the website Slashdot. Back in the day, there was an article there about Bitcoin. And previous, maybe a couple of years before I found Bitcoin, I was kind of on a personal journey, to understand money in more and more detail, because I feel like, you know, most people go through their lives not really understanding what money is. I started on that journey and found Bitcoin along the way and sort of fell in love with the Austrian economics viewpoint on money. And over the years, continuing to sort of foster that interest in Bitcoin I tried mining back in the early days with some of the earliest mining equipment that was made by a company called Butterfly Labs, which many of the people from back in that day will remember; gave up on that pretty, pretty quickly, when I realized that if I just held on to the Bitcoin that I spent on that miner, I would have done far better than actually trying to mine. And then moving through the years, I started to diversify my Bitcoin. So I started essentially, to become an investor. And I went through the typical investor rookie investor cycle of, you know, not managing my risk and losing lots and lots of Bitcoin. And after that happened, I sort of took a step back and started taking the idea of investing in the crypto space very seriously. And that was around 2013/2014. And that sort of put me in the direction of looking at things like Ethereum. And I invested in that when, when the presale came along, I invested in a few other things, which are, you know, projects that never really took off. And found that I got a great deal of satisfaction in sifting the real signal from the noise in the crypto space. And as I seem to have a talent for it, but I continue to do that all the way through, all the way up to present day. And I didn’t really in any way link my professional background in IT into specifically into the crypto side of things. All I did was I took the capital I was you know, making from various crypto investments, and I would roll it forward into new crypto investments. I would never actually take my engineering skills and apply them in the crypto space, I tried to keep the two worlds very separate. Because at that, you know, back in that day, it was very controversial to be involved in these things. And some of the opinions that people would hold around crypto could be thought of as quite controversial, whereas today, they’re not so, so controversial.

When did you first become aware of The Graph?

So funnily enough, I was talking with a friend about when I came across The Graph only a week ago and found the exact tweets, in fact, where I was engaging with Yaniv from The Graph, now Edge & Node, discussing the start of Mission Control, which was the name of the Indexer testnet, that The Graph ran in 2020. And it was a response from Yaniv that basically said, you know, it doesn’t matter if you’re a, what you might call an industrial level validator, this, you know, it’s got a lot of assets under management, and validating across many, many networks, or if you’re one guy, you know, with one server, just essentially a hobbyist node operator, The Graph wanted to get all types of different node operators involved. And as soon as I got that sort of feedback from Yaniv, I was in, because that’s exactly what I am, right? I’m a hobbyist at the end of the day. That’s where I started out as a tinkerer. I obviously have my career, which is technical engineering. But I could take all of that in that sort of knowledge and apply it here to The Graph. And it was, you know, the combination of the team being very interactive with people, and also just being totally… I call this a mind virus, right? It’s the same thing that happened when I first found Bitcoin, you find some new technology that you’re interested in, and it’s just so enamoring to you that you just keep reading and reading about it. It’s just, you know, you found something special, right. So that’s what The Graph was to me. So that would have been around… It would have been late July, early August in 2020, just before the testnet started.

The Graph can be difficult to understand. How do you explain it to others?

Yeah. And that’s a good question. And I asked this question to other people as well, quite a bit. And it’s a difficult one to explain. Because you have to get into the concept of distributed apps (dApps), right. That’s in order for it to make sense. The difficulty with the “Google of blockchain” piece is that there are so many technical achievements required between Google and The Graph that, you know, it’s difficult to draw that analogy from fundamental thinking. I prefer to just talk about the actual practicality of The Graph itself, right. So we have these blockchains, which are very, very inefficient databases, we need a service that can process the data and make it available to developers, right? Developers have the option to build that infrastructure themselves. So they could run servers that pull data from the blockchain, which is a very, very intensive process, it takes a lot of computing power to do, and a lot of complex software. So we could have millions of developers out there all learning how to do that themselves. Or we could have a single service, which was The Graph, which allows people to sort of come together and work on a single platform that can deliver that data from any blockchain. And for any dApp, that somebody wants to index for, right? And what’s the end goal here? At the end, the goal is that we want data. You know, right now, there’s a lot of focus on financial data. Now we’re seeing more focus on the NFT space, right? So that’s a similar but slightly different space that has different needs.

How do you think about The Graph’s current market adoption and the existing userbase?

I mean, this was one of the main selling points for me when I first joined the testnet. It’s very rare to find a crypto project that has an already existent userbase, a successful product. In most cases, the temptation to sell out as a, what they call a Software as a Service (SaaS) platform, is just so great that teams will often just go that route. And what I mean by that is, whatever service they create never ends up being decentralized. It just stays as a central service. And you know, they charge a certain amount per month for everybody to use it. The Graph, the whole team at The Graph, Edge & Node now, are very focused on decentralizing the product. So what we have today is a hybrid, where there’s one what I sometimes call a “mega Indexer,” which is The Graph hosted service, which has been running for a long time now. I think they’re up to 14.5 billion queries per month at this point in February [2021]. This is a centralized service, or essentially a large Indexer, that Edge & Node run. And that’s the service that’s currently supporting, I believe it’s over 9,000 subgraphs now. So any data that you might see on a website like Uniswap.info or on the Synthetix websites, the data in those dApps is being provided by The Graph hosted service. Now, beside The Graph hosted service, you also have Graph protocol mainnet, which is where the decentralized Indexers live, which is where the Curators will live, it is where the Delegators live. And that’s basically taking the model of the hosted service and just breaking it up into many separate Indexers all running on their own infrastructure with their own operational procedures. But running some extra software that allows us all to sort of work together to provide service to the network. Where we’re at today is, we have one subgraph running on the decentralized network. That’s the PoolTogether subgraph. And there are queries running through that right now, as test data basically. And over the rest of this year is expected that the subgraphs that run on the hosted service will migrate over to the decentralized service, which is the point where individual Indexers will start to see more query business coming their way, if they decide to allocate stake to specific subgraphs, the exact dates for that we don’t know at this point, but we’re all very much prepared. You know, the whole point of bootstrapping the network is so that when that business comes along, Indexers are ready to support it from day one.

The move from the testnet to the mainnet seems like a big deal. Should we expect any technology issues? Or should the Delegator community have any concerns?

The first thing I would say, just sort of like as an overarching comment, is decentralization is not easy, right? Good things don’t come easily. So this is brand new sort of territory for most projects to take an existing centralized project and to decentralize it. So, you know, I’m a pragmatist. I’m a realist, right. So there’s likely to be hurdles along the way, there were hurdles along the way, all the way through the testnet. And the entire point of having testnet is so that when we reach those hurdles, we deal with them before they become problems. So, you know, before we even talk about what migration would feel like, I think it’s important to talk about how we mitigate issues before they hit the mainnet itself. And the key way that we do that… I’m just talking as an observer here, right? I’m an Indexer. I’m a Graph Council member, but I’m not part of Edge & Node. So I don’t… I’m not part of the development process, from the outside as an Indexer looking in, thinking about how do I make sure that I provide sort of, you know, the service during migration and, you know, mitigate any issues, Edge & Node have committed to running continuous testnet now. So there’s a live testnet running, which runs, I think it’s a slightly more updated version of the sort of the Indexer software stack right now. And as we get closer and closer to migration, part of that roadmap is updating that software that we use, and testing that software that we use to make sure that when we get to the migrations on mainnet, you know, all the bugs have been handled, or the majority of bugs have been handled. So saying that from a Delegator’s point of view, migration won’t actually you know, there’s nothing that Delegators will have to do themselves, proactively. But, thinking, if I’ve just put my Delegator hat on for a minute, the things that I would be doing is, I might spend my time at the moment in the Delegator’s channels in Discord. But maybe I would spend some time looking at what’s happening in the Indexer software channel, where the Indexers are talking about, you know, the challenges they’re seeing in the testnet, talking directly with the Edge & Node engineers, and founders, about how we’re going to fix certain problems, keeping an eye on the GIP processes as well, too. So, that’s The Graph Improvement Process (GIP) or how we apply governance in order to make changes to the network. But you know, from an entirely practical point of view, there will be no, there’ll be nothing that the Delegators will need to do proactively, as far as I’m aware. It’s just a matter of, you know, keeping your ear to the ground and just keeping an eye on what’s happening with the network, not relying on somebody else to give you that information. But you know, diving in yourself and finding out what’s going on.

Following the move from the testnet to the mainnet, do you expect to see more market adoption of The Graph?

I think so. It’s, you know, I guess an analogy would be like upping anchor on a ship, right? You’re, you’re no longer tethered to the old system. I mean, it doesn’t do, that analogy isn’t perfect, because, the migration is not a one-shot operation. It’s going to be gradual, you know, there’s 9,000 subgraphs. They don’t have to all migrate at the same time. There’s going to be a gradual sort of process where, you know, tranches of subgraphs might move over. Again, I’m speculating here, all of that sort of roadmap is with Edge & Node. But from what feedback that we get as Indexers when we talk to the team is that it’s going to be a very, you know, we’re not just going to be all or nothing, it’s definitely not an all-or-nothing type situation. If there are problems, there’ll be addressed as we go along. And, you know, subgraphs will come in gradually, many reasons for that, not just about, it’s not just about the risk side of things, it’s also Indexers are going to have to build up the process of managing all these subgraphs, right? Because, you know, the software, the Indexer software, will take you so far, in terms of managing it. But there’s a lot of automation to be done, you know, if an Indexer has, I don’t know, 100 subgraphs to manage. They can’t manage that manually, right? They need to automate the process. So there’s lots of things that are going to benefit from a very gradual migration of subgraph over, you know, it might start with one subgraph, but we’re, I guess we’re there already with PoolTogether, and then they’re just going very gradually ramp that up over time and iterate on the software as we go. A cautious approach.

It looks like The Graph has some competition. How should we think about that?

Competition does exist in certain forms. There are various other platforms out there. One that comes to mind is Dune Analytics. And these, most of these, solutions that I’ve seen are centralized solutions. So they’re very sharp. Think of them as like razors, right? So they’re very sharp ended. They have specific goals, and they do them very well. But they’re centralized. The Graph protocol is sort of going in the opposite direction. So it’s decentralizing the whole, the whole mechanism of providing data to a dApp. Some people were like, “So what, what is The Graph protocol’s moat?” And, quite frankly, I think it’s a very similar moat to Ethereum itself, as an example, right. Right now we see a lot of new, what they call, I guess, Ethereum killers, coming to fruition at this point, are really starting to now show their head as, you know, their better transactions, or there’s some element of the trilemma – the decentralization trilemma that they do better than Ethereum does, right. But Ethereum continues to be the king when it comes to smart contracts. The moat with Ethereum is the community, right? One of the hardest things for any new project to do, and it’s one of the reasons why good community leaders are super rare, is building a community that actually sticks. It’s very clear that Ethereum has done that and continues to do that. You see all the different types of initiatives that are going on around Ethereum. You see the continued success of rough consensus on Ethereum governance. Yes, some of the upcoming projects have communities. But is it too late now for them? Maybe, I’m not sure. I personally believe in the multi-chain world. But I still think Ethereum sits at the top of that hierarchy. Similarly, with The Graph, I think it’s very much hinged on the communities within The Graph. And there’s many of them, right? We have multiple stakeholders, and they all have their own pockets of communities that come together to make the whole. And as far as I’m aware, there’s no other project out there which is doing that. And if you haven’t got the head start on the community side of things, then, you know, the chances of getting traction over something like The Graph, I think is very difficult. Very difficult.

So for you then, it’s that community or The Graph’s ecosystem that sets it apart?

Yeah, I mean, maybe to expand on the community piece a bit more. I mean, one of the things that I’m kind of big on these days is new opportunities for new types of careers. Brandon did a blog post about work tokens a long time ago that I read. And I felt like there was a whole other side to the sort of the dialogue within his blog post on thegraph.com. He was talking about the protocol side of work tokens, and, you know, how people can, get paid for doing query work and that sort of thing. But, you know, I felt like there was also a human story on the other side of it. You know, my story is one pretty good example where I’ve, you know, I eventually after 9-10 years, took the leap into this space, and now I’m full time in this space, right? The whole way of working in this space is completely… it’s a new paradigm. I really do think it’s a new paradigm, the way that people work in this space. You know, I’m working alongside the most diverse group of people I’ve ever worked with, and I’ve worked for a fortune 200 company for most of my life, you know, internationally, working with people from all over the world and, yet, now that I’m working with The Graph community, the diversity is just amazing. And these people come from all walks of life, you know, some of them are, university educators, some of them are academics, some of them are, you know, they pull themselves up by their bootstraps. There’s all types of people all working on this together, and they’re all working towards a common goal. And they all have some sort of meaning in their life from the shared goal, right? That for me, you know, my experience working in the enterprise world, was something that was missing in, I guess, in my heart, right? I didn’t, you know… I always enjoyed sort of the startup side of working in enterprise because I did quite a bit of that. In the cloud space, when I was working in the enterprise world, I got a taste of that feeling of, sense of meaning, or a collective goal, right. But I didn’t feel it, like I feel it now, with this, working with The Graph. There’s a sense of everybody working towards the same thing, it’s the sense of having found one of your tribes, and you know, I think in the modern, in the modern world, that’s something that we’re all missing a great deal, right? You know, I don’t know what it’s like for you where you live, but you know, where I live, I know who my neighbors are, but they’re not friends. You know, we’ll say hello, when we, see each other outside, but we’re not necessarily friends, people have lost this tribal thing that they need something to grab onto and say, “this is mine.” And when I talk about community, and I talk about, it’s not just The Graph, it’s a theory, it’s everything else that’s going on in the crypto space, it’s Bitcoin. That’s one of the things, you know, put the financial thing to the side, that’s the other thing that’s grabbing people that, you know, they’re finding their passions, and they’re finding their tribe. And when I talk about the moat, that’s what I’m talking about.

Let’s turn our attention to some important concepts or jargon that members of The Graph community need to understand. How would you describe what a subgraph is?

Right? So subgraphs are, more on the developer side, a subgraph is basically the way to define how we would like to process data from a blockchain. So if we have dApp, for example, Uniswap is an easy example, Uniswap is a decentralized exchange where you can exchange one token for another token, and various other things. So, the purpose of this: If uniswap, or subgraph, might be to list out all of the prices for all of these tokens to spot prices, right? How much would you pay for this specific token at this specific time? And The Graph allows you to do that without any requirement to own servers, right? So the Uniswap developers don’t own any servers to process the data, they simply come to The Graph. And they use the Uniswap subgraph via an API or web API to get that information. And the subgraph, all the subgraph is doing, is instructing the Indexers how we want to process and present that data.

How would you describe the work of Curators?

The Curator’s job is essentially to signal to the network that a specific subgraph is going to, or already has, demand for use, right? So, an example, maybe there’s a new dApp that’s coming along, it might be a copy of an existing dApp, and people know that it’s going to be popular, a Curator who’s sort of got their ear to the ground on what’s happening in the DeFi space, what’s hot, and what’s not, might know that this is coming. And when they see that subgraph deployed, then they will, they’ll deploy GRT as a signal against that subgraph… Indexers either manually or automatically, or, looking at the data about the network and seeing where the signal, you know, is distributed among all the subgraphs. And if they see a new subgraph with increasing signal, what they might do is they might take some of their GRT stake and they will apply it to that subgraph and they’ll start indexing that subgraph. And if the Curator is correct, and they’ve signaled against that subgraph, and then there’s demand for that subgraph in terms of data, you know, consumers wanting data from this dApp connected to the subgraph, then both parties benefit. The Indexers make the query fees, the Curators, they make a 10% fee on query fees, even before it gets to the Indexers. So, it’s a symbiotic relationship of sorts, a feedback loop of sorts, to try and make sure that the quality of these subgraphs that are being indexed is as high as it possibly can be.

At the time of this recording, it seems like there’s a lot more we can expect when it comes to the curation services and the work of Curators.

The curation piece is very much tied in with the… you know, having the consumer gateway where customers the dApp developers can buy data. And it’s also tied into having a number of subgraphs to curate against. You know, right now we have one subgraph and there’s no curation going on because there’s no real, you know, there would be no aim to curate one subgraph. The whole premise of a token curated registry, which is sort of what we’re talking about here and when we talk about subgraphs, is that you would have a large selection of subgraphs to, you know, curate against. We don’t have that right now. So what you’re going to see is, along with the subgraph migration occurring, you’ll also have the curation piece building up to, again, I’m not part of the Edge & Node team, so I can’t talk about specifically how they’re going to do that. But again, I imagine it will run alongside in parallel with the migration of subgraphs. As more subgraphs come in, Curators will be able to via their own UI, which again, will be similar to the network that everybody uses. Today, there’ll be you know, like you use for delegation, similar to similar type of interface, the Curators will then be signaling their GRT, against the subgraph that are coming in. And then Indexers in turn will react to how those, you know, how much signal the Curators are putting against each of the subgraph. It’s the type of question that is almost easier to answer with an illustration, right, or a plan, like a flow diagram. All of these different components are all coming in, you know, when they’re going to be coming in together, as far as I understand it. And they’re going to come in very gradually, alongside the gradual introduction of the subgraphs, that means that will, there’ll be a gradual increase, assuming there’s business, every business, there will be a gradual increase in the query fee rebate. So the amount of revenue that an Indexer makes via query fees, so all of these things are going to happen. I think very gradually, I don’t expect any sort of shock, where you know, we deploy 1,000s of subgraphs and then Curators just go crazy signaling against them. It’s going to happen very gradually. I don’t think there’s any one step that is more important than the other, if that makes sense. All of these things have to happen alongside each other.

How should we think about who the consumers of The Graph are? For example, is that the dApp developers? Or is it those that use the dApps?

Right? We probably need to sort of define who the consumer is, to be clear, the consumer, in this case, would not be the end user of the dApp. So there’s no expectation that a customer of Uniswap will actually directly pay for data. It’s the developers of the dApps themselves that would pay for data. And in terms of how that would actually look, this is something that Edge & Node are currently working on. So you might be familiar with the network dApp that Edge & Node currently support and continue to develop the interface or the consumers to buy data or, you know, by blocks of data will be sort of, you know, I’ll be able to say the same type of UI. But as to what it will actually look like, I can’t comment on that, you know, something that edge and node are working on right now. We haven’t you know, there’s nothing public for that right now. So I can’t really comment on what the experience will be. All I know is, it will be a very, it will be a very rich experience. So you know, the consumer will be able to select what’s important to them for the data? Do they want it to be super low latency? Do they want it to be, you know, do they not care about latency, they just want it to be cheap, various different, what they call utility scores for Indexers, they’ll be able to sort of define what they want, and how much they’re willing to pay for it.

So we defined what a subgraph is, we’ve talked a little bit about what Curators do, and we’ve identified who the consumers are. Now we should talk about Indexers, which is what you happen to be. So what can you tell us about the operations of being an Indexer at The Graph?

I mean, it’s essentially a large DevOps operation, right. But what do I mean by that, in order to run an Indexer, you have to, you have to provide for a number of components in this graph protocol stack. And the number of components is only going to grow as more as The Graph protocol, you know, supports more and more blockchains. So, you know, there’s two or three main components on top of my head, or for an Indexer. You have your labor costs for running your operation. You have your capital costs, potentially all pegged depending how you do it for your server infrastructure. You have your hosting costs, do your internet costs, your datacenter costs, and then you have your development costs on top of that. So the numbers can run very high for an operation that’s doing it right. I mean, you could easily you know, run a very basic operation with no kind of redundancy, no monitoring, no resiliency, relatively cheaply, right. But if you were to one of the issues there is, you know, if you were to have a failure on one of your Ethereum nodes, for example, you didn’t have a backup Ethereum node, you’re completely out of service. So you and your Delegators are not going to make any money while that service is down, right, you’re not gonna make any money from the query side of the business. And we’re going to get to a point where the business is, so the margins are so thin that, you know, you’d be able to measure your, your losses per you know, per minute, basically, in terms of downtime. So a well architected Indexer operation is going to cost many 1000s per month to run, you know, taking into consideration OpEx, CapEx, and the labor, you know, your labor costs on top of that, then, you know, like I’ve already said, once we have new networks coming on board, we then have the requirement to run nodes for other networks. But that’s more compute power that’s required, that’s more labor in terms of looking after the infrastructure. And then it’s also a lot more research, every time a new sub graph comes along that maybe we want to index and provide queries for, then we also need to do a lot of work around modeling the costs, right? Because cost modeling is quite complex. Well, it can be basic, but if you want to do well, here, you will, and you can, you know you to build some robust cost models. So you might have cost just to look after the operation. But then you also have research costs on top of that, in order to make sure that you’re at the cutting edge of whatever, you know, dynamics are playing out playing out between Curators and Indexers business intelligence, that sort of thing. So there’s a, you know, there’s a whole, there’s a whole slew of operation going on behind this. It’s very much the antithesis of most node operations that, you know, maybe Delegators that have delegated other networks are familiar with, you know, you might have a network like any other delegated Proof of Stake network, where what all you’re doing is validating transactions, and that’s relatively it’s still complex. There’s nowhere near as complex as running, you know, the six or seven different components, you need to run for a graph. So I hope that gives some kind of understanding as to why it’s a much more complex protocol to run than maybe Delegators are aware of.

Sometimes we see Indexers with multiple Indexer IDs on The Graph, can you explain why an Indexer would have multiple IDs on The Graph?

There’s many different situations where you might want to do that, first a technical point, a lot of Indexer’s are under these vesting contracts. Where their tokens are locked into a contract, but they’re not liquid. And you cannot combine those contracts into one Indexer. You can only run them as separate Indexers. That’s one potential reason. Another reason might be that some of the especially some of the bigger Validators, they might be representing not only themselves, but also an investment partner, right, that holds a significant amount of GRT and wants to once it run as a separate operation. So that’s another potential scenario. And then you might also find Indexers who want to run different strategies on different Indexers trying to think of an example, maybe, maybe an Indexer, wants to run one Indexer in a specific geographical location. To serve a specific need maybe a dApp, that needs really low latency in a specific geographic location. In order to capture that query business, they need to have very low latency, they need to be able to serve, you know, the chain head. So the very most precious data from the blockchain as fast as possible. That’s often the case with financial products. And then maybe they also want to run a cheaper operation. So maybe they want to run a more generic operation in the center, you know, in the heart of America that serves, you know, everyone that you know, every possible consumer across America, that’s just looking for relatively cheap queries. That’s, you know, I’m just coming up with these ideas off the top of my head, there could be many more, but those are the three that comes to the top of my head immediately.

Let’s turn our attention to the relationship between Indexers and Delegators. How should we think about that relationship?

I think it’s a very timely topic, given the enthusiastic debates around GIP-2, which is about allowing Indexers to siphon their rewards to a separate address and access them instantly. There’s been a lot of doing and froing between Delegators and Indexers in terms of you know, Is it fair, that indexes are able to do that, and Delegators aren’t. And that plays very much into my personal opinion around, you know, the relationship between Delegators and Indexers. To me it’s a very symbiotic relationship. And it’s going to change over time. So right now, there’s quite a heavy focus on APY, you know, specifically APY from staking. So that’s very much what you know, most delegates have in their mind, and rightly so. Indexers are focused right now on trying to get some revenue, because we’ve been locked up for eight months. Because there is no function right now to pull our rewards without completely unstaking our entire operation for a month. And through the discussions that we’ve seen happening around this, I’ve kind of come to understand that the relationship between Indexers and Delegators is symbiotic. I’ve heard some controversial statements around with the network still run without Indexers with the network still run without Delegators. And I don’t think any of that’s really particularly constructive. I think we need each other. I think that Delegators in a way, you know, delegates are providing that extra level of security around the subgraph allocations that Indexers, like myself, I’m a small Indexer, I don’t have a huge self-stake. They provide sort of amplification of my stake, so that I can deliver secure query business to my customers basically, so I need Delegators at the end of the day, and over time, I think this relationship is going to become more, it’s going to become more clear where the boundaries are, right? We talk a lot about, or we hear a lot about equality between Indexers and Delegators. And although I do agree with some of that, for example, I agree that, you know, whether or not Indexers should have instant access to their rewards or not, is not that important to me, what’s important to me is that we don’t disadvantage one party more than another, you know, for let for any more than a temporary period of time. Right. So that’s part of the big argument around GIP-2.

You’ve brought up GIP-2 a couple of times. So I guess I’d like to get your opinion on it. How do you think the debate surrounding GIP-2 went and the outcome that was reached?

Well, I mean, first of all, I would say, I’m thrilled to see so much engagement, especially on the discussion side of things, you know, irrelevant of whether it gets heated, people are very clearly passionate about The Graph, I think there’s a few issues that were sort of like growing pains that we’re experiencing, the first one that’s cropped up has been, you know, it’s taken them quite a lot of my time is around, you know, rules of engagement on the forum. At the moment, it’s very open. And there’s nobody really guiding the conversation. And that causes a lot of stress. And it causes people to not engage, I’ve had a lot of DMS, from people who, you know, they’re observing the conversations, but because they’ve become quite aggressive or heated, they don’t want to get involved. So that’s one, you know, area that we’re working well, you know, the foundation are aware of, and they’re working on potentials, you know, solutions to help guide the conversations in a more constructive manner. The second issue more around, I guess, education and understanding of the GIP itself. There was a decision to use Radical, which is sort of a decentralized, GitHub, it’s in its very early days right now, to publish the GIP. And, you know, a lot of people don’t have access to that, that you need to, you know, install a specific piece of software in order to get access to the GPS. So, you know, there’s, I think, a lot of hearsay, around, you know, unfair treatment of Delegators, preference for Indexers around the, you know, instant access to rewards. And I think a lot of that could have been avoided if people had access to the actual material, and they could see exactly what it was addressing and why it was addressing it. This specific GIP has, you know, a very long history, the Indexers were always supposed to be able to access their rewards, instantly, that was always supposed to be the way the smart contracts worked, and it wasn’t there because of an oversight. Now, the question of whether that’s fair on Delegators is, to me a valid question, right? I don’t think it deserves the level of sort of dramatics that is sort of generated but I do think it is a valid thing to discuss. My personal belief is that whether we have a 28-day thaw on rewards or not, it should be applied ultimately to both Delegators and Indexers reading some of the feedback from the Engineers, they have said that, you know, adding Thor periods for the sake of adding thaw periods is just not efficient. And that’s one of the reasons why there is no thaw period, excuse me..for this new patch to the smart contract. So, you know, again, I’ve said before, I’m ultimately a pragmatist. So my expectation is that, if this GIP is passed, then the next GIP on the on the table should be around, bringing the Delegators mechanism rewards into line with the Indexers. Again, I talked about nuance, you know, there’s nuance between the responsibility the Indexers have, versus the responsibility that Delegators have, for these base level mechanisms, I think that there needs to be a level of equality. And that comes by matching, you know, either both parties have a 28-day thaw on rewards, or neither party has a 28 day thaw on rewards.

So you bring up this 28 day thaw period, maybe we can take a little bit more time and discuss what it is and how it ever came to be?

So we’ve mentioned before, you know this 28 day period in relation to other parts of the protocol. And essentially the whole protocol runs on these 28 day period. And the reason that there is a 28 day thaw per Delegators is to make sure that delegated stake can’t be used twice, essentially front running the settlement period. If we were to think through an example, if we imagine there was no 28 day thaw or Delegators. Let’s say there’s two Indexers. The Delegator A is delegated to Indexer. A right now. And Indexer a settles his rewards for the last, let’s say 28 days, the Delegator notices that the rewards have been distributed, or that Indexer. And what they do is they, they acknowledge that they’ve collected that reward on chain, they then undelegate immediately from that Indexer. And they delegate to another Indexer that they know is going to settle their allocation, maybe in the next one day, right. And it’s again, it’s a 28 day allocation. So rewards have been accrued over that 28 day period. So when the Delegator goes to the Indexer B and delegates to them, what they’re basically doing is they’re doubling up on the rewards they get in the period. This is the reason this is called front running, right? And this is the reason why there is a 28 day thaw period, it stops Delegators from double dipping, basically, their rewards. And this is all tied into the fact that the protocol runs on these essentially 28 day cycles.

Thanks for explaining that it’s very insightful. Given all the debates surrounding GIP-2, I have the opinion that maybe The Graph should look at that 28 day thaw period, and lessen the burden to Delegators who need to switch out of an Indexer position for any variety of reasons. What do you think?

First of all, I fully agree with you. And this is part of what I mentioned before where I feel like equality is important. And it’s nuanced. It’s not just a quality for equality sake. And in this specific case, where you might have a malicious or a poorly performing Indexer. I don’t think it makes sense for Delegators to be stuck with the 28 day or the opportunity cost of exiting. And then going to another Indexer 28 days is a relatively standard on bonding period, right in a lot of protocols. It does provide that level of economic security that’s needed to you know, reduce token visit velocity, for example, we see similar numbers on other layer one protocols. Polkadot is a good example Cosmos is another example. But, you know, once a Delegator is in that situation where they are under the you know, they’re stuck under an Indexer that they don’t, that they feel is behaving poorly, that to me is punitive to have them stuck within the protocol for 28 days. And other protocols have, you know, solutions to this. Cosmos, for example, has an instant read delegation feature. So, at any time, a delegator on Cosmos can change their, we’ll call this an Indexer, or they’re called Validators on Cosmos, they can change their and, add on to another Indexer. And, yes, there are slashing penalties associated with that and risk for the Delegator but they’ve don’t have to exit the protocol. So I think we need to explore the option of doing something like that on The Graph. And a number of people agree that that’s something that we need to investigate, there might actually be a thread on that specific topic, I’m not sure.

So there’s a concern among Delegators, or a worry about selecting the wrong Indexer. Or getting stuck in an Indexer partnership, where the Indexer is a bad actor at The Graph? I’m curious, what would be the behavior of an Indexer who happens to be a bad actor? What should Delegators look for?

So today, the sorts of bad actors we see, generally speaking from, you know, from an optics point of view, without ever talking to the Indexer, what you might see is something like erratic changes in their, you know, their, or their sort of the Indexer reward cuts. So maybe you were expecting a certain return over the next the last month. But the Indexer went and changed their fee cuts, and you’re only getting half of what you expected. Right? We see that relatively often. Now, is that a bad Indexer? In most cases, what we’ve seen is that when we you know, when the Delegators or another Indexer, sort of tags that Indexer, and says, Can you give an explanation for why you’ve done that? It usually tend tends to be they’ve adjusted the cuts, because they’ve basically stated somewhere down the line prior, that they’re going to always provide a certain percentage cuts. Right. They’ve communicated that somewhere else. So what we have there as a serious communication problem, right. So in that situation, I think there’s a protocol issue. Right. And that needs to be addressed via proposals. But it’s still a red flag, erratic changes of Indexer rewards to me are an issue that needs to be addressed at the protocol level. But in terms of whether it’s a red flag for a delicate Delegator? Absolutely, I think it is. So you have a couple of options there as a Delegator, you either, you know, have the discussion with your Indexer. They explain it to you, you’re happy with the explanation, you go forward, or you leave that Delegator and you move on for another one. Now, in with regards to how do you avoid Delegators like this? You know, it’s a difficult question to answer. Because we’re so early in the network and reputation takes so much time to build, we’re only two months or three months into the into the main net. And you know, people are trying to build the reputations already. But I think it’s simply too early. In terms of real like double red flags, I don’t think we’re gonna see many of them until we have significant query traffic. One example that I would recommend Delegators pay very close attention to is what I would call a leaching Indexer. Right. So what is a leaching Indexer? This is just a term, I’ve come up with. A leaching Indexer is an Indexer, that doesn’t do any query business. Maybe they have a very, very large self-stake, right? 10s of millions, hundreds of millions. And they can make so much money from just the index rewards, the rewards due to inflation, that they don’t actually do any query traffic. That would be a huge red flag to me as a Delegator. If they’re not participating in the query part, query fee side of the market, then they’re just leeching from the network. They’re not actually providing a service to the network. In my opinion, some would argue that they’re providing data security, I would argue that they’re only doing half of their job, if that… but this is something for later down the line, but something that I definitely think delegate Delegators need to be watching as the new subgraphs come in.

Another thing that you can look out for is Indexers, you know, the worst case, behavior that we see is something called a sandwich attack. What is a sandwich attack? Basically, a sandwich attack is when an Indexer coasts along with maybe a very low they’re taking a very low commission, let’s say they’re taking 5% commission or something like that. And just before they settle, you know, the rewards which Indexers generally do In a 14 to 28 day period, but just before they settle that, that reward, they’ll change their their commission to 100%, which means they take all of the rewards, they’ll change it to 100%, then they’ll settle the rewards. That means the entire reward pool goes to the Indexer. And then once that’s confirmed on chain, they’ll set commission back to 5%. And if you weren’t paying attention to this, using some of the dashboards that are out there, you’ll be wondering, where are my rewards, right? But they basically just stolen all the rewards from you. We haven’t seen this used maliciously, is something to keep an eye out for. Because as the network stands today, the cooldown feature for making changes to an Indexers rewards won’t necessarily save you from a sandwich attack. You know, I don’t want to be scaring people. And I want to be very careful, they don’t scare that scare Delegators with things like this, I mean, these things are talked about openly, right? We’ve not seen them in in the open. We’ve seen things that look like them. But we’ve never seen them used maliciously. My feeling overall, is that the network doesn’t do enough to protect Delegators right now, some would argue that, you know, delegating is low risk, relatively low yield activity. I mean, if that’s to be true, then you cannot have Delegators having the rug pulled from under them, you know, via a sandwich attack, or some other type of issue where maybe an Indexer isn’t settling the rewards. Delegators need to have a way to counter that as well, you know, and there are proposals and in motion to make that happen. I think they’re quite technical. But a lot of people realize that, you know, when you’ll often see Delegators, realizing the situation they’re in in the Discord, and wondering why the only option they have is to either stay with the an Indexer that might be behaving badly, or to suffer the opportunity cost of 28 days thawing, right? And in that situation, specifically, I don’t think that’s fair.

So how should Delegators go about choosing an Indexer? I mean, you’re an Indexer. Coach us? What should we know about making that important decision?

I would keep it simple. First, see who’s active in the Indexer Delegator chat channel, who’s interacting, who’s having good base debates in their APY is important, right? It’s one element that you can look at. So take a look at who’s providing sort of the mid band of APY, take a look at who’s doing more than just more than just providing an indexing service or just a huge APY, who’s actually out there doing something proactive for the community is sort of staked their reputation on the community, there’s plenty of people who are doing that on, you know, in all parts of the of the stakeholder system. And finally, just to try and make it a bit more practical, when you do look at the APY don’t just pick the highest APY, right? You’re I mean, in APY is a measure of risk at the end of the day, right? The higher it is, potentially the more risky, you know, in terms of maybe that APY changes very quickly, maybe it goes to zero maybe goes negative, find a balance. And maybe if you’ve got enough GRT to make it practical, split your risk across your top, if you can 3, 4, 5 Indexers that are providing a range of APY’s and are maybe involved in the community in different ways. That way, you insulate yourself from some of the existing risks that we see today. And that we know that we need to fix that. So that would be the big message from me would be don’t just deploy to one Indexer deploy to a selection of them across the APY. And that insulates you from a lot of the potential risk that we see today.

Sometimes there’s confusion about when Delegators will receive their GRT rewards earnings from Indexers as an Indexer, what can you tell us about how to think about that?

In terms of just how the protocol works, if you’re if an Indexer is to make an allocation on chain, that allocation will automatically settle assuming that the Indexer continues to run their infrastructure within 28 days. If the Indexer is running multiple allocations, so let’s say you have, I don’t know, two subgraphs and you’re running three allocations, so lumps of stake against each of those subgraphs, then the allocations will stagger. And they will settle automatically anywhere between 14 and 28 days assuming the Indexer continues to run their infrastructure, and has Ethereum or Ether rather, in their account to pay the gas fees for their transactions. Now, in reality, what we have seen is that early on, many Indexers were settling their allocation to pull together daily. That’s certainly what I was doing in the early days, because the returns were very high. I wanted my delegates to see that they’re, you know, they’re making serious return, because they were so, you know, quick to getting into the network. And many Indexers did the same thing. And now, I’m falling back on pretty much settling just about at the 28 day mark, and I try to make it as gas efficient as possible. If I see a period coming up near that 28 days, I might manually settle the transaction in order to keep the gas costs low, because it can cost you upwards of, you know, in today’s you know, Ethereum gas wars, it can cost you upwards of $100. To settle on allocation, in terms of how Delegators can manage expectations today. The best option really is to talk directly to your Indexer. You can also use some of the dashboards, one of my favorite is stakemachines dashboard, which will show you your unrealized gains, even if they haven’t been settled, so you can still track how much you’re making. It’s just they won’t have settled yet. In the future… You imagine, let’s say we had 50 subgraphs, running on the mainnet, then I imagine that most Indexers will stagger their settlement of those sub, you know, the allocations against those subgraphs on some sort of daily schedule. So it will be you know what a delay, Delegator will then experience is more like a constant trickle of returns over time, against their address, you know, we’re in one of the things that people will sometimes feels like the entire community forgets is it’s really early in the network. All of these issues that we see right now, a lot of them will dissolve over time. And I think this is one of them that will dissolve over time. Because indexes will have so much settling to do, that they’ll be able to do multiple settlements every day staggered across the month that, you know, Delegators will see returns every day into their account.

Similar to the question I asked about Curators, I’d be curious what your opinion is about the future of Indexers? For example, as it sits today, should we expect more Indexers to come to The Graph?

There are some concerns around the centralization of stake. So, you know, it could go either way, really, as we stand today. If the stake continues to centralize, and the delegations continue to centralize, we’ll get to a point where it’s not marketable for an Indexer to run my understandings talking to other Indexers who sort of do a lot of number crunching, is that, you know, if an Indexer was to start today, with 100,000, GRT, they would struggle to cover their costs. And that’s purely down to the, the amount of Ether they would have to spend on transactions to settle, you know, so this is basically, the cost of doing business on Ethereum would be too much for them to make any profit at 100,000 GRT self-stake. On the other side, we, you know, we have the option through governance to change parameters that might make it more favorable for more Indexers to come in. A lot of the grant proposals that I’ve seen, are sort of, you know, they rotate around this idea of making it easier to index. So you know, there’s some proposals that are working on like, one click deployment of indexing operations, that sort of thing.

How about Delegators? Is there a time in the future when Delegators are no longer needed at The Graph?

Strictly speaking, if you’re just talking, you know, cold, hard facts, the protocol could work without Delegators. But you lose a huge amount of security. I mean, in fact, you lose more than half the security, right? Because, I mean, I don’t have the stats pulled up in front of me, but there’s a great deal more GRT on the delegation side, and there is on the indexing side. So if there was if you know, if there was no need for Delegators, and that stake disappeared, then you’re losing economics huge amounts of economic security within the protocol. The entire point, in my understanding of delegation is to allow is to allow anyone with any amount of GRT to contribute to the protocol and be a productive entity within the protocol. But as far as I’m concerned, Delegators are as important as Indexers. In the long term, we need each other basically. Indexers have the burden of very large operational costs a great deal of responsibility within the within the system. Delegators less responsibility, less risk, less return, right? But both sides are important. You need people who are very heavily committed to it, you know financially. But you also need to be enabled to enable people who have a small amount of GRT to also contribute. So I don’t see any time where the delegation role is not as important as it is today. But the protocol.

Sometimes those who want to participate in The Graph and take a different approach than staking their GRT directly and acting as a delegator. For example, they might stake their GRT with companies like Bancor. What’s the difference between the two options?

Bancor is the DeFi product. And I haven’t looked into the actual product that’s being provided specifically with GRT. But imagine its some form of Automated Market Maker. So somebody with GRT could be a liquidity provider, which means that they would be providing liquidity into a pool of assets, where users can then buy or sell those assets. And for their contribution to the liquidity, they’ll get some kind of primary fee in return. And then in some cases, they might also get an additional reward on top of that, for contributing to the pool. So that’s very strictly a DeFi product, right. And there was a there was a sort of corollary to that in Mission Control test net, where we had the option to take our stake, if we wanted to, in the testnet, pull it out of the protocol and put it into a something called gDAI, which is sort of a, an imaginary, stable coin that had something like a I can’t remember if 0.5% return rate. So it would want the idea was that we create this dynamic between, is it worth keeping the stake in the protocol? Or will I get a better return if I, you know, stick in this stable-coin? So this is a similar situation that we use when you talk about Bancor. If, if a delegator decides to put their GRT into Bancor, then they wouldn’t be contributing to The Graph, the security, the security of the subgraphs, on The Graph, main net, they’d be completely at what we would call out, you know, outside the protocol. But they might be getting a better return. Right? So it’s all comes down to personal ideals. And it’s the same question with it with APY within the protocol, right? Personal ideals, which is more important to you that you contribute to decentralization, or that you get the highest APY or some mix of the two. So it’s this it’s exactly the same sort of question, the rational thing to do, you know, if you’re just a profit seekers to find what the greatest return you can find. So maybe that might be outside the protocol. But, you know, from my point of view, you know, it’s all fine making a great return. But what are you actually contributing to? You know, are you really, are you just a yield hunter? Or are you, you know, do you have some ideals? Are you are you in it for more than just a return? In that case, maybe you put a proportion of the outside in Bancor, and in proportion of it in the protocol, so you’re playing both sides. So there’s a dynamic that’s going to evolve over time between The Graph protocol, and then GRT, outside the protocol, can be very interesting over time to watch how that dynamic plays out.

In addition to being an Indexer at The Graph, you’re also a member of The Graph Council. What can you tell us about that role?

My role at on The Graph Council is initially it’s around representing smaller Indexers, the remit of the council is basically to provide a voice to all the stakeholders. There’s, I believe, 10 of us on the council. And we have a multisig of 10 multisig, which means that in order to pass any motion, or any changes to contract or anything like that, we need to have six people to sign the multisig, to make the change happen. The most important thing for me, in terms of being on the council, is to make sure that, first of all, all voices are being heard, and that there is a thread of, you know, equality running through the discussions. But the nuance is also taken into account, right? It’s not just equality for equality sake. And also as part of that, I like to try and make sure that especially on the Discord side of things, make sure that I try and be present in the Discord so people can see that council members are listening. It’s a very different role, obviously, to my Indexer role. So you know, I have different hats on at different times. Sometimes I might be expressing my own opinion and other times on my might be trying to just give a give an overview of maybe a hot, hotly debated topic, and I’m not specifically going into my own my own opinion on it. So, for me, I like to try and think that I’m acting as a vessel to get Indexer opinions, you know, taken on board as part of the Council. And the, the council itself, the remit of the council itself, is to make sure that any decision that’s made doesn’t unnecessarily advantage, one stakeholder group over another. That’s a big thing for the council. That’s one of the line items on our council charter.

Are there any upcoming projects we should know about? Or you’d like to share with us?

Sure, there’s a few of them, which are sort of, they’re not launched yet. So I can’t talk about those but two that I run personally, at the moment, I run an Indexer office hours, six o’clock GMT on Wednesdays, and it’s basically a voice chat on Discord, where anybody who’s part of the ecosystem can come in and have a chat with us about indexing, whether it’s a basic question about starting out as an Indexer, or a very advanced question. It’s a very casual hour, where we just have a discussion about what’s going on in the ecosystem, specifically around indexing. So if anyone wants to join that you’re welcome to do so it’s Wednesdays at six o’clock GMT. And the other thing that I do on a regular basis is I put out a newsletter on the last Friday of every month, called ‘This Month in Graph Indexing’. And it is what it says it is just basically talking about the last month of happenings within The Graph that impacts Indexers. And if you know, if you’re a busy person that doesn’t have the time to be around, you know, all of these ongoing through the month, it’s a great way to find out what’s going on in the indexing space. And that’s just basically kept as a forum post. And you can go and take a look at that anytime. And I also I always tweet out when I’ve published a new one.

Okay, I think the last question I’d like to ask you is about the future. What’s your future vision for The Graph and this exciting project?

Well, I think The Graph is a really great example of a work of a work token architecture, right, where we’re using the GRT token for many different, you know, takes on many different roles. And allows us to provide, you know, a service, the decentralized service to the community that needs it. I think the potential once The Graph protocol itself has matured, is endless, you know, and it goes way beyond just providing data for dApps, it’s looking way beyond that into replicating this model for other services, right? When I think about where this is going, and why I’m so you know, why I’ve got the mind virus when it comes to graph is because it’s the first time I’ve seen a work token really, actually do its job. Often, when you see these work tokens come out, they end up just being subject to speculation, financial speculation. This is the first one where I’ve seen a real product behind it. So the work that’s being done here, I think it echoes out into other industries, other industries, where you can, you know, you might currently have centralized services, providing information, right, that’s where the whole Google of blockchains thing comes from. Maybe somebody could provide a decentralized search service using the same, you know, the same software, maybe somebody could take an existing Software as a Service industry, really big one, and make it make it work under a work token. You know, that’s the type of thing I like to think about things that are so that you know, they’re so far out there, that you can’t quite shape them in your mind yet. But you know, that’s the direction things are going. If you want more salient answers to that question, then, you know, people like Yaniv are really good people to talk to.

Jim, you’ve been so generous with your time and shared a lot of important information. Thank you! What are ways listeners can stay in touch with you, learn more about your work at The Graph Council, and also what you’re doing as an Indexer at The Graph with Wave Five?

Sure. So, I’m most active on Twitter. My Twitter username is @_cryptovestor. If you’re interested in my indexing operation, you can take a look at my website. It’s a very basic website at the moment, that’s WaveFive.co. You will always find me on The Graph Discord. I’m usually in there talking with other Indexers, Delegators, and Curators. So I always welcome a DM if somebody wants to talk Graph, or if you want to talk my Indexer specifically, you’re welcome to DM me on any of those platforms.

This has been a production of the GRTiQ Podcast. We want to thank Jim Cousins for joining us, and all our listeners for supporting this project. You can access more information about the GRTiQ Podcast, including show notes for this particular episode, by visiting GRTiQ.com/podcast.


Receive New Content
Direct to Your Inbox



DISCLOSURE: GRTIQ is not affiliated, associated, authorized, endorsed by, or in any other way connected with The Graph, or any of its subsidiaries or affiliates.  This material has been prepared for information purposes only, and it is not intended to provide, and should not be relied upon for, tax, legal, financial, or investment advice. The content for this material is developed from sources believed to be providing accurate information. The Graph token holders should do their own research regarding individual Indexers and the risks, including objectives, charges, and expenses, associated with the purchase of GRT or the delegation of GRT.