There are three basic models for DEX price discovery: orderbooks (dYdX, Injective, Sei, Uni v3), AMMs (Perp v2, Osmosis) and oracle-based models (GMX, Gains, Synthetix). The basic tradeoffs between them can be seen as follows:

• Orderbooks: Tried and tested model from TradFi, providing the most granularity for traders to express their preferences on a given asset. However, they don’t tap into passive liquidity and they’re highly computationally intensive, requiring high throughput or specialised chains. Since blockchains will always be gas-constrained environments, there’s a question about whether orderbooks will ever make sense
• AMMs: Currently the dominant solution for spot markets. Low computational requirements and able to tap into billions of dollars of latent passive LP capital. However, existing designs either provide poor capital efficiency (xy=k), resulting in poor execution for traders, or sacrifice the passive LP experience (Uni v3), resulting in poor returns for most LPs. Unlike some, we expect innovation in the AMM space to continue with designs that choose different points on the tradeoff space (e.g. Curve v2, Liquality)
• Oracle-based models: Extremely capital efficient since they outsource price discovery from CEX’es rather than establishing their own liquidity. As a result, they can offer CEX-like execution to traders from the very beginning. Downsides are that they rely on price discovery happening externally on a CEX, meaning they will never become the primary trading venue, nor can they scale to approach the size of the external market. In addition, they’re highly reliant on oracles which are one of the weak spots in current DeFi infrastructure.

While orderbooks and AMMs are well-represented in the Cosmos, oracle-based solutions are not. Oracle-based solutions have capped upside in the long-term but are likely to be the most successful short-term.

We believe we’ve just scratched the surface of the design space here and we’re particularly interested in oracle-based models that don’t require native assets (e.g. Gains Network). These are particularly well-suited to Cosmos since, unlike GMX-style models, they don’t even require the native assets themselves, meaning you only need to bootstrap a stablecoin pool rather than attracting liquidity for each market they want to list. With native USDC coming to Cosmos, this is far lower risk/friction than making users bridge over native assets from non-IBC enabled chains and inheriting the associated bridge risk. This model also allows users to speculate on anything with an oracle price feed, including cryptoassets, forex, commodities, stocks, sportsbetting, etc.

The real challenge with these models is the risk engine, which must balance capital efficiency with blow-up risk by not allowing too much exposure to build up on any single market. We’re interested in seeing further experimentation with more advanced on-chain risk engines and liquidation models that can drive efficiency. As part of this, we’re also interested in seeing models that have dynamic slippage parameters, perhaps leveraging something like the Pyth liquidity oracle.

A second challenge with oracle-based dexes is the latency inherent to price updates, and the tension between trader user experience and LP profitability. If oracle updates are slow, traders can take advantage and LPs begin to leak value. If traders are required to wait for these oracle updates to protect LPs, trader UX is degraded. Clever usage of off- and on-chain mechanisms to balance these concerns are required for a successful oracle-based dex. This is an area where app-chains can offer significant benefits. Since vote extensions allow validators to include arbitrary data alongside tendermint votes, this functionality can be leveraged to update oracles on a per-block basis. This eliminates the MEV games where protocols are trying to guarantee protocols get oracle updates in before arbitrageurs.

A third challenge is the need for some sort of orderbook functionality for critical components such as limit, stop, take profit and stop loss order types. This can be built using a service like Warp or Autonomy.

Where: This would be most appropriate on faster chains such as Injective for faster oracle updates. However, it would also make sense on Osmosis given user base and existing DeFi applications. Eventually, this could also be implemented as an app-chain to benefit from the vote extension feature mentioned above.

Hackathon MVP

Create the foundation for an oracle-based DEX with stablecoin liquidity and collateral, and synthetic leverage for assets via Oracles. Scope can be reduced by simulating the deposit-side logic and ignoring trader PnL risk for the purposes of the hackathon.

On-chain Logic:

• A set of smart contracts that can:
  • Take stablecoin deposits from LPs
  • Allow traders to deposit stablecoin collateral
  • Allow traders to open and close positions using an external oracle

Middleware:

• Infrastructure that feeds oracle prices to the smart contracts and allows trades to be executed in a timely manner

Front-end:

• An interface that allows LPs to deposit stablecoins
• An interface that allows traders to open positions, using a combination of the middleware and smart contracts to give a fair price while protecting LPs from oracle front-running.