Scaling the Data Supply for Smart Contracts with the Honeycomb API Marketplace
What do you see when you imagine an API marketplace? Possibly a neat Amazon-esque grid of data provider logos, displaying prices for monthly subscriptions. Then, a shopping cart where the APIs you choose to purchase will go, and a checkout process where you pay for the access. This is usually the mental image of a user interface that goes with being an online marketplace. It doesn’t matter if your marketplace is selling shoes or access to data, they all sort of look the same and operate in a similar fashion on the UI/UX level. But is this really the best way to set up a data marketplace for oracles? And what kind of node operators would actually benefit from a marketplace?
In this article we look at what it takes to run a node depending on what kind of data you’re looking to provide as the node operator, and how a per-call priced marketplace for API calls can alleviate some of the issues that third party nodes might face.
Types of Independent Nodes
As a rough categorization, (at current) third-party Chainlink nodes can be divided into two categories by the type of data they provide: 1. specialized nodes connected to paid APIs, and 2. nodes connected to open APIs. What we intend to create with Honeycomb is a third category of nodes — let’s call them Honeycomb nodes — which we will introduce in the last chapter. It should be noted that the article only covers independent nodes. For this reason, services like pool staking are excluded from this particular discussion, although Honeycomb can be utilized by pools also (this is a topic we may cover in a later article).
Specialized Nodes are Akin to Running a Business
Specialized nodes will generally be ran by operators who have recognized a lucrative niche, e.g. flight data, and are looking to make this the cash cow of their operations. In other words, the operator knows exactly what kind of data they want to provide for the network and are working off a premise that they can predict future market demand.
These node operators can simply go to the data providers directly and purchase one or two monthly or annual subscriptions with a redistribution licence for their data niche. In essence, they are betting that the data demand will cover these subscription fees and then some for their profit margins. To the same end, building and updating one or two external adapters for the purchased API subscriptions is not terribly time consuming, so operators can either manage it themselves or have someone do it for them. This “quality-not-quantity” approach is indeed a relatively safe, yet potentially lucrative way to monetize a node in a situation where the network is young and nodes have the chance to build reputation to become the main provider of their niche. If their prediction is right, in a few years they may find their node bringing in a decent cash flow even despite risen competition. At the same time if it’s not, they aren’t burning a ton of money, since they’re not adding up expenses with dozens of API subscriptions.
However, as the name of the approach suggests, what the “quality-not-quantity”, subscription-based model is not, is horizontally scalable or simple to manage. This is because with each new API the node operators add to their portfolio, they are adding not only to their monthly expenses via subscription fees, but also to the overall effort of keeping things technically operational with the adapters, as well as financially lucrative with their chosen data niches. Their upfront expenses grow with every new API they serve, and the operator will probably need to have lines open to the data providers to anticipate changes that might break the adapter and cost them their staked LINK. A node serving subscription APIs also can’t afford too many low demand months because of the upfront fees, so they need to have their finger on the pulse of the emerging smart contract economy and be right about the horses they place their bets on. However, at the same time the upfront fee is their friend in that it limits the competition they face, since it provides a small but real financial moat for competing nodes to enter the play.
To put the challenges of specialized nodes in a nutshell: expand too far from what you know and your operations might quickly start to resemble those of a cat herder. Predict the market demand wrong and all you’re doing is stacking monthly subscription bills. You hope your data provider doesn’t start providing a per-call pricing model (more on this later) or worse yet, begin running their own nodes.
Open APIs are Easy, but Easy is Rarely Lucrative
So what if you’re not 100% sure you can spot the lucrative APIs and manage your node to become the de facto provider of your specific data niche? What if you want to hedge your bets with multiple APIs, or better yet, don’t want to bet at all?
Let’s hop out of the world of cut-throat commerce for a second, and into a world where everything is free and plentiful: open APIs. As most node operators know by now, Chainlink oracles are-out-of-the box compatible with all open APIs. In principle, this is great news for any operator who is looking to connect their node to these free data sources. First of all, they don’t need to build or maintain any adapters, which is great, because not everyone is technical enough to build one. Second, since there are no upfront fees, these operators can simultaneously offer any number of open APIs on the web through a single node. As each call to an API is free and the node charges a small fee, they generally make a guaranteed profit with every call. To add to all of the nice things about open APIs, since operators don’t need to worry about revenue vs expense calculations, demand forecasts or external adapters, running a node that’s connected to open data is going to be as close to the set-and-forget, college dorm room early cryptocurrency mining operation we all recall so fondly.
In practice however, it’s most likely not going to be all sunshine and rainbows in the world of free and plentiful either. Open API nodes have a high likelihood of becoming the public service jobs of the smart contract economy, where for most third party operators everything about the job is great — except for the money. There’s the common truth that when everything is free and unlimited, ultimately it isn’t worth much as competition drives the prices down. However, what may not be so apparent at this point is the mechanism by which we see this happening and how low the prices will be driven.
The most important thing to realize when considering the future market economics of running a node connected to open APIs is that all open API calls will most likely be priced the same — and since every node calling open APIs on the network will be competing for the same jobs, the profit margin will quickly diminish towards zero. This effect will accelerate as the network grows and more nodes enter the competition.
Eventually we expect this to lead to a situation where only the most well-managed and efficient operators will be able to function at a profit, and running open API nodes will be comparable to PoW mining where operators take every edge they have against the rest of the market. Reputation will play a part, but will resemble a hygiene factor where any reputation score above X is enough, and there are diminishing returns for any score above the generally accepted level. Thus, what seemed like an easy market to tap and make some effortless money, will quickly be swallowed by nodes that have a good enough reputation and can offer any open API at $0.00001 per call, whereas the average 3rd party node can only manage $0.000013. This is obviously not great for your average independent node operator.
A New Type of Independent Node
Ok, so paid API subscriptions are more like running a full time business than your average crypto mining operation, and open APIs are like a mining operation in all the worst ways, where the race to zero destroys all profits. Is there no way to run a long-term profitable node without making it your full time job? Also why did we start the article off with that schpiel about the user interface of a marketplace?
What we are building with Honeycomb API marketplace is not like your average online marketplace. You will not purchase API connections — instead you’ll be able to buy individual calls from any API offered on the marketplace. This means that there will not be a shopping cart or a checkout process. Rather, your node will be simultaneously connected to all APIs listed on Honeycomb, and it will be able to provide smart contracts with data from all of these APIs with zero upfront fees due to the per-call pricing of the platform. Whereas the average specialized node can only manage a handful of paid APIs due to the upfront subscription fees and the need to build, run and update their own adapters (and potentially negotiate redistribution contracts), Honeycomb nodes will be able to provide data from dozens (and later hundreds) of paid APIs simultaneously without having to worry about adapters, contracts or making a loss.
What the Honeycomb API marketplace provides for third party nodes is horizontal scalability, which is similar to that of nodes serving calls from open APIs. Horizontal scalability, then, means the ability to supply a very broad, sporadic and hard-to-predict demand base with high-quality paid API calls while keeping upfront costs at zero. This allows operators to run a node delivering paid API data without the need to forecast market demand, negotiate contracts or create rigorous break-even analyses before connecting to said paid APIs. In essence, with Honeycomb, you’re not betting on any individual API on the marketplace, rather the marketplace as a whole. And since your node can call any number of APIs provided by Honeycomb simultaneously, to the smart contracts your node essentially becomes the marketplace.
From the user interface point-of-view, since there is no shopping to be done for the node, the UI of the marketplace will not be directed towards the node operator at all. Instead, the function of the marketplace interface is to present smart contract developers with a wide array of high-quality data sources in every useful category. Due to being on Honeycomb, these data sources will have guaranteed decentralized supply (remember, all nodes utilizing Honeycomb will be simultaneously connected to all Honeycomb APIs) at any given time. First of all, this provides stability for the Chainlink network, as the supply of an individual data source is not monopolized by a small number of nodes which may go down, hike call prices between jobs, or disrupt the supply of their data in a number of other ways. Second, this enables smart contracts to be built on API data sources which would otherwise not be financially lucrative enough to be offered to the network by a specialized node, let alone multiple specialized nodes. With this in mind, we believe that Honeycomb we will be enabling thousands of smart contract use cases which would otherwise not become feasible until much later.
Learn More About Our Project
You can find more information about Honeycomb API marketplace and the team building it, CLC Group, on our website. We have also written a whitepaper, which details the role of Honeycomb as a Chainlink ecosystem hub and also introduces our oracle certification service, Nodary. To stay up to date on our project’s progress, you can join our online communities on Telegram, Twitter and Reddit.
