Morning. This is the Status Code, your cool friend who tells interesting stuff about APIs.

Today, I will do something different. Instead of news, I will talk about APIs in Web3 and the recent developments in the space.

Not subscribed yet? Stay in the loop with AI weekly by reading the Status Code for five minutes.

If you don’t already know, a Blockchain is a closed system. It cannot access the Web APIs you and I always talk about. At least, not without some clever maneuver.

It presents us with an interesting problem. Because decentralized apps (if you want to sound cool, call them DApps) need external data.

A sports betting app uses data from SportsDataIO or Sportradar. Binance or CoinMarketCap for Crypto trading apps.

So, how does it work?

Don’t worry. I will explain it to you within the next five minutes.

But, first, let me explain what a smart contract is and how it works.

A smart contract is a program stored in the blockchain with terms of the agreement between a buyer and seller.

DApps (yes, I am cool!) are possible because of them. They drop the intermediaries.

When you bet on sports through Bet365, you trust the Bet365 name to meet their end of the deal. You trust you will receive a payment if you predict the correct score.

You are trusting the brand and its past reputation.

A smart contract, meanwhile, eliminates that need for brand and reputation.

It makes it impossible for its creator to run away. Because it self-executes itself when you meet specific agreement terms within the contract.

You bet on Rafael Nadal having 10 Unforced Errors, and that's what happened?

The Smart Contract gets the information and executes the payment for you. And since it's on Blockchain, no one can control its actions.

So, you can trust the DApp to fulfill its promise as long as the dependencies are trustworthy (as long as the data about Nadal’s game, for example, is reliable).

So now, we go back to where we started.

How can we inform the Smart Contract that Rafael Nadal had 10 Unforced Errors?

They cannot call a Web API. And, the data is sure as hell not in the blockchain. We call this a Blockchain Oracle Problem.

The Blockchain Oracle Problem says that a smart contract, by design, has a fundamental limitation. We isolated them from the outside world. And the isolation helps blockchain maintain its basic properties. Strong consensus on the validity of user transactions. Prevention of double-spending attacks. Mitigation of network downtime

So, the only way for a blockchain to access off-chain data (this is what the hippies call it) is through an oracle. An oracle is a bridge between the two worlds; of blockchain and the Web.

And, since trust is essential for such applications, a blockchain requires a good oracle mechanism.

But a mechanism with a single oracle isn't the answer (it's awful!) because it brings a single point of failure.

When we depend on one oracle for our data, we risk everything on that source. And you know there is no way for a smart contract to backtrack on a previous agreement. Even if it depends on incorrect data.

How can we solve it?

We take inspiration from our pal, a cloud architect. A good Cloud Architect knows they should not design any system with a single point of failure. And they use redundancy to make sure of that.

A decentralized oracle network (for you jargon nerds) has the same idea. It combines many independent oracle node operators and data sources. This way, you can rely on the data you use for your smart contracts.

You may have heard of Chainlink. They are the pioneers in building such a network.

Chainlink is so popular that its market cap is already a whopping $3 billion. At the peak of the Crypto bull run, it was $21 billion.

So, Chainlink’s network aggregates data from many oracles. And their network has incentives to reward reliable data sources.

All good and done, but Chainlink still doesn’t solve the transparency problem.

When using Chainlink, you ask for and receive data from its network. But you have no control over the data sources.

If you dislike CoinMarketCap as a data source for your trading app, bad luck, my friend.

You can’t say you don't want it as a source (btw, we don’t hate CoinMarketCap here).

Now, are you asking for your freedom back? Do you wonder whether this is the world we want?

Okay, you are becoming dramatic.

But I get what you mean.

The best case scenario would be to have control over the data sources. Like a good old non-decentralized financial app.

Maybe you like Binance, maybe you don’t. You want to be sure about what powers your application.

You want to pick a Web API and use that in your smart contract.

In other words, you need a “superpower” that enables you to use any Web API in your Smart Contract.

API3 is trying to build infrastructure to give Web API developers that superpower.

Their protocol AirNode allows Web API providers to run their own oracle nodes. So, they can provide data on-chain, without an intermediary, to a dApp.

This way, API providers receive the entire revenue for their data. And, as a smart contract developer, you have complete control over what Web API you use in your dApp.

API3’s market cap (as of writing) is ~$107 million. And it's growing.

Meanwhile, the developments in Web3 excite API developers. Postman’s latest State of the API report says over 30% of developers find it exciting. Don't you want a piece of that pie?

By the way, the next newsletter will catch up on the State of the API report 2022.

Until then,

See ya nerds!