Funktionsweise, Marktstrukturen und Risiken von Proprietary AMMs (PropAMMs) auf Solana und deren Übertragbarkeit auf Ethereum

24. September 2026 Kryptowährungen

Proprietary AMMs (PropAMMs) verlagern das Liquiditätsmanagement und die Preisfindung von passiven DEX-Pools zurück auf die Blockchain. Durch aktive Market Maker, die in Echtzeit Oracle-Updates senden, werden LVR-Verluste (Loss-Versus-Rebalancing) im Vergleich zu klassischen CPMM-Pools deutlich reduziert. Gleichzeitig entstehen neue Anforderungen an zensurresistente Latenzgarantien, um toxische Arbitrage und eine weitere Zentralisierung von Block-Buildern zu verhindern.

1. Der LVR-Effekt als Treiber der PropAMM-Adoption

Die theoretische Notwendigkeit aktiver PropAMMs wird primär durch den LVR-Effekt bestimmt. Passive Liquiditätsanbieter (LPs) in klassischen AMM-Pools verlieren bei hoher Marktvolatilität systematisch Wert an Latenzarbitrageure, die Preisunterschiede zu zentralen Börsen (z. B. Binance) im Block-Top ausnutzen. Der LVR-Kostenfaktor ist proportional zur quadrierten Volatilität (σ²) und wurde 2022 analytisch von Milionis et al. abgeleitet. Diese Analyse zeigt, dass passives Bereitstellen ohne dynamische Spread-Anpassung strukturell unprofitabel ist.

  • Metric: LVR-Kosten passiver LPs
  • Wert: Proportional zu σ² (2022)
  • Interpretation: Passives Bereitstellen ist bei hoher Volatilität unwirtschaftlich

2. PropAMMs auf Solana – Oracle-Streaming und Netzwerklast

Auf Solana dominieren PropAMMs ein Drittel des On-Chain-Volumens. Das Modell von HumidiFi illustriert diesen Trend: Täglich werden rund 6 Millionen Oracle-Transaktionen (≈ 175 TPS) gesendet, was etwa 20 % des gesamten Solana-Transaktionsvolumens ausmacht. Jede Oracle-Push-Transaktion verbraucht weniger als 500 Compute Units, führt jedoch zu täglichen Netzwerkkosten von 9 000-10 000 USD.

  • Metric: Tägliche Oracle-Transaktionen von HumidiFi – 6 000 000 Tx/Tag (2024)
  • Metric: Anteil von PropAMM-Updates am Solana-Volumen – ca. 20 % (≈ 175 TPS, 2024)
  • Metric: Tägliche Netzwerkkosten – 9 000-10 000 USD (2024)

Durch die niedrigen Compute-Kosten können Market Maker häufige Updates finanzieren und damit die Preisaktualität sicherstellen. Die kontinuierliche Oracle-Inklusion wirkt als schwache Form von Application-Controlled Execution (ACE), weil kleinere, hochprioritäre Transaktionen vor den eigentlichen Trades landen.

3. Risiken und Gegenmaßnahmen auf Ethereum

Die Übertragung des Solana-Modells auf Ethereum L1 stößt auf mehrere strukturelle Hürden:

  • Builder-Oligopol: Titan kontrolliert > 50 % der Blöcke, Quasar ~20 % (2024, Quelle S2). PropAMMs, die nur auf diesen Buildern zuverlässig Quotieren, schließen kleinere Builder aus und verstärken die Zentralisierung.
  • Fragmentierte Nutzererfahrung: Je nach aktuellem Builder schwanken Spreads stark. Auf unabhängigen Buildern fehlt die Update-Garantie, was zu Fehlschlägen oder schlechter Ausführung führen kann.
  • Unzureichende Zensurresistenz von FOCIL: EIP-7805 (FOCIL) garantiert die Inklusion einer Transaktion, nicht jedoch ihre Position am Blockanfang. Damit bleibt das Arbitrage-Risiko für Market Maker bestehen.

Zusätzlich wurden auf EVM-Rollups wie Base sogenannte „PropAMM Shenanigans“ beobachtet: Market Maker verbreitern Spreads am Blockanfang und nutzen enge Spreads am Blockende, um Orders mit maximaler Slippage zu füllen. Aggregatoren (z. B. 0x/Matcha) haben darauf reagiert, indem sie unzuverlässige Maker vollständig delisten.

  • Metric: Aggregator-Sanktionen – vollständiges Delisting unzuverlässiger Maker (2024)

4. Exploit-Vektoren auf Rollups – Das Base-Flashblock-Problem

Auf Base manipulierten Akteure die Latenz zwischen Aggregator-Preisanfrage und Ausführung. Sie setzten enge Spreads am Blockende, weiteten sie jedoch zu Beginn des Folgeblocks aus, sodass Nutzeraufträge mit maximaler Slippage gefüllt wurden. Dieses Verhalten führte zu einem vollständigen Delisting der betroffenen Maker durch 0x/Matcha im Jahr 2024.

  • Metric: Aggregator-Sanktionen – Vollständiges Delisting (2024)

5. PropAMMs und Ethereum – Mikroökonomische Verwundbarkeit und institutionelle Lösungen

Die strukturelle Herausforderung von PropAMMs auf Ethereum lässt sich direkt auf das LVR-Framework von Milionis et al. (2022) zurückführen. Passive LPs verlieren systematisch an Latenzarbitrageuren; PropAMM-Betreiber versuchen, diesen Verlust durch exklusive Top-of-Block-Inklusion zu vermeiden. Derzeitige bilaterale Vertrauensverhältnisse mit dominierenden Buildern (Titan, Quasar) verlagern das Vertrauen von transparenten Smart Contracts auf intransparente Absprachen. Diese Lösung ist nur oberflächlich: Sie reduziert das LVR-Risiko, erhöht jedoch die Zentralisierung und das Risiko von Builder-Zensur.

Um die mikroökonomische Verwundbarkeit zu adressieren, sind robuste Protokollmechanismen notwendig:

  • Application-Controlled Execution (ACE): Ermöglicht deterministische Parameter-Updates vor allen Swaps und schützt vor myopischer Builder-Zensur.
  • FOCIL (EIP-7805): Bietet Inklusionsgarantie, jedoch ohne Top-of-Block-Position – muss mit ACE kombiniert werden.
  • Builder-Sanktionen: Durch Signatur-basiertes Commitment können Builder bestraft werden, wenn sie nicht das neueste Quote inkludieren.

Erst wenn Same-Slot- und Top-of-Block-Zensurresistenz gewährleistet ist, können Market Maker PropAMMs ohne das Risiko von Builder-Zensur betreiben.

6. FAQ zu PropAMMs

Was unterscheidet ein PropAMM fundamental von einem klassischen Uniswap-Pool?

Ein klassischer AMM nutzt eine unveränderliche mathematische Kurve mit passiver Liquidität vieler LPs, während ein PropAMM von einem professionellen Market Maker betrieben wird, der Parameter und Spreads via Oracle-Updates in Echtzeit an externe CEX-Preise anpasst.

Warum kann das Solana-PropAMM-Modell nicht einfach 1:1 auf Ethereum L1 kopiert werden?

Ethereum besitzt 12-Sekunden-Slots und hohe Gasgebühren. Kontinuierliches Oracle-Spamming wie auf Solana (über 6 Millionen Transaktionen täglich) wäre auf Ethereum wirtschaftlich untragbar und würde zu enormer Latenzarbitrage bei Slot-Enden führen.

Wie schützen sich Aggregatoren gegen unehrliche PropAMM-Quotes?

DEX-Aggregatoren wie Jupiter oder Matcha überwachen die tatsächliche Ausführungsqualität algorithmisch: Weicht der finale Abrechnungspreis systematisch negativ von der Vorab-Quote ab, wird die betreffende PropAMM-Liquiditätsquelle automatisch herabgestuft oder temporär blockiert.

Fazit

PropAMMs stellen einen bedeutenden Schritt hin zu aktivem, on-chain Liquiditätsmanagement dar. Auf Solana ermöglichen günstige, hochfrequente Oracle-Updates ein Drittel des On-Chain-Volumens, erzeugen jedoch signifikante Netzwerklast und tägliche Kosten im fünfstelligen Dollarbereich. Die Übertragung dieses Modells auf Ethereum L1 wird durch lange Slot-Zeiten, hohe Gasgebühren und ein stark zentriertes Builder-Ökosystem erschwert. Ohne protokollintegrierte Mechanismen wie ACE oder erweiterte FOCIL-Garantie drohen LVR-Verluste, Builder-Zensur und fragmentierte Nutzererfahrungen. Die Kombination aus Top-of-Block-Inklusion, Builder-Sanktionen und dezentralen Execution-Mechanismen ist entscheidend, um die mikroökonomische Verwundbarkeit zu überwinden und PropAMMs langfristig sowohl auf Solana als auch auf Ethereum skalierbar und zensurresistent zu machen.