Skip to main content

Introduction

Oracle is an essential component in DeFi protocols. It allows users and developers to observe information about a given asset on the network.

note

Unfamiliar with the concept of an oracle? Check out the Hedera's oracle overview first.

A blockchain oracle was first built and utilized by Ethereum. Currently, there are several ways to create an oracle(i.e. ad-hoc, time-weighted averaging, volume-weighted averaging). However, each one has its distinctive advantages and limitations.

The ones that are commonly found in DeFi are Time-Weighted Average Price(TWAP), which was invented by Uniswap and Volume-Weighted Average Price by external parties like ChainLink or Band Protocol.

Sigmaswap uses the oracle retrieved from the Uniswap V2.

All Sigmaswap pools can serve as oracles, offering access to historical price and liquidity data. This capability unlocks a wide range of on-chain use cases.


Concept​

The oracle includes several improvements for supporting manipulation-resistant public price feeds. First, every pair measures (but does not store) the market price at the beginning of each block, before any trades take place. This price is expensive to manipulate because it is set by the last transaction, whether it is a mint, swap, or burn, in a previous block.

To set the measured price to one that is out of sync with the global market price, an attacker has to make a bad trade at the end of a previous block , typically with no guarantee that they will arbitrage it back in the next block. Attackers will lose money to arbitrageurs unless they can “selfishly” mine two blocks in a row. This type of attack presents several challenges and has not been observed to date.

Unfortunately, this alone is not enough. If significant value settles based on the price resulting from this mechanism, an attack’s profit will likely outweigh the loss.

Instead, the protocol adds this end-of-block price to a single cumulative-price variable in the core contract weighted by the amount of time this price existed. This variable represents a sum of the Sigmaswap price for every second in the entire history of the contract.

This variable can be used by external contracts to track accurate time-weighted average prices (TWAPs) across any time interval.

The TWAP is constructed by reading the cumulative price from a HTS token pair at the beginning and at the end of the desired interval. The difference in this cumulative price can then be divided by the length of the interval to create a TWAP for that period.

TWAPs can be used directly or as the basis for moving averages (EMAs and SMAs) as needed.

A few notes:

  • For a 10-minute TWAP, sample once every 10 minutes. For a 1-week TWAP, sample once every week.
  • For a simple TWAP, the cost of manipulation increases (approx. linear) with liquidity on the protocol, as well as (approx. linear) with the length of time over which you average.
  • The Cost of an attack is relatively simple to estimate. Moving the price 5% on a 1-hour TWAP is approximately equal to the amount lost to arbitrage and fees for moving the price 5% every block for 1 hour.

Manipulation resistance​

The cost of manipulating the price for a specific time period can be roughly estimated as the amount lost to arbitrage and transaction fees for the entire period. For larger liquidity pools and over longer time periods, this attack is impractical, as the cost of manipulation typically exceeds the value at stake.

Other factors, such as network congestion, can reduce the cost of attack. For a more in-depth review of the security of Sigmaswap price oracles, stay tuned.