Sunsetting Honeycomb, and a Retrospective

We’re sunsetting Honeycomb, and will be using the data we have gathered from it to build API3 and ChainAPI. In this post, we will do a retrospective.

The main thesis of the Honeycomb whitepaper is that the oracle problem is not technical in nature, and the main difficulty is to get a large variety of independent and competing actors to cooperate in a decentralized way and achieve business outcomes*. The solution put forth was an API marketplace for oracles — a neutral platform that allowed API providers, oracle node operators and dApp developers to come together and do business. We achieved a great deal with Honeycomb, and also found out that some of our initial assumptions were simply not true. Today is probably the best time to do a retrospective.

*I would continue this today with “However, technical solutions can be designed in a way to conceive an ecosystem where this can feasibly happen.”

The good

The best thing to come out of Honeycomb was that it acted as a laboratory and an incubator for API3. Above all, it affirmed that API providers must be considered a critical component of an oracle solution, and paved the way for API3 to become the API-centric solution it is today. Furthermore, it taught us the wants and needs of API providers, and how to approach them in practice. The well-standardized API–oracle integration capabilities of Airnode were adopted directly from Honeycomb tech, and we prototyped the first fully-serverless oracle node to be used by Honeycomb.

Honeycomb was a major UX success for all parties involved. Honeycomb–API integrations were essentially effortless for API providers, which allowed us to onboard new APIs frictionlessly. Similarly, oracle node–Honeycomb integrations were seamless (barring a node bug that caused significant headache) thanks to our tooling, and the feedback received about this process was extremely useful in designing the Airnode deployer UX. Perhaps most importantly, we were able to simplify oracle–dApp integrations to the bare minimum (while providing essential functionality that alternatives lack), which has received widespread approval from users in surveys and interviews.

The bad

A retrospective wouldn’t be complete without the shortcomings. Most importantly — and this was something we were aware of from day one — from an architectural standpoint, Honeycomb was acting as a middleman between APIs and oracle nodes to facilitate the integration. We were planning to use this initial model to bootstrap the platform, and then move on to a solution with a trustless integration-path. However, our research showed that the only acceptable option was for the API provider to operate the full oracle node, and none of the alternatives were as trust-minimized (and this explains why we emphasize first-party oracles with API3 so much).

A second problem was the oracle ecosystem model. We took the existing oracle ecosystem model that only considered oracles and dApps, and added the API providers as a third group to better represent the situation. Although this model is more accurate, it has also proven itself to be very complex due to having to make sure that three different parties play along. The solution posed by API3 is to cut out the oracle node operator group as the middlemen and have the API providers operate their own oracle nodes, which greatly simplifies the ecosystem model (APIs and dApps). As a small note for who’s wondering, this was also why Nodary (oracle certification service for Sybil attack resistance) was abandoned, because it is only needed by third-party oracles, which are redundant in the first place.

The unknown

The most critical unknown, which essentially forced us to stop developing Honeycomb, was that its underlying infrastructure in terms of the oracle solution it depended on ended up not satisfying the needs of the business model. The main pain points were

• Oracles covering the gas cost of fulfilling requests and the cost being uncertain
• Related to the above, static service pricing with respect to gas price, ETH price, etc. (and the gas cost overhead of implementing on-chain dynamic pricing)
• Need for off-chain coordination to update pricing parameters (which is especially difficult with the three party model)
• Payment token friction, awkward pricing model (compared to the traditional API provider pricing models) and not being able to customize it

Although these issues existed from the beginning, we expected them to be resolved in time due to their universal nature. This not happening can be considered an unknown at the time. After attempting some band-aid solutions, we realized that we had to implement our own oracle node/protocol from the ground up based on these requirements (in addition to the requirement of being operable by API providers).

Our second oversight was that we did not consider the central governing entity of the ecosystem in our model. Centralized ecosystems are not permissionless, and this prevents independent usage. Our assumption was that value-add to the ecosystem would result in permission, yet if the incentives of the governing entity and the ecosystem do not align perfectly, this does not apply. To avoid this conflict of interest, API3 is governed by its DAO not only at the oracle-level, but also at the ecosystem-level, i.e., the DAO manages the ecosystem funds.

Conclusion

We were successful in some things, hit roadblocks with others, and learned some things the hard way. The resulting wealth of knowledge is why the API3 solution ended up being so convincing, especially to people experienced with existing oracle solutions as a user, partner, investor or even a well-informed community member. Therefore, all in all, we would consider Honeycomb to be a major success.

Based on the resulting knowledge, we have conceptualized a spiritual successor, ChainAPI, to become a vital part of the API3 ecosystem. We must note that ChainAPI will be a significant iteration over Honeycomb. While Honeycomb was supposed to be an ecosystem hub, that task lies with API3 now. Instead, ChainAPI will be an integration platform, which will allow API providers to self-integrate their APIs to an Airnode to create first-party oracles. This will stop oracle–API integrations from being a bottleneck, and allow API3 to scale its operations up exponentially. In addition, differently from Honeycomb, ChainAPI will not be on the data-path at all, and will not degrade any trustlessness guarantees. However, it will use all the UX lessons were learned from Honeycomb to bring first-party oracles to the masses.

Farewell for a brief time, and we can’t wait to see you again on ChainAPI!