AMMDEUS: Covariance-Adaptive Liquidity Protocol

Research Prototype | Archived

Executive Summary

AMMDEUS explores a novel approach to reducing Loss Versus Rebalancing (LVR) in automated market makers by dynamically rotating liquidity concentration shapes based on real-time asset correlation data. Unlike static curve AMMs that assume fixed relationships between paired assets, AMMDEUS uses an ellipsoid invariant that adapts to market conditions—concentrating liquidity along the path where correlated assets are most likely to trade. This research prototype demonstrates the feasibility of automated liquidity shaping while exposing critical trust assumptions that prevent production deployment.

---

Architecture

The Body (Solidity)

The core AMM replaces the standard constant-product invariant ($xy = k$) with a generalized ellipsoid:

$$\alpha x^2 + 2\beta xy + \gamma y^2 = k$$

Where:

• $\alpha$ controls sensitivity to Token A balance changes
• $\beta$ encodes cross-asset correlation (negative = positive correlation)
• $\gamma$ controls sensitivity to Token B balance changes

The precision matrix $[\alpha, \beta; \beta, \gamma]$ is the inverse of the return covariance matrix, allowing the curve to "stretch" along the principal axis of expected price movement.

Contract: contracts/src/AmmdeusVault.sol

The Brain (Python)

An off-chain keeper fetches historical prices from Chainlink oracles, computes log-returns, derives the covariance matrix, inverts it to obtain the precision matrix, and pushes the scaled parameters on-chain.

Components:

• risk_engine/core.py — Covariance calculation and price scaling
• risk_engine/vision.py — Chainlink data fetching
• risk_engine/keeper.py — Automated update loop

The Eye (Oracle)

Real-time reserve ratios scale the covariance matrix to correct for "unit bias" (see below). The price scalar $P = \text{reserve}_1 / \text{reserve}_0$ adjusts:

$$\beta_{\text{scaled}} = \frac{\beta}{P}, \quad \gamma_{\text{scaled}} = \frac{\gamma}{P^2}$$

---

Key Technical Challenges

The "Unit Bias" Problem

• Initial deployments drained liquidity rapidly. A 1 ETH → BTC swap returned far less value than expected.

• The covariance matrix operates on percentage returns, which are dimensionless. However, pool reserves exist in absolute token quantities (e.g., 1 BTC : 30 ETH). The precision matrix, when applied directly, assumed a 1:1 token ratio—creating an ellipsoid rotated 45° off the true price axis.

• Apply the on-chain price ratio $P$ to stretch the ellipsoid. This "rotates" the curve to align with actual market prices rather than unit quantities.

Oracles on Testnet

Sepolia lacks stETH/ETH feeds, so we simulated correlation using ETH/USD and BTC/USD as proxy pairs. This demonstrated the mechanics while acknowledging the data isn't representative of a real stablecoin or LST pair.

---

The Invalidation

This prototype will not launch as a production protocol. The following issues are fundamental:

• Historical covariance is a rearview mirror. Market correlations shift—especially during volatility spikes when LVR matters most. By the time the keeper computes and submits new parameters, the market has often already moved. Sophisticated traders can front-run these updates or exploit the stale curve during regime changes.

• The Python keeper is a single point of failure. If it halts, the curve freezes with potentially dangerous parameters. If compromised, an attacker could set precision values that drain the pool. This trust assumption is unacceptable for a protocol holding real liquidity.

• Heavy reliance on Chainlink introduces:

  • Feed updates have inherent delays
  • Thin oracle liquidity on testnet (and even mainnet for exotic pairs) can be exploited
  • Oracle downtime leaves the protocol blind

---

Conclusion

AMMDEUS successfully proves that liquidity shapes can be automated. The ellipsoid invariant works, the covariance-to-precision pipeline is mathematically sound, and the price scaling fix demonstrates how to bridge theory and practice.

However, the off-chain keeper model introduces unacceptable trust assumptions. Future iterations should explore:

1. ZK-Coprocessors (e.g., Axiom, Modulus) to prove covariance calculations on-chain
2. On-chain volatility accumulators using TWAP variance or realized volatility oracles
3. Commit-reveal schemes to prevent front-running of parameter updates

The research question has shifted from "can we build adaptive curves?" to "can we build trustless adaptive curves?" AMMDEUS answers the first; the second remains open.

Deployment (Sepolia)

Contract	Address
AmmdeusVault	0x4FE762F3FaB4e0E21e59Db3322A6833660671c66
Token0 (aWST)	0xbD35FbcCeFebF682254A71a532AEB825b2DAfdd0
Token1 (aETH)	0x2708FfecA52963dA7C6bFf5D6b40f3BaEfE17410

License

MIT