Internal oracle

Geminon GLPs are part of a complete decentralized finance system that includes stablecoin minting and lending. These types of applications are vulnerable to price manipulation attacks, and therefore need reliable sources of prices for their calculations. Given the central role that the GEX token plays in the Geminon protocol, an internal oracle has been incorporated into the GLPs that allows secure token pricing.

Oracle algorithm

The GLP internal oracle algorithm employs a principle similar to that used for the GEX token supply limiter and StableSwap Guard, which is based on adaptive exponential smoothing whose parameters vary depending on the application. The oracle algorithm calculates two values, an instantaneous value that includes the operations within the current block ($\Delta t = 0$) and another considered the safe value that is only updated at the close of each block ($\Delta t > 0$).

Instant value

The oracle's instantaneous value, $l_n$, is updated each time an operation occurs on a GLP. The smoothing parameter, $\beta$, is obtained from the relationship between the volume of the current trade, $v_n$, and the average volume of trades in the pool $\overline{V}$.

$$\beta_n = \begin{cases} \ \ \ \ \ 1 &\text{if } \beta_n > 1 \\ \dfrac {\overline{V}_n}{v_n + \epsilon} &\text{if } \beta_n \le 1 \end{cases}$$

$$l_n = \beta_n p_n + (1-\beta_n) l_{n-1}$$

The parameter $\beta$ takes its maximum value, limited to 1, when the volume of the current trade is less than the usual volume of the pool. In that case, the instantaneous value of the oracle price $l_n$ matches the instantaneous price of the pool $p_n$. If the volume of the last trade is higher than the usual volume, then $\beta < 1$ and the price is filtered proportionally to the volume anomaly. For example, if the volume of the operation is 1000 times higher than normal, then the new price will have a weight of 0.001 in the average price $l_n$ and its value will not affect the instantaneous price of the oracle, achieving its objective of filtering out abnormal operations.

To calculate the average volume of operations, a simple exponential smoothing is used, with parameter $\gamma = 0.001$. This smoothing is equivalent to using the average of the volume of the last 1000 trades:

$$\overline{V}_{n+1} = \gamma v_n + (1 - \gamma) \overline{V}_n$$

The update of the average volume of operations is done afterwards, so the volume of the current operation is not taken into account in the oracle calculations until the next operation. This detail is important, since it prevents a flash loan from altering the average volume data used to calculate the parameter $\beta$, improving the filtering capacity of the algorithm.

Finally, the accumulated volume of the current block is calculated:

$$V_B = \begin{cases} \ \ \ \ \ 0 &\text{if } \Delta t > 0 \\ \sum_{n \in B} v_n &\text{if } \Delta t = 0 \end{cases}$$

Safe value

The oracle safe value is calculated only at the start of a new block ($\Delta t > 0$). The calculation is similar to that of the instantaneous value, the difference being that the safe value takes as input the values of the oracle's instantaneous value, producing second-order filtering. For the smoothing parameter $\alpha$, the cumulative volume of the previous block $V_{B-1}$ is used instead of the volume of the last trade:

$$\alpha_n = \begin{cases} \ \ \ \ \ \ 1 &\text{if } \alpha_n > 1 \\ \dfrac {\overline{V}_n}{V_{B-1} + \epsilon} &\text{if } \alpha_n \le 1 \end{cases}$$

Finally, to calculate the safe value of the price $m_n$, the smoothed instantaneous value of the previous block is used as input, $l_{n-1}$, instead of the current price $p_n$:

$$m_n = \alpha_n l_{n-1} + (1-\alpha_n) m_{n-1}$$

This calculation structure ensures that the safe price $m_n$ cannot be affected by a flash loan attack, since it takes the closing price of the previous block, which has also been previously filtered, ruling out operations with anomalous volume, and which is again filtered through of the parameter $\alpha$. This double filtering also ensures that even spot attacks are properly discarded until several trades with normal volume are made in the pool at the new price.

The justification for security against spot attacks that last longer than the block time of the network is found in the hypothesis of market efficiency and the principle of non-arbitration. An attacker who tries to manipulate the price of a pool without using a flash loan is exposed to market reaction (arbitrage) in the next block to restore the price balance, so the price resulting from the following operations will be a fair market price that must be reflected by the oracle.

This ability to immediately reflect price changes when normal trading flow is established while filtering out one-off anomalies is possible because the smoothing is done in the volume domain rather than the time domain, therefore, a great noise filtering capacity is achieved without introducing delay in the smoothed series.

The goal of a price oracle is not to completely eliminate large trades but to prevent instant price manipulations while providing the most up-to-date price possible. In this task, the algorithm proposed by Geminon is extremely efficient and outperforms the algorithms used so far in other decentralized protocols. The combination of this oracle with the entropy capture feature of GLP makes it extremely unlikely that a GEX token price manipulation attack would prove beneficial to the attacker.