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]).
The following podcast is for informational purposes only. The contents of this podcast do not constitute tax, legal or investment advice. Take responsibility for your own decisions, consult with the proper professionals and do your own research.
Jim Cousins (00:00:21):
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 a subject of speculation, financial speculation. This is the first one where I’ve seen a real product behind it.
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. Our conversation with Jim covers a range of important topics from the relationship between Indexers and Delegators to the basis for that 28 day thought period. The recent debate regarding GIP two 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.
Jim Cousins (00:01:55):
Gosh, that’s a long time ago. It would’ve been back in 2012 was when I first saw Bitcoin and it was a slash dot, if you can remember the website slash dot. Back in the day, there was a article there about Bitcoin and previous, maybe a couple of years before I’d found Bitcoin, I was kind of on a personal journey to understand money in more detail because I feel like most people go through their lives not really understanding what money is. So 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 quickly when I realized that if I had just held onto the Bitcoin that I spent on that minor, I would’ve 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 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 the presale came along, invested in a few other things, which are 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. So I continued 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, specifically into the crypto side of things. All I did was I took the capital I was 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 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 controversial. So I kept the two separate.
When did you first become aware of The Graph?
Jim Cousins (00:04:44):
So funnily enough, I was talking with a friend about when I came across The Graph only a week ago and found the exact tweet in fact where I was engaging with Yaniv Tal from The Graph now Edge & Node discussing the start of mission control, which was the name of the index or testnet that The Graph ran in 2020. And it was a response from Yaniv that basically said it doesn’t matter if you are a, what you might call an industrial level validator. This has got a lot of assets under management and is validating across many, many networks. Or if you’re one guy with one server, just essentially a hobbyist node operator, 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, I’m a hobbyist at the end of the, that’s where I started out as a tinkerer.
I obviously have my career, which is technical, it’s engineering, but I could take all of that in that sort of knowledge and apply it here to The Graph and it was the combination of the team being very interactive with people and also just being totally, I call it a mind virus. 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 and it is just, you think you found something special. So that’s what The Graph was to me. So that would’ve been around, it would’ve 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?
Jim Cousins (00:06:35):
And that’s a good question and I ask 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, in order for it to make sense. The difficulty with the Google of blockchain piece is that there’s so many technical achievements required between Google and The Graph that it’s difficult to draw that analogy from fundamental thinking. I prefer to just talk about the actual practicality of The Graph itself. 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. Developers have the option to build that infrastructure themselves so they could run servers that pull data from the blockchain, which is a 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 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. And what’s the end goal here? The end goal is that we want data. Right now there’s a lot of focus on financial data, now we’re seeing more focus on the NFT space, 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 user base?
Jim Cousins (00:08:22):
I mean, this was one of the main selling points for me when I first joined testnet, it’s very rare to find a crypto project that has an already existent user base, a successful product. In most cases, the temptation to sell out as what they would call a software as a service 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 they charge a certain amount per month for everybody to use it. The Graph, the whole team at The Graph are sort of, or 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. 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 synthetics websites, the data in those dapps is being provided by The Graph hosted service. Now beside The Graph hosted service, you also have The Graph protocol mainnet, which is where the decentralized Indexers live, which is where the Curators will live, 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 pool together subgraph, and there are queries running through that right now as test data basically. And over the rest of this year, it’s expected that the subgraph 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 prep. 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?
Jim Cousins (00:11:33):
The first thing I would say, just sort of as an overarching comment is decentralization is not easy. 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 I’m a pragmatist, I’m a realist, so there’s likely to be hurdles along the way. There were hurdles along the way all the way through the testnet, but the entire point of having testnets is so that when we reach those hurdles, we deal with them before they become problems. So 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, and 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’m not part of the development process.
But from the outside as an Indexer looking in, thinking about how do I make sure that I provide service during migration and mitigate any issues, Edge & Node have committed to running a continuous testnet now. So there’s a live testnet running which runs, I think it’s a slightly more updated version 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, all the bugs have been handled or the majority of bugs have been handled. So saying that from a Delegators point of view, migration won’t actually, 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 maybe I only spend my time at the moment in the Delegators channels in Discord, but maybe I would spend some time looking at what’s happening in the index or software channel where the Indexers are talking about 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. So that’s The Graph improvement process or how we apply governance in order to make changes to the network. But 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 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 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?
Jim Cousins (00:14:29):
I think so. I guess an analogy would be upping anchor on a ship. You’re no longer tethered to the old system. I mean, that analogy isn’t perfect because the migration is not a one shot operation. It’s going to be gradual. There’s 9,000 subgraphs, they don’t have to all migrate at the same time. It’s going to be a gradual sort of process where tranches of subgraphs might move over. Again, I’m speculating here. All of that sort of roadmap is with Edge & Node, but from what the feedback that we get as Indexers when we talk to the team is that it’s going to be a very, we’re not just going to be all or nothing. It’s definitely not an all or nothing type situation. If there are problems, they’ll be addressed as we go along. And subgraphs will come in gradually. Many reasons for that, 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 the software, Indexer software will take you so far in terms of managing it, but there’s a lot of automation to be done. If an Indexer has, I don’t know, a hundred subgraphs to manage, they can’t manage that manually. They need to automate the process. So there’s lots of things that are going to benefit from a very gradual migration of subgraphs over. It might start with one subgraph, well I guess we’re there already with pull together and then they’re just going to 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?
Jim Cousins (00:16:13):
Competition does exist in certain forms. There are various other platforms out there. One that comes to mind is Dune analytics, and most of these solutions that I’ve seen are centralized solutions. So they’re very sharp, I think of them as razors. 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 mechanism of providing data to adapt. Some people will, well will often question, so what is The Graph protocols moat? And quite frankly, I think it’s a very similar moat to Ethereum itself, as an example. Right now we see a lot of new, what they call, I guess Ethereum killers coming to fruition at this point or at least starting to show their head as their faster transactions or there’s some element of the trilemma, the decentralization trilemma that they do better than Ethereum does.
But Ethereum continues to be the king when it comes to smart contracts. The moat with Ethereum is the community. 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. It’s 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. Personally, I believe in the multichain 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. We have multiple stakeholders and they all have their own pockets of community 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 headstart on the community side of things, then 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?
Jim Cousins (00:18:41):
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 Ramirez did a blog post about work tokens long time ago that I read and I felt like there was a whole other side to the dialogue within his blog post on thegraph.com, he was talking about the sort of protocol side of work tokens and how people can get paid for doing query work and that sort of thing. But I felt like there was also a human story on the other side of it. My story is one pretty good example where I eventually after nine, 10 years took the leap into this space and now I’m full-time in this space. 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. I’m working a lot 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, internationally. Loads of, worked 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. Some of them are university educated, some of them are academics, some of them are, 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. That for me, my experience working in the enterprise world was something that was missing in I guess in my heart.
I always enjoyed the startup side of working in the 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, but I didn’t feel it like I feel 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 I think in the modern world, that’s something that we’re all missing a great deal. I don’t know what it’s like for you where you live, but where I live, I know who my neighbors are, but they’re not friends. 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 Ethereum, it’s everything else that’s going on in the crypto space, it’s Bitcoin. That’s one of the things, put the financial thing to the side. That’s the other thing that’s grabbing people, that 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?
Jim Cousins (00:21:56):
So subgraphs are more on the developer side. A subgraph is basically a way to define how we would like to process data from a blockchain. So if we have an app, 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 a Uniswap or subgraph might be to list out all of the prices for all of these tokens, the spot prices, 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. So the Uniswap devs don’t own any servers that process the data. They simply come to The Graph and they use the Uniswap subgraph via an API, a 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.
So then how would you describe the work of Curators?
Jim Cousins (00:22:59):
The Curator’s job is essentially to signal to the network that a specific subgraph is going to or already has demand for use. 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’ll deploy GRT as a signal against that subgraph. Indexers either manually or automatically are looking at the data about the network and seeing where the signal 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, consumers wanting data for this, for the 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.
Jim Cousins (00:24:44):
The curation piece is very much tied in with 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. Right now we have one subgraph and there’s no curation going on because there’s no real, 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 when we talk about subgraphs, is that you would have a large selection of subgraphs to 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 too. 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 dapp that everybody uses today. They’ll be used for delegation, similar type of interface. The Curators will then be signaling their GRT against the subgraphs that are coming in and then Indexers in turn will react to how much signal the Curators are putting against each of the subgraphs. It’s the type of question, it’s almost easier to answer with an illustration or a plan like a flow diagram. All of these different components are all coming in. 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 they’ll be an gradual increase, assuming there’s business, query business, there will be a gradual increase in the query fee rebate.
So the amount of revenue that an Indexer makes via query feed. So all of these things are all going to happen I think very gradually. I don’t expect any sort of shock where we deploy a thousand 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 it the dapp developers or is it those that use the dapps?
Jim Cousins (00:27:15):
Right. So when we say, we probably need to 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 would actually directly pay for data. It’s the developers of the dapp 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 for the consumers to buy data or buy blocks of data will be sort of, it’ll be of the same type of UI, but as to what it will actually look like, I can’t comment on. That’s something that Edge & Node are working on right now.
There’s nothing public for that right now, so I can’t really comment on what the experience will be. All I know is that it will be a very rich experience. So 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, 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 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 you happen to be. So what can you tell us about the operations of being an Indexer at The Graph?
Jim Cousins (00:29:00):
Sure. I mean it’s essentially a large DevOps operation, but what do I mean by that? In order to run an Indexer, you have to provide for a number of components in this, The Graph protocol stack. And the number of components is only going to grow as more as The Graph protocol supports more and more blockchains. So there’s two or three main components off the top of my head, for an Indexer. You have your labor costs for running your operation, you have your capital costs or potentially OpEx depending how you do it for your server infrastructure. You have your hosting costs, so your internet costs, your data center 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 run a very basic operation with no redundancy, no monitoring, no resiliency, relatively cheaply.
But if you were to, one of the issues there is 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. You’re not going to 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’d be able to measure your losses per minute basically in terms of downtime. So a well architected index or operation is going to cost many thousands per month to run. Taking into consideration OpEx, CapEx and your labor costs on top of that, then I’ve already said once we have new networks coming on board, we then have the requirement to run nodes for other networks.
So 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 subgraph 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 because cost modeling is quite complex. Well, it can be basic, but if you want to do well here, you need to build some robust cost models. So you might have costs just to look after the operation. Then you also have research costs on top of that in order to make sure that you are at the cutting edge of whatever dynamics are playing out between Curators and Indexers, business intelligence, that sort of thing.
So there’s a whole slew of operation going on behind this. It’s very much the antithesis of most node operations that maybe Delegators that have delegated on other networks are familiar with. 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 the six or seven different components you need to run for 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?
Jim Cousins (00:32:33):
There’s many different situations where you might want to do that. First, a technical point, a lot of Indexers are under these vesting contracts where their tokens are locked into a contract, so 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 especially some of the bigger validators, they might be representing not only themselves but also an investment partner that holds a significant amount of GRT and wants 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 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 the chain head, so the very most freshest 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, in the heart of America that serves everyone, every possible consumer across America that’s just looking for relatively cheap queries. 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 come 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?
Jim Cousins (00:34:35):
I think it’s a very timely topic given the enthusiastic debates around GIP two, which is about allowing Indexers to siphon their rewards to a separate address and access them instantly. There’s been a lot of toing and froing between Delegators and Indexers in terms of is it fair that Indexers are able to do that and Delegators aren’t. And that plays very much into my personal opinion around 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, specifically APY from staking. So that’s very much what most Delegators 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 would the network still run without Indexers, would 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, Delegators are providing that extra level of security around 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’s going to become more clear where the boundaries are. 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 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 for any more than a temporary period of time. So that’s part of the big argument around GIP two.
You’ve brought up GIP two a couple of times, so I guess I’d like to get your opinion on it. How do you think the debate surrounding GIP two went and the outcome that was reached?
Jim Cousins (00:37:21):
Well, I mean, first of all, I would say I am thrilled to see so much engagement, especially on the discussion side of things, irrelevant of whether it gets heated. People are very clearly passionate about The Graph. I think there’s a few issues that we’re sort of like growing pains that we’re experiencing. The first one that’s cropped up has been, it’s taken up quite a lot of my time is around 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, they’re observing the conversations, but because they become quite aggressive or heated, they don’t want to get involved. So that’s one area that we’re working well, the foundation are aware of, and they’re working on potential 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 GIPs and a lot of people don’t have access to that. You need to install a specific piece of software in order to get access to the GIPs. So there’s I think a lot of hearsay around unfair treatment of Delegators preference for Indexers around the 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 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. I don’t think it deserved the level of sort of dramatics that it 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 adding thaw 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 for this new patch to the smart contract.
So 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 table should be around bringing the Delegator mechanism for awards into line with the Indexers. Again, I talked about nuance. There’s nuance between the responsibility the Indexers have versus the responsibility that Delegators have. But for these base level mechanisms, I think that there needs to be a level of equality and that comes by matching 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.
Jim Cousins (00:41:49):
So we’ve mentioned before this 28-day period in relation to other parts of the protocol, and essentially the whole protocol runs on these 28-day periods, and the reason that there is a 28-day thaw for 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 for 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 for that Indexer, and what they do is 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.
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 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, and this is the reason why there is a 28-day thaw period. It stops Delegators from double dipping basically their rewards, and it’s 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 two, 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?
Jim Cousins (00:44:00):
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 equality for equality’s sake, and in this specific case where you might have a malicious or poorly performing Indexer, I don’t think it makes sense for Delegators to be stuck with the 28-day thaw or the opportunity cost of exiting and then going to another Indexer. 28 days is a relatively standard on bonding period, in a lot of protocols. It does provide that level of economic security that’s needed to produce token velocity, for example. We see similar numbers on other Layer 1 protocols. Polkadot is a good example. Cosmos is another example. But once a Delegator is in that situation where they are under the, they’re stuck under an Indexer 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 solutions to this. Cosmos, for example, has an instant redelegation 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 to another Indexer. And yes, there are slashing penalties associated with that and risk for the Delegator, but they 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?
Jim Cousins (00:46:13):
So today, the sorts of bad actors we see, generally speaking from an optics point of view, without ever talking to the Indexer, what you might see is something like erratic changes in their index or reward cuts. So maybe you were expecting a certain return over the last month, but the Indexer went and changed their fee cuts and you’re only getting half of what you expected. We see that relatively often. Now, is that a bad Indexer? In most cases, what we’ve seen is that 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 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. They’ve communicated that somewhere else. So what we have there is a serious communication problem.
So in that situation, I think there’s a protocol issue and that needs to be addressed via proposals, but it’s still a red flag. Erratic changes of index or 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 Delegator, absolutely, I think it is. So you have a couple of options there as a Delegator, you either 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, with regards to how do you avoid Delegators like this? 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 mainnet, and people are trying to build their reputations already, but I think it’s simply too early.
In terms of real double red flags, I don’t think we’re going to 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. 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, Tens of millions, hundreds of millions, and they can make so much money from just the index of 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 fee side of the market, then they’re just leaching 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 Delegators need to be watching as the new subgraphs come in. Another thing that you can look out for is Indexers, 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 a 5% commission or something like that, and just before they settle the rewards, which Indexers generally do on a 14 to 28-day period.
But just before they settle that reward, they’ll change their commission to 100%, which means they take all of the rewards, they’ll change it to a hundred percent, 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 aren’t paying attention to this using some of the dashboards that are out there, you’ll be wondering, where are my rewards? But they’ve basically just stolen all the rewards from you. We haven’t seen this used maliciously. It’s something to keep an eye out for because as the network stands today, the cool down feature for making changes to an Indexers rewards won’t necessarily save you from a sandwich attack. I don’t want to be scaring people. I want to be very careful that I don’t scare Delegators with things like this. I mean, these things are talked about openly. We’ve not seen them 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 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 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. And there are proposals in motion to make that happen. I think they’re quite technical, but a lot of people realize that 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 an Indexer that might be behaving badly or to suffer the opportunity cost of 28 day thawing. And in that situation specifically, I don’t think that’s fair.
So how should Delegators go about choosing an Indexer? I mean, you are an Indexer, coach us. What should we know about making that important decision?
Jim Cousins (00:52:18):
I would keep it simple. First, see who’s active in the Indexer, Delegator channel, who’s interacting, who is having good faith debates in there. APY is important. 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 providing an indexing service or just a huge APY. Who’s actually out there doing something proactive for the community, who is to sort of stake their reputation on the community. There’s plenty of people who are doing that in all parts of the stakeholder system. And finally, just to try and make it a bit more practical, when you do look at the APYs, don’t just pick the highest APY, I mean, APY is a measure of risk at the end of the day, the higher it is, potentially the more risk in terms of, maybe that APY changes very quickly. Maybe it goes to zero, maybe it 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 APYs and are maybe involved in the community in different ways. And that way you insulate yourself from some of the existing risks that we see today and that we know that we need to fix. So that would be the big message for me would be, don’t just deploy to one Indexer, deploy to a selection of them across the APY band. 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?
Jim Cousins (00:54:10):
In terms of just how the protocol works? 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 the 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 making serious return because they were so 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. So 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, in today’s Ethereum gas wars, it can cost you upwards of a hundred dollars 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 Stake Machines 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. They won’t have settled yet. In the future, if 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, the allocations against those subgraphs on some sort of daily schedule.
So what a Delegator will then experience is more like a constant trickle of returns over time against their address. One of the things that people, well, it sometimes feels like the entire community forgets, is that we’re 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 we’ll dissolve over time because Indexers will have so much settling to do that they’ll be able to do multiple settlements every day, stagger it across the month that 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?
Jim Cousins (00:57:27):
There’s some concerns around the centralization of stake, so 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 if an Indexer was to start today with a hundred thousand GRT, they would struggle to cover their costs, and that’s purely down to the amount of ether they would’ve to spend on transactions to settle. 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 sales stake. On the other side, 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 they rotate around this idea of making it easier to index. So there’s some proposals that are working on 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?
Jim Cousins (00:58:48):
Strictly speaking, if you’re just talking 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, then there is on the indexing side. So if there was no need for Delegators and that stake disappeared, then you’re losing huge amounts of economic security within the protocol. The entire point in my understanding of delegation is to allow anyone with any amount of GRT to contribute to the protocol and be a productive entity within the protocol. So 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 system. Delegators, less responsibility, less risk, less return. But both sides are important. You need people who are very heavily committed to it financially. 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 for the protocol.
Sometimes those who want to participate in The Graph take a different approach than staking their GRT directly and acting as a Delegator. For example, they might stake their GRT with companies like Bancorp. What’s the difference between the two options?
Jim Cousins (01:00:35):
Bancorp is a DeFi product, and I haven’t looked into the actual product that’s being provided specifically with GRT, but I imagine it’s 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 strictly a DeFi product. And there was a sort of corollary to that in mission control testnet, 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 something called GDI, which was sort of an imaginary stable coin that had something like a, I can’t remember, a 0.5% return rate.
So it would want, the idea was that we’d create this dynamic between is it worth keeping the stake in the protocol, or will I get a better return if I stick it in this stable coin? So this is a similar situation that when you talk about Bancorp, if a Delegator decides to put their GRT into Bancorp, 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 outside the protocol, but they might be getting a better return. So it’s all comes down to personal ideals. And it’s the same question with APY within the protocol, 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 exactly the same sort of question.
The rational thing to do if you’re just a profit seeker is to find what the greatest return you can find. So maybe that might be outside the protocol, but from my point of view, it’s all fine making a great return, but what are you actually contributing to? Are you just a yield hunter or do you have some ideals? Are you in it for more than just a return? In that case, maybe you put a proportion of it outside in Bancorp 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, going to 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?
Jim Cousins (01:03:40):
My role 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. I believe 10 of us on the council, and we have a six of 10 multisig, which means that in order to pass any motion or any changes to contract or anything like that, we would 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 equality running through the discussions, but the nuance is also taken into account. It’s not just equality for equality’s 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 I’ll have different hats on at different times. Sometimes I might be expressing my own opinion, and other times I might be trying to just give an overview of maybe a hotly debated topic, and I’m not specifically going into 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 taken on board as part of the council. And 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. It’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?
Jim Cousins (01:05:46):
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 at 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. It just basically talking about the last month of happenings within The Graph that impacts Indexers. And if you are a busy person that doesn’t have the time to be around 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.
Jim, 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?
Jim Cousins (01:07:20):
Well, I think graph is a really great example of a work token architecture where we’re using the GRT token for many different, it takes on many different roles and allows us to provide a decentralized service to the community that needs it. I think the potential, once The Graph protocol itself has matured is endless and it goes way beyond just providing data for dapps. It’s looking way beyond that into replicating this model for other services. When I think about where this is going and why I’m so, why I’ve got the mind virus when it comes to graph, it’s 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 a subject of 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 might currently have centralized services providing information. That’s where the whole Google of blockchains thing comes from. Maybe somebody could be provide a decentralized search service using the same software. Maybe somebody could take an existing software as a service industry, a really big one, and make it work under a work token. That’s the type of thing I like to think about. Things that are so, 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 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 the audience 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 Wavefive?
Jim Cousins (01:09:23):
Sure. So I’m most active on Twitter. My Twitter username is underscore 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, wavefive.co. You’ll always find me on The Graph Discord. I’m usually in there talking with other Indexers and Delegators and Curators. So 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.
Receive New Content
Direct to Your Inbox
CONTINUE THE CONVERSATION
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.