Episode 07: Today I’m speaking with Gary Morris, an Indexer (Staking Facilities and 0xFury) at The Graph and a member of The Graph Council. We recorded two interviews with Gary – one before the recent migration of 10 subgraphs to the mainnet and one shortly afterwards.
Our first conversation, recorded before 4/27, covered a range of topics, including Gary’s work on The Graph Council, his unique perspective working with a large Indexer operation (Staking Facilities) and operating his own, smaller Indexer (0xFury).
Our second conversation, recorded on 5/1, Gary came back to discuss the migration, what he experienced as an Indexer during the migration, and some advice for Delegators.
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.
So the fact that they had this product that was already highly adopted, tied to their token, and now they’re trying to decentralize that it ticked all the boxes, and then even some In addition, and I think that that’s something that’s very eye opening to a lot of people. When they start to get more closely involved in The Graph, they start to see that underlying value, in addition to the surface level value.
Welcome to the GRTiQ podcast. Today I’m speaking with Gary Morris an Indexer at The Graph and member of The Graph Council. Gary offers a unique perspective not only because of his role at The Graph Council, but because he works on the Staking Facilities team, a large and well known Indexer, while also operating his own smaller, independent Indexer operation 0xFury. During this podcast, you’ll hear two separate interviews. The first interview with Gary Morris was recorded before April 27, which is when the first 10 subgraphs migrated to the mainnet. Rather than delete the first interview, which contains a lot of great information, Gary agreed to let me publish it in its entirety. Gary also agreed to come back and record a brief second interview about the migration. So near the end of this podcast, you’ll hear a second interview with Gary that took place shortly after April 27 in the recent migration, during the second interview, Gary provides some insights about the migration from the perspective of an Indexer that listeners will find interesting and helpful. When we recorded the first interview, we started our conversation talking about The Graph Council.
There’s 10 members of the council and there’s two from each stakeholder group. And I represent the Indexer stakeholder group along with Jim from Wave Five. And I guess the way it’s seen is that we’re supposed to fight the corners of our respective stakeholder groups. But that’s in fact, not the case at all. It’s just so that each stakeholder group has representation. But everybody on the council is expected to avoid any kind of zero sum thinking. So any decisions we make need to bear in mind every stakeholder because every stakeholder in The Graph is an essential piece of the puzzle. So, as far as council activities go, we have our calls from time to time where we have to discuss things that are going on with the foundation. Any proposals upon come in any situations that, you know, we might need to act on. There’s often security or, or legal aspects that we have to discuss.
How do you approach your role representing Indexers on the council?
We obviously have to keep a close connection within the community, we I think myself and Jim are both very active in the community. And we talk privately and publicly to a lot of people, whether it’s in Discord, or on the forum, you know, DM’s, wherever. And we’re always there for people to pass their concerns to. And it’s not only Indexers that, you know, can bring concerns to us. We were also completely open to, you know, hearing from anyone who has any kind of feedback or concerns.
Is there a particular focus you place your attention on?
My focus has always been on? How can we keep the network decentralized, and, you know, make sure that smaller Indexers can stay involved. And I think that’s something that is maybe overlooked a lot of the time by a lot of people, no matter their position in the ecosystem. I mean, the point is to be decentralized in the endrun.
So tell us a little bit about your professional background.
Well, a lot of my education was studied in university, generally was Computer Science, I guess, but we’ve focused on computer networking. But when I came out of university after I graduated, I didn’t really want to focus on networking. As essential as it is it wasn’t really something that I enjoyed. I more enjoyed the kind of Administration, Systems Engineering type side of it. So a lot of my focus in my career has been, I guess you would call it mostly Systems Administration, but I’ve always tried to move away from the lower tiers like I guess you would be because, you know, System Administration is pretty broad, it can start off with you being the guy that changes the batteries in people’s mouse. And it can be you, you know, talking to ISP trying to troubleshoot site to site connectivity issues. So I’ve always tried to aim myself towards the more challenging stuff, because if it’s not challenging, it’s just not fun to me.
So then, how did you first get involved in crypto?
So my story starts quite a long time ago, I think it must have been around 2010. And I was actually an intern at the time. And I heard about this thing called Bitcoin. And I looked into it a little bit. And, you know, I was, you know, I’ve always been interested in computers, and I was a SysAdmin/ Network Engineer intern at the time. So obviously, very hands on with, you know, any weird little tech, things like that. It’s kind of in my blood. And I remember reading about mining Bitcoin. And, you know, I downloaded everything I needed to mine it and search and you know, I read about doing this with CPU, or GPUs and I had a gaming PC. So I was all set up and ready to go. And then I read a story in the news about a student who was mining in his dormitory. And obviously, they lived in a small dorm room at the time. And he was mining, this Bitcoin thing that I’d heard about. And he gave himself minor brain damage, because he left his windows closed during the summer, and his room got too hot. So I don’t know why that kind of like spooked me a little bit. And I was like, I don’t really understand this thing. So I’m just gonna give it a pass for now, obviously, mining it back in 2010, 2011, would have been a great move. But I kind of forgot about crypto for a couple of years after that point. And then I guess it was probably back on my radar sometime around 2013. And I think some of the big tech sites and Engadget or someone like this, started talking about crypto a lot. And I was like, oh, that thing. Yeah, I remember this thing now. And I looked into it and realize, you know, I’d made a bit of an error, taking a step back, back then with mining. So I hopped right back on the trend and started on with GPU mining. And it was a little unfeasible in my position. But I did it anywhere I live in an apartment. So you know, I didn’t have a basement or somewhere to put these noisy GPU miners. So I did the reasonable thing and built a canvas greenhouse with air venting on it on my balcony, on the third floor. You know, quite good security, on the third floor, just running these mining rigs in a canvas greenhouse. And, you know, that was kind of fun. But it’s also a lot of work, you know, I was going on Bitcointalk, every evening after work for hours looking at what the next big thing to mine would be this new announcements every few hours coming out. And you know, so much speculation going on, as to is this coin going to be the next big thing is that coin going to be the next thing and, you know, the I was mining things, you know, like, DUG coin, and CataloniaCoin and Catcoin, and just all kinds of random nonsense, because at the time, you saw so many people making, you know, great gains, just GPU mining, you know, and I kind of, I think back then, I wasn’t in it for the tech. As you know, the meme goes, it was just more speculative for me, you know, I was I was a fresh graduate at that point. So, you know, even getting into GPU mining was quite a big investment for me. But I saw this is kind of an avenue to take advantage of some of the hype surrounding this stuff. And then as we all know, everything kind of went back down in 2014. And, you know, I had to spin down my mining operation, because it just wasn’t really feasible in Germany, you pay 35, 40 cents per kilowatt hour of electricity. So, you know, it’s not really the best place to mine. And even if you have, you know, some balcony best colocation like I did. And then I guess I went dormant again until maybe 2016. And then I started looking into the space a little more, because I still held some of the things that I mined. And one of those things was Darkcoin, which later became Dash. And I looked back on that and I looked on back on some of the other stuff and it wasn’t doing so badly. And then I started to look into some projects a bit more deeply on the technical level. And I started to see something beyond the speculative value, I started to see some real use cases and problems that people were trying to solve. And I started to actually get involved in some communities and even work amongst some projects over the past few years. And I had my hands on with a few different projects in various capacities.
And I spent a lot of years running different types of nodes which kind of fell well in line with what I was doing, you know, System Administration System Engineering. Computer Networking as my full time career, and then I came across a tweet some time, I think it was 20…must be mid-2019. And I saw some monster GPU rig of some kind. And it was a tweet by Stacking Facilities. It was their Solana testnet miner. And I saw this and I was like, wow, that’s some, you know, impressive hardware that they built for themselves. And I looked into them, and they were like, oh, you know, staking company, blockchain validator. And I was like, what’s, what’s a validator company? And I was, I was looking into it. And you know, they thought they were in blockchain notes. And I was thinking, hey, I’ve been doing that for years at this point, mostly for free, you tell me I can, I can make a career out of this. And then I looked into Staking Facilities a bit more. So they had a vacancy, wrote to introduce myself to them. And you know, the rest is kind of history, though. I joined their team towards the end of 2019. And I’ve been there ever since.
When did you first become aware of The Graph?
So after I started working for Staking Facilities, and they obviously had a hands on with a lot of different projects, other than the ones I’d already been working, and, you know, dabbling in in my spare time. And we were having a conversation one day about, you know, who’s going to be the Project Lead, I guess, you would say, for different projects and The Graph had been on my radar for a short while before then. But I’ve never dived into it fully, or really got myself involved in the community. And then around summer, last year, we were having this discussion. And I said, you know, I’d like to be our lead for The Graph, because it sounds interesting to me. And obviously, The Graph was actually quite popular within Staking Facilities. So I wasn’t the only one that wanted to, you know, take the lead on that. But in the end, I did. And I’m glad I did, because as soon as I started getting involved more closely, I realized that the product they were building was much more than I’d imagined on the surface level. And not in addition to that, the community around that had been built around it already. And I guess, especially as far as the testnet Indexer guys go, was probably the warmest and most helpful community I’d come across. And we’re just talking about when all of this was in its infancy testnet hadn’t even begun. And I’ve seen in over projects that I’ve been a part of that these things can live or die by their community and to have such a strong community. So early on, was such a big plus point to me going into it. And I guess that’s something that just drew me in further.
How would you explain what drew you to The Graph?
I think something I know a lot of other people in the space look for is kind of what is the token for? Is there a purpose for the token, is there a use case for this product is the adoption, then even before main(net), The Graph has already been taken all those boxes, you know, you’ve seen the kind of adoption rates that they’ve been seeing, and it doesn’t show any signs of slowing down. So the fact that they had this product that was already highly adopted, tied to their token, and now they’re trying to decentralize that it, it ticked all the boxes, and then even some, in addition, and I think that that’s something that’s very eye opening to a lot of people, when they start to get more closely involved in The Graph, they start to see the underlying value, in addition to the surface level value.
So what’s your opinion about the type of opportunities The Graph creates for people like you and others?
So there are a lot of opportunities in this space in general, not only within The Graph, I mean, for example, I speak to at least 10 people, mostly on a daily basis, who were in The Graph testnet with me, and a lot of them are already making their own path in this space, whether that’s as an independent Indexer working for a project or even within The Graph, or the foundation itself, in some form or fashion of all the people that I spoke to on a frequent basis in testing that I’m actually the only one who’s still in the same employment situation as pretestnet. And this is all in the span of maybe eight months since I met these people, things move really fast in this space. And you know, there’s new opportunities cropping up every day. And it doesn’t really matter on your skill set. I’m just talking about people are in technical roles, but there’s obviously opportunities no matter your background. And it’s quite interesting because this is this is obviously great, as far as decentralization goes as well as being great for those individuals who are you know, capitalizing on those opportunities, but actually, it kind of impacts larger Indexer/Validator outfits, such as you know, where I work Staking Facilities, it makes it really hard to source new talent. Because in this space, it’s so easy to kind of forge your own path that you have to offers something really great to turn someone away from, you know, making it on their own.
It seems like the opportunities created by The Graph is something that you really get excited about.
It’s really cool to see, so many of these guys that I spoke to, like, you know, some of them had certain jobs with some projects or companies before, some of them were even unemployed. And you know, they worked hard in the testnet, obviously, they got a sufficient bag to make indexing feasible for them. Some of them chose to even not continue index and just delegate their funds, but then went on to work for other projects. And it’s really cool to just see like, all these people making it off the backs of their own efforts and purely on merit, like hard work being rewarded hand over fist.
So let’s talk about Staking Facilities for a moment. You work for Staking Facilities, which is a large Indexer at The Graph, but you also operate your own independent, smaller Indexer. How does that work?
Obviously, I was, you know, involved in running this kind of infrastructure before joined for Staking Facilities. And when I joined, I made it clear that I’d like to continue doing that in some kind of capacity. Because after all, the point of the sphere is that there’s some aspects of decentralization, so they were completely fine with that, I think any reasonable employer should be okay with their staff members, you know, having extra-curricular activities, if you will, as long as they don’t conflict with the main business or, you know, eat into their, their official working times. So I run the Staking Facilities Indexer. And I also run my own on the side, and Staking Facilities, were completely fine with me doing that. And it’s nice to have that kind of freedom. And you know, The Graph is just one of the projects I take care of, in my own spare time. And the funny thing about this space is, I think that makes it different to a lot of industries is that even if you’re in the same line as business, when you do something like this in this space, you’re not clear cut competition. For you know, even in my case, I’m not clear competition for Staking Facilities, because like I said before, the point of this space is decentralization and they recognize that I think other people recognize that. And that’s one of my kind of motivations to continue doing that is because, you know, there’s only so many cogs in this wheel. So if I can be an extra cog, then you know, that’s a plus for everyone. And another benefit of this, I think, is that there’s less of an adversarial perception looming over us, is more of a general camaraderie I find within these operator communities.
What have you learned about the difference between working at a large Indexer and operating a small independent Indexer?
I would say there’s a lot of challenges. Or, let’s say the little guys, the independent guys, I can obviously observe how things go in a validator, I guess you would say industrial grid validator, outfit like, Staking Facilities you know, within my own operation, and then also contrast that to people I know, in the community who are just up and coming stays with their Indexer operations. And I think a lot of the little guys have a lot of challenges ahead of them, or even that are on their shoulders at the moment. And a lot of that is to do with, you know, having the means to compete within the ecosystem. Because obviously, hardware OpEx, CapEx, things like this, not everyone has the means to get up to speed. And, you know, you also don’t have additional staff members, initially, who can help you with these things. So basically, every task, every responsibility, every issue falls on your shoulders. But in that sense, they also have, in a way, an upper hand if they play it right. And that is something I’ve said to all the smaller Indexers who’ve come to me with, you know, doubts, concerns and worries that they’re not going to be able to maintain a role as an Indexer in The Graph and I’ve said that even successful large operations, like stacking facilities and an over big names, they all have a lot of overhead to take care of, which obviously is taken care of, by you know, diversifying their time across many projects, in most cases, you know, a lot of big name validators, they run 10-20, maybe more projects, maybe multiple nodes within those projects. So they have a lot of revenue streams, and some of these smaller guys, graph could be their only revenue stream. But since they don’t have that, overheads, and, you know, not just cost but also time and you know, distractions of running a big operation. I’ve always said to them that as long as you can make your operation lean, and, you know, come in in a competitive way, whether it’s on costs or how you spend your time vs. the big guys, I feel like there’s definitely a position for you in a project like graph. And I think as long as the mechanics stay for to, you know, Indexers of all sizes, and we try and balance the, you know, various variables of the protocol in a way that doesn’t only benefit small Indexers and doesn’t only benefit large Indexers, I think there’s going to be a chance for every good actor of every size to compete.
There’s a lot of interest in the upcoming migration to the mainnet, what would you tell Delegators, as they think about this move?
The Graph team, and well, let me refer in this, as the Edge & Node team, as they’re known now, they’ve proven themselves to be very methodical and cautious, and they like to do things right the first time. So I think the way it’s going to go as you’re going to see a slow, steady stream of subgraph start to get migrated over, maybe you know, 10 at a time, then 20, maybe 50, maybe 100. And then I think once things have been tested on mainnet, and they’re happy with how things are going, I think the floodgates will then open quite quickly. I obviously don’t have any kind of timeline for this. But they’ve always said, you know, quarter two, quarter three, and quarter four this year. So, you know, personally, I’m hopeful the majority of subgraphs could get migrated this year. But you know, we have to wait and see, you can never really tell when you’re developing products like this, what snags you’re going to run into. And I know we’ve run into many snags along the way but the Edge & Node team have always proven themselves capable fighting through any kind of issues we come across. So I am very confident in their ability in the likelihood of us seeing a lot of sub-net migration this year.
Do you think things will change within the index or community following the move to the mainnet?
I would say it’s a giant unknown. Because I could make an educated guess that would come back and bite me. But I’ll go ahead anywhere, I think that the more adoption The Graph sees and the higher query traffic goes, the more space that’s going to make for more Indexers to join the network. But it’s also going to get a lot more competitive. So in the same sense, what could make space for more Indexers could also squeeze out over Indexers. So it’s going to be very important for people to stay very focused and involved in everything that’s happening in The Graph. And I think a lot of large and small Indexers could end up becoming complacent to the point where they start to, you know, lose the ability to stay competitive within The Graph, because the former graph team Edge & Node, they’ve always said that they envisioned the role of an Indexer being a full time operation. And I can tell you from the experiences in the testnet, which were still just a small slither of, you know, the kind of work capacity is going to be once the subgraph migration starts. Even that was definitely a full time job. So I think there’s a lot of challenges ahead, no matter the size of the validator operation. And you know, it’s going to be interesting to see who rises to the top and who kind of like, you know, flounders and sinks down.
Let’s shift our attention to the relationship between Indexers and Delegators. How do you think about that relationship?
The way I feel about the relationship between Delegators and Indexers is that it’s maybe gotten off on the wrong foot for various reasons and due to various variables, but it’s still very much in its infancy. I think the dynamics between Delegators and Indexers is going to change massively. Once migrations begin to happen, and Indexers start to become a little more judged based on the performance side of things. I also think that there’s been certain things happen along the way in the past few months that have, you know, made delegates feel on the backfoot. An obvious example of that would be the proposal GIP-0002, which was to allow Indexers to withdraw the rewards. Now, this, this is something that was intended to be in when mainnet launched, but you know, due to, due to certain issues with communication timelines, things like this, it didn’t pan out as such. So Indexers were actually left on Apple to should have said tech profits or any kind of revenue from their operations. And they’ve also been unable to take anything be were rewarded from testnet due to them being in token lock contracts. Now, the issue with that would have been fine. You know, Indexers have been pretty patient with that. But the issue is it was this kind of mechanic wasn’t in from the start. So when Delegators joined the network and delegated their funds they agreed to a certain set of, let’s say, terms or mechanics as they understood it, and as they existed at the time. Now, even if this mechanic for example was intended to be in from the start, obviously, it was absent when Delegators has joined the network. So it’s understandable that they were not really happy with seeing something introduced, that wasn’t there. And they had no idea it was coming. And, you know, in an ideal world, GIP-0002 would have taken on a different form that probably would have been a little more equal and equitable between the two stakeholder groups. But unfortunately, due to, you know, technical issues that are a little above my pay grade, it wasn’t actually possible for a solution to be implemented that, you know, for example, to add a 28 thaw, to Indexers, which would have been preferable for a lot of people and was actually investigated investigator with GIP-0004. Hopefully, there’s other ways we can actually address Delegator concerns going forward. As a council member, I’m very interested in any suggestions that come up regarding that. Even if we can’t find equal footing on an issue, such as GIP-02, there’s maybe other things that we can do to alleviate Delegator concerns. For instance, one concern that I see come up plenty from Delegators is the issue of redelegation. So they will delegate to an Indexer, maybe, you know, they made a bad choice than the Indexer. And you know, they change the cooks on them or they’re not, they’re just generally not happy with the Indexer for various reasons, they then need to go for a 28 day thaw, in which time they own no rewards, before they can actually retail get someone, if we could make read delegation a bit more dynamic for Delegators. I think that would be something on the checklist of a lot of Delegators may kind of you know, go some length to bridging the gap left by something like GIP-02 two. And it would also have the added effect of keeping a lot of Indexers more answerable. If they’re not able to, you know, kind of entice delegations and then report them, as it were.
What have you seen in the relationship between Indexers and Delegators with your unique perspective on The Graph Counsil?
The thing I’ve noticed a lot is that there’s a lot of tribalism, and there’s a lot of us versus them mentality. So it’s something I want to kind of communicate and I’ve been trying to communicate more clearly, in the past month or two is that it’s not us versus them mentality, and even on the council. I’m not just representing Indexers. I’m representing everyone. That’s my goal, you know. Hi, this is Gary Morris, and I’m an Indexer and council member at The Graph. My conversation with the GRTiQ podcast has been helpful to you, then please consider supporting future episodes by becoming a subscriber. Is it GRTiQ.com/podcast for more information GRTiQ.com/podcast. Thanks for listening.
To see the relationship between Indexers and Delegators changing, following the move to the mainnet.
So this is going to be when Indexers selection starts to matter, a lot more than some of the surface level, APY’s based decisions, let’s say that Delegators are making at the moment it’s going to it’s going to start having an impact based on an Indexer of stack efficiency, their query performance, their cost modeling, which is a whole extra rabbit hole that you know, Indexers have to worry about. So I think once this activates, there’s not only going to be challenges for Delegators, but there’s also going to be challenges for Indexers. And no matter your role in this ecosystem, there’s a lot of things come in that are going to add a lot more challenge and questions the people on both sides of the fence. And I think from the shoes of a Delegator, what you’re going to need to start to look at is who’s really acting in a dynamic manner on the network who’s adjusting their allocations across all the new subgraphs versus, for example, who is still got their allocations tied up on, maybe they have their allocation weighted into subgraphs in an incorrect manner. As far as it relates to the curation signal, maybe they’re not closing and opening their allocations very frequently than first not being very dynamic, not really reacting to the state of the network, because all those things are going to lead back into impacting the returns the Delegators see. And I feel like this is going to be the point where people who are really on the pulse, whether they’re big or small Indexers are really going to rise to the top and start to get noticed by Delegators. And the more query traffic that actually shifts over, the higher these people are going to be elevated, you’re really going to start to see a difference in performance between who is and isn’t paying attention, and who’s actually trying to work in the interests of their Delegators on a daily basis.
There seems to be a consensus that the way Delegators select an Indexer following the migration will become even more important. Would it makes sense for Delegators to un delegate in advance of the migration to be ready for this new environment?
I wouldn’t say there’s any reason for Delegators has to change their allocations, the allocations that we’ll be changing will be on the Indexer side, because this will be what determines their share from, you know, inflation rewards and query fees goals, what Delegators need to do is to start paying attention to how reactive their Indexers are, and then start to see whether there’s more performance and force more profitable targets for them to hop on to, but bear in mind, there’s going to be that 28 day thaw, so you shouldn’t make those decisions lightly, no matter which direction you’re going.
So I asked everybody that comes on the podcast, what’s your advice for Delegators? When selecting an Indexer?
It’s a very long and broad question. But it’s very easily summed up with, Do Your Own Research (DYOR). So some points that you could make on Do Your Own Research, you should look at who’s active in the community, not just to see that, you know, maybe this person is on the polls, they’re going to, you know, be performing once query traffic starts picking up. But also, because from the impression I get, it’s preferable to a lot of Delegators to have the ability to contact their Indexers should the need or want to, as with any investment decision, I would consider spreading your assets and verse risk across more than one option. If the amount of GRT you have makes sense, because we have to bear in mind things like gas costs, which, you know, obviously, as a monetary cost to enter an exit in these positions. And if you spread across multiple delegations, that cost increases pretty linearly. APYs, obviously very important to a lot of Delegators. But from observation, going for purely the highest returns can often be very risky. You know, it’s possible for there to be unknown actors with no ENS addresses set to run Indexers. And you know, they could always flip their coats at will, because not every Indexer makes use of the parameter lock feature. In my opinion, that feature needs to be revised a little and improved, maybe even a new feature, introduced to replace it, because I don’t feel like it’s sufficiently protected delegate as at the minute. And I also feel like it hampers Indexers, and stops them from being dynamic with their cuts. You know, responding to new delegations are lost delegations. So it really needs to be improved and aware. And there’s already been a lot of suggestions of how to do that. But, you know, there’s a long list of improvements to get through. So that’s one of the things on the to do list, I’m sure. One thing I would say, though, and something I noticed from a question in the community today is that if you notice your returns change, you should bear in mind that it can often be due to things that aren’t a malicious action by the Indexer. There could be, for example, they just got a lot more delegation added to them, and didn’t, you know, have the time opportunity or an or not to set so they could adjust their cut. And as long as they adjust their cuts, to be more in line with what it was before they got that delegation, for example, you won’t actually lose anything, because rewards are only calculated when they close their allocation. And I would say it’s not just the first time that you delegate, obviously, that you need to do your own research. If you plan to switch Indexers. It’s just as important maybe even more important, because you might feel you have a grasp on who a better target will be this time around. But it’s completely possible that you know, for example, the APY of your intended target could change by the time you’re GRT unthaws due to you know, them receiving more delegations or changing or cuts. It’s always a risky move. And as I’ve said before, it would be nice for there to be a way for delegates to more easily switch their delegations wants their funds are in protocol, rather than having to remove them and then reintroduce them because you know, there’s always that 20 a day thaw period that they have to go through.
Are there any red flags that you would share with the Delegator community when working to avoid a bad actor Indexer?
You could set bad actor or, you know, it could just be a bad target for various reasons. Sometimes, you know, people, for example, might look at the APY of an Indexer and find them quite a juicy prospect. And then the APY will quickly change. But this can sometimes not be the fault of the Indexer. It could be that they have, for example, a low stake amount and force, even small amount of delegation dropped on them, could substantially change the APY that delegate has received from them. I would say one red flag in let’s say 99% of cases would be the absence of an ENS name, which is the name you see above the address on the official dashboard. And, you know, most of the dashboards, if they haven’t bothered setting ENS, it’s often hard to identify them. I will say there are a few exceptions to this, a couple of which you will see towards the top of the official dashboard, I’m not going to name names, because it’s obviously I can’t name names, because they haven’t set in them. But I will say it’s not the case in every situation. But it’s a very common red flag, if you ask me in 99% of cases. I would say, as far as over red flags go, it really depends how much time and energy you want to put into researching. And I guess that’s partly to do with, you know, the amount of GRT you plan on delegate and your risk appetite. There’s so much data that you can look at, for example, on, you know, dashboards like graphlibs or graphscan, you could check how often they close the delegations, if you’re interested in that, or, you know, maybe you’re interested in front running their allocations, you could see how often they change their cuts, you can see all kinds of things. But I think what is often the best course of action for people that don’t want to get too far into the weeds, is to just go into the community. And if you’ve got some ideas of who you might want to delegate, you could ask, what do people think of this Indexer? Do people have any suggestions for Indexers, and I think you’ll get feedback not only from Delegators, but also from Indexers. Because anytime a Delegator falls foul of a bad actor, or, you know, maybe made the wrong choice due to lack of understanding, it reflects badly on all Indexers, especially in the case of a bad actor. So that’s not something any Indexer wants to see happen. So I think if you ask any questions in The Graph community, there’s always going to be someone there to help you.
Would you agree it’s a red flag when an Indexer doesn’t close their rewards allocations in a 28 day period?
It depends how you define a red flag, I would say that there could be a number of reasons for this. But obviously, it’s not a good situation for them to be in, it could be something as simple as forgetting to top up their operator address with Ethereum and saw their graph edge and come close their allocation, it could be that their infrastructure down, which is obviously not good. But regardless of the reason once or above that 28 day period, they don’t earn any rewards. In addition to that, and obviously, if you can’t contact them, and they haven’t advertised what the issue might be, you don’t actually know how long that’s going to persist for and I saw one the other day that hadn’t closed in something like 69 days. So you know, people, whoever was delegated to them. During that time, they lost out on more than a month for reward. So obviously, that’s something you want to avoid being tied up on. So I would say it’s worth something definitely taking note of when making your selection.
Do you think there comes a time when Indexers specialize?
There’s certain ways the Indexers could behave or, as you say specialize, they could, you know, some Indexers, especially if the means as far as you know, resources are low, they might try and focus on the less heavy, subgraphs that aren’t as resource intensive, and try and run an operation this way. Obviously, that won’t be fully optimal if you’re ignoring certain subgraphs. But at the same time, it all depends on the cost that consumers are willing to pay. Maybe ignoring some of these larger subgraphs, doesn’t actually impact earnings that much, but you know, this is a free market. So I think if that situation arose, and there was not so many Indexers, and not a great response time for those consumers, they’d obviously have to up the rate that they’re paying for that, you know, but the way I imagined this will play out is that dApp developers, consumers, whoever, however, you’d like to refer to them as I think that though, it’s more likely that they’re going to actually communicate with Indexers as a group. And this is something that’s actually going to be essential because there’s going to need to be some kind of orchestration between these developers and the Indexers to ensure you know, a high uptime on their subgraphs, you know, good performance, and, you know, maybe a new subgraph comes along or a new version, and they want to Indexers to, you know, index that quickly so that it’s ready to be consumed sooner. I think sometime in the near future, once the migrations have occurred, you’re going to see a lot of discussion happening within the community between Indexers. And those developers.
Delegators are always curious about seeing The Graph use cases. Is there a particular use case do you think Delegators should be interested in or might have encountered?
Yeah, I mean, one great example I could give, it’ll be a name that everyone should recognize Uniswap. So they built a subgraph for Uniswap v2 as it stands, which processes their raw on chain data and transforms it into more useful data structures. These are defined in the subgraph schema. And it can then be queried and consumed a lot more easily by developers when integrating into the dApps decentralized applications with the added benefit of avoiding the overhead of processing on the page. So you can even see this data in action if you go to info.uniswap.com. This page is actually powered by the Uniswap v2 subgraph itself. And, you know, I understand the confusion behind this because I’m not a developer myself. So it’s still quite hard for me to grasp some of these things at times. So I completely understand why it sounds alien to most people. So I think it’s great when you can actually see this stuff in the wild and how it’s being used by projects.
Are there any upcoming announcements or milestones that you think the Delegator community should be watching for?
I think the next big milestone will be one that everyone is already aware of. And that will be the subgraph migrations that should be coming fairly imminently. I think this is going to completely change the dynamic, for Delegators. And it might even make it a little more complex when it comes to choosing an Indexer. Because this is going to introduce a whole new variable into that choice, which is going to be query performance. And query performance isn’t just going to be some kind of raw brute force, you know, process as many queries as possible. There’s also going to be a case of you know, Indexers, setting their cost models correctly, making the stake efficient maximizing the returns for their Delegators. You’ve already asked me about how delegates should make their choice. And we’ve touched upon that. But I will warn that I think this is actually going to get a little harder for delegates further down the line. So that’s something they really need to be prepared for and pay attention to, because it’s coming very soon.
How do you advise Delegators, who feel overwhelmed or uncertain about staying informed?
There’s a lot of data to look at and consume as a Delegator or probably any stakeholder. And there’s a lot of the time, you don’t have the time or means to stay on the polls constantly. And things change very fast in this space. And I think the next big value add in The Graph ecosystem is going to be any product or offering that can simplify all of these variables in a way that’s more digestible and relevant to each type of stakeholder or consumer so that they can make better informed decisions without having to make the same kind of time investment is, you know, an Indexer might. I mean, there’s a lot of dashboards and you know, proposals coming into address things like this. So hopefully, we start to see things that make people’s lives a little easier on that front very soon.
Another question I typically ask podcast guests is how they define a subgraph.
I would say that the simplest and shortest way to explain it is it allows you to take data that exists in one format, and make it into something that’s more usable for a particular use case, without you needing to worry about how exactly and when that data is going to be processed. That’s basically what comes to mind. But I don’t think it’s a particularly interesting response.
Do you think it’s important that Delegators understand these types of technical things like defining a subgraph?
I could understand if Delegators don’t want to get into the thick of it with stuff like that? Because what’s important, I think, from maybe less technical role, like a Delegator? Is the product at the end of it, like what is the product? What are people paying for in the end? I think it’s completely fine for people to kind of, you know, focus on the more high level stuff like that, rather than going into the low level of how things work. You know, if they can see that developers have a use for this and it’s being highly adopted, which you can already see in The Graph, then I think that’s a valid level of ignorance to have, let’s say.
Last question, when it comes to The Graphs potential, what’s your vision?
Well, mostly,The Graph could be applied to all kinds of applications use cases products. But I prefer to not let myself drift off into fantasyland too much. So I try and stay a little more grounded and think about what I see coming in the short term. And it kind of takes me back a little, too, you know, in recent years, where I was working within a project that aim to be part of the multi-chain ecosystem, let’s say. And that’s something that I’ve always seen the need for and always had in the back of my mind. And I feel like the introduction of miltichain is going to be what catapults The Graphs success in the short term, and leads to further adoption, obviously, then, in the long term, multichain. And, you know, connecting all these different ecosystems is this huge value trap behind this. And, you know, there’s a lot of projects that are trying to work on this in various ways, not even the same manner The Graph is. But you know, what I would compare it to is basically, the internet, how the internet lets us connect to local area networks to over local area networks to make a global network. A big name in this industry is Infura. They’re generally well known for anyone that’s dealt with or required access to Ethereum endpoints. And this is something that graph reminds me of a little in various ways. But graph also offers something that’s much further beyond just offering raw endpoints, you know, it has formatted and process data that it can offer via API to developers, it’s just a complete level up from that offering. So you know, huge one open an already very successful and highly adopted business model. And Graphs obviously already seen a huge amount of adoption itself within the ecosystem, we find ourselves in who knows where that leads to let further down the line outside of our current ecosystem. And the fact that they’re already working very well on its way to decentralizing this offering is really some next level unicorn product, in my opinion. So a lot of what it could end up doing, or, you know, achieving, we might not like maybe Edge & Node, such haven’t even thought of it yet, you know, they’re always coming up with new ideas and new ways to improve the product. I’m not really surprised anymore when they come up with a good idea. And I just think there’s going to be more and more ideas, maybe not even from Edge & Node, but from our developer teams, who just think of the next unicorn to add to the unicorn, you know. And also, I would add that, in my opinion, The Graph already does for dev is pretty much what AWS lets DevOps do in general, it provides an offering that lets you bypass potentially large investments in your infrastructure, both in time and monetary terms in order to solve a problem quickly and efficiently. And ultimately, I think the culmination of all these efforts past and future is going to lead to The Graph protocol becoming very omnipotent and essential in the blockchain world, the same as TCPIP is for the internet.
So that concludes the first interview conducted with Gary Morris prior to the April 27 migration of the 10 subgraphs to the mainnet. The next portion of this podcast was recorded shortly after April 27. Gary was gracious enough to come back and answer a few more follow up questions related to the migration.
Gary, thank you for coming back and recording a follow up conversation related to the recent migration of the 10 subgraphs to the mainnet. Let’s start by discussing your experience and perspective as an Indexer as news of the migration filter through the community.
Well, the interesting thing is that once the first 10 subgraph migrations were truly announced, there’d already been a lot going on before then. And the even more interesting part about that is that there was less than 10%, probably close to 5%, of Indexers that actually noticed things occurring. You know, even a couple of days prior to the announcement, there had been some movements regarding signal and stick in the network. And I think there was somewhere between 9 and 11 Indexers out of roughly 170, that took action, because I think, while people have been waiting on announcements, a lot of people have probably lost a bit of their initial focus, but you could really get a sense of who had their finger on the pulse and was paying attention to everything that was going on, even before the migration and then since then, of course, we’ve seen more people hop over. But I think what’s really important is that Indexers, have a bit of a wakeup call of this and realize that they do need to pay attention to the dynamics of the network, if they’re going to run optimally and provide the best returns for their Delegators and themselves.
So when you say you noticed only a few Indexers took action, what do you mean? What is meant by taking action?
So, by taking action, I basically mean redistribution of their allocations to optimize, let’s say the share in rewards percentage that they’re receiving. If you’re, say, like, when the new subgraphs came along, there was quite a high stake to signal ratio, the discrepancy between the old subgraphs and the new subgraphs. So it made sense to get onto the new ones as soon as possible. Not everybody did this, there’s still some that haven’t done it. So I think Delegators should be paying attention to who’s really paying attention to these things, and making moves sooner rather than later. Because if you have a lot of lag between responses, or maybe you’re held back by bureaucracy, you’re not going to be dynamic, and you’re not going to be optimal. And you’re not going to be the most profitable spot for a Delegator to allocate his GRT to.
Should Delegators be concerned if their Indexer hasn’t allocated to any of the new subgraphs, and still only allocate to the pool together subgraph?
That really depends on the state of signal and stake at that period in time, it’s not always optimal to be on a particular subgraph, it’s not always optimal to be on all subgraphs. Maybe when query traffic ramps up, you know, if there’s two and beyond the migration itself, this will change. But for now, it can be completely optimal to balance yourself just on one subgraph. Ideally, in the same way, you’d expect the Delegator to spread their risk across more delegations, I feel an Indexer should consider spreading their allocations across more than one subgraph, because if somebody takes away signal or adds a lot more stake on to subgraph, and it’s the only one you’re on, your revenue is going to be impacted and your Delegators as returns are going to be impacted. So I think it’s still a good idea to spread that risk, where it makes sense.
The news of the migration was very welcomed within the Delegator community. How should Delegators respond? Is it status quo steady state, or if things changed enough that they need to respond or act in different ways?
The state is definitely less steady than it was when we only had one subgraph. Because, you know, there was no concerns about being optimal, there was no wherefore over Indexers to be more performant or dynamic or rise above the rest. But what a lot of Delegators probably already noticed is that there’s been a huge shift up and down between a lot of Indexers as far as the APY on offer. And that’s generally, because a lot of Indexers are popping on the new subgraphs there. They’re taking note of signals to stake ratios, and they’re optimizing their allocations, maybe, maybe even daily. I will say that when we had one subgraph, I was reallocating less frequently. But since the new ones came out, I’ve been rebalancing daily, where it makes sense, because I’d like to, I’d like to keep burning as high a percentage of the reward pool as I can. And really, every Indexer should be aiming to do this, not only for themselves, of course, for their Delegators, you always have to bear the interests of your Delegators in mind. Otherwise, they’re going to notice that you’re not keeping up with the changes in APY, you’re not getting your fair share. And they’re going to go elsewhere.
So when you say rebalancing your allocations, what do you mean by that? Should Delegators expect Indexer, rewards allocation scheduled to change? Maybe more frequently, like daily or weekly?
So when I say I’m rebalancing, daily, I’m talking in reference to my own node, because you know, I can do what I want, when I want to that since it’s, you know, solely under my discretion. But yeah, I do think that you’re going to see allocations probably shorten in length, in general, because people, as I mentioned, people need to act dynamically to optimize their share of the reward pool. Once we have more and more subgraphs in place, the costs related to open and close with those allocations that you pay in gas terms, is going to increase substantially, which may then reverse that trend back towards more long term allocations. And that’s the point where Indexers are really going to have to stop and start taking note of this and trying to strike an optimal balance in between allocation, length, and redelegation to make themselves optimal. Because if you’re just blindly closing your allocations daily, and you have 100 subgraphs, maybe with more than one allocation person graph, the amount of gas you’re going to be paying for those daily reallocations is going to be absolutely through the roof to the point where it might actually lose you money. So I think in the short term, yes, and move away from the 28 day allocations in the long term. Once you know we have maybe towards triple digit subgraph count, I think a reverse back to long term allocation. This is what you’ll see.
I want to ask a follow up question related to Indexers that only allocate to the pool together subgraph. If after a few weeks, a Delegator notices that our Indexer is still only allocating to the pool together subgraph. Is that a red flag?
So by that point, yeah, an allocation should have passed its maximum rewards period of 28 days, so they should have reallocated by then if they’ve then reallocated back to the original pooltogether subgraph. If it indeed, is even on the network, by that point, not sure if those bonds the deprecated in favor of the new one, you can now see on the network. But if they did re delegate back to the exact same subgraph, then that would, yes, this would be a red flag for me. I will say though, that this always depends on circumstances and deprecation or not, this would obviously depend on the signal and stake on that subgraph, you could see so many people move away from the old subgraph in the short term that possibly becomes more profitable than the new subgraphs. If it wasn’t deprecated, of course.
What’s your opinion about the 10 subgraphs that were selected to migrate? Do you know if there’s any underlying rationale as to why these particular 10 were selected?
Well, the way I understand that is that The Graph or Edge & Node Foundation, they’ve been speaking to certain projects that they would be interested in being what they call ‘aunch partners. And so these launch partners are essentially bringing some… what some production traffic, let’s say to our mainnet, so that we can test in a live environment. So in a way, they’re kind of doing us a favor of being our guinea pigs, in my opinion,
What advice do you have for members of the Delegator community who want to stay in touch about migrations, or better understand the most recent migration?
I’d say they just need to keep their ear to the ground. And, you know, pay attention to announcements, I would probably just refer them back to the blog post on The Graph site that goes over the plans for the three different phases of subgraph migration. So you know, phase one being where we are now, phase two, is, once these subgraphs have been bootstrapped to the network, we’re then going to move on to testing, production traffic, and from there on, the floodgates could open. As far as that big sessions, I don’t know whether, you know, floodgates could be 10 of subgraphs a week, 100 a month, who knows? That’s yet to be seen.
Last question. Many members of the Delegator community also want to act as Curators does the recent migration signal that the beginning of curation services have begun, and you can now begin curating subgraphs?
So there’s no interface official integration on the dApp for curating yet, but you can. Now you read to any of the subgraphs. However, you know, you need to know how to interact with the contracts or you know, go about this in a different fashion. It’s not something I would suggest to those who aren’t comfortable with interacting with contracts directly. I believe part of the plans of the migration is going to be the introduction of a curation UI. So I would probably personally suggest most people hold off until that’s in place. And by then hopefully, we will have a number of more of subgraphs, for people to investigate and curious if they’re interested.
Gary, thank you so much for your time, and all this thoughtful information. If listeners want to stay in touch with you and the work you’re doing at The Graph Council with the team at Staking Facilities, or your own independent Indexer, 0xFury. How can they stay in touch?
So I’m on Twitter at _fattox I’m not exactly active on there. So if you want to catch me, you’ve probably got a better chance of that if you hop into The Graph Discord, I’m in there, you’ll see me on the sidebar, under the council section just as Gary, feel free to DM me about anything you feel. You can also catch me on the forum. You know, I’d love to engage with more people on the forum. There’s a lot of interest in discussions always going on there. So make sure to check that out as well.
Please support this project
by becoming a subscriber!
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.