Walter Chen
Background
Auston Bunsen is co-founder of QuickNode. We talked to Auston to learn more about building a crypto infrastructure company, how multi-chain changes the market for blockchain developer platforms, and what it means to be developer-centric when it comes to blockchain developers.
Questions
- What’s the problem you're solving with QuickNode and who are your customers?
- Can you give us an “explain it like I’m five” explanation of how blockchain development platforms like QuickNode work?
- For those who know Web2 infrastructure, what’s the layer of infrastructure for blockchain development look like: is it IaaS like AWS, or PaaS like Vercel, or is it more developer middleware like Plaid or Twilio?
- From the developer perspective, what does their tooling look like when they're, for example, building a dapp?
- Can you talk a little bit about developer-centricity and fintech? What’s different or specific for blockchain developers that helps you win and be top of mind for them?
- You've talked about both Web3 and Web2 use cases. Are you focused on one or the other? Does one or the other seem more interesting in terms of growth? How do the use cases differ?
- Could you talk a little about the market? How do you position yourselves with respect to Alchemy and Infura? How do you see the market today for blockchain developer platforms?
- Can you talk a little bit about the multi-chain approach and how you’re positioned against Ethereum-focused Infura? Does that allow them to go deeper on Ethereum versus being more high-level across more chains? What are some of the trade-offs?
- Can you talk about where you've built abstractions internally that allow you to treat every chain the same? Does that provide massive leverage to developers for any particular use cases?
- The incentive on the developer side is that it allows them to expand their user base or their addressable market?
- On that, can you talk about when one would want to integrate with OpenSea’s API directly versus integrating with the QuickNode NFT API versus some other approach?
- Do you integrate with OpenSea's API to bring that in so that anyone who integrates with your NFT API will get that and not have to integrate with OpenSea? Or do folks integrate with both?
- Can you talk about how you design for a company that gets stronger during downturns and can capitalize on the bull runs and boom times?
- You mentioned that you don't necessarily have super-high concentration, but how do you think about concentration risk? How do you retain customers as they grow large on QuickNode given the kinds of build versus buy decisions other infrastructure products see?
- Do people ever tell you they want to bring this in-house?
- What do you think about this ideology out there that with services like QuickNode, Alchemy, and Infura, Web3 is going to be as centralized as Web2 in five years? How do you think about the future that you're building with QuickNode as it becomes successful?
- What’s the long-term of what you're building? What sort of increasing returns to scale does your business have?
- Can you share a vision-oriented statement with us? If everything that you're executing on just hits, what does QuickNode become in five years?
- Does that basically come down to blurring or removing the distinction between writing Web2 software and Web3 software?
Interview
What’s the problem you're solving with QuickNode and who are your customers?
What we're solving at QuickNode is abstracting blockchain node management away from customers.
Our customer is basically anyone that needs to read or write information to the blockchain and that’s anyone building a Web3 enabled product, whether it’s deeply-integrated or lightly-enabled.
You can see some of our customers on our website and see some big names—Adobe, Coinbase, etc.—and all of them actually have slightly different use cases, but the most common one is that they need to read block data or transaction data from the blockchain and they also need to write information to it.
There are two reasons why customers typically choose QuickNode.
One, our latency is elite. We are the fastest. We're in 14 different data centers worldwide, so we have a global presence that brings latency to sub-100 milliseconds.
Two, we're also a leader in multi-chain. I don't think there's anyone in the space that is self-serve that provides access to the same number of chains that we do.
Can you give us an “explain it like I’m five” explanation of how blockchain development platforms like QuickNode work?
It's hard to do anything with blockchain and explain it to a five-year old. So, we're just going to assume you know what a blockchain is and then try to get an ELI5 from there.
You need to run your own node if you want to read or write information from the blockchain, or you can pay someone else to run your own node. It's very similar to how email works. I don't know any five-year-olds that use email, but if they did, they’d understand that they could run their own SMTP server. But you shouldn't do that for a few reasons.
One of them is, it's annoying. You have to deal with server upgrades, protocol upgrades, etc. and the same thing applies to blockchains. The London Hard Fork, the Berlin Hard Fork, the merge, etc. are things that you would need a team of experienced DevOps people to manage. If you don't want to do that, you should use a company like QuickNode.
As to what the tech stack looks like, you need to have some particular software that is continuously synchronizing the blockchain as well as some software that provides the data from the blockchain in an RPC format—the format for blockchain communication. For most of them—Bitcoin, Ethereum, and all EVM-based chains, and even Solana—it’s JSON-RPC. It's just a specific kind of API. These clients are written in any number of languages, including Go, JavaScript, Python, etc.
Specific to us, we have a whole proprietary setup that's doing caching, indexing, etc., just the sort of the things that you would expect. Geolocation too, because we're in 14 different data centers.
On the frontend or the customer-facing side, it's relatively boring—HTML, JavaScript, CSS, etc.
For those who know Web2 infrastructure, what’s the layer of infrastructure for blockchain development look like: is it IaaS like AWS, or PaaS like Vercel, or is it more developer middleware like Plaid or Twilio?
Let's just for a second back up and talk about Ethereum.
Ethereum is a general compute that is distributed and it marries your state with your business logic. That means your database and your application code are together. It's kind of like if you took all three of those examples (IaaS, PaaS and Middleware) and you just smushed them together.
At the base layer, you need some set of infrastructure that's running this stuff, that's the RPC level where it's just whatever comes out of the box with the open source software clients. But the way that you access it isn't some VPS that you get to manage. The way that you access it is like a Twilio or a Plaid.
You need to call its API, but then, there are additional layers to it. The past sort of analogy comes into play where you have these indexes. So we have an ERC-20 index of every single token that exists on Ethereum, what the balance is, when, and all the transfers that happen.
It’s the same for the NFTs. We have the most up-to-date owners. That's sort of abstracting away the complexities of raw infra and giving you more Web2-ish kind of calls. Then again, you're consuming everything through an API. It's hard to fit it into any single one of them.
From the developer perspective, what does their tooling look like when they're, for example, building a dapp?
It varies widely. I did customer support for us for quite some time, and it was everything from just a frontend library like Ethers to their own homegrown rolled HTTP wrapper that they make their own stuff with. There's starting to be quite a few of these sort of abstracted wrappers around what was previously just interacting with the blockchain. So you would see Ethers. You could see thirdweb now as one of these abstracted ones. Web3.js was the very first one.
Then in every language, there's a whole gradient of very raw to higher level— Web3.py., Ethereum.rb., Web3j and in each one of these, you can see some custom implementation and some forks. That's the latter part of their tech stack. Once you're fully deployed and live on Mainnet, that's probably what you'll see.
But then, there are the earlier parts. You've got your Testnet stuff and when you're in it, you're thinking of dealing with things like Hardhat, or OpenZeppelin, or Ganache.Those are sometimes simulating or forking Testnet.
There's Tenderly, which is actually a paid service. It's not even just an open source dev tool, but Tenderly will give you stack traces like Sentry.
So, the tooling is immense, and it's still not good enough. On top of all of that, you do need to worry about where your files are going to be hosted. Are they on arweave? Are they on IPFS? Are you just hosting on a centralized server? If so, are you still at least delegating most of the files serving to the IPFS or the arweave?
Can you talk a little bit about developer-centricity and fintech? What’s different or specific for blockchain developers that helps you win and be top of mind for them?
You have your standard set of things—good docs, dev evangelists, etc.—but there's a slight difference in Web3, which is that most of the libraries are open source and provider-agnostic, so switching cost is almost nonexistent.
I can go from Alchemy to Infura to QuickNode relatively quickly, unless I'm using one of their sort of custom APIs.
That goes to developer centricity, which is, developers that are Web2 focused are going to tend to want high-level APIs that just do the thing that they want. "I just want to know who owns the NFTs.” “I just want to know the wallet balance.” “I just want to know the token transfer date." Whereas, people that were in this space previously, grew up with the tech stack. They know that you can perform an ETH call and send parameters and it'll give the balance at a particular block or whatever it is.
The Web2 developers that are just getting started want those higher level APIs and that's where it starts to be a winning game. It's just a race at this point to see who can add more developer-friendly APIs the fastest.
You've talked about both Web3 and Web2 use cases. Are you focused on one or the other? Does one or the other seem more interesting in terms of growth? How do the use cases differ?
From our standpoint, anyone that needs the data to relay transactions is our customer. That can literally be Adobe or Samsung. It could also be a Web3 company like Chainalysis. When we think about all of our customers, the biggest are not super-concentrated. We see all sorts in our top 100 customers—from indie devs you've never heard of that are just crushing it with their smart contract that does X, Y or Z to major Web2 companies, major Web3 companies, and companies transitioning from Web2 to Web3—and so there's no clear pattern.
In terms of use cases, it's so different from customer to customer. If we look at a social network, and pretend for a moment that Facebook was our customer, I'm not saying they are; I'm not saying they aren't, but they would be essentially only fetching NFT data, presumably from a high-level API.
Now, compare that with doing analytics, which is a Web3 native company, and they're going to be doing very hardcore, “What was this method call? Let's trace the transaction through every single op code that happened in the transaction. What were the internal transactions? What block was it at? When did that block happen? What was the time? What was the date? What chain was it on?” They're doing very, very sophisticated analysis and so yes, the use cases are very different.
Could you talk a little about the market? How do you position yourselves with respect to Alchemy and Infura? How do you see the market today for blockchain developer platforms?
To date, we have been very focused on making sure we acquire customers that can pay. You don't have to be a rocket scientist to see that we require a credit card to get started. Infura, Alchemy, and other players in this space don't require a credit card so presumably they're just getting a bunch of people that are making use of their service and not paying them.
That has a clear upside and a clear downside. The upside is that you get to say you registered more developers, and get them before they get big. You get to see them get big on your platform.
Then the downside is you have tens of thousands of non-paying customers who’re just sapping your network and that's probably the biggest sort of clear difference. We're attacking people that we know can pay.
Second, when we're explaining our value prop, it's most certainly that we are faster. Every single way that we know to measure, we come up as a winner and that's not necessarily happenstance. That's a concerted effort from our engineering team to make sure that no matter where you are in the world, you're getting serious performance.
So, we actually run an open benchmark, quickNode.com/compare and if you run it, we will benchmark whatever endpoint you put in against our network from your web browser, right there in the browser. We're not sending it to some server and some place that we determined. It's you, wherever you are.
I'm just looking at our compare page because I could see where the last couple were from. I'm looking at one right now where we are 25% faster. I'm looking at another one where we were 5, 6X faster. We're not choosing our favorite data center here to run these tests. We're just running it straight from the browser and that's very clearly telling us that we're faster.
Of course we run actual, controlled, more scientific comparisons and benchmarks, and we come up faster there as well. So speed is probably our number one sort of positioning differentiator.
After that would be the breadth of our chains. If you, let's say, are building cross-chain decks or cross-chain NFTs and don't have all the chains that you have on your provider, you now need to open an account for each provider that you need. We're servicing all these chains to the tune of as much as 8 billion requests per day, and that's giving us an edge.
You don't need to go and open three different accounts at three different providers. That's where we are today in terms of positioning, and there's more coming very soon. You might have picked up on it based on what I told you about the race to add value or what I like to call them—peripheral APIs.
Can you talk a little bit about the multi-chain approach and how you’re positioned against Ethereum-focused Infura? Does that allow them to go deeper on Ethereum versus being more high-level across more chains? What are some of the trade-offs?
Yes, it does in a way but it's not an insane mode. One thing that I actually really like from Infura is they have this crazy cool transaction relay service where you can only transmit your transaction when the gas is a certain amount or based on the conditions. They'll auto-retry for you and do all sorts of stuff like that.
We don't have that, but that's an example of where they were able to go deep and provide a higher value or peripheral API that is separate. That’s just the name of the game. You figure out some particular method—there's a bunch of methods in Ethereum—and then you optimize that particular method really, really well. Then you figure out if it's being called too much or if people have to call it millions of times to get the result that they want. Then, you build that thing.
That's the general sort of method of attack for every single company in the space. I'm talking Infura, Alchemy, Morales, Chainstack, GetBlock, Anchor, Pocket etc. All of them are just basically running that same play, over and over again. Find the thing that is annoying people out of this very long list of methods, abstract it, index it, cache it, make it re-tryable automatically, whatever and then sell that. To your point, Infura has the ability to go deeper on Ethereum, but they haven't as much as they should.
About the benefits of cross-chain, you have one account that gives you access to everything and beyond that, it will make your life easier as a developer if you don't need to log in. We talked about how it could be helpful from a payments standpoint where your AP, accounting department, and developers don't need to log into six different accounts. That's a small thing but what we’re betting on is that having the ability to set up a new chain very quickly is going to be a competitive advantage for us.
That actually cuts in two different ways and I need it in both ways.
The first is, we've actually written software that allows us to figure out how quickly we can stand up a new chain literally in that time or less. We've got an intake that processes how much space is on this thing, where the snapshots are, how we can get those, and what are the most common methods. Should they be cached? Is there any sort of indexing that should happen? We also have a fully automated process.
When I'm telling you this, I mean, it's one line—I type it, hit enter, and it will generate all the code for us to add it to the site, the checkout process, and the platform. We get a big, fat, speed advantage there.
Can you talk about where you've built abstractions internally that allow you to treat every chain the same? Does that provide massive leverage to developers for any particular use cases?
Any particular gap that needs to exist cross-chain doesn't get your right ones run anywhere. They get the right ones run in many places, because your smart contract that you wrote for Ethereum isn't going to work on Solana, but it will work for Polygon, the Gnosis chain, and the Binance Smart Chain. If there's some contingency of users that you want to give access to your dapp, then, having a multi-chain provider will give you a major benefit. All you've got to do is add a couple of characters to the domain name, and you're good to go.
The incentive on the developer side is that it allows them to expand their user base or their addressable market?
Exactly. You look at something like a Rarible or an OpenSea. Whatever, their EVM—all the code that they use to extract from Ethereum—can technically be used for Gnosis, can be used for Polygon, and so on.
On that, can you talk about when one would want to integrate with OpenSea’s API directly versus integrating with the QuickNode NFT API versus some other approach?
I haven’t actually played with OpenSea’s API in depth, but I do know that in some cases, it can be and we'll call it complementary to using QuickNode. If you want to know, for instance, what the description of a NFT collection is, only OpenSea has that. If the collection is a verified collection on OpenSea, or it's a verified collection on Rarible, each of them will have their own respective descriptions. That's just for them. If there's a description of a particular NFT token that lives on OpenSea or Rarible, they'll have that again, respectively. But all the data that's on chain, all of us have too because it is, by nature, public.
The picture of the metadata—who the current owner is, what its properties are, what the collection address is, what the token idea is, what blockchain it’s on, what standard it's using—are all the same across all of us. It's just those certain collections that are verified in one place or another for which we don't have that top-level description, for the most part. It really is only description as far as I could tell.
Do you integrate with OpenSea's API to bring that in so that anyone who integrates with your NFT API will get that and not have to integrate with OpenSea? Or do folks integrate with both?
Folk will integrate with both. We don't integrate directly with OpenSea because they have really, really stringent rate limits, and the amount of requests that we do on a daily basis would probably destroy their API.
Can you talk about how you design for a company that gets stronger during downturns and can capitalize on the bull runs and boom times?
This is a pretty tough question and I actually don't have a good answer. For me, the process of building a company is the same, no matter if it's boom or bust. There are customers that want to use your service. The service should be available, of high quality and with great customer service. That's pretty much it.
I guess it’s just about the fundamentals. So, whether there's 50,000 customers at the door or five, we're just focused on making sure all of them are well taken care of and happy.
You mentioned that you don't necessarily have super-high concentration, but how do you think about concentration risk? How do you retain customers as they grow large on QuickNode given the kinds of build versus buy decisions other infrastructure products see?
The number one thing is we want customers that use our platform for a very long time and if we see someone whose usage is exploding—and it’s happened many, many, many times—we'll reach out and say, "Hey, what's going on? You're making a lot of calls here."
They'll tell us, "X is happening. Y is happening, Z is happening." Depending on which one of those things is happening, we don't have formalized playbooks, but we have generalized ideas around what we can do to make sure X can still happen, but the number of calls doesn't need to be 50 million per day.
A real example of this is when a customer came to us, and said, "I'm doing 20 million calls every hour. I don't know why," We looked at their usage, and it was all coming from different IPs. So we say, “What's going on here?" Then we say, "Where can we use the product?" We go to the website where the product is, look at the network tab that shows that 1,000 requests are going to our servers from the browser. We then step in to look at the code and say, "What's going on with this code?" They have a loop that's checking the balance of 500 tokens or so but they are loading all 500 tokens. Even though you can't see 500 tokens all at once, they are checking it every second. So the simple optimization here is, “Hey, you should only load tokens that are visible on the screen. Here's how you can do that.” When you do that, there's block times of 15 seconds, so you don't have to check the balance every second. You go from 20 million requests an hour to 5 million or something like that, or a million.
The customer's happier. They got high-quality engineering support and are going to stick around for a long time. For the customers that use us the most, we do this for them. It allows them to stick around longer, not necessarily increasing spend as much as we would like them to, but we maintain a relationship and when they want to build their next Web3 enabled product, we know they're going to come to us.
Of course, if there is no way to reduce the number of calls they're making, we're going to do the obvious thing and try to find a deal that makes sense for everyone.
Do people ever tell you they want to bring this in-house?
No. The unfortunate truth right now is that we are by far the most competitive priced product on the market. If you took a customer of ours and put them on a competitor, their bill would 10X. If you put them on a cloud provider, their bill would 3X. That's because they would have to hire a DevOps engineer and get all this crazy swagged-out hardware. They would be paying list price for whatever cloud provider they're using.
We, on the other hand, have a competitive advantage, given my co-founders have 20 years in data center management experience. They know how to tweak the contract on a cloud provider (DigitalOcean, Oracle, AWS, etc.) to get the discount that we need.
What do you think about this ideology out there that with services like QuickNode, Alchemy, and Infura, Web3 is going to be as centralized as Web2 in five years? How do you think about the future that you're building with QuickNode as it becomes successful?
Let's say I write a Ruby app that just emails you at the end of every day. It asks you what you did. Let's say that AWS takes my app down. None of my users can access that app, so they're not going to get their emails. Nothing is going to happen.
If you deploy an app to Ethereum and if we, let's say, decide to take your app down, the switching cost is immediate. You just change to Infura and you're good. You're not hosting your website with us. You're hosting your dapp with us, and your dapp isn't actually hosted with us; we just have a copy of it.
As long as you can change the little snippet of code to point out the right server, your app will actually never really, truly be down. You can even decentralize it further by using something like IPFS or arweave so that it's accessible through the IPNS (Interplanetary Name Service), where you just go to ipns.com and you get shown the appropriate dapp. Or, you could just use a IPFS hash and any IPFS gateway, of which there are many that don't charge.
Sure, the number of players that depend on us is going up but if we were to go down, if Alchemy was to cut someone off, or sell their data to some hedge fund, the ability for users to continue using the dapp would not be extremely prohibitive. You’d just make a change.
I don't want to say your point is invalid, because I think there is validity to it. If, let's just say, some real dapp—Uniswap—is using us. The government says we've got to cut off Uniswap, and we do. Then the users of Uniswap can still use Uniswap. It goes even further in that the Uniswap dapp is actually completely decentralized. So anyone that has a copy of Ethereum could call directly to the Uniswap dapp.
Rainbow Wallet has a swap feature. But Uniswap has or Rainbow has a Uniswap feature, which is actually just their own front-end pointing at the Uniswap smart contract. Yes, there's a little centralization risk, but in my opinion, it’s mostly acceptable because you could just do it on your own if you're super-determined.
For instance, I run my own Ethereum node here at home. So I have it and I'm staring at it. It doesn't matter if AWS turns me off. I've got the latest copy, and I could read all the information I need, and I could use it to relay a transaction if I wanted.
What’s the long-term of what you're building? What sort of increasing returns to scale does your business have?
If I share with you the answer to your question, it can be executed on by every single person in the space.
I'm not sure that what my answer is is obvious to everyone in the space. If I felt like it was obvious, then I would just tell you. But because I feel it's not obvious, and I think that it's probably a competitive advantage for us long-term, and we've seen our competitors copy us repeatedly unabashedly, I think I'll refrain from saying it just on the record.
Can you share a vision-oriented statement with us? If everything that you're executing on just hits, what does QuickNode become in five years?
I want to give you a slightly different question-answer. What will the world look like if QuickNode succeeds at everything we’re doing?
If we succeed at everything we're doing, you will see blockchain deeply integrated into many, many aspects of your life. It will be everything from how you check into an Airbnb to how you hold politicians accountable, to how you hold police accountable. There's a lot between us and the reality where public officials' actions are auditable 24 hours a day. If we're able to provide all of the core Infrastructure that makes it easy for developers to not think about lower level things, we'll call it a Cambrian explosion of blockchain enabled apps.
Does that basically come down to blurring or removing the distinction between writing Web2 software and Web3 software?
No. I think the distinction gets more pronounced and writing Web3 software just becomes significantly easier.
Disclaimers
This transcript is for information purposes only and does not constitute advice of any type or trade recommendation and should not form the basis of any investment decision. Sacra accepts no liability for the transcript or for any errors, omissions or inaccuracies in respect of it. The views of the experts expressed in the transcript are those of the experts and they are not endorsed by, nor do they represent the opinion of Sacra. Sacra reserves all copyright, intellectual property rights in the transcript. Any modification, copying, displaying, distributing, transmitting, publishing, licensing, creating derivative works from, or selling any transcript is strictly prohibited.
