#9 | Oracle Module

2023-03-17 · 4 min read

Historical context: This post describes early Sai work as of 2023-03-17. Product details and launch plans reflect that period. See the Sai documentation for current trading and integration guides.

Oracles are one of the fundamental building blocks of decentralized finance (DeFi), providing a secure and efficient means of bringing real-world data onto a given blockchain system for smart contract use.

By: Lachlan Todd, Multichain Media

At the same time, numerous oracle exploits in recent times have exemplified that not all oracle systems are built equally. Establishing the optimal oracle design is critical as DeFi continues to expand in both adoption and complexity, and we’ve solved this.

Nibiru’s Oracle Module provides a fast and reliable, next-generation oracle solution that builds upon past decentralized oracles. It aligns incentives between both validators and oracle nodes, addresses potential attack vectors present in other oracles, and is extremely fast and robust. The result is a cutting-edge oracle design that not only benefits users of Nibiru’s products (such as index pricing for Sai) but that the rest of the Cosmos ecosystem can comfortably rely on in turn.

Prior to this, we will provide a high-level overview of oracles and why they are important. We will then discuss challenges in designing them, as well as past exploits. Last of all, we will highlight existing price-feed oracle architectures that are widely available. This will make it clear why Nibiru’s Oracle Module is a cut above the rest.

TLDR:

Oracles must be fast and efficient, but this often comes at the expense of security.
The Nibiru Oracle Module aligns incentives between validators and oracle nodes. This increases the cost of attack while mitigating potential attack vectors such as data manipulation or front-running.
The Nibiru Oracle Module will serve as the backbone of index pricing on Sai, and serve other purposes such as accurate pricing for minting/redeeming of NUSD.
This oracle can greatly benefit validators who choose to become oracle nodes, protocols that elect to rely on the oracle, and users of the Nibiru ecosystem as a whole.

The Oracle Problem

Blockchain smart contracts require real-world information in order to execute code, as the information does not originate on the blockchain itself. Oracles enable this by transmitting data from real-world events, meaning that the integrity of their data provided is critical to the overall health of DeFi ecosystems. For example, the on-chain trading of financial instruments requires fast and accurate prices, while decentralized insurance requires knowledge of real-world events.

Broadly, oracle systems may be divided into two broad categories:

Centralized: A single entity uses a web API to provide information, creating a direct link between the data source and the smart contract. An example would include Oraclize.
Consensus-based: also known as decentralized oracles, these rely on cryptocurrency incentives to provide reliable responses in a trustless manner. Examples would include

Chainlink and MakerDAO.

Each approach has its advantages and disadvantages. Centralized oracles require less computational effort and gas fees but may be easier to manipulate and represent a single point of failure. In contrast, decentralized oracles are less efficient from a computation and gas standpoint but are much more in tune with the blockchain ethos of decentralization.

Navigating the Challenges of Building an Oracle System: High-Level Attacks and Historical Exploits

Both types are critical for blockchain ecosystems and any manipulation of an oracle’s data can have disastrous consequences. As such, they are often considered the weakest link of a project and are frequently subject to attacks by malicious parties. For example, in 2020 Compound Finance experienced an exploit causing $89M in liquidations, while more recently Mango Markets experienced an exploit of $112M. Many other examples exist, with victims including

Solend, QuickSwap, Deus Finance, Inverse Finance, and MakerDAO ($7M).

Attacks will only continue, and current oracle designs are insufficient. In order for DeFi to prosper and grow in both complexity and usage, the most secure and robust oracle architecture possible is needed.

Attack Type #1: Data Manipulation

Given that oracles provide information, they must first and foremost have a reliable source of data. One common method is relying on the pricing from decentralized exchanges (DEXs) such as Uniswap. However, it turns out that these are in fact capable of being subjected to price manipulation.

For example, a flash loan could be used to execute a large trade on a DEX, drastically affecting asset pricing. Protocols with oracles relying on that price would in turn be subject to exploitation, as attackers may use the newly inflated price of their assets to take out a large loan, and subsequently reverse their initial transaction on the DEX. Their loan’s underlying collateral would then drop in value and be liquidated, but their loan outweighs this loss.

This might look as follows:

A pool begins balanced with $40M of USDT and 36,000 ETH. A malicious party then swaps $10M of $USDT for 9,000 ETH. If liquidity is not sufficient on the DEX, this could lead to a significant change in USDT/ETH pricing.
Rather than ETH being priced fairly at $1,111 $USDT, it may now be priced as significantly higher because there is now much less ETH in the liquidity pool than prior.
On a separate DeFi borrowing platform that relies on DEX pricing, a malicious party takes out a large $USDT loan collateralized by their ETH.
The malicious party reverses their original trade, depositing 9,000 ETH in exchange for $10M of $USDT.
The collateral (ETH) on the lending platform falls in value and may trigger a liquidation, but the loan taken out on it is worth significantly more.

One method for mitigating the impact of quick price manipulations is through the implementation of Time Weighted Average Pricing (TWAP). For example, Uniswap V3 uses TWAP. This is effective, but in periods of volatility, it may not be sufficient as a rise or fall in an asset’s price may be warranted.

Attack Type #2: Sybil Attacks

Given that oracles are pseudonymous, it’s possible that a single party may replicate their vote in order to have higher voting power. An example would include a single entity controlling 20 different oracles, without others knowing. The Sybil refers to the entity controlling several oracles, and there are subcategories of this type of attack as well:

Mirroring attacks

: if a single party controls multiple oracles, they may decide to simply copy the data from one oracle onto the other oracles that they control. This lowers the cost of data collection and increases centralization.
Freeloading

: similar to a mirroring attack, an entity’s oracle may simply decide to replicate the data provided by an honest entity. Doing so would lower their cost of providing the data, increasing competitiveness and forcing honest oracles to lower their prices in turn. This may eventually push a certain percentage of the honest oracles out of play, with corrupt oracles replacing them.

Attack Type #3: Front Running

Due to oracles being the first to know critical data uploaded to the blockchain, this poses the risk of front-running. This may be conducted by an oracle provider, or by anyone who sees an opportunity to execute a profitable transaction. For example, in 2019 Terra Money experienced a front-running attack due to a discrepancy between their on-chain forex market and the global forex market.

Attack Type #4: Malfunctions

Oracles are software and as such may be susceptible to malfunctions. An infamous example stems from 2019 when the Synthetix derivatives protocol misreported the price of the Korean Won. This was due to an off-chain oracle misreporting the price to be 1000x the actual price, and given that Synthetix relied on the average pricing of only two off-chain oracles, the error was not corrected. Over $1B was arbitraged by a trading bot, but later returned in exchange for a bug bounty.

Recent Exploits of Derivatives Protocols

While we have highlighted certain historical oracle attacks above, derivatives protocols such as Nibiru have been targeted to a greater extent in recent months. Two significant examples include:

GMX: Liquidity providers on GMX receive GLP token, which is used to maintain zero-slippage on GMX. An attacker opened large positions (both short and long) on AVAX token, and then manipulated the price on centralized exchanges. The GMX price oracle relied on the price feeds of these external markets, causing the price to change as desired by the attacker. A series of quickly executed fluctuations in AVAX price resulted in $570K in profits, at the expense of GLP token holders.
Mango Markets: An attacker listed a large amount of MNGO token perpetual futures then used a separate account to purchase them all, inflating the price of MNGO tokens significantly due to slippage caused by a lack of liquidity. Account B was therefore sitting on a large unrealized profit which enabled them to take out a loan of $116M using collateral from the rest of the Mango Markets protocol. While the oracle technically operated as designed, this illustrated the challenges in properly designing an exchange that relies upon oracles.

The traditional derivatives market is estimated to be upwards of $700 trillion globally, and if DeFi is to grow and capture market share, then exploits like the above cannot continue. With more attacks to be expected in the future, this makes it clear that all possible attack vectors must be addressed. Designing an efficient oracle system will provide a significant advantage for protocols that elect to rely on it, ensuring both security and robustness.

Design of the Nibiru Oracle Module

Nibiru’s oracle builds upon past oracle architectures to enable fast and accurate pricing through economic alignment between validators and oracles. The result is a more robust oracle that mitigates the risk of corruption, in turn enabling the Cosmos community and beyond to rely on it as a source of truth.

The first way that this is accomplished is by providing validators with the option of becoming oracles as well.
In doing so, they will receive additional rewards in the form of $NIBI tokens (and later $NUSD), and be able to pass this along to delegators who opt to delegate to them.
Delegators will still be able to elect those that only validate, although those also acting as oracles would provide the highest returns and economic alignment.

This is implemented through a sidecar process called the “price feeder”, whereby validators are running software alongside their validator node. This enables them to efficiently query and post prices while simplifying their technical requirements for doing so.

Nibiru’s Price Feeder is critical to Nibiru as it will serve various functions, including being the backbone of index pricing on Sai, as well as facilitating accurate pricing for the minting and redemption of NUSD.

Why should validators care?

Accrual of rewards to Nibiru’s validators will differ from other chains in that it won’t come purely from gas fees and token inflation. There will be a rewards pot with a few additional sources of fees:

A proportion of mint/burn fees from Nibiru’s $NUSD stablecoin.
A proportion of taker fees from Sai.

As Nibiru continues to expand beyond the 40+ currently connected blockchains, while simultaneously introducing additional DeFi products, the rewards pot can be expected to grow significantly in value. Early Nibiru validators can therefore expect to benefit from early adoption, especially those who also act as oracles.

These rewards will be paid out in both $NIBI and $NUSD, although the inflationary $NIBI rewards may decrease in the future as protocol usage grows, thereby accruing value to the NIBI token.

How is this more secure and robust than existing oracles?

In the event that an oracle provider performs poorly, they will be penalized as both an oracle as well as a validator. For example, slashing would occur should a validator not vote on an exchange rate for each and every asset pair specified, or if their vote is outside of a certain deviation from the weighted median.

Potential oracle attack vectors are also mitigated:

Data Manipulation: Nibiru’s Feeder oracle takes data from a range of centralized exchanges, decentralized exchanges, and other oracles including Chainlink and Pyth. The Nibiru team will choose the initial sources, and a governance listing process will be used later on as data sources continue to be added.
Front-running: a commit-reveal scheme is used to protect against front-running. This entails a first phase whereby oracles pick a price and commit to it, and a second phase whereby the value is revealed and checked against others.
Sybil attacks: due to correlating oracles with validators, it’s possible to weigh the input of posted prices according to validator power. Their stake as validator acts as economic proof, meaning that it’s irrelevant how many oracles they operate, as it will be their validator power that impacts the ultimate oracle price.

Improving the state of oracles

Nibiru’s oracle module also updates within 10-15 seconds on average which is comparable to Pyth Network’s 1-2 second update time, although fully decentralized. While this update time could technically be shorter, this may come at the expense of validators that struggle to keep up and inadvertently get slashed. Regardless, it is extremely fast for a decentralized oracle network and is in sharp contrast to Chainlink’s updates which may take as long as 20 minutes. Fast, decentralized oracles are needed to scale the DeFi landscape as it continues to grow in complexity, and in turn, requires timely data.

Oracles are critical for the success of blockchain ecosystems, and yet the current state of price feed oracles is not sufficient. Several high-profile exploits have occurred in recent times, causing the loss of ecosystem funds and jeopardizing trust in DeFi as a whole. If DeFi is to continue growing in both adoption and complexity, then a more secure and robust oracle architecture is needed.

The Nibiru Oracle Module is the next step in the evolution of oracles, enabling fast and accurate price feed data through a combination of economic alignment of validators and oracles, an array of data sources, and feature implementations that prevent common attack vectors. Users of Nibiru can rest assured that prices are accurate and timely, preventing any opportunities for corruption or MEV-capture.

We hope our community is as excited as we are, and we look forward to feedback.

🔮 Docs | 👾 Discord | 🐦 Twitter | 🔥 Web App

⛓️ ️Explorer | 🌴 Link Tree | 👨‍💻 Code | 🎥 YouTube