API3ground - A testnet playground for API3 products

Ideas
#1

I’d like to create a playground environment for Airnode and API3 data feeds on testnets.

The API3 core tech team is (rightly) focused on production data feeds and only sets up Airnodes and data feeds on limited testnets. For example, QRNG is only on Ethereum’s testnets and data feeds are only on Polygon’s testnet. It’s also a nuisance for API providers to run first-party oracles on testnets because they can’t be monetized.

But protocols and dApps want to build on testnets for various reasons.

  • They want to get familiar with API3 products, learn, and build confidence before committing to using them.
  • They don’t want to spend money on gas during development.
  • They may need an API or feed for development that doesn’t exist yet on the mainnet where they intend to deploy.

Additionally, APIs and data feeds on testnets don’t have the same quality, reliability, or security requirements as on mainnets.

  • Devs understand that testnets are not for production and accept/expect some failures.
  • There is no real money at risk when they fail.
  • There is little/no reason they need to be first-party.

The API3 playground would be a set of third-party Airnodes, run by the marketing team and others who are interested in contributing, that make API3 products available on testnets so that developers on those chains can easily experiment and develop with API3 tech.

The priorities of the playground would contrast with and compliment API3 products on mainnets.

Mainnet Products Playground Products
Managed by the core tech team with quality in mind Managed by the marketing team with growth in mind
Reliability and security are top priorities Quick and easy access for developers on testnets
First-party oracles to minimize trust Third-party oracles so API providers don’t need to deal with testnets
Limited to reputable, proven API providers Able to experiment with other API providers
Requires redundant, dedicated RPC nodes Public testnet RPC nodes are acceptable
Expectation that APIs and feeds will remain in service APIs and feeds can be dropped without consequences
Ideal for production and late-stage testing Ideal for learning, experimentation, and development

In addition to the Airnodes and data feeds, the playground will have a website with features like

  • Lists the APIs and feeds available on testnets
  • Helps teach developers how to use them
  • Allows users to make API requests and see the responses

There would be a soft goal, but with no promises, to mirror production dAPIs on the playground and to support testnets for any chain that we support its mainnet.

[WPR] Marketing - Ryan - July 9th
#2

Think there is a slight misconception when it comes to “usually doesn’t have time to facilitate setting up Airnodes or data feeds on testnets”.

All Beacons/dAPIs (no matter on which network) will be replicated on Polygon Mumbai.
We’ve decided to only do Mumbai because of several factors:

  1. It’s an EVM testnet, so there is pratically no difference (except for block times etc) between testing on e.g. Rinkeby or Mumbai.
  2. Sponsor wallets need to be topped up and monitored, otherwise these feeds will stop working. Most Testnet faucets are a living nightmare in the sense that they are down for several weeks and/or only give you an arbitrary amount of tokens that are sufficient to play around a little but don’t really allow to replicate all the feeds onto testnets. We don’t have this issue with Polygon because we’re close with them and they send us a sh*tload of tokens whenever we ask for it.
  3. Self-serve whitelisting: This repo allows people to whitelist themselves on any data feed (dAPI or Beacon/BeaconSet) that we have on Polygon Mumbai. It would also need to be replicated, which adds additional steps/workload.

All of those steps made us come to the conclusion that setting up permanent testnet datafeeds on other chains than Polygon Mumbai is an unnecessary overhead.
Of couse it makes sense for a short timeframe for e.g. a hackathon or something alike, but it doesn’t really justify the operational overhead in any other times.

#3

Good point. I didn’t mean it as a criticism. I updated that part to:

The API3 core tech team is (rightly) focused on production data feeds and only sets up Airnodes and data feeds on limited testnets. For example, QRNG is only on Ethereum’s testnets and data feeds are only on Polygon’s testnet.

From a growth perspective, people building on one chain don’t want to develop/test on another chain’s testnet just because of API3. Also, the blockchains themselves who are working hard to promote their own ecosystems and provide a good developer experience don’t want to tell their developers to go test on another chain’s testnet.

For the playground I would probably look for ways to avoid access control all together, if possible, instead of replicating the whitelisting contract. The goal would be minimal friction to getting started.

I understand there would be difficulties with monitoring and refilling sponsor wallets. We would have to find a solution on a chain by chain basis. I suspect we could even get the chains themselves to help with that because they want our products on their testnets.

For hackathons, I would still prefer the core tech team to handle them when possible since those should be treated as a more mission critical situation.

I agree that it’s unnecessary overheard for the core tech team but it’s not for the marketing team team whose entire purpose is to facilitate growth and adoption.

#4

For the hackathon part I think it won’t be an issue in the future. Currently it’s just a little bit too much of an ask considering our timelines.

As for reading without authorisation, I’m pretty sure that would require changes to the contract, since it’s build with it in mind. On Polygon Mumbai we gave another contract the right to whitelist and that is callable by anyone, but there is no default setting that allows everybody to read. (At least that I’m aware of.)

I’m also aware that every chain obviously would love their own integrations including all of their testnets, but it’s simply not feasible for us at the moment since we’re rather focused on brining as many mainnets live as we can.

The ask is simply a marketing one (for both sides) since functionally, everything can be fully tested on polygon Mumbai without involving api3 in any way and followed up with a request to be whitelisted on their respective chains mainnet.

We chose the path of least resistance, which turned out to be polygon.

Altogether I also think the issue of this will be that API providers are not super keen on serving on every testnet possible.
We’d probably need to ask for a separate API key and spin up a different instance of Airnode if we consider serving 20+ chains and their 20+ testnets just to isolate the production feeds.
That’s increased cost on them and another api key in addition to the ones we’re already asking for.