Explore → dAPIs

SearchHighlight.vue

FLEX_START_TAG

What are dAPIs?

dAPIs are on-chain data feeds sourced from off-chain first-party oracles owned and operated by API providers themselves. Data feeds are continuously updated by first-party oracles using signed data. dApp owners can read the on-chain value of any dAPI in realtime.

dAPIs are composed of a beacon or a set of beacons and are sometimes referred to as first-party data feeds because they are sourced from first-party oracles. Therefore a beacon is directly powered and maintained on-chain by the owner of the data, the API provider, which effectively removes third-party middlemen that other oracle solutions rely on. This approach creates source transparency in addition to higher security, cost-efficiency, and scalability through less parties being involved in the oracle service operation.

dAPIs connect smart contracts to first-party data feeds

Through the use of the proxy contract function read(), API3 can associate the ID of a beacon or beacon set with a human-readable name like ETH/USD. The benefit of this approach is that dApps continue to read the same dAPI name without being required to make any changes to their code, effectively turning dAPIs into a turn-key data feed solution for smart contract developers.

At the core, a dAPI is a mapping that points towards a beacon or a beacon set, similarly to how an ENS name is mapped to a wallet address. The ability to control this mapping allows the API3 DAO to take over the management overhead that is associated with oracle infrastructure by e.g. creating a new beacon set if one first-party oracle becomes unavailable and pointing the name, e.g. AVAX/USD, towards the newly created ID.

What is a Beacon or a Beacon Set?

A beacon is a point of data that is kept alive on-chain by a respective first-party oracle. It corresponds to an ID which is derived from the hash of the Airnode address that is deployed by an API Provider, in combination with the request parameters. This resulting ID will always represent a specific provider with specific request parameters and cannot be changed.

Following the same principle, a beacon set is addressed by an ID, which is derived from the hash of multiple beacons. This allows for the creation of aggregations between multiple beacons. The resulting ID of a beacon set always represents the specific beacons that make it up and cannot be changed.

Values for beacons or beacon sets are kept up to date on-chain by many Airnodes which are owned by API providers, where they can be read using an API3 Market proxy contract.

dAPI: A standardized interface

dAPIs possess a range of distinct attributes:

• dAPIs have a standardized, user-friendly interface that intends to abstract away the technical implementation.
• A dApp uses the dAPI interface to access data feed services. These services exist in a fully permissionless or authorized format.
• dAPIs exist entirely on-chain managed by a central contract that manages a beacon store that is in turn updated by Airnodes.
• Through a dAPI smart contract, developers can access additional services such as Service Coverage or Oracle Extractable Value.

Read more

Dive into the design decisions about dAPIs by reading dAPIs: APIs for dApps.

Role of API3Server.sol

A dAPI points to an individual beacon or an aggregation of multiple beacons (beacon set). Each dAPI has a human-readable name (e.g., AVAX/USD) that makes them easy to categorize. The contract API3ServerV1.sol maintains the link between a dAPI name and the beacon(s) it uses for the dAPI. dApps use an API3 Market proxy contract to read any dAPI from API3ServerV1.sol.

dApp owners use a proxy contract, available on the API3 Market, to access a dAPI. Proxy contracts use the API3Server.sol contract to access dAPIs. Developers can easily set the proxy contract address in a dApp contract to start reading from the dAPIs.

The API3ServerV1.sol contract reads directly from its data store of beacons, which are powered by API provider-operated Airnodes. Thus proxies allow dAPIs to be used like libraries. The smart contract only needs to import the interface for calling the proxy contract.

This means once a dAPI is integrated to read a different data feed, the contract does not need to change the code itself, rather it only needs to use a different proxy address when calling the read() function on the proxy contract. If the dAPI interface has previously been imported, it abstracts away the technical implementation of accessing new data feeds.

Refer to these guides and learn how to fund a self-funded dAPI and to read the dAPI using a proxy contract:

• Subscribing to Self-Funded dAPIs
• Reading a Self-Funded dAPI Proxy

FLEX_END_TAG