In the realm of DeFi, asset pricing remains a complex challenge. Existing platforms like CoinMarketCap offer incomplete coverage, requiring manual asset additions - and are moreover totally inefficient on low-volume assets, while DEX explorers such as DexScreener can only visualize trading pairs, not the whole market price of assets. At Mobula, we're bridging this gap with our market data engine, Octopus.

Introduction

Octopus harnesses real-time multi-chain DeFi event streaming from +30 blockchains to maintain a current state of liquidity pairs and compute prices of millions of DeFi assets. This removes the need for updates from outside and manual inputs, making the coverage both complete and instant.

Octopus allows aggregated price computing, based on volume & on-chain liquidity as a fallback, updating prices by recomputing the LPs ratios of all the assets every second. Our volume system is engineered to reflect true market activity, discounting volume spikes that could skew asset valuation & erasing MEV-bot or flashloans price manipulations.

Octopus solves pain points from current solutions:

1. Current reliance on manual work for assets tracking (CoinMarketCap team has to manually list a given asset for it to be tracked)
2. Lack of coverage on new DeFi-bootstrapped tokens first hours/days of trading (for example, Pepe has been added to CoinMarketCap +7 days after its launch)
3. Lack of on-chain aggregated coverage for tokens & assets (CoinMarketCap tracks assets both on & off-chain in a fully aggregated way, which means during depeg events, or on-chain exploits, there is no way to track aggregated price of the underlying tokens)

OK, but why can’t we use DexScreener instead? Pair-based data providers are great for some usecases, but as they are pair-based, they don’t cover the full picture, and aren’t resilient to exchange migration, protocol migration, or stablecoins depegs - making aggregated prices much more suitable for lending protocols, portfolio pricing, checkouts, and virtually all pricing usecases that aren’t trading on the given pair. Let’s dig into how Octopus works.

Pricing computation

One of the issues of AMM pricing is that everything is based on ratios - tokenA is worth Y tokenB, not X USD. Thus, you can only compute tokenA in $ if you know tokenB in $. But, in a closed state, you’d also need to compute tokenB price, based on… tokenA, or maybe tokenC if tokenB has two liquidity pools.

To solve this problem, there are two ways around:

External pricing from cherry-picked assets

We can imagine cherry-picking some assets (say ETH, BNB, UNI) & track them off-chain, i.e. on Binance, or through CoinGecko. This would solve the chicken&egg problem, given a first price to tokenA, allowing us to compute tokenB, and so on.

However, this exposes us to 2 pain points: depegs and scale changes. One of the cherry-picked assets could depeg (1) because the CEX we track bankrupts, (2) because the on-chain contract is exploited, i.e. Gala with its wrapped BNB chain version. A single asset exploding can have devastating consequences on the prices of the whole engine, as… everything is ratios. If Gala is worth x1000 less than it should on a CEX, tokenB will be computed worth x500 more than it is - tokenC (if paired with tokenB) will thus be computed worth x250, and so on…

A similar thing can happen with scale changes - decimals amount changed, or supply number changed, and CEX price dramatically increases x100000 - the project deployed a new contract, but Octopus didn’t catch up (because it requires a manual intervention) and we still believe the old contract is worth x100000, leading to the same propagation of incorrect prices. Let’s take an example:

Now, imagine that C is injected as worth $1000 - we’d recompute B & A the following way:

$$ ⁍ $$