Alexandre Bourget CTO StreamingFast Dfuse Montreal Intel The Graph Firehose Core Dev Edge & Node GRT

GRTiQ Podcast: 42 Alex Bourget

Episode 42: Today I’m speaking Alex Bourget, Co-Founder and CTO at StreamingFast, a core dev team working on The Graph.

As you will hear, Alex is highly passionate about blockchain, Web3, StreamingFast, and The Graph. His brilliant career includes time at Intel, entrepreneurial success, and the creation of unique and valuable technology solutions.

During our conversation, Alex shares his journey from classical music to technology to crypto. Alex talks about what StreamingFast brings to The Graph, including a detailed discussion about the Firehose technology. We conclude our discussion with Alex talking about programmable currency, like Bitcoin, the future of Web3, and The Graph.

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.,[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.,[episode]).

Nick (00:00:17):

Welcome to the GRTiQ Podcast. We begin today’s episode with special recognition of The Graph’s first birthday, and a revolution that began one year ago today. And to get things started, we welcome back some old friends of the podcast to share in the celebration.

Nick (00:05:25):

And so, on behalf of GRTiQ Podcast, I want to congratulate the entire Graph ecosystem on this one-year birthday and everything that’s been accomplished. I not only look forward to the years ahead, but to the many contributions that many of you will make as The Graph continues to evolve and web3 reaches its full potential.

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.

Alex Bourget (00:06:22):

They understand, they get it, they see it. So it’s really rejoicing, I would say, to have landed in such a place that appreciates the work we have done, and also laid a nice ground for more growth, more adoption because The Graph had much more adoption than we had. So it’s a nice place to be, I would say.

Nick (00:07:14):

Welcome to the GRTiQ Podcast. Today, I’m speaking with Alex Bourget, co-founder and CTO at StreamingFast, a core dev team working at The Graph. If you’ve listened to the podcast before, then you already know the name StreamingFast and recognize the team for their technology and capability contributions to The Graph protocol. As you’ll hear, Alex is highly passionate and energetic about Blockchain, web3, StreamingFast, and The Graph. During our conversation, Alex shares his journey from classical music to technology to crypto, what StreamingFast brings to The Graph, including a detailed discussion of the Firehose. Alex also shares many brilliant ideas about web3, the future of Blockchain, and his long-term vision for The Graph. In honor of today’s date, I started our discussion by asking Alex to share his thoughts on The Graph’s first birthday.

Alex Bourget (00:08:12):

Well, yeah. Well, happy birthday to The Graph. And in the Blockchain space, one year, it’s similar to 10 years in the traditional world. The amount of innovation, the excitement, and the engagement, the community is well beyond a one-year-old protocol. And me and the whole team, we’re really excited to be part of it and we’re looking forward to the next 10 years of innovation over the next 12 months.

Nick (00:08:35):

Alex, I always like to start by asking guests about their professional and educational background. So what can you tell me about yours?

Alex Bourget (00:08:41):

See, when I was young, I used to program in my math class in high school. I would program in a paper, in a book, and I always was interested in computers and programming. But then, I went and I had a training in music. I went on in studying music and science to start with in college here in Quebec, and then did a classical music bachelors, and then I just jumped back into computer science, got a job in there. I wasn’t going to feed my family with playing classical piano. It was a crazy life to have these people there that would just work 12 hours a day on their piano, smoke a cigarette, and go back. I was just too interested in computer science and programming.


So that’s what I did. I studied music at night, and midday in the morning, program. But I never formally studied computer science, just informally. I always liked to play piano but play with exploring and curiosity in computer science and studying things because I was fooling around with these. Anyway, so my first job was… In high school, I programmed things for my father, scanning car ads on the internet with some MIRC scripts, absurd thing. And we had started a business doing that. I was in high school, that was in ’94, ’95, something like that. So I had a PHP 3 scripts at some point to… Anyway, so I did things. My first job was computerish, and then I joined Savoir-faire Linux. That was me jumping in the open-source world doing services over there. So that’s how I started my [inaudible 00:10:34] journey.

Nick (00:10:34):

Do you use any of those skills you learned as a classical musician in your job today? I got to imagine that composition and attention to detail is a factor here.

Alex Bourget (00:10:44):

Absolutely. I still think today that music is a great form of training, and the Greeks would train in music as a general purpose training for the mind. And maybe I have a small story for you guys. There was that story with that guy who was a conductor in orchestra, and he died. And they both made an autopsy and they figured out that his brain, his two hemispheres were closely knit together. And that usually is not how adults brains are laid out. They separate through the life. Babies have very tightly-knit hemispheres in the brain, but they slowly separate and they specialize… You have language on one side, but it happens that music is one of the only disciplines that bring together things of the different hemisphere.


And it’s done in a high performance way. Managing emotions, and language, and motor skills, and all these things that, normally, in other disciplines, do not intertwine, which I think makes music an incredible training for intelligence in general for the neurons. That is kept. I’ve seen musicians just outperform everyone in so many disciplines. So I’m really happy to have that background, even though I didn’t practice as much as I could… And we have also a bunch of musicians in StreamingFast, and it shows. I have a friend, she’s a neuropsychologist and I was participating in helping her studies when she was doing her doctorate, and in their discipline, they would systematically note if you’re a trained musician because they would always skew their studies. And she told me that there’s really… Yeah, how does she say it? Brain plasticity? Things are different physically when you have people who trained well in music.


So, is it useful today? Definitely useful. I’m not saying I’m a superhero or super brain there, but I think I can see that there’s some discipline. You said also there’s attention to detail. I see in music, you’re organizing things that are very minimal. You’re moving your hand a quarter of an inch, and then making sure you stretch the finger this micro movement to reach out for a larger phrase, a larger movement, a larger piece. It all needs to make sense. So, there’s really architectural design in music that in software engineering you need to do, and you need to maintain all these abstractions layered at the same time, the micro and the macro, constantly going from one to the other, a software engineer requires that, and in a very particular way too. Large scale systems, but a great library with good dependency of whatever.

Nick (00:13:28):

Well, one of the themes of this podcast is that the guests do represent varied backgrounds. And I have to say, this is a GRTiQ first in being able to interview a classically-trained musician. I think another first for this podcast in being able to interview you, Alex, is you have seven children and that is a new record for a guest. Most of my guests haven’t even had children. So I think the question is, how do you find the balance?

Alex Bourget (00:13:55):

Yeah, I have seven kids. Well, from the same wife if you ask. I have a great wife. She’s the best. She helps manage me and the seven kids so that we have a successful life and fun times. I was just telling her this morning, it’s awesome with the number of kids that they’re finding themselves, like friendship, and they’re having a life of their own and exchanging things that we’re not part of. They [inaudible 00:14:25] at night and then play Legos, and there’s a small community. So that’s really awesome.


But how do I manage? Yeah, my wife does a lot of the work, and I would say that, after a certain number of kids, things get simpler. If you have a few friends that also have a bunch of kids, but for us, it was number four that was more complex, number five, six and seven really they just entered into something that was already organized. You get a first one, changed your life. Two? Okay, that’s one-on-one, you’re two there. And then, three, you need to organize. At four, depending on the ages, it’s more or less complex. Ours, we have four in four years or something like that, when the eldest was four. So that was a little trickier. But number five, we didn’t see past. Six, seven, things are well-oiled. I must announce here that we’re going to be waiting for an eighth child sometime in June, something like that.

Nick (00:15:14):

Oh, congratulations.

Alex Bourget (00:15:16):

Yeah, thank you. Thank you. So does that answer the question? I don’t know.

Nick (00:15:20):

It answers it well, and congratulations to you and your family. I really appreciate with the schedule that you have at home and at the office that you’d take the time and speak with us today. So thank you for that. So I want to get back to your professional trajectory. You started in music, you made this move in high school to more technical, learning code and different things. What happens next in that career trajectory to get you to StreamingFast?

Alex Bourget (00:15:45):

Right. Well, so did a lot of open-source work. And then, at some point, I was in a services company. And I realized this. In a service, I don’t want to say everyone is mediocre in service companies, but I discovered that, in services company, you are incentivized to have medium people. I say mediocre because mediocre means medium. It’s more punchy, I guess. But, if you’re very good, you make less hours for the same job, therefore less pay. And if you’re very good you’re going to have a higher pay there for less margin. So I just discovered that there’s an incentive to go to products company. Products company will have the best talent, said, “I wanted to be with the best and learn from the best.”


So I switched from there to go to a product company. So I joined a startup and we built things. I started lean startup, lean analytics and I started building a lot of data systems for the company. And then, at some point, no cash in the bank there, I started another thing, and comes May 2013, where I read the Bitcoin Whitepaper. And I read the whitepaper and I say, “This could actually work. This works. I mean, it is simple seven-pager there, and it could work.” So I was fascinated. I was fascinated by this, the fact that, all of a sudden, money in the world could be programmed. I could be part of those who program the money. It’s in my realm.” I’m like, “I just open a new terminal there and I could interact with the money system there.” So, I was fascinated.


So I founded a first company called, was the first Canadian Bitcoin payment processor out there, was in Las Vegas 2013 at Bitcoin, inside Bitcoins there was on a panel, I was on a panel with Dan Larimer and we were four… I was a nobody. I was just doing a small payment processor. They had all sorts of… He had crazy ideas they’re starting bit shares and all that. We would cross paths later on.


So, that brought me to Bitcoin. Then I ran that thing through an accelerator program, similar to Y Combinator called Founder Fuel here in Montreal. And then I shut down the business because there was no Bitcoin payments, and we were going to take what fraction of a cent on things that would pass through. There was no market for that. It was too simple of a business model, of a business idea, to be a payment processor. Some people would do that further down at much larger scale anyway. So fault of that, but I always kept an eye on crypto space and then I joined another startup, and eventually joined Password Box, where I met Mark Antoine , who’s my CEO today, and over there he was just acquired by Intel. I had helped him just before acquisition, then joined back after acquisition.


And so we would run over there the data science department for software that would ship on 200 million machines per year, and we would be doing behavioral analysis. So how do people use their product? Do they click this? Do they click that? What’s the sort of pattern that emerged so we can know what people want, don’t want and tailor fit the experience so that people are better satisfied. So, behavioral analysis. So for that we built crazy data systems, and huge pipes of data, huge piles of data, and I guess that’s where I ramped up my data science scales or large scale data machinery. That’s where I got my hands first in Kubernetes. That’s where I ran the first clusters by hand. I guess you have other questions. I’ve drifted a little bit here.

Nick (00:19:25):

No, I appreciate it. So for listeners that are interested in meeting Mark Antoine Ross, I interviewed him in a prior episode so you can look that up and listen to that, but you are partners with Mark Antoine. And so out of those days at Intel and Password Box, launched new enterprises which eventually led to StreamingFast. So what’s the jump from your time at Intel to StreamingFast?

Alex Bourget (00:19:48):

So our time at Intel was ended when there was that Intel selling out McAfee and McAfee Spining out, and then eventually they closed the Montreal office. So all the [inaudible 00:19:58] was there, the software was sort of absorbed inside the new McAfee, and then we were left with interesting packages and a lot of free time to figure out what’s the next step. So we were actually really stoked we were able to do that. So with Mark, we went back to a sort of venture builder called Diagram, and over there we were incubating small startups. And we said like okay, we need to do… So especially in InsureTech and FinTech, we said we need to get back into Blockchain, definitely something there. So we laid out a plan and started, but at first was EOS Canada, sort of our… [inaudible 00:20:38] leapfrog jumpstart, our thing with the launch of a new network and we would build data products in the Blockchain space.


And so eventually that was rebranded to Dfuse. To clarify this is a data product. We weren’t doing the, not staking, but doing block production at some point we really wanted to focus on building technology. That’s what we’re good at. And in Blockchain there’s a lot of data, there’s a bunch of data that needs to be… in French it’s [foreign language 00:21:04] extract value of, make valuable, valorized. So our goal was to bring it about, bring the value out and making a good use of it, making good utility out of it. So that was Dfused and that’s what eventually led us to StreamingFast. And I guess there’s some interesting stories about what we’ve learned as Dfused, being a centralized company and then what led us into StreamingFast and then The Graph.

Nick (00:21:31):

Well I know that the story of StreamingFast, partnering with The Graph and becoming a core developer is a story we want to touch on today and for listeners that want to hear another telling of that story, of course you can listen to Mark Antoine Ross’s episode. But with our time together today, Alex, I would like to just ask, one thing that came out of that interview with Mark was this realization I believe that you and he had about business models and plugging in your capabilities with an entity like The Graph. Do you mind just kind of restating that and shedding some light on what you were thinking at that time?

Alex Bourget (00:22:03):

Yeah, yeah. So I was just saying there was learnings from a business at Dfuse, and maybe I could just a quick summary. We posited that it would be great to index whole networks data in a database and we crafted several technologies of indexing from scratch. We wrote a backend that is similar to Elastic Search, a distributed search system. We would put all the Blockchain data in there, and we would sell it by the query people would where we would sell it by document given fee, we would have a certain number of documents, we would hold the whole thing. At some point it was like, I don’t know, say a 100K per month to have that in memory in RAM on SSDs ready to be queried. And people were interested in tiny fraction of that tiny bits like almost nothing in the grand scheme of things because you have Blockchain data, there’s a lot of things, there’s a lot of sometimes pollution you would call that you need to keep it in RAM if someone wants to query it.


So that business model was not working. We wouldn’t find enough growth of people wanting to query that data to keep it in RAM. So we just shut it down and at some point we discovered, we figured out that the core, the most juicy bit, the most important technology that we had built was the Firehose, was the thing to extract the model to extract data from Blockchains, keep it in a way that was easily manipulated because it was flat files easily paralyzed because coming from data science world, we’d never wanted to have to wait for days, not even one day to process something. We want it to be designed so that we could process it fast. And having that in flat files was one way to go so we can always paralyze. And also having the Firehose being the most performant, reliable and I’ll give some details.


So the most performant because you would get data faster than any other system like querying JSONRPC nodes, querying and Blockchain nodes, traditionally you would have latency that we would not have because of the streaming nature of the Firehose. And then we wanted to have the best guarantees so that when you are connecting to the Firehose, you have better guarantees of, well I have a t-shirt, you guys don’t see that but I have, it says never miss a beat, right? Dfuse, that was our motto. The guarantee that you’re not going to miss a beat because the way you connect, because of the way we had cursors, you could be guaranteed you would have a continuous stream that would not break off and then we would not have missed any bitten of information in between, which doesn’t exist. Any Blockchain nodes you query today in web sockets whatever will not give you that guarantee in a simple way.


You always need to do all sorts of crazy pulling and other client side queries to make sure you are sure where you’re at in the reorganization status and whatnot. So we had solved that. That was the crux. All of our service sort of derived their reliability out of that fundamental Firehose guarantees. So, at some point we said, now that brings us to StreamingFast. We were doing that on ESIO, high throughput chain, a lot of data, and we came to Ethereum, it was maybe 5% of the data. So we had built systems for high throughput and then we were on Ethereum like okay, not a lot of data there, let’s bring our tech and then it’s also go and try to stretch it by going to Solana. So we went and dug into Solana to sort of stretch the technology and make it even more powerful, which we’re doing, we’re still doing today because we had let on aside for some reasons.


So that’s some tech, we’re happy to squeeze it the Firehose, make sure that it gets, it’s the most powerful thing on earth. But so if I’m going, so we had trademark issues with Dfuse, big companies owned Dfuse with a Z, we didn’t have check that, whatever, we need to change the name. And at the same time we’re sort of mutating going to Ethereum being a little bit more Ethereum native. So having a brand new brand was also useful there. StreamingFast therefore was sort of a Ethereum. And then we were with that technology and we said okay, how we’re going to sell that? And we were looking around that and maybe crosses with the story of [inaudible 00:26:11] and we thought we need to decentralize that. We had started our venture with a closed source product, we would sell it. Then at some point we decided okay, that’s not the growth we need and it doesn’t fit the ethos.


Let’s open source, we open sourced our tech. That brought us also some growth but not enough to satisfy the business model at some point then… And we us also needed to have something even more part of the ethos there was to have a decentralized solution. So that was our… The last things we were thinking of when all The Graph story came about, we had great tech, you guys will remember the pancake swap thing, which we boosted performance 800 times. So we wanted to sort of prove our technology, but at the same time we’re thinking we had a light paper going around, we need to decentralize that layer. And we were discussing with The Graph, because to me that layer is sort of something that today is realizing that vision is underpinning The Graph. The Firehose today is what is sort of being infused underneath The Graph to power the indexing and brought the multi-chain aspect.


The Firehose was multi-chain because there’s just a few principles in the Firehose. Take a Blockchain node, spew the data out, put it in files, and then streaming block by block with a very linear, just a few notions of reorganizations with contiguous block numbers. That’s the primitives that are needed for the Firehose. So it’s extremely useful for indexing anything or as a matter of fact for building bridges between chains, because a bridge listens on the other chain, you listen to the two different chains and you write on the opposed chains. And then also for trading purposes, traders would love to connect to the Firehose, because they have the fastest, lowest latency information was going on in the chain for some reason. I can explain if you’re interested. So they have that and they have the most complete dataset because there’s much more detail in the Firehose than when you can get from standard nodes.


And obviously the other thing was indexing. So we say let’s decentralize that we were discussing with The Graph, no, network effect. We rebuild that, we benefit from network effect and at some point that joint force. And I think today we’re seeing, it’s a fascinating time because we’ve put our head into indexing technology, Blockchain, very low level things and we’ve fell in that land of people who understand our challenges. Like The Graph people, they understand, they get it, they see it. So it’s really rejoicing I would say to have landed in such a place that appreciates the work we have done, and also laid sort of a nice ground for more growth, more adoption because The Graph had much more adoption than we had. So, it’s a nice place to be I would say.

Nick (00:29:02):

So I want to ask two follow up questions and try to make Firehose, which you’ve so eloquently described, a little more tangible for non-technical listeners. So, the first follow up is, as I understand it, Firehose is a piece of code software of some kind that reorganizes data from the Blockchain and makes it more easily indexed or transferable? How would you tie a bow on that?

Alex Bourget (00:29:28):

Well you said it right. I mean it’s more easily indexed and it’s more easily transferred. It’s more easily verified. So at the risk of being a little technical, when you have a Blockchain node, it’s a running program on a computer somewhere and it has a database underneath. And what people do today is they connect through the network and they query that running program so that this running program reads in its database and outputs some data. Our model was to say this is slow, this requires a lot of memory, a lot of CPU, a lot of SSDs that are fast ,resources, computing resources that are costly. So we said let’s be done with that because people are interested in the data. Let’s separate the data from the computing needs. And so we extracted, we run the Blockchain node, but the first thing we do is we output the data and put it in a file.


So that’s much easier to transform. Reading a file is much easier than querying a network system because it can fail, the [inaudible 00:30:29] see it’s much less costlier also. Loading a file… but files have been optimized like crazy. Think S3, think the Google bucket stuff storage there, Azure, these guys have made the cost of these things so low, a hard drive, the cost shrinks each month putting that on a file flat. And there’s also different grades of others’, fast disc. But maybe if you don’t use the data a lot, put it on a slow disk, something that is even cheaper, that’s been optimized like crazy. And let’s tell you the truth that that’s used in the data science world more and more. That’s actually fascinating because you have these big engines… They do a Google what people do to feed data in those big data systems like a BigQuery or something like that.


They actually write files in the storage. And that’s the source where a big query is going to load and process the data files. So, that was the premise. And the Firehose is a little bit of two things because it takes the node and in real time it spews out the data. So there’s an aspect of it which is a stream of live data and the Firehose sort of bridges the real time stream and the fallback on the files so that you don’t see anything, like you’re going to go really, really fast reading the whole history because it’s reading from flat files and at some point, it flips and goes in real time mode. All of a sudden you’re on the edge. And what I was going to say earlier is you’re on the edge and you’re on the fastest edge there is because of the nature of the push streaming, right?


Let’s imagine you have three Blockchain nodes and they are in sync in different places of the world. Maybe the first guy in Taiwan sees the block and outputs and then pushes it to the client. Well, you’ll have the first of the three, one in Taiwan, one in Frankfurt, and one in Montreal. The first one to see is going to push it to you. So you’re going to have the fastest right there. Everyone is racing to push you data as fast as possible. So that by design made it like an awesome streaming solution the fastest there could be by design. So yeah, I find it fascinating. I love it because I see nowhere where something could arrive and outcompete the Firehose. Fastest, most paralleling the most complete data wise. So there’s no room for beating it in a way. So that’s why I’m happy that it lands in The Graph that we can reach the whole world and make it the defacto solution for reading any Blockchain data. I think it’s a pattern that will apply to all Blockchain.

Nick (00:33:08):

Before I ask my second follow-up question, I think we should define a term which is parallelism or parallelizable, a word you keep using. Can you just conceptually, yeah, help me understand what’s meant by that.

Alex Bourget (00:33:19):

Okay, so the story for that is block cipher. We were starting 2017… I don’t remember the date. And there was that story of block cipher, cipher block, I don’t remember which one. A company. And they were down for three weeks because they said, oh our Ethereum node crashed and we will be reprocessing it and it’s going to be ready in three weeks linearly. Why? Because the node was built so that you load, you open it, and then it’s going to slowly execute all the transaction, write the data to your database and you did that linearly. Look, parallelism is sort of the counterweight to linearity in parallelism. You can take the history, let’s say at that time maybe there were 5 million blocks, you can chunk it in 10,000 blocks, but you run them in parallel. Yes, you put, I don’t know, 500 machines, they all do a small bit of work, but at least you’re not going to wait for three weeks.


Three weeks is crazy. Your business is dead in the water if you’re offline for three weeks. And that was their case. So, I never wanted to be in that situation. The solution to that is to make things that they can be chunked, done in parallel. So when I’m processing blocks 0 to a 10,000, I can process separately 10,000 to 20,000 and the output of all of these things can just be sort of dumped in the same directory. So, after you have all these segments, let’s call them, and one of them is going to be longer than the others, we’ll call that one the worst case, I don’t know, block 5 million to 5,010,000, took 45 minutes. That’s their worst case. But after 45 minutes, that was our target an hour. Process the whole network. And we did it with Ethereum, would take not more than two hours.


And our goal was to get it done in an hour, an hour or half an hour, and we would have done sort of similar to what they would have in three weeks because of paralyzation. And with Blockchain data it’s ever growing, never going to shrink. Some things were written at the beginning of the chain that are still true and you need to have, so you need to have it all. So if you need to extract it and be able to go through the full history, well one thing we know is that we’re going to be able to add a few more computers each year to the parallel system. What we don’t know is if we’re going to be able to sustain a linear process that’s going to grow linearly and okay, it’s three months today, but tomorrow is four months… And then the day in two years it is going to take six months.


What does that mean? It’s impossible. We cannot do that. So that’s why I think extracting data, making it parallelly digestible and processed like it’s done in the data science world is a tremendous utility. We need that. The world needs that. Blockchain will not thrive or survive if we don’t have access to its valuable data in a consumable way. I think as I would say, the best solution I’ve seen by far.


So the second follow up question I want to ask then is about making StreamingFast technology with the Firehose tangible for listeners, how does it impact the stakeholders in The Graph ecosystem? So where do you see it in the wild and how do you see the benefits yielded?

Alex Bourget (00:37:56):

So this is a multifaceted question because it’s so fundamental. I think it could have impacted in many, many ways. So I can start maybe enumerating a few of them. First we have an Ethereum ingester now in The Graph node for people who are indexing Ethereum main net today or ETHM chains. Well because of the push nature, this has good chances to increase the speed of indexing, especially for those large subgraphs that consumer have a lot of things happening in each blocks, because the data doesn’t need to be queried out, it’s pushed in the face, let’s say of The Graph node. There’s just latency optimizations there. Then there’s also the richness of the data that makes it the subgraph, not need query call handlers, which is another technical thing that it exists in subgraphs because the data again is pushed. So we’re saving thousands of queries.


So that means just improved performance. Another thing is there’s new triggers we could be designing like triggering when some variables changed in an Ethereum contract, which we can’t do right now, but we’ll be able because the Firehose contains that data to have new triggers and it opens really a boatload of new opportunities for indexing and strategies for indexing. So I could get more detail on that, but let’s let it on the side for now then. The fact that it enables parallelism. So I could see, we could see we have a prototype, that story of the pancake swap 800 times faster, that was all done in parallel. We tried to prove in a way that we could apply the same semantics of subgraphs, but they could be done in parallel. We did it. I think the learning here is that it’s hard. So we need to think about how we’re going to make that usable by end users, but in at least prove that, that could become some product of The Graph Network that enables tremendous performance improvement a thousand times faster for certain use case.


And that scales paralelised leads to horizontally with a number of machines you’re just going to add. There’s also other things we’re seeing ,because the Firehose itself is valuable, useful for different purposes… I’ve been earlier traders bridges indexing, so we’re seeing right now we have one indexing pattern in The Graph. You could totally imagine new indexing patterns based on the Firehose data that belongs to The Graph. And also, new economic like business models. Like The Graph is a business model in a way, a new way. Why not buy such Firehose data? Why not have an economy to share these files and have ways to cross verify them, verify their… And have economic security. So I’m imagining all these things become possible. Which rate when we do that, if we don’t want to do, that’s a different thing. But I think the possibilities could becoming since more and more because it’s such a foundation that allows so much things to be thought of in a new way or to be built. So does that cover a little bit of the angle?

Nick (00:40:56):

It does. Thank you so much for taking me and the listeners through that. It’s very helpful. And I think another thing to hit on here is that outside of its role as a core dev team working at The Graph, StreamingFast is still its own entity with its own initiatives and objectives. What are some of the other things that you could share with listeners that StreamingFast is working on outside of its core dev partnership with The Graph?

Alex Bourget (00:41:20):

Right, we focus a lot on The Graph but each time we hit up a new chain, which we’ve done more recently with Solana, we love to experience the developer experience. We want to know it all right? Because we get into the weeds, into the depths, we read the source code of those Blockchain protocols, we want to know it all. And one thing is to try it, right? So just recently we shipped a thing called scarcity. I wasn’t involved the rest of the team fool around to learn more of how we write smart contracts in Solana, and sort of build the developer experience interactions with wallets and all that. So we can have good knowledge when we come and we’ve always done that and we’re could… We’re going to continue to do that cause we often have hackathons. A large part of our culture is hacking around and playing right, fooling around to learn because that’s how we’ve figured out the best things and I guess it’s a little of influence from my side.


I like to have people play because that’s how they discover and create, for me that’s important. So we’ve always done that. All the Blockchain protocols we hit and so we also wrote a thing called Shine, was very important in our company to sort of give a pat on the back, have sort of a reward system. I don’t know if you’ve heard about Shopify’s unicorn system, that was Shopify sometime and they had a thing, it’s sort of a social web app, an internal social web app and then people can say, oh you did a great job with that mobile app refactor, whatever. And then everyone would go and plus one, plus one, plus one, they add unicorns and at the end of the month there’s actually part of the profits from the company that is spread according to those weights and reward people for their good job.


So we wanted to do that but on-chain, so we wrote for Ethereum, EOS, Solana, we wrote those things and sometimes they live a little bit, sometimes they don’t. So that’s some other projects. They’re not directly related to our work on The Graph. But at the same time, it’s always for dog fooding, right? It’s for dog fooding because we want to make sure we use our tech. If we’re not using our tech, we know it’s going to be inferior. And I think we’ve improved because we were doing all these sort of side projects. Who knows what the future reserves, maybe we’ll have other projects, we’re hiring also, so allows us to have a little bit more flexibility. I guess that’s covers it.

Nick (00:43:38):

For listeners who want to learn more about the positions available at StreamingFast and some of these other things that you’re venturing off on, what’s the best way to learn more?

Alex Bourget (00:43:45):

Join us on our Discord. We’ve sort of opened a Discord, the new brand got out. You could go to which is a website with not much content because we’re really in the trenches, but there’s a link there to our Discord and we can chat there. You can check also the careers page or directly on the website you can, we’re hiring.

Nick (00:44:09):

Well I definitely want to encourage listeners to visit StreamingFast and learn more about the open positions ,and some of the great projects you’re working on. I want to also take this opportunity to congratulate you and the team for the contributions you’ve made in this role as core devs working at The Graph. Obviously in Lisbon, a lot of great announcements for The Graph ecosystem and StreamingFast was center stage on some of this in relationship to near and Solana. I was wondering if you could take listeners through that announcement and kind of what it meant to you and the team.

Alex Bourget (00:44:37):

So the first thing it was announced was the near integration. That was sort of our first dent into integrating directly into The Graph node for the benefit of the community, and it relied on the Firehose implementation that we had just freshly done taking a new Blockchain… And there again we stretched our capabilities because Near has some wonky things about being able to skip block numbers and so we adapted the stacks so now it’s even more flexible. And so we were able to ship a Firehose… Because of that distinction between processes and data, because the Firehose brings that abstraction, it says here’s the data no matter where you get it, whatever here’s is a well defined schema of data, and then hitting The Graph node, mapping it through what people are used to in the subgraphs and the manifests and all that, becomes much, much easier.


So we’re really happy to be able to ship near fast like that with a brand new Firehose implementation that we didn’t have just some weeks before, and I was really impressed by our team because we weren’t rust experts. The guy just dug in and yeah, I want to tell that story because it’s really testimony to their grit and their drive. We weren’t rust experts, but some of the early things, we figured out there were some, now I’m assigned, it is a little low level here, but dependency issues, some things that we need to upgrade but that would upgrade some libraries in The Graph node that are really low level. That’s the sort of thing that you want the experts to do because it’s very sensitive, it has large impact and a lot of things and there’s potential for regressions and could break things.


The guys, they nailed it. They went and sort of upgraded some of the fundamental pieces that even the guys at Edge & Node didn’t have the time to wrap up. They were occupied with many other things. So they were really happy they be able to contribute at that level in such an important place. And then we were able… because we had learned more about the code barriers, to integrate the near integration there in a very elegant way. So that’s great. I mean that’s one of a great integration I’m really proud of. Now the next thing is, so we’re working on Solana, Solana’s a different beast. It’s a large scale thing, and we also want and need to make sure that we have the Firehose. That’s some of the two priorities I’d say here. Make sure the Firehose works for Ethereum and Ethereum and EVM chain, because right now it’s implemented, it’s all there not yet tested and we want to make sure we have that, also to sustain larger throughput chains like Polygon.


BSC notably has a lot of throughput these days and we want to make sure we get these performance also for Ethereum centric things and also for Ethereum main net, because there’s some things on Ethereum minute that require the sort of performance boost that we could bring there. And Solana there’s some challenges from the Solana node side, and then we’ll figure out the integration with The Graph and what it means in terms of performance there. But we’re solving the Solana side right now doing the Firehose.


That extraction I’m talking about right earlier on that needs to live in the Blockchain node. But someday I hope that we will have a clearly defined Firehose-esque, perhaps an internet draft, an RFC to say if you guys implement the Firehose, that method of extraction on your Blockchain, all of a sudden you are The Graph ready. Can all of a sudden be integrated in a fell swoop. Yeah, so we’re slowly doing protocol by protocol. There’s the Figment team also been working on the integration, have good knowledge about that. So they’re learning about the Firehose by doing that integration, bringing that knowledge and eventually [inaudible 00:48:31] all sorts of chains. But the pattern works. And one thing I’m impressed and… How welcoming this multi-chain approach has been received, how well it’s been received.

Nick (00:49:17):

You mentioned Figment, obviously Edge & Node is another core team. I would love to get your perspective on this ecosystem, build, this bringing together of core devs working jointly, as you mentioned Figment using Firehose, something that StreamingFast contributed. What can you share with listeners about melding all these core dev relationships together to build out the ecosystem?

Alex Bourget (00:49:40):

So that’s a fascinating question because we’ve led through something quite unique. This has never been seen before. The fact that we were adjoined by a crypto network of some sort. We were aligned in terms of incentive, but we’re still sort of an autonomous company and we decide on our goals but we make sure we want to and we do align them with the goals of The Graph Network in general. So it’s very special and I see the other teams doing that also. So there’s I think something very interesting happening. There’s a lot of honest talk, right? We’re discussing ideas and, it’s not a direct boss relationship, although we’re trying to build something great together. But we were able to express, for example, the parallelism and the technology we had built, we were able to discuss it and talk about it and it’s sort of a proposition that arises with strength in a way.


And so we can have those discussions we were having those discussions makes it all very interesting, nice, fascinating way to collaborate because we’re aligned, right? We want to do something great for the whole network, yet we can have divergent opinions and that’s going to be valued sort of structurally what you would want in a company. You would want your company to have people who are going to put their ideas out there, not be shy, not be afraid of bruising someone’s opinion or whatever so that the information comes out and then we can build. So we have that. That’s fascinating I think, I don’t know if that covers the whole thing, but that’s definitely one element. And now we have Figment who joined added another thing of uncertainty, we weren’t sure, but now they’re going to be tackling some of the challenges that we don’t need to do and they’re going to tackle that through the Firehose aspect. So that’s fascinating to see how it built up in a social way, in a collaborative way.

Nick (00:51:34):

Alex, I really appreciate the description you’re sharing here of StreamingFast of Firehose and of how all the core devs are working together. Really, appreciate this and I’m catching the vision of everything you’re describing here. I want to take a minute and pick your brain on some key themes that are in the crypto Blockchain web3 space and just get your opinion on some of these things, and I think I want to start this part of the interview by going back in time to 2013 when you read the Bitcoin white paper. And you said the draw for you was that money could be programmed. Now in terms of utilities, I understand why you would enjoy that, right? You’re a smart guy, you’re in the field, you can program it, you can participate. But for people like me that are non-technical, what might be some of the benefits of a world where Bitcoin and programmable money exists?

Alex Bourget (00:52:28):

Well, maybe the easiest way to answer that is to get back to my pitch in 2013, because what I did there I still believe needs to happen and a simple example, a simple use case that we were trying to do there… You were on a website, I don’t know how about you guys, but we live in French Canada, and oftentimes finding movies in French available for streaming, it is not like some shady weird place that will actually accept cash so that you can listen to the movie. Sometimes it’s hard. I think in the US there’s a lot of streaming services, they have most of the movies, but it’s not always the case. I dreamt of a place where you could go and they would take your cash, so you don’t need to go to Torrance to find the thing you need and so on.


In that experience, you would go to the site and you would have a QR code, you would take out your phone. That’s the first pitch I made. That’s why how we entered the accelerator program. You would send out money to the website and you would have five bucks on the website. The movie would just turn around, start, it would consume one of these five bucks, and then it was frictionless. You didn’t need to log in, you didn’t need to do anything. And we would do that also for newspaper articles. And to me it was like we needed that. We needed to have something that rewards journalism directly instead of through ads. I would’ve dreamt that you go on a website and you put 25 stents and you could read a 10th of a penny per article. That’s already 10 times more they’re making on articles per view.


But you just say, I wouldn’t care. I’d put 25 cents. I can read articles 250 in a month, that would’ve covered, they would make more money. I would’ve loved to have no friction. I still want to see that now with crazy gas fees, you can’t do that. You need something high throughput. You need something that has very low fees, but I want to see that experience rise so that we can realign. For example, in journalism, that was something that was very dear to me, that people were not skewed in their approach because they would be rewarded for perhaps building the truth, for the value of their work directly instead of just because they need to sell an advertisement on top of their thing and they’re geared toward mediocrity again, right? Something not too long or too fast just to sell an ad and then continue on with the next one because you need more and then it is just… So yeah, that led me in the crypto space.


I was very adamant of that. I think social networks will need to be sort of disrupted in that way so that we have, again, I know you guys have seen social dilemma, it really struck me, the movie, the social dilemma, struck me as… things if they are geared towards profit for advertising, it yields them crazy things that we don’t want for this world. If we could pay, I would pay three bucks per month in order to have access to social media that I could gear towards what I want.


I would gear towards an algorithm, perhaps a pool of algorithms that there’s talk about these things, that this… bring your own algorithm. Once we have data in the Blockchain world and you can keep your data up to yourself and everything you’ve collected from you, your friends, that you give it to an algorithm provider and they’ll order things for you. They’ll give you something. There’s competition. There’s not locked into one provider. I see that. I see that. I want that. I think we need that to get rid of the possibility that information and knowledge being hogged by financial interes, totally needed. Is that… I’m not sure that answers the question, but whatever.

Nick (00:55:58):

No, it answers the question very well. I appreciate that you would take the time. I want to ask you another kind of general question then a general theme, which is this move you made from web2 to web3. So that’s not moving from one bank to another bank in terms of profession. What was that move like? Or have I mischaracterized it?

Alex Bourget (00:56:17):

Well, we were starting… And our goal was to build data system. My interest, I’m not an economist, I don’t know nothing about token economics really. You’re talking to a noob here, but I love the technology. I love data systems. I love real time, I love processing, I like programming systems on architecture. That’s my interest first and foremost I’d say. So to me was going to web3 because I saw a great opportunity of valuable data that needed to be played with, tackled, and I see there’s a lot of excitement around. So, I went there and I’m discovering day after day the uses. At the beginning we started that company, it was like that’s five years ago, four years ago. There were still around questions about, oh, but what are the use cases for Blockchain? We’re still near the launch of Ethereum, so having a computer that works there on the rule there and we can send freely transactions and they would exchange things, we were very early.


But now, today I see them more clear. I see those use cases more clear. So I’m excited by some of these prospects. There’s one company here in Montreal called, and they were going to disrupt Uber. I found that fascinating. I find it so appropriate that people would get together and put on a Blockchain and advertisement for saying, I’m available, I’m in that vicinity and this is my price. Then they hook me up and then on-chain you can say, okay, I’m nearby come and get me and then you have all these proofs. To me it just makes sense to have an economy where people just work together to shave off and then you have a foundation getting some money to develop those tools and it just makes a lot of sense so that the economy stays local, not extract…


A lot of money goes in another country and they have these, they’re called co-op, they have a co-op here, a co-op there with people working together. If we can make that efficient, there’s a real gain for local communities. There’s a real potential to build economies and have them in a way that works for their locale, for their community, for their preference and values if they want to support this and that with the… I don’t know, I think I drifted a little but.

Nick (00:58:28):

I don’t think you veered off there and I appreciate the insight there. So one way that I’ve approached thinking about The Graph in web3 and particularly the web3 stack, is this necessity of having something in that stack that can query and index data from the Blockchain. In my mind it seems like it’s necessary component. So if that’s true, can you then provide an idea or an insight as to why The Graph is uniquely suited to fill that role?

Alex Bourget (00:58:59):

So I’m going to give you an answer there that hopefully doesn’t brush people the wrong way, but I think we need The Graph, definitely, and we need more than The Graph and I can see that. I can see where the things are going to go. I can imagine… And that idea, I would say, I told you earlier that I was on that panel with Dan Lara, and we’re discussing the idea of a large scale gateway. His goal recently is to create a thing… This is sort of social media. A lot of people are working on decentralized socials, so you can chat with your friends without being risk of being [inaudible 00:59:36] He’s working on things like that. But there’s one thing that’s required for that to work, anti-fragile infrastructure. So it’s slightly different, more than decentralized because decentralized, it just means so many things, so many places.


But the core thing that is needed, I see there is anti-fragility, meaning that you can use a provider, you can switch provider, you can go to many people because the whole stack is available for anyone to run. Not everyone is going to run it, but you have the choice of people who are going to run it. I see The Graph as definitely a component, but let’s say there’s a social application, he’s building a social application there, there’s many things that are need needed. Yes, there’s an indexing endpoint because you want to present in there in the UI there the last messages or your list of friends which are on-chain, the query, the subgraph to get the list of friends. And then there’s some rankings of some sort. That’s all good. But then the next thing is you change your profile picture.


You’re reading from an in and out of IPFFs or some other decentralized storage solution, you also need to have access to that and you’ll want to pay for that service because you want to be anti-fragile. You want to be autonomous as a user, right? Because in that world, users pay for that service because otherwise they’re the product. So we need… There’s that ship that needs to happen at some point it happens and we are, sort of freed in some way, but you need an anti-fragile… architecture. And that also means that you need a service to do the cropping of the image. You need a service to do either the raspirization of whatever that the system needs. And it’s not just a subgraph query, although subgraph query is absolutely necessary. How do you get the data from the Blockchain… That central piece of information where value is attached but also authority is attached.


Also, reputation is attached. Anything like in the example earlier about the decentralized Uber, like the number of stars, how many stars you gave, you need to have made the ride to have the right to write the rating to influence the reputation, all that so that precious information lives on the chain query through query The Graph. Because it is my deep belief that it does not make sense to query nodes for Blockchain data. It’s my deep belief that that’s one of the premises a Firehose do, and does not make sense to query a Blockchain node in the long term game to query Blockchain data. The Blockchain node… That gets a little technical, but being a master to replication database, replicated database, means it’s always occupied a hundred percent of its time at writing. It needs to process transaction. Don’t give another task. Let that task be to the subsystem.


Pick the data out as soon as possible and let the subgraph do the query. Let the Firehose do the… And feed whatever systems you need, not the Blockchain node. That doesn’t make sense I think in the long term. So I’m saying that because definitely we’re querying The Graph for any Blockchain data. That’s my firm belief, that you’re querying an Indexer that has prepared the data in a fashion that makes sense to your app. That’s a given. And it needs to be anti-fragile because it needs to be… So what I imagine is that these apps will have a single URL. You will provide them with your perhaps single URL provider, anti-fragile provider, and there you will have a sort of a description. Your app can describe all the backend services it needs this and that subgraph. It needs IPFS read fashion, it needs to have prepaid IPFS, right?


Something like that. It needs to have access to that other decentralized storage. If you’re going to pay that provider, the provider of that URL for all of these backend services, but you know can have many service providers provide you with that URL, and you’ll be able to give it to your app one single URL, with a token in there authenticated. You’ve paid them in some way right? With GRT and you can have a boatload of providers from which you can take the URL and use that application and you have sort of that negotiation with them that they will provide the right services, the right versions of the software and all that. And then you’re anti-fragile. Now we’ve reached web3 where you’re autonomous, your potentially master of your data… And I imagine they’re like, so some people must say you’re not fullly decentralized.


I imagine that if you want, if it’s eficient and cost effective for you, you could say that this backend, it says it’s an IPFS, but I don’t personally care to drop it in Dropbox. So I’m going to pay it Dropbox. Maybe it’s less pricey, more pricey, but provided that the backend service offers the right API, this is my Dropbox, I’m going to store it there. Or it’s my personal hard drive living here, but that can be abstracted away. I think the important aspects that we get, to what I call there, hopefully we can build that in The Graph like the web3 gateway. That’s what I imagine to reach anti-fragility and to get to that point where we can be freer and control our data better.


But most importantly, I’m not an [inaudible 01:04:45] . It’s not my goal to be free from the large corporation, but to be able to have the means to talk to people without being the deplatformed or having the fear that your idea is not present and have forces around that will make you shut up, I think these past years that’s necessary for the truth to be heard, the truth, to have a place to go and not be crushed by just… And just me talking to my mom. Even these things if I’m deep platform I can’t do anymore.

Nick (01:05:19):

I think it’s an incredible answer and I appreciate you taking the time to go through all that. So this idea of a web3 stack has come up many times on the podcast. I’ve never asked the follow-up question of what is the minimum viable stack to accomplish web3, what must be there at minimum for web3 to be fully evolved?

Alex Bourget (01:05:41):

So that is definitely, it ties really well with that web3 gateway I’m talking about. Depends on the application. Some applications will need, let’s take a simple uni swap, querying a simple just with the current price and then writing a transaction and having that web3 gateway or whatever to the chain a transaction. And then you listening on maybe pulling, there’s a very simple… That app can exist with very minimal footprint. Now if you’re talking about social, and at some point you need bring your own algorithm to sort your post, that’s a different story. And at the same time, different apps will have… I imagine also in that realm necessity for services that are not so much Blockchain centric. Think about a stupid image resizer. Say your app needs an image resizer, but there’s no backend to do that for you. So all of a sudden you have, with this web3 gateways, you have a market for you running a stupid image resizer and that’s new.


Everyone can do it, but there’s no way to monetize. But all of a sudden you have a place where you’re going to have payments because there’s some costs, you’re going to have payments. And then you can start having a large part of the open source stack world program being served in a decentralized way, in an anti-fragile way, and with a business model. That’s crazy. And at that point, well sky’s the limit, right? Sky’s the limit in terms of what applications will need, and they’ll be more and more hungry. They’ll need more and more services and it might not matter that they use 75,000 services. One thing I like about that idea is that mean you have your app that can be degraded.


Let’s say you don’t have a bring your algorithm for sorting your post, well maybe the default thing is just linear, and then you graph through all your aunt posts that you don’t care about because… And at some point you find it useful to pay for the reordering algorithm, but the app can work without, to have optional. So the app becomes degradable according to what you are ready to pay and not ready to pay. I see that. And so that’s why there’s a large spectrum and the spectrum will sort of bloom and more and [inaudible 01:07:59] more things, which will at some point all become web3, right? Because they’ll all be anti-fragile, the app is going to be perhaps a bundle of program that you have on a USB key, or you download from the static storage and all the rest lives on anti-fragile infrastructure.

Nick (01:08:15):

In your opinion, is web3 just an experiment? We’re hoping to see how it turns out? Or is it in inevitability?

Alex Bourget (01:08:22):

Well, it already exists, right? Some apps already exist and they’re already anti-fragile in some ways. They can take the front end for uni swap, and then you’re talking directly to the Blockchain. Simple app is going to work. You are antifragile, that exists, has some values, things that are happening there. So I just see that growth. There’s no question whether it exists or not. We have proofs and sample applications. I think it’s just going to bloom and multiply and change shape and form and we’re going to vet business models, and we’re going to trash business models. I think in a decentralized way, it’s harder when you have a decentralized company it’s easier to iterate on your business model. I think i touched a little bit on that, iterate on the business model. So maybe I can give you a little bit of learning from our previous venture.


I think that’s interesting. I wanted to share that with you guys, beause I think it needs to be said somewhere. Remember earlier I told you that we had a business model where we cost per query, and then we would be paying so much and we had learned that it didn’t work. So we trashed the business model, we fired customers, and we found a new business model. And then the next business model we also trashed, until we came up with a business model that works. The Firehose, if we sell it by the byte, it works, because the cost structure makes sense. You store it on flat files, you stream it out. The cost of CPU, RAM, is less than the cost of storage and it’s pretty linear. If you stream a lot of bytes, then it’s stream linear with the cost [inaudible 01:10:05] . So it’s a business model that works.


Now, I see that in the decentralized world, people build business models. That’s what protocols are, right? Business models in smart contracts, where people interacting with the business model, let’s say you have different… You have the Indexer, you have the consume, there are different parties of that economy and they’re abiding by the rules of the business model that we codify in smart contracts. Well, that’s very difficult to change. It’s slow to change because you can’t just decide, okay, I think this business model doesn’t really work, so let’s trash it and fire customers. What happens in a decentralized ecosystem if you do that? It’s going to be scary. So I think we will need to accelerate the experiment, and we will see what happens when we figure out a business model doesn’t work. I don’t know how that’s going to look like.


Often in our history we’re looking at different chains, see where we’re going, what’s the next chain we developed? We’ve tried a bunch of things and analyzing them… And one of my question was always, okay, how are we going to see Blockchains implode? What’s the end of life of a Blockchain? How does it happen that things die in this space? Sometimes we’ve seen them being acquired, a chain being acquired, but how do they die? Sometimes the guy goes into prison, but even then the guy goes to prison, people still trade that Blockchain. So, I think features is going to be fascinating in terms of how things die, and how do they survive and thrive. How will we learn? What’s the fast… What’s the speed at which we get to learn what works and doesn’t work? Super excited to see that.

Nick (01:11:49):

Alex, thank you very much for taking time today to share so many great ideas, and updating listeners about the great work that the team at StreamingFast is contributing to The Graph ecosystem. If listeners want to stay in touch with you and learn more about your work, what’s the best way to do it?

Alex Bourget (01:12:04):

You can reach us, go to the website, and you’ll have a link to the Twitter account there and to the Discord, which is the best way to reach us. So StreamingFast, all stick together, no dash, no underscore whatever, I wanted to thank you. Thank you for putting out the podcast. I appreciate always loving these things, so hit me back anytime.


Please support this project
by becoming a subscriber!



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.