Pieter Brueghel the Elder, The Hunters in the Snow (winter), 1565.

API3 Core Technical Team Report, December 2021

As promised in the November report, we released Airnode v0.3 on December 7th. We started working on v0.4, which is largely focused on revising how the requests are handled to:

In the meantime, we are also working on the v1.x protocol contracts, which include PSP (publish–subscribe protocol), RRP+PSP Beacons, dAPIs, token lock-up and payment functionality for automating access to API3 services.

After Certik, Sigma Prime has completed a second audit of the v0.x protocol contracts. The audit report can be accessed through our monorepo. No vulnerabilities have been uncovered in the protocol, and releases v0.2 and v0.3 are once again confirmed to be safe to use. Nevertheless, it is planned for the v0.4 release to use a new iteration of the contracts where the suggestions from the audit report are implemented.

This month, we published an article introducing Beacons. A Beacon is a data feed that is powered by a single first-party oracle. It can either be used by itself, or multiple of them can be combined to form dAPIs. This relates to the core technical team in that the Beacons and the Beacon-based dAPI architecture is our design. In other words, similar to what has happened with the authoritative DAO, the core technical team has claimed dAPI (and Beacon) development and operations, despite them not being a part of our responsibilities according to our most recent proposal.

The core technical team is responsible for building a scalable infrastructure, which increases the leverage of the ecosystem participants. Developing ecosystems commonly don’t have participants that can utilize the available tools to their full potential. A common pitfall here is for the core technical team to go in and show ’em how it’s done. This is done by choosing a few, large enough clients and bending over backwards for them. This will result in some short-term success and mutual backslapping, but it ends up poisoning the project because:

These observations delayed us from participating in dAPI development, noting that building Beacons or dAPIs wouldn’t have been enough, they would also need to be actively operated, which would take up a considerable amount of time that we could spend developing the node and the protocol (which can be used for much more than Beacons and dAPIs). That being said, we are indeed the best people available to operate these services reliably. We have a two-fold solution to this:

In summary, the core technical team has taken over development and technical operation of Beacons, and dAPIs by implication. This work will be carefully balanced with infrastructure development to uphold the long-term interests of API3. From a general point of view, the core technical team is on track with building the deliverables from the whitepaper in the stated three years (of which one has passed) without requiring outside help (assuming that our proposals pass). We are still carefully optimistic about external dAPI operation teams (meaning “external to the core technical team”), and will be designing and documenting the Beacon and dAPI operation process in a way to make that feasible.

Thanks for reading our report, Happy Holidays and best wishes for the New Year for the API3 community!



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store