API monetization on Web3
First-party oracles are on-chain entities operated by real world businesses — API providers — to provide services on Web3. Understandably, the primary motivation of the businesses that participate in this ecosystem is to monetize their services. An effective monetization model benefits the first-party oracle solution in two ways:
- API providers will self-integrate, resulting in sustainable and scalable growth of the ecosystem
- Commercial competition among API providers will produce more secure, performant and innovative oracle services
First-party oracle monetization is a problem yet to be solved effectively because of its multiple and independent requirements. In this post, we will discuss these to shine light on the solution.
Support for all motives of demand
The oracle services that are currently available are extremely limited in variety. Therefore, most potential first-party oracles can be considered innovative. The blockchain space values novelty over all, which is a tremendous advantage for monetization. However, this property is a double-edged sword. A novel service initially sees no usage because no developer builds a product that depends on a service that doesn’t exist. This can be summarized as the chicken-and-egg problem.
Keynes lists three motives for cash demand: transactional, precautionary and speculative. We can translate these to utility demand in the following way:
“I need this utility now” (transactional)
“I will need this utility in the future” (precautionary)
“Someone else will need this utility in the future” (speculative)
Note that the chicken-and-egg problem is caused by the lack of people saying “I need this utility now.” However, in the case of a first-party oracle service with compelling utility, there will be a lot of people saying “I will need this utility in the future” or “Someone else will need this utility in the future.” Therefore, the monetization should aim to capture all motives of demand, and not only immediate usage.
Market-based pricing
First-party oracles are an absolute requirement to build useful smart contracts, and a novel first-party oracle can enable multiple useful dApps, of which a single one can be valued in the order of billions of dollars. On the other hand, a novel first-party oracle will not see any usage initially due to the chicken-and-egg problem. This creates an intractable ambiguity regarding how even a single first-party oracle should be priced, which implies that no entity should hope to do this effectively at ecosystem-scale. The solution will be obvious and familiar to people from the blockchain space: Prices should be collectively discovered through a market mechanism.
Automation
Co-marketing campaigns and “Partnership confirmed” posts have traditionally been the bread and butter of blockchain projects. Since this is an indispensable and rather manual step in on-boarding a new user, automating the monetization is not seen as an important problem for oracle projects. Furthermore, the limited variety of available oracle services and the small number of potential users have made manual payments a workable strategy.
We are not only looking to build a set-and-forget oracle node, but also a set-and-forget business model for API providers. In such a model, the API provider cannot be expected to take any kind of a manual action for each user being on-boarded. In addition, we are looking to support many orders of magnitude larger numbers of unique oracle services and users than what manual payments will work with. Therefore, it is critical for monetization to be automated.
Supply policy
API providers need to control the supply of their services for effective monetization. If users can access the services of an API provider for free — for example, through a third-party oracle — any effort in monetizing these services will be futile. This is as simple as adding a simple line in the API terms and conditions, “No cryptocurrencies, no blockchain,” and enforcing this as strictly as any other term that protects the API provider business model.
The API providers also need to control the monetized usage. Consider the case where someone gets paid access to a first-party oracle service, then puts that behind a proxy that resells the service to multiple users for cheaper, or worse, makes it publicly available for free without the API provider’s consent. Fortunately, this is an easy problem to solve, as a well-managed supply policy and effective monetization create a positive feedback loop. Providers of valuable services will be better motivated to take the precautions to keep the service valuable, which will make the service more valuable.
Conclusion
Getting first-party oracle monetization right is difficult, but on the bright side, the rewards are bountiful. With a solution that doesn’t suffer from the chicken-and-egg problem, there will be an influx of API providers with novel, secure and reliable first-party oracle services because they will receive an immediate and tangible benefit. These services will allow developers to build projects that don’t resemble anything that we have seen so far, and bring in a new era of useful dApps.
