Net API Notes for 2022/03/03 - Issue 191 - The API3 One

This newsletter was challenging to write for multiple reasons. Not only is the subject matter (API3) complex and pockmarked with several contentious rabbit holes, but the largest European war since WWII started last week. Dithering over "POST" this or "PUT" that seemed self-indulgent amidst the real stories of life-or-death occurring.

If you are in a position to help, please consider donating to:

Big breath.

Now, let's talk about API3.

Net API Notes is a regular, hand-curated digest of impactful news and analysis for busy API practitioners. Are you reading this and not subscribed yet? Sign up today and be the first to get ad-free, actionable info delivered directly to your inbox.



API3 is an architecture to connect the web API ecosystem with blockchain-based applications (also known as "smart" contracts, or decentralized applications [dApps]). It is the basis for an interesting but flawed whitepaper. It is also is a distributed autonomous organization (DAO), a tradeable cryptocoin, and (apparently) a non-fungible token (NFT).


Despite a unique architectural approach, API3 does little to address companies' hesitation to integrate with decentralized applications (dApps). This technology will be relevant for only a tiny minority.

Topics like DeFi, Web3, and blockchain itself remain contentious issues. If this area's clamor deafened you long ago, feel free to skip this one. I'll see you next week.

For everyone else, we have to establish some shared meaning. In this area, more than most, obfuscation via technical jargon seems as though it is not a bug but a "feature". If you're a seasoned blockchain bro, bear with me.

If you're along for this journey, keep this quote from agile coach Tim Ottinger in mind:

"It is shameful and sad how many root causes fester while people build processes to make the symptoms tolerable."


The easiest way to visualize the blockchain is as an immutable ledger; when transactions are added, they can't be deleted, updated, or rearranged.

Reading from the ledger is free, but writing to the ledger is not. Before a new transaction can be written to a blockchain, it must be validated and confirmed. We're used to a central authority, like a bank, performing this confirmation. In the place of a central authority, however, a blockchain relies on algorithmic mediation. This algorithmic consensus must run its course before a transaction can be added to a blockchain.

Reaching algorithmic consensus takes work. There are different approaches to doing this. (Discussions of the various proofs - proof-of-work, proof-of-state, proof-of-history, etc. - and their various energy efficiencies are beyond the scope of this summary). Regardless of how it is performed, computers (or nodes) are paid in a cryptocurrency to do the work.

The ledger is openly available and links all individual blocks of transactional data (the "blockchain"). If you wanted to grab a copy for yourself, you could. At this writing, the Ethereum blockchain is 561.61 GB in size.


In the beginning, transactions consisted of the amount to be transferred, the source of that amount, and the destination to where it should go.

However, in 2013, there was a proposal to store more in each ledger entry. Implemented in 2014, the Ethereum blockchain enabled developers to store executable code. This code is also known as a smart contract. They are also known as distributed applications or dApps.

To write to the Ethereum blockchain requires Ether, also known as gas. This cryptocurrency covers the cost of achieving consensus. When people refer to the price of Ethereum, they're actually talking about the price of Ether, which can vary considerably.

How fast is computation? This Computer Security 161 Cryptocurrency lecture does a fine job going through the details. However, in short, the entire global Ethereum network costs approximately $250 a second to use. For that amount, a user has about 1/5000th of the computing power of a single, $45 Raspberry Pi 4.


A dApp might encode a bet between a cryptographers' favorite couple, Alice and Bob. Suppose that Alice bets Bob a certain amount that the price of Ether will be lower today than yesterday. That agreement could be coded into a dApp, Ether paid to put it on the Ethereum blockchain, and then Alice and Bob would wait while a consensus algorithm determines who pays who.

Or at least it would work except for one massive problem that has stunted dApps since 2014: if information, like the daily price of Ether, is not on the blockchain, it effectively doesn't exist. Even though there may be dozens of "conventional" APIs that provide today's Ether price, Alice and Bob's dApp can't use it without significant help.


(We're getting to where API3 enters the picture, I promise.)

The inability for dApps to interact with the API economy is known as "The Oracle Problem". A dApp, after execution, is programmed to write a transaction - the amount to transfer, and whether that amount flows from Alice to Bob (or vice versa). However, for algorithmic consensus to be achieved, those performing the work need to replicate the computation presented in the dApp. To recalculate, they need a source that is free from tampering - simply calling the same API means trusting that it will return the same value. That is why values used in the calculation must be on the blockchain.

An API that wished to provide information publishes it with several intermediaries, known as oracles, to bypass this problem. These 3rd parties each take the data and publish their version as independent records on a blockchain. Ideally, there may be other sources of data, like a cryptocurrency price, also publishing to other oracles. A special consensus mechanism then is able to look across the array of provided values, conclude what the "right" value is (for example, based on simple majority), and provides that variable for the subsequent dApp processing.

The usefulness of dApps is severely limited without utilizing outside information. Oracles are a means to facilitate consensus. However, they create more issues, issues that API3 claims to solve.


Two of API3's executives, Burak Benligiray (CTO) and Heikki Vänttinen (CEO), previously worked together on the Honeycomb API Marketplace. Honeycomb tried to make web API providers available to dApps. Manually onboarding new APIs proved problematic and slowed growth while incurring considerable (and volatile) gas fees.

To overcome these limitations, those two, along with Saša Milic (COO), created API3 does not require API providers to publish multiple copies of the same data to oracles. Instead, API providers provide data directly to a blockchain, using the API3 "1st party oracle" code. Each API-owning entity operates its oracle. API providers can write an OpenAPI-like description, written to the Oracle Integration Specification (OIS), to their node. This description defines the operations of the API, the endpoints of the oracle, and how the two map to each other.

API3 claims that by not hiding the data source behind 3rd parties and providing more transparency, trust is increased (ironic given the space's emphasis on "trustless applications"). Further, given more direct control, oracle operators can "enforce whitelists [sic], blacklists [sic], monthly subscription payments or per-call fees". This makes it possible to implement a blockchain accessible API "where the users assume all gas costs, which is not possible with the existing oracle solutions". intends to create a centralized "node dashboard and marketplace" for oracles to simplify endpoint discovery. API3 is governed by a Decentralized Autonomous Organization, or DAO. To review the stake, governance, or history, a person must first connect their crypto wallet (like Metamask) to view. In short, the DAO allows API3 to raise funds and issue grants to perform work.


In the whitepaper, under the section "4.2. Barriers to API providers operating oracles", the authors note that "Traditional [sic] API providers are typically not more familiar with blockchain technologies than the general public." They also note that "unless one is guaranteed significant subsidies or future profits, operating an oracle node is financially infeasible".

The paper goes to great lengths to solve dApp's lack of access to reliable, first-party data. But that problem is not the API providers' problem. While API3's claims of lowered gas fees and additional payment options are interesting, it doesn't answer web an API provider's question: why? Beyond an abstract allusion to financial gain, why is any of this in my best interest?

It is yet another example of this space's assumption that the answer is just a better technical solution. The reason that dApps haven't caught on isn't because of the lack of a certain technology, or that we were missing a mechanism for paying for access. Those have existed for some time. What is missed is how participating in these scheme aligns with a company's strategic agenda.

The web API space went through a period, approximately 2008-2014, where companies would create FOMO-driven API programs. These were the days of ESPN, Netflix, and even GM(!) standing up "open" API programs. Leaders hoped to be the engine powering the next viral "mashup". Companies rushed to provide data with vague "platform" allusions that went something like:

  • Step 1: Provide API and Get Developers to Use It
  • Step 2: ?
  • Step 3: Profit!

Throughout the middle to late 2010's, as budgets dried up and reality set in, many of these programs were shut down or drastically retooled. Companies where the API was the business, like Twilio or Stripe, flourished, of course. For them, the time and effort to support the widest number of use cases is the business. Like Netflix or ESPN, others realized their value proposition was not serving data to every person who asks for it. They still have APIs, of course, but access is narrowly defined to a set of partners that align to larger, more strategic efforts. Today, partner integration abound.

API3's conceit is that API providers would flock to the space if the barrier to entry was lowered. While there may be occasional enthusiasts looking to kick the tires, the APIs that engage in the effort will be the ones for whom the growth of blockchain-based solutions is strategically aligned with their business. If that isn't your company's core value proposition, API3 doesn't change your daily work.


I can't tell whether those involved believe in the space's claims of efficiency, transparency, and decentralization or whether they're willing participants in the grift. I don't know their motives, only that so many others in the space use the rhetoric of the revolution to perpetuate the same, tired windfall motives. Ultimately, the motivation doesn't matter.

What does matter is that there is an entire generation of bright, capable people who opted for something different. And I empathize. We're living through history where we have seen successive systemic failures by the institutions that should be working on our behalf - governments, companies, and institutions. When presented with those stacked odds, the math becomes clear: why toil away for years in someone else's casino when you can make your own?
Different, however, does not mean better. The mechanism to mint an alternative path to wealth and prosperity for those "in the know" has made the world arguably worse. Crypto, along with the problems in the existing financial world, has created increased levels of terrorism, fraud, ransomware, tax evasion, physical attacks, armed robbery, kidnapping, torture, and murders. (Seriously, where would ransomware be without blockchain-based crypto?)

From Bitcoin to NFTs to DAOs, Every crypto paradigm has become increasingly centralized. Almost all web3 apps use the same two centralized entities, Infura or Alchemy, to communicate with the blockchain. Crypto exchanges like Coinbase and FTX have emerged because trading coins without a centralized entity is bonkers hard. And, when it comes to NFTs, OpenSea is pretty much the name of the game.

There are real, systemic problems in the world. We need to recruit successive generations to help identify and correct these problems. That status quo is untenable. But avenues for pitching in and lending a hand need to be easier and more evident than recreating the worst parts of capitalism on an inferior technology (the rent-seeking, windfall mentality alongside a lack of accountability).

There are decentralized models that work. Podcasting has had its various aggregators over the years. But anyone can record audio, host it on their website, and syndicate it with RSS (recent efforts by Spotify notwithstanding). ActivityPub is an incredible, decentralized protocol that works without blockchain (and scales because of that). DAOs aren't required for communal governance - just ask any Wikimedia member.

Of course, we don't talk about these things because, being truly decentralized efforts, they are lousy investment vehicles. Web3 is not about the freeing possibilities of the technology, at least not anymore. It is about shifting power for financial gain during a moment of cultural, political, and financial upheaval.

And anyone else that tells you different is probably trying to sell you something.



Yikes! That one got away from me. Even with thousands of words on the cutting room floor and hours more in research left out, this got long. It is time to end with a thank you to this newsletter's Patrons. Sometimes, like this week, there is a tremendous amount of research, writing, rewriting, and re-re-writing required. If I had to churn out a newsletter each week to meet a sponsorship obligation, I'd have to let the quality suffer, avoid challenging topics, or both. Being able to say no to sponsors means the work can take as long as it needs to make sense. For that, I am very grateful. Thank you.

Till next time,

Matthew @libel_vox and

While I work as a Concentrix Catalyst, a boutique of color commentary along a boulevard of otherwise beige beings, the opinions presented above are mine.

Subscribe to Net API Notes

Don’t miss out on the latest issues. Sign up now to get access to the library of members-only issues.