Oracles & Solvency

Within the context of money markets, Oracles are an essential part of the infrastructure in that they are price feed providers for the assets Genera supports. Oracles are needed to correctly 'price' an asset, as prices are not directly available on chain. As a money market, we rely entirely on the accuracy of these price feeds to properly manage liquidity and risk.

Genera's core oracle partners include RedStone and Chainlink as a primary sources of up-to-date token data on Neura.

Oracles for Genera

For listing new assets, Genera follows a strict evaluation process to assess if an oracle is fit for supporting the asset. Core parameters such as liquidity threshold and oracle reliability have to be met to warrant a safe listing. Oracle types acceptable for asset support are:

1. Centralized/Aggregator Oracle Providers: oracles that base 'price of asset' on 2+ sources (such as Chainlink), generally query several data sources to arrive at a final price feed.

2. Decentralized DEX/UniswapV2/V3 oracles: as long as they pass a specific liquidity threshold (defined per-asset, based on total available on-chain liquidity of that asset), and implement a time-weighted moving average of at least the last 10 observations. UniswapV3 oracles will be considered as long as their cost of attack exceeds the total available pool liquidity by a factor of 2.

To mitigate Oracle Risk further, Genera uses monitoring and alerting mechanisms and a rapid response approach to any threat to the price feed integrity.

The main requirement of a price feed is providing accuracy at all times, checked against an external data source every 10-20m for added security, not deviating from alternate data sources (possibly not trust-less e.g. Coingecko) by more than x%, where x is determined per asset.

Oracle monitors for assets based on decentralized price feeds (AMMs) will trigger alerts and pause the markets if the pool liquidity drops below the thresholds, pre-configured per-asset.

No perfect Oracle implementation exists and not all Oracles are created equally. Many hacks across DeFi imply that oracles are a source of significant vulnerability given fact that oracles bring off-chain data on chain (data that is not validated by the blockchain's own consensus mechanism).

The level of difficulty and cost to manipulate an Oracle is usually what defines the security of an Oracle, with flash-loan exploits being on attack vector if the Oracle can be manipulated easily (more on flash loan attacks here: https://insights.glassnode.com/defi-attacks-flash-loans-centralized-price-oracles/).

Liquidity & Solvency

Protocol Solvency

The solvency of a borrowing and lending protocol hinges on the ability with which it can perform liquidations, and with which it can price assets in a fair-market manner. While the latter hinges heavily on the security of the oracles, the former is heavily dependent on a variety of factors such as the willingness of external actors to constantly monitor open positions, and liquidate as they go in loss and the ability to perform such liquidations, either with capital of their own, or via a flash loan.

Genera's liquidation system is fully permissionless, and any actor is incentivized via liquidation incentives granted to liquidators. We must guarantee the liquidate-ability of each and every position.

Liquidity Monitoring

While the liquidation system is flexible enough to be able to use a variety of different liquidity pools as sources for liquidations, it is important that such liquidity pools would be able to withstand any liquidation event. In particular, the aggregated liquidity of all the pools for a specific asset should be higher than the total borrowable value of such asset, and the largest liquidity pool should have enough depth to withstand a trade of the largest borrow position with minimal slippage. This usually means a full-range liquidity of 2-5 times larger than the largest possible borrowable position.

To ensure these requirements are met, Genera developed a custom liquidity monitoring solution with the goal of mitigating the situation in which protocol solvency could be at-risk. The methodology by which such system operates is by preventing market operations on markets for which on-chain liquidity is not enough to perform liquidations or sustain an oracle attack.

LP Drainage & Concentration

In the event of a large drop in liquidity in any of the liquidity sources, Genera pauses market operations for the asset in question and the borrowable assets in the protocol with such asset. In particular, this will prevent any further borrowing of any assets, and prevent any further minting of new collateral for the asset in question. This will however still allow users to repay their debts and withdraw liquidity from the pool

Liquidity concentration is another risk vector for a liquidity pool. If the liquidity is concentrated into very few wallets, the changes of such liquidity being removed immediately is higher than if spread across multiple small holders.

Our monitors will issue alerts if a critical level of concentration is detected. It will issue an alert if the top holder of the liquidity pool holds enough liquidity that, if removed, it would cause the available liquidity to drop below our specified thresholds.