📈Floor Price Oracle (Perpetuals)

Credits to NFTPerp for providing industry expertise throughout the development of the pipeline.

Data Ingestion

Two types of data points are ingested in order to compute the floor price oracle:

• Sales Data - on-chain data taken from all marketplaces, aggregators, and decentralized exchanges

• Bid/Ask Data - off-chain data taken from all marketplaces

Data Eligibility

Sales Data

Several filters are employed to eliminate trade instances executed with malicious intent

• Directed Graph Encoding of transaction data for wash trading pattern recognition - prevents floor price manipulation by flagging transaction patterns between a group of addresses, executed with the sole purpose of artificially inflating/deflating the floor price.

Examples of Wash Trading Patterns

• Cooling Period for Token IDs - prevents floor price manipulation by restricting the number of times a single token can be traded in the span of $X$ hours, where $X$ is chosen based on historical trading frequency of the NFTs within a collection under different market conditions.

• Address Tracking - prevents floor price manipulation by restricting the number of eligible transactions an address can participate in, in the span of $Y$ hours, where $Y$ is chosen based on historical address activity under different market conditions.

Apart from wash trading filters, an outlier removal methodology is utilized in order to exclude any anomalous sales which may distort the floor price.

• When a new sale instance occurs, its eligibility is determined by the last $X$ sales which form an acceptable price range. The new transaction is included in the computation of the floor price if:

$$\bar{x} - m\cdot s \le\text{Sale}\le\bar{x}+m\cdot s$$

Where:

• $\bar{x}$ is the Truncated Mean of the last $X$ sales

• s is the Sample Standard Deviation

• $m$ is a sensitivity multiplier which takes into consideration collection-specific factors such as average volatility under different market conditions, peak-to-trough for different floor price combinations, etc.

Bid-Ask Data

Top-bid/lowest-ask pairs are ingested in order to compute a floor price based on order book activity. There is one primary issue regarding their ingestion:

• Given the current state of the market microstructure for NFTs, instances of diminished liquidity can be observed either on the buy-side or the sell-side. Consequently, a wide bid-ask spread emerges, rendering conventional price discovery mechanisms imprecise. The resolution of the problem can be found in Bid-Ask Floor Price.

Floor Price Calculation

Two methodologies are used for the computation of the floor price - floor price based on Sales Activity and floor price based on Order Book Activity. After their computation, they are averaged (Aggregation) in order to obtain the true floor price.

Sales Floor Price

In the following section the methodology behind the sales part of the equation is described. It is important to note that the Sales Floor Price and the Sales Floor Price TWAP are two different metrics, with the Sales Floor Price TWAP being the one averaged by the algorithm.

The Sales Floor Price is updated whenever a new eligible sale occurs. A weighted average of the last $X$ admissible sales is computed, with the weights being inversely proportional to the order of the samples.

The Sales Floor Price TWAP is a time-weighted average of the Sales Floor Price with a 1 hour lookback-period and a smoothing factor $\alpha$.

Bid-Ask Floor Price

In the following section the methodology behind the bid-ask part of the equation is described. It is important to note that the Bid-Ask Floor Price and the Bid-Ask Floor Price TWAP are two different metrics, with the Bid-Ask Floor Price TWAP being the one averaged by the algorithm.

The Bid-Ask Floor Price is updated every $T$ seconds and is computed according to the formula:

$$\text{Bid-Ask Floor Price}=\frac{\text{Top Bid} + \text{Lowest Listing}}{2}$$

In case the bid-ask spread is higher than $y\%$, where $y$ is based on historical spread tracking, the floor price is equal to either the top-bid or the lowest-listing, depending on their proximity to:

$$\frac{\sum_{i\in(T-z,...,T)}\text{Bid-Ask Floor Price TWAP}_i}{z}$$

The corner case handling is motivated by empirical analysis of the true floor price's behavior in such situations. The mean of the Bid-Ask Floor Price TWAP, with a lookback period ($z$), serves as a determining factor in identifying the side(buy/sell) that has experienced a decline in liquidity and opts for the other one.

Example of Bid-Ask Spread Handling

The Bid-Ask Floor Price TWAP is a time-weighted average of the past $z$, lookback period, Bid-Ask Floor Price values, having a smoothing factor $\alpha$.

Smoothing Factor

The formula for calculating the Smoothing Factor ($\alpha$) possesses the following characteristics - it ensures that older values do not have a higher weight than newer ones when the value of $n$ is small, and it converges to $\alpha_{static}$ when the value of $n$ is large:

\left\{\begin{array}{@{}l@{}@{}} \alpha_0=1\\ \alpha_n=\frac{1}{\frac{1-\alpha_{static}}{\alpha_{n-1}}+1} \end{array}\right.

Lookback Period

The Lookback Period ($z$) is dynamically adjusted based on the number of eligible transactions in the past $X$ hours - $n$. Let's define the percentage of days when $n_t\ge n_i  for  i\in \{0,1,....,t−1\}$ as:

n_{percent}=\frac{\sum_{i=0}^{t-1}\mathbb{1}_{n_t}{(n_i)}}{t-1},\;\text{with}\; \mathbb{1}_{n_t}{(n_i)}=\left\{\begin{array}{@{}l@{}@{}} 1\;\text{if}\; n_t\ge n_i\\ 0\;\text{if}\; n_t\lt n_i \end{array}\right.

$z\in[z_{lower},z_{upper}]$, where the lower/upper bound are collection-specific and based on backtesting. High values of $n_{percent}$ result in low values for $z$, i.e., the higher the relative market activity, the shorter the lookback period.

Aggregation

The last stage of the pipeline involves merging the results of the two approaches using the following equation:

$$\frac{\text{Sales FP TWAP}+\text{Bid-Ask FP TWAP}}{2}$$

• If the corner case mentioned in Bid-Ask Floor Price continues for a period of more than $m$ minutes, the Sales FP TWAP is outputted. The value of $m$ is chosen through an optimization process that aims to achieve a balance between responsiveness and the occurrence of false positive instances.

The rationale behind the aggregation is based on the idea that the bid-ask component enables quick responsiveness, while the sales component serves as a reference point that normalizes market movement if it lacks support from actual sales data.

Example: MAYC