API3 Core Technical Team Report, June–August 2023
With no doubt, the most important news of the previous cycle was the managed dAPIs being made publicly available on the API3 Market. To explain briefly, a managed dAPI is a decentralized first-party data feed for which API3 provides the operational guarantees that the client requests. This is a milestone in blockchain technology, as it’s a first for such a high-level, managed service being offered on-demand in such a streamlined and transparent way. The API3 Market clients are not required to join Telegram groups, attend endless calls or chant “API3 rules, the other thing drools”. Clients fill their shopping cart, pay with their crypto wallet and enjoy their data feeds, saving their time and dignity in the process. All payments go to the dAPIs team’s operational gas fund, so this is essentially a gratis service, similar to our self-funded feeds. Monetization will be handled with the upcoming OEV share, which will be opt-in for managed dAPI clients.
While this is amazing news for up and coming chains and dApp developers, it poses new challenges for the established DeFi projects that are used to depending on privileged access to data feeds as a moat. Specifically, it will be increasingly trivial for developers to fork DeFi apps on newly launched chains and have them operate as reliably as the real thing. Frankly, I have no advice to give here, so we’ll see how it all plays out.
So, managed dAPIs are a huge deal and a very solid foundation for large-scale OEV generation, but let’s talk a bit about what happens behind the curtains. The managed dAPIs launch is obviously a very dAPIs team-thing; it was Phase 2 in their roadmap (Phase 1 being self-funded feeds and Phase 3 being OEV share). The story of a managed dAPI starts with business development though, where suitable API providers are signed on as partners by the BD team. You can see them all on API3 Market, and verify yourself that it’s actually them that are providing the service, which is again, a first. Nodary integrates them and starts monitoring their data (which never stops from this point) to determine what dAPIs they would be viable for. Each dAPI is curated continuously to uphold our security standards, which is why we call it managed after all.
As promised in the previous report, we have released Airnode v0.12 with a few, long-awaited features. Most importantly, Airnode operators can now omit the fulfillment gas limit in their config files, which will cause the Airnode to estimate the required gas limit at run-time with RPC calls. For example, one will be able to request a large number of random numbers from QRNG and mint an NFT with each in the fulfillment transaction, as long as their sponsor wallet is funded to be able to do so.
If you’re up to date with your API3 governance, you should have noticed that two additional teams have spun-off from the core technical team at the end of this cycle: the UX/UI team and the independent monitoring team. I’ve been continuously encouraging people to spin-off from CTT to create teams to work toward a more specific goal in a more autonomous way, which inevitably left CTT with a group of people for which spinning off doesn’t make sense but also they are not specifically cohesive. To address this issue, CTT will be wound down. I will post a closing financial report on the forum, the multisig will return the remainder of the funds to the DAO, and I won’t give a CTT proposal for the next cycle. This dovetails perfectly into the restructuring of the other DAO teams (which you should be able to read about on the forum soon), and the current CTT members will be swallowed by this new structure (including me).
