Discover more from Bankless Publishing
The Oracle Edition | DeFi Download
Oracles and DeFi; Pricing Mechanisms; Maker OSM; Chainlink; API3; UMA
Dear Bankless Nation 🏴,
In this edition of the DeFi Download we dig into another crypto-primitive: Oracles. Oracles allow blockchains to communicate with the off-chain world. This could mean communicating with other chains or with traditional institutions.
Blockchains revolutionized the concept of trust by allowing a network of computers arrive at an agreed upon truth, and any information outside of that consensus mechanism is by default suspect. But a blockchain that only interacts with itself is boring. Oracles allow the outside world to communicate information on chain. They can tell us the price of assets or the results of sporting events.
If blockchains are going to be a part of the world, the world has to be a part of the blockchain. Buckle up.
This is the DeFi Download ⚡️
The Oracle Edition
Oracles and DeFi
From the days of Socrates in the legendary town of Delphi to the era of blockchains and your unhealthy price prediction habits, oracles have played a monumental role in transferring information from one realm to another. Modern oracles, unlike their ancient Greek predecessors, aim to send information from the off-chain world to the blockchain, or vice versa. This technology can then be used in DeFi to enhance automated market makers (AMMs) and lending protocols alike. I am going to explore these use cases, as well as the caveats they face.
To help visualize the use of oracles in AMMs in its simplest (and sometimes more controversial) form, we can take a look at prediction markets. Users bet on an outcome (which can vary from real world events like "Will Kanye West be elected as president in 2024?" to market predictions like "Will Ether be below $1k on February 15, 2023?"), and when the set time or event occurs an oracle relays the results and the money is distributed to the winners. All it has to do is send information to a smart contract, and that information determines which outcome receives the profit.
Two problems may be caused by the oracles in this case. Centralized oracles are faster and more efficient, but require trust in the operators. Nobody can falsely change the data except for the entity in charge. Decentralized oracles are open and trustless, but are more easily manipulated by bad actors. This can be fixed by using more secure protocols that involve parties without a direct involvement in the information being relayed.
A real life example is Uma's optimistic oracle being used in a particular betting market (Polymarket, in case it's relevant). It's decentralized, and false information can be disputed before hitting the blockchain. This is done by Uma DAO members who do not have assets in the related markets.
Decentralized exchanges (DEXs) have a more complicated relationship with oracles. While sharing the aforementioned caveats with decentralized vs centralized oracles, they raise the question whether these sources of information are needed. Constant product AMMs exist without oracles and price changes happen independently of external markets. Liquidity providers (LPs) pool their assets, and the rate of the trade moves accordingly. Liquidity providers run the risk of impermanent loss (the assets change in value disproportionate to each other. For example, if a liquidity pool has 100 ETH and 100 000 DAI, a sale of 25 ETH would greatly impact the price and leave the pool with 125 ETH and significantly less DAI). So, these DEXs are constantly exposed to arbitrage. High-volume trades are also subject to slippage (the sale of the asset drops the price while the order is being executed, giving the trader a worse rate than expected). Oracles can be used to mitigate these risks in different ways.
Dynamic Automated Market Makers (dAMMs) use oracles to change the weight of each pooled asset to stay at a 50/50 proportion. In the ETH to DAI example used previously, if ETH went up in value the dAMM would automatically sell enough to keep the pool balanced. This is more capital efficient and decreases permanent loss.
Virtual Automated Market Makers (vAMMs) depend on oracles to inform its tokenized derivatives. Users input collateral to receive leveraged virtual assets, and price feeds from oracles help these assets move according to their originals. This squashes impermanent loss and price impact, but the risks are still high. Trading with leverage is only for the bravest (or stupidest) investors and has eliminated a depressing amount of capital. If the price moves against you, your collateral will be liquidated.
Proactive Market Makers (PMMs) aim to mimic human-style order books and keep adaptable liquidity pools. Oracles are used to stabilize the pools and help them adapt to market conditions, and the price information provided is what helps maintain the order book feel. Again this reduces impermanent loss and slippage, but similar to the previous two AMMs, the old problems are replaced with oracle manipulation risks.
A common oracle used for these cases in Chainlink, which is decentralized and pulls its information from a collection of high-quality sources. It is able to pull price information directly from centralized exchange APIs and combines it, making the information extremely difficult to falsify.
Lending protocols are another essential service in decentralized finance that use oracles by using them to determine whether a debt position is subject to liquidation. The lending market determines the price of collateral compared to the price of the loan, and if the ratio falls below a certain threshold, the position qualifies for liquidation
Let's pretend ETH is $1000 again. Imagine you use 20 ETH (20,000 USD) as collateral to take out a loan of 15 000 DAI. The loan is over-collateralized with a liquidation threshold of 85%. If ETH decreases in value to 882.35 USD your collateral would be worth $17,647 and you would be subject to liquidation. But how does Maker determine the price of ETH? Oracles.
Using an oracle can help avoid bad debt and keep the lending protocol solvent. Information could be gathered to dictate what the maximum loan should be, accounting for the possible market impact it might have. Additionally, it could calculate a heavier interest rate for higher interest loans, ensuring that there is always incentive to liquidate debt before it turns sour and loses its financial incentive. Integrity of the user can also be checked, evaluating their previous liquidation rates and financial health and analysis of the lenders.
Other than the previously mentioned oracle risks, this solution can be bypassed if large loans are scattered into many small loans. The oracle would have to somehow account for separate loans that may get liquidated at the same time to create a larger market impact.
Decentralized Finance is the future of money, and AMMs and lending protocols play a large part in that. The use of oracles further develops those services to be safer, stronger, and more robust. Knowledge is power, and oracles can provide it in a trustless, decentralized manner. Sage advice is written in Delphi. "Know Thyself". Our modern-day counterparts have an equally wise message. "Know Thy Markets".
Author: Jake and Stake
Time Weighted Average Price (TWAP) Oracles
TWAP is a pricing algorithm used to calculate the average price of an asset over a specific period of time. Typically, these prices are created using on-chain data. Prices are collected over this period of time and averaged to create a final price result.
For example, suppose we want to determine the price of an asset using TWAP. If we choose 1 minute intervals over the course of 60 minutes. We can calculate the price using the following equation:
However, in order to construct such a pricing mechanism, we need to use a price feed to get samples. Such a TWAP oracle feed can be constructed using prices provided by Uniswap’s constant product pricing function, offering a cumulative price that can be used to calculate a TWAP of any time interval.
To get the TWAP, users can calculate the difference between the two prices and time elapsed between them.
TWAP is simple to calculate, but there are fundamental tradeoffs between price accuracy and security. Because TWAP oracles use price history to calculate the current price, the accuracy of the price decreases during periods of high volatility.
Long periods: Hard to manipulate; Inaccurate during high volatility. TWAP is a lagging indicator of price because it takes previous prices to calculate the current price.
Short periods: Accurate during high volatility; but easy to manipulate.
However, this oracle would only represent prices and liquidity on Uniswap.
Volume Weighted Average Price (VWAP) Oracles
To get a more generalized price, developers should integrate activity on other markets as well. This will defend the integrity of the price from manipulation of TWAP oracles because the increased liquidity of the source’s assets makes the feed more expensive to attack.
VWAP oracles are similar to TWAP oracles, but they also integrate price data from a variety of liquidity pools. Then the oracle mechanism normalizes the price differences using each market’s trading volume. Many designs use median price in order to avoid the impact of outliers, which may be the result of an attack or error.
As a result, VWAP oracles take a wider view of price action and reduce the impact of price manipulation on specific markets.
The formula for calculating a VWAP is:
vi is the volume of a market
pi is the price of the asset in that market
n is the total number of markets.
VWAP feeds can integrate several data sources to increase accuracy and security. The calculation of the broader market reduces the effectiveness of a flashloan attack.
As an example, assume we’re tracking the price of some asset using the same conditions as above (60 minute period; 1 minute intervals). Instead of using only Uniswap to calculate prices, we could also integrate prices from Coinbase, Binance, Kraken, and Gemini. An attacker would need the liquidity and timing to affect all 5 markets in a coordinated manner in order to take advantage of some exploit.
TL;DR it’s much harder to impact the price of an asset on multiple markets than just one.
Maker Oracle Security Module (OSM)
To really understand the Maker Oracle Security Module, one must be familiar with these 4 questions:
What is an oracle module?
What is it composed of?
How does it work?
How does it affect the security of this space?
Here we answer those questions using the Maker protocol as an example, and how its oracle implementation has served MakerDAO so far.
What is an oracle module?
An oracle module is a component of the Maker protocol which makes price data for various assets available on-chain in order to calculate important metrics, such as the collateralization ratio in a Maker vault. Maker’s oracle derived data is drawn from several feeds by individual participants elected by DAO governance, and the price of each collateral is determined by the medianizer contract as the median price of those feeds.
The Oracle Security Module (OSM) is in charge of updating collateral prices on a regular basis, which the Maker Protocol then uses. It acts as a safety net for the prices that enter the Maker system, protecting vault users from flash crashes and short-term market volatility, as well as compromised price feeds.
Yeah, you've seen the word 'vault' a number of times, right?
What is a vault?
Each collateral type approved by MakerDAO governance for use in the protocol has at least one corresponding vault. Collateralized ETH can be used in two different kinds of vaults, one with a higher, and one with a lower, collateralization ratio; 170% and 130% respectively.
What does this mean if we have 10 ETH for collateral at a price of $1,500 USD and have $7,500 USD of DAI borrowed? Our vault with the higher ratio would be liquidated if ETH fell below $1,275 USD, and the vault with the lower ratio at $975 USD.
In early 2020 the ETH price oracle failed to update correctly causing the incident now remembered as ‘Black Thursday’.
What is it composed of?
The Oracle Module has 2 core components consisting of the Median and OSM contracts. To understand these contracts, it is better to get a bit acclimatized with some details of these contracts, most especially, the OSM contract.
peek() : returns the current feed value and a boolean indicating whether it is valid
peep() : returns the next feed value (i.e. the one that will become the current value upon the next poke() call), and a boolean indicating whether it is valid
read() : returns the current feed value; reverts if it was not set by some valid mechanism
poke() : updates the current feed value and reads the next one
The median is a reference price that Maker uses to determine how much a given token can be worth. It uses a whitelist of authorized price feed contracts, which are able to send updates about the price of cryptocurrencies. Every time a new list of prices is received, the median of these is computed and used to update the stored value. The median has permissioning logic, controlled via governance, enabling the addition and removal of whitelisted price feed addresses. Governance can set other parameters—for example, the bar parameter is the minimum number of prices necessary to accept a new median value. This smart-contract type is known as 'The medianizer'.
The Oracle Security Module (OSM) ensures that new price values propagated from the Oracles are not taken up by the system until a specified delay has passed. Values are read from a designated DSValue contract. This delay is used as a mechanism to allow the module to detect and react to any oracle attack. “An OSM contract can only read from a single price feed” so it cannot be used for price feeds for different collateral types at once.
How does it work?
The OSM works by delaying any price updates it receives from the Medianizer by one hour before publishing them as ‘The current price’. This means that Vault owners have one hour to react to any price changes, as well as Maker Governance, if they believe the price being passed to the OSM is incorrect (i.e. due to an exploit or co-ordination of price feeds giving false price information).
How does it affect the security of Maker protocol?
It is quite a surprise that the OSM is quite susceptible to malicious attacks. In the Maker Protocol, if the reference price for an asset was determined by a single party, then they could fraudulently report an incorrect price and cause severe issues. For instance, if the price of ETH was reported to be fraudulently low, say $0.01, then every single ETH Vault in the system would be Liquidated. On the other hand, if the price of ETH was reported to be artificially high, say $1,000,000.00, then any ETH Vault owner would be able to issue an excessive amount of Dai since the system thinks there is more Collateral value than there actually is. Oracle attacks can be very profitable for a successful attacker and can be very disruptive to MakerDAO and its users.
On the brighter side, the Maker Oracle security module is quite resistant to attacks.
The Oracle security module resistance to attacks is due to the existence of the feed whitelist, it's not simple to become a feed. They (the feeds) need to be approved by MKR governance, therefore an attacker cannot gain a majority influence by creating many pseudo-feeds.
Conclusively, the Maker OSM is a good step in the right direction for oracle security and the DeFi space as a whole. Taking a queue from the Maker protocol, other protocols can work on the systems even more, and bring DeFi to another level of security.
We keep our fingers crossed as things unfold.
Beyond Blockchain's Boundaries: An Overview of Chainlink's Decentralized Products
Have you ever wondered how we receive prices for our crypto assets? What about the floor prices of your favorite digital collectibles? Or how about those NFT plants that somehow knew it was spring in the northern hemisphere and blossomed alongside your real-life houseplants?
Due to the seamless nature of how we receive information during our interactions on decentralized applications (dapps), it can be easy to forget that not all data comes from the blockchain. Blockchains are inherently isolated, lacking the functionality to send and retrieve data to and from external systems. Smart contracts today can securely and reliably perform tasks such as aggregating and reflecting asset prices for DeFi or automatically executing parametric insurance policies based on weather data. However, before blockchain oracles, smart contracts were isolated from external systems and other blockchain environments, creating limitations to the potential of smart contracts.
Blockchain oracles connect the blockchain to external systems, enabling smart contracts to execute based on inputs and outputs from real-world data. But using a single or centralized oracle negates the advantages of decentralization and could open the door to a single point of failure by a potentially corrupted oracle. A single oracle failure could feed data discrepancies onto an immutable blockchain, leading to inaccurate transactions and irreversible damage. Alternatively, Chainlink's decentralized oracle network brings together independent oracle node operators and several trustworthy data sources to establish decentralization at each layer.
What is Chainlink?
Chainlink is a blockchain-agnostic, heterogeneous, decentralized oracle network (DONs) that enables the communication of off-chain and on-chain data. One of the critical features of Chainlink is its use of these oracles because they are a decentralized network of independent nodes that collect and validate external data, then deliver it on-chain to the smart contract. Decentralization ensures tamper-proof and accurate data delivery onto the smart contract, eliminating the potential for a single point of failure.
This very interconnectedness gives rise to hybrid smart contracts, which are smart contracts that synchronize the mechanism of on-chain code with off-chain data and computation. Hybrid smart contracts enable trustless economic and social coordination while utilizing secure off-chain oracle services to achieve additional features like scalability, privacy, fairness, and connection to any real-world data system. DONs are composed of different types of oracles to accommodate the vast range of information from off-chain sources and the diverse needs of hybrid smart contracts.
Input Oracles: Fetches data from off-chain resources and brings it on-chain for a smart contract. You may have experienced this the last time you checked the price of ETH.
Output Oracles: Instead of fetching off-chain data, output oracles deliver on-chain commands from smart contracts to off-chain systems to trigger an action. An example is when an event occurring on-chain transmits an inventory update to a warehouse or automatically initiates a real-world item shipment once an NFT is minted.
Cross-Chain Oracles: Enables interoperability between different blockchain and layer 2 (L2) environments. Cross-chain oracles can translate information allowing for cross-chain communication and asset bridging across various ecosystems.
Computational Oracles: Facilitates secure data computation to take place outside of the blockchain. Oracles can perform trust-minimized off-chain calculations such as smart contract automation to execute a hybrid smart contract when predetermined parameters are met, verifiable randomness to provide a cryptographically verified fair randomness to smart contracts, and computing zero-knowledge proofs to secure private information on-chain.
Heterogeneous Decentralized Oracle Network
These different types of oracles all makeup Chainlink's heterogeneous decentralized network design. A heterogeneous model allows for networks to operate independently and without cross-dependencies, as opposed to a monolithic oracle network which forces nodes within an oracle network to support all services. Node operators can specialize in an oracle service by only acquiring access to the external data required by the specific oracle network they participate in. A heterogeneous ecosystem allows for the possibility, and flexibility, of building customizable oracle networks to support the particular needs of every smart contract.
When dealing with a decentralized ecosystem, it's crucial to implement a mechanism to incentivize a reputable, accurate, and honest environment. The generalized DONs framework solves the centralized oracle issue, but how can we trust the integrity of the many independent node operators? In the case of Chainlink, independent node operators are paid and rewarded with LINK, Chainlink's native ERC677 token, for providing reliable off-chain data. The ERC677 token standard builds on the capabilities of the ERC20 token standard, adding the ability to support token transfers and contract execution in a single transaction.
In December 2022, Chainlink introduced a staking mechanism, similar to proof-of-stake blockchains, that would enable node operators and community members to stake LINK as a form of assurance regarding oracle performance. Staked LINK and accumulated rewards are locked until the next staking release in 9-12 months. The intention of introducing staking as part of Chainlink Economics 2.0 is to generate community participation and sustainable rewards while also bringing on a new layer of crypto-economic security. As the reliability and security of nodes reach peak consistency, a long-term goal of the staking approach is to eventually introduce a reputation framework by delivering high-value jobs to node operators with significant LINK staked on the network.
Revamping Chainlink's Economics
Recently, Chainlink announced a new economic model that would enhance value capture and encourage the utilization and proliferation of decentralized services across the entire web3 ecosystem. A segment of this initiative is the staking mechanism, in addition to the BUILD and SCALE programs.
The BUILD program intends to provide early-stage projects with support and priority access to Chainlink's products, in exchange for a pledge of a portion of the project's total token supply. Meanwhile, the SCALE program, an acronym for Sustainable Chainlink Access for Layer 1 and 2 Enablement, aims to accelerate the growth of blockchains and layer 2s by providing specialized oracle services, such as smart contract-specific needs, in return for covering the operating costs of oracle networks, which are currently being supplemented by oracle rewards. The intention for covering operating costs is to free up oracle rewards, analogous to block rewards for validators and miners, that are distributed to node operators in addition to user fees. Ultimately, freeing up oracle rewards would allow the redistribution of these resources towards additional Chainlink initiatives.
Chainlink's Suite of Products and Services
Chainlink's generalized framework is uniquely positioned to empower the next wave of decentralized applications and hybrid smart contract innovation by enabling significant collaboration between real-world knowledge and the trustless landscape of on-chain processes.
Chainlink expands the possibilities of blockchain by leveraging its features to operate as middleware or an abstraction layer, securely connecting real-world data living on enterprise systems onto any blockchain or layer 2. By providing enterprises with the ability to push their data onto the blockchain, smart contracts can tap into a reputable data source while promoting the wide adoption of the web3 economy.
Off-Chain Computation and Reporting
Not every step has to be done on the blockchain, so why contribute to on-chain congestion when certain functions can be completed in a secure off-chain environment? Similar to how layer 2s offload computation work, decentralized oracle networks can provide a trust-minimized form of off-chain computation, or computations occurring outside of the blockchain.
Off-chain computation contributes to the functionality of Chainlink's verifiable randomness (VRF) and smart contract automation. Additionally, off-chain reporting (OCR), which powers the Chainlink Data Feed, can aggregate external data off-chain and provide a single oracle report to be verified on-chain. The OCR protocol uses a secure P2P network, where multiple nodes submit their external data findings and sign off on the report, aggregating them into a single aggregate transaction. A single node then sends the aggregate transaction on-chain, where the signatures are verified and validated on the immutable blockchain—streamlining results in a cost and time-effective method, opening the possibility for greater scalability of oracle networks.
Taking trustlessness to another level, we must remove the manual component and introduce automation. Automation enables hybrid smart contracts to execute automatically when predefined external parameters are met. Smart contracts are not inherently auto-executing, requiring an on-chain input to initiate the contract. Automation can occur based on two triggers: time-based and custom logic. With access to off-chain data and off-chain computation, automation of hybrid smart contracts opens the doors to a vast range of applications, from dynamic NFTs to automatically settling transactions after a predefined event occurs.
Verifiable Random Function
Ensuring fairness used to incur some subjectivity, but that's not the case when fairness is randomly generated and cryptographically verified as random. Verifiable random functions (VRFs) compute a series of inputs and generate a random output along with a published and verified proof on-chain. By removing human error, Chainlink VRF offers tamper-proof unpredictability that can be utilized across gaming, NFTs, and most importantly zero-knowledge proofs.
Chainlink Data Feeds are widely relied upon in DeFi and cover a wide range of capabilities such as Price Feeds, Proof of Reserve feeds, L2 Sequencer Uptime Feeds, and NFT Floor Pricing Feeds. Data feeds function to retrieve the latest prices and data points of assets for hybrid smart contracts.
Chainlink Price Feeds are on-chain reference contracts that are updated automatically by oracle networks. Reference contracts store the price of an asset in the form of an exchange rate (e.g., ETH/USD), where smart contracts can ping on demand. To ensure high-quality and decentralized data, price feeds utilize off-chain reporting mechanisms and a multi-layered decentralized aggregation system at the data source, node, and oracle network levels. Additionally, data source providers use volume-weighted average price (VWAP) methodology to generate accurate and reliable market data.
Unbounded by limitations, Chainlink's decentralized oracle network enables access and connection to any real-world data source via API. Nodes can readily connect to open-source APIs, whereas specialized or private APIs require external adapters. Providing the ability to push and pull data from any API facilitates interoperability between on-chain and off-chain applications.
Cross-Chain Interoperability Protocol (CCIP)
Blockchains are limited to their native environment and unable to communicate with other chains outside their ecosystem. This brings about limitations in how users can interact across different blockchains, consequently creating disparate, isolated economies. Although some connectivity between chains exists today, such as token bridging, to create a robust web3 economy, interoperability between chains needs to be seamless and universal. Chainlink CCIP aims to create global connectivity between diverse chains with a single standardized interface. A universal interface enables communication with any Chainlink-integrated blockchain across Ethereum virtual machine (EVM) and non-EVM chains.
Since its launch, Chainlink has contributed to the growth and innovation of DeFi, NFTs, insurance, and supply chain management. As more traditional institutions begin to explore the opportunities of web3, a framework such as Chainlink could provide a seamless method for institutions to dip their toes into the blockchain. The possibilities are endless for web3, but one thing that will stay the same is the need to bridge interconnectedness across all facets of life.
API3 is focused on first-party oracle solutions which may be able to offer several benefits over third-party oracle networks. The benefits include data-source transparency, security, and efficiency.
API3 provides traditional API services to smart contract platforms, using a trust-minimized approach. It attempts to get past the middleman by allowing data providers such as stock exchanges to operate “airnodes” which run on the same cloud hosting platform that hosts their API. Instead of having to aggregate data through an intermediary, the data collector directly operates as an oracle for the chain.
Staking and API3 DAO
API3 token may be staked in the staking pool, used to provide insurance for the staking pool, and used to get governance rights in the API3 DAO. All stakeholders are able to use the DAO to participate directly in the governance of the project. To gain voting power in the API3 DAO, token holders may increase the amount of tokens they have staked.
Proposals can be created by holders with at least 0.1% of staked tokens. Votes can be casted on matters such as grant proposals, staking incentives, and determining the best service providers to provide data aggregation services.
Stakers may earn commission when decentralized applications pay subscription fees to use API3 data services. This incentivizes effective management of the API sources.
The funds staked are used in an insurance pool that compensates smart contract users if a malfunction occurs. In return for staking, stakers receive protocol rewards. Insurance claims can be made by decentralized applications from the staking pool if the API data is not correct. The staked quantity is used to bear the burden of the cost for the claim.
API3’s DAO can also be used to manage payment for data streams, manage dispute resolution to protect data consumers, and increase data sources. The DAO prioritizes the integration of top quality data providers. Disputes over the data may be managed in Kleros Court which helps to mitigate risks using on-chain alternative dispute resolution.
The API3 DAO is designed to help to construct new data feeds in an open process which uses proposals. Each data feed implementation is to be preceded with a proposal. Insights on API providers, data filtering, and data aggregation methods will be gained through the DAO which crowdsources for such information.
DAOv1, Smart Contracts, and Airnode
In the early stage of its DAO operations, the project began using DAOv1, which is based on Aragon with voting power hardcoded into it by founding members. The token-based governance is based on time locked tokens held by holders with voting power. This gives more incentives for voting power holders to carry out actions that uphold the long-term success of the project.
Following this, a new implementation was to be rolled out with a more complete “authoritative DAO” that existed alongside DAOv1 during the migration process as a subordinate to the new DAO.
API3 learned many lessons from its use of DAOv1, including the benefits of using fractal structures. Sharding the DAO can help to improve DAO scalability. The API3 team used a flatter approach in their first operations cycle but later changed to a team-based structure that allows teams with budgets to take more ownership over how they use funds (depending on proposal approvals) and report on their progress in running the operations that contribute to the common goal of solving the API connectivity problem.
Authorizer smart contracts were developed by API3. API3Authorizer.sol is designed to allow for an Airnode to be accessible without any API provider interaction. API3 partners would be able to use the native tokens to execute the contract. SelfAuthorizor.sol enables the API provider to whitelist users themselves based on a criteria of their choosing. The Authorizers can be used with a decentralized application to enable API providers to do this.
Development began on ChainAPI to allow API providers to set up first-party oracles easily and for airnodes to be deployed. It provides an interface for API3 employees to execute integrations for the API providers.
Airnode is not typically considered as a node. Rather, it is a collection of simple, single-purposed functions that link together to provide the functionalities of Airnode. A main “coordinator” function executes every minute, serving as the focal point of the system, causing other “worker” functions to be initiated.
By default, Airnode does not have hard dependencies. This means it does not have cache, a web server, or a database. This is based on the team’s view that dependencies can give rise to points of failure, attack vectors, additional costs, and other complexities.
API3 prioritizes connectivity through APIs that negate the need to rely on third-party intermediaries. By connecting to API3’s serverless nodes (Airnodes) data providers may connect their data directly to smart contracts, feeding their data directly to decentralized applications without the extra costs of integration.
Airnodes can easily be integrated using existing technologies without the need for dedicated blockchain development resources. The nodes also have the potential to increase transparency for users of decentralized APIs while doing away with Sybil attack vectors.
Airnode provides an open-source solution that is middleman-free and easy to use. Its first-party design helps it to comply with Europe’s strict GDPR requirements. First-party oracles are operated by the API providers themselves, in contrast to third-party oracles which are not operated by the owners who are served the data.
First-party oracles help to leverage the off-chain reputation of the API provider. This means that the trustworthiness of API providers is based on their reputation and success in the off-chain business world, even if staking is not carried out.
Oracle Extractable Value
OEV (Oracle Exctractable Value) describes how oracles capture value that would have gone to third parties, if not for the oracles using their position to take advantage of the value capture opportunity.
OEV with API3 could make oracles more financially viable. They could allow for more value to be captured and retain MEV (Maximal Extractable Value).
The additional fees paid by users of decentralized applications to miners is known as MEV. It represents the maximum amount of value taken by block producers in excess of standard block reward and gas fees. Thanks to arbitrage and liquidation fees, millions in MEV can be made by block producers. This is great news for those that benefit from gas wars and the like, but not so great news for users of decentralized applications.
API3’s OEV-enabled oracles are designed to remove the need for paying third parties and block producers for blockspace in auctions. With OEV-enabled oracles, auctions can be taken off-chain so that third-party searchers can be given rights to extract on-chain value without affecting gas prices. The proceeds can be redirected to decentralized applications, helping to retain more value for platforms.
As an example, a user with a position that can be liquidated when the data feed value hits 1000 (while the price of the cryptocurrency they purchased is increasing) typically precedes a race between third parties to liquidate the user and make rewards. Before this occurs, the oracle waits until APIs return the new value. OEV oracles on the other hand, update for the reward to be claimed as soon as the underlying APIs get the value of the user’s asset and the user gets liquidated in the same transaction.
Tokenomics and Revenue
Revenue from the API3 DAO will be burned. Pairing this with the floating inflation rate could help to align the incentives for the governing parties through a smoother staking and reward process.
API3 transitioned from a predetermined inflation schedule to setting a target staked amount through which inflationary rewards would be paid out to stakers. The inflationary rewards paid would float to meet the target.
The staking rewards become withdrawable after 1 year. This provides an incentive for stakers to meet their governance responsibilities. By making these rewards withdrawable after 1 year, the stakers are incentivized to fulfill their governance responsibilities to the best of their abilities.
Token distribution for API3, based on its public distribution event, is as follows:
25 million tokens for the ecosystem fund
10 million tokens for partners and contributors
30 million tokens for the founding team
20 million tokens for public distribution
10 million tokens for seed investors
5 million tokens for pre-seed investors
API3 sets itself apart from other oracle providers with a combination of approaches. From the API3 token, to its large association of Web 3 API providers, its DAO, and its Airnode technology, structures have been positioned to move the industry away from third-party oracle networks to first-party oracle solutions.
We can’t forget, however, that a full working product has not been developed. It may take a while to witness just how effective the architecture of API3 is in pushing the oracle space forward.
An Optimistic Oracle
Author: Austin Foss
Just as bridges were a common point of attack in DeFi—and cryptocurrencies broadly—in 2022, oracles were the same for 2020. Among the various price feed oracles popping up in the early days of DeFi, the UMA Project proposed their own oracle design as a solution to the problem of securely and trustlessly, bringing off-chain data on-chain; the optimistic oracle (OO).
In November 2018, a trademark application was filed by Risk Labs for the name "UMA", referred to hereafter as Uma to avoid confusion with the UMA token. Almost a year later Uma launched their first product, a Synthetic Token Builder, on the Ethereum test network, and a few months later, in May 2020, "UMA Project Creates Its First Synthetic Coin, Matching ETH Against BTC".
What is Uma's Optimistic Oracle?
From the project's documentation, Uma's OO is described as “a generalized escalation game...". How this differs from usual oracle designs where off-chain information is validated by a consensus of nodes, as with Chainlink, is that the data is assumed to be valid unless disputed; hence this oracle being optimistic.
Off-chain data is first requested by a "requester" who offers a reward in exchange for the correct information. A proposer can then propose their answer, but in order to do so they must post a "proposal bond." If the proposer is incorrect they lose their bond. This ratio between the value of the reward and the value of the bond is important because, in order to make manipulating the oracle uneconomical, the value of the reward must be greater than the value they might gain from such manipulation minus the value of their lost bond.
Disputers may dispute proposed answers to a request, but they too must post a bond in order to do so, escalating the request to the next level. In the case of a dispute, the request in question is raised to the Data Verification Mechanism (DVM).
When this happens a vote is held among UMA token holders to resolve the dispute and arrive at the correct answer within 48 to 96 hours. This process assumes and incentivizes honest behavior while making an attack on the protocol uneconomical for malicious actors.
When the project launched, Risk Labs created a starting point of 100 million UMA.
2% - 2 million deposited to Uniswap
35% - 35 million to developers and UMA community
15% - 15 million to investors
33.5% - 33.5 million to Risk Labs and early contributors
14.5% - 14.5 million to future token sales
To incentivize participation in the protocol UMA was designed to be slightly inflationary as long as the DVM is in use. For every dispute, voters who elect the winning answer are rewarded with a 0.05% total supply increase divided among those voters by stake. Currently, UMA has a total supply of more than 112.5 million, having inflated about 12.5% since launch.
According to the Uma Project's Duna Analytics Dashboard, there has been an average of about 60 individual addresses and about an average value of 20 million UMA.
Uma's first use case for their OO was to create a synthetic asset, but its utility doesn't stop there.
In last week's issue of the DeFi Download we talked about bridges, the other big security concern in DeFi alongside oracles, and absent from the list was Across; a bridge built using Uma's OO.
According to L2Beat Across V2 currently sit at rank sixteen in terms of TVL for bridges at 36.65 million in USD.
Across manages to bridge optimistic L2 rollups to main-net, and between each other, without having to wait for the rollup to settle, which can take days, by using Uma's OO.
Polymarket is a prediction market on Polygon that, while it states it is oracle-agnostic, currently utilizes Uma's OO. By "using the Gnosis conditional token framework (CTF)" in combination with the OO, paired with a contract that can communicate Uma's answer to the CTF, resolving the condition and settling the bet.
Everything from politics, pop culture, sports, and more, is, or could be, bet on using Uma.
In late December, 2022, the Uma Project announced UMA 2.0 with three milestones on their roadmap for 2023 and the intent to:
broaden voter participation, including by encouraging protocols and DAOs that use the oracle also have a stake in $UMA and vote. - Uma Project
UMA Token Staking
"...rewards will be streamed continuously..." instead of being paid out per vote.
Inflation be changed to reflect the above streaming method and be set to 0.18 UMA per second, managed by governance.
Unstaking cooldown of 7 days.
Simplified Oracle Interactions
Voting dapp 2.0 to support staking.
Requesters will also make a proposal when making their request.
"...encouraging protocols and DAOs that use the oracle also have a stake in $UMA and vote."
This upgrade was originally planned to launch in January but because of the results of their last audit, and pending the results of a follow up audit, it was announced in the project's Discord that Uma 2.0 would be delayed until the end of February.
Optimistic Outlook to the Future
It's a bit of an odd juxtaposition that a tool as useful, and vulnerable, in the blockchain ecosystem as an oracle has chosen to do the opposite of one of crypto's oldest tenants; 'don't trust, verify'.
By trusting first, being optimistic, and verifying later Uma's design of their OO has leveled up oracle efficiency and versatility. Uma version 2.0 is sure to oracle technology even further.
⛏️ Dig into Decentralized Oracle Networks (DONs) | ChainLinkGod
🎧 Listen Vitalik Buterin on Chainlink and hybrid smart contracts | Lex Clips
Project Releases 🎉
Hand-picked project updates to understand the current state of the DeFi ecosystem
OpenSea Launches on Arbitrum Nova
OpenSea has joined Arbitrum’s Data Availability Committee (DAC)
Arbitrum Nova is a chain dedicated to social applications and gaming
Coinbase Joins Rocket Pool’s oDAO
oDAO is a collection of oracle node operators
Oracle Node operators are responsible for relaying information from the ETH2 beacon chain to the ETH2 execution client
Verify rewards, penalties, and maintain the ratio of RETH-ETH
🔥 and 🧊 tweets from across the DeFi ecosystem
🛠 BANK Utility (BanklessDAO token)
With over 5,000 holders, BANK is one of the most widely held social tokens in crypto. So it bears asking, where are the best places to put our BANK to use? The five protocols below will allow you to deposit BANK in a liquidity pool and earn rewards. To get going, just click on the name, connect to the app, filter by BANK, and start earning passive income.
Balancer has two 80/20 liquidity pools, meaning that you are required to deposit 80% BANK and 20% ETH in the pool. There is one pool on Ethereum and another on Polygon. Once you’ve provided liquidity, you’ll receive LP tokens. Keep an eye out for opportunities to stake these LP tokens. There is nearly 500,000 USD in the two Balancer liquidity pools.
SushiSwap has a 50/50 BANK/ETH pool. As with Balancer, you will receive LP tokens, and while you can’t stake them on SushiSwap’s Onsen Farm yet, you may be able to in the future. Liquidity providers earn a .25% fee on all trades proportional to their pool share. The SushiSwap pool has a little over 100,000 USD in liquidity.
⏛ Rari Fuse Pool- Deprecated Soon
This will be deprecated soon. The Rari Fuse Pool allows you to borrow against your BANK or earn huge APY by providing assets like DAI to the pool. At present, all borrowing is paused for this pool. There is over 450,000 USD deposited in the Pool
The Uniswap V3 liquidity pool is 50/50 BANK/ETH, and provides a price oracle for the Rari Fuse Pool. By depositing in the Uniswap pool, you can earn fees and help enable borrowing on Rari. This pool currently has over 500,000 USD in liquidity.
You can also provide liquidity to the Arrakis Uniswap V3 pool. The ratio is about 2/1 BANK/ETH. This pool is new, and only has a bit more than $6,000 in liquidity. In the future, you may be able to stake your BANK/ETH LP tokens within the protocol to earn additional rewards.
Get Plugged In
Get a job in crypto! Do you like solving hard problems, care about building more efficient markets for everybody, and want to work at the frontier of decentralized finance? Rook is looking for full time contributors, with salaries ranging from $169,000-$722,000. There are positions ranging from engineering, recruiting, product marketing, copywriting, and design. Sound interesting? Sign up for our referral program and go full-time DAO.
DeFi Research Lead (Fully remote)
DeFi Bot Wrangler (Fully remote)
Blockchain Economist (Fully remote)
Head of Research (Fully remote)