Proprietary Automated Market Makers (PropAMMs) stellen eine aktive, on-chain-fähige Market-Making-Architektur dar, die institutionelle Liquidität zurück auf die Blockchain bringt. Im Vergleich zwischen Solana und Ethereum zeigen sie, wie Loss-Versus-Rebalancing (LVR) reduziert, Zensur- und Reordering-Risiken adressiert und neue Fragen zu Builder-Zentralisierung sowie Sequenzierungsgarantien aufwerfen.
Loss-Versus-Rebalancing (LVR) – Warum passive AMMs systematisch verlieren
Milionis et al. (2022) modellierten LVR als unvermeidbare laufende Options-Prämie (Theta), die passive Liquiditätsanbieter (LPs) an Arbitrageure zahlen, sobald externe CEX-Preise schneller aktualisiert werden als On-Chain-Pools. Die analytische Herleitung zeigte, dass LVR nicht-negativ und proportional zur Preisvarianz ist – eine fundamentale Obergrenze für die Rentabilität passiver LPs.
- Metric: LVR-Charakteristik – Nicht-negativ, proportional zur Preisvarianz (2022).
- Quelle: Milionis, Moallemi, Roughgarden & Zhang, „Automated Market Making and Loss-Versus-Rebalancing“ (arXiv, 2022).
Diese formale Ökonomie begründet, warum DEX-Architekturen von passiven Pools zu aktiven Modellen wie PropAMMs migrieren müssen.
PropAMMs auf Solana – Marktanteil und Compute-Unit-Optimierung
Marktanteil im Solana-DEX-Ökosystem
PropAMMs wie HumidiFi und SolFi haben innerhalb kurzer Zeit erhebliche Marktanteile erobert. Blockworks- und On-Chain-Daten belegen, dass PropAMMs zeitweise 30-50 % des gesamten Solana-DEX-Volumens ausmachen und über 60 % des SOL/USDC-Handels über DEX-Aggregatoren wie Jupiter abwickeln. Spitzenwerte von bis zu 86 % des täglichen SOL/USDC-Volumens wurden beobachtet.
- Metric: DEX-Volumenanteil von PropAMMs auf Solana – 30-50 % (2025, Blockworks Research / Galaxy Research).
- Metric: SOL/USDC-Handelsanteil von PropAMMs – > 60 % (bis zu 86 % Spitzenwert, 2025).
Compute-Unit-Reduktion durch Oracle-Updates
Auf Solana benötigen Oracle-Update-Transaktionen nur einen Bruchteil der Compute Units (CU) im Vergleich zu regulären Trades (etwa 100-mal weniger). Market Maker können daher Millionen von Oracle-Updates pro Tag streamen (z. B. HumidiFi mit ~6 M Updates, Kosten ca. 0,0016 $ pro Update, Gesamtkosten 9-10 k $ täglich). Diese niedrigen Kosten ermöglichen eine nahezu Echtzeit-Preisaktualisierung und damit ein schwaches Form von Application-Controlled Execution (ACE).
- Metric: Oracle-Update-Kosten – ca. 0,0016 $ pro Update (2025).
- Metric: Updates pro Tag (HumidiFi) – ~6 M (2025).
PropAMMs auf Ethereum – Builder-Schnittstellen und Proposer-Builder-Separation (PBS)
Technische Umsetzung über Titan & Quasar
Auf Ethereum Mainnet werden PropAMMs über dedizierte Streaming-Verbindungen zu führenden Block-Buildern betrieben. Titan und Quasar bieten APIs, über die Market Maker Preis-Updates direkt einreichen. Titan sequenziert Taker-Transaktionen deterministisch gegen den aktuellsten Zustand und re-simuliert Bundles bei jedem Quote-Update, um Preis-Staleness zu minimieren.
- Metric: Ausführung unter Binance-Midprice bei 12 s Slot-Staleness – 84 % (2026, Analyse von 4,77 M Swaps).
- Builder-Marktanteil: Titan > 50 % der Blocks, Quasar ≈ 20 % (2026).
Einfluss von PBS und Vertrauensbeziehungen
Im aktuellen PBS-Modell muss ein PropAMM Vertrauensbeziehungen zu Top-Buildern pflegen, um Censor- und Arbitrage-Angriffe zu verhindern. Ohne diese Beziehung könnten stale Preise (12 s) zu erheblichen Verlusten führen, wie die Analyse von Titan zeigt.
Zensur- und Reordering-Risiken – FOCIL, ACE und Validator-Komitees
EIP-7805 (FOCIL) zwingt Proposer, Transaktionen aus Inclusion Lists in den Block aufzunehmen, wodurch reine Zensur reduziert wird. Ein Validator-Komitee von 16 Validatoren pro Slot (2024) prüft die Inclusion Lists.
- Metric: Validator-Komitee-Größe für FOCIL Inclusion Lists – 16 Validatoren/Slot (2024, Quelle S4).
Allerdings garantiert FOCIL nicht die Top-of-Block-Platzierung; das Reordering-Risiko bleibt, solange kein in-Protocol ACE implementiert ist.
Gegenargumente und Risiken von PropAMMs
- Entstehung geschlossener Builder-Oligopol: Abhängigkeit von privaten Builder-Pipelines stärkt dominante Builder (z. B. Titan) und widerspricht Dezentralisierung.
- Limitierung von Inclusion Lists: FOCIL erzwingt Inklusion, legt aber keine deterministische Reihenfolge fest – Arbitrage-Risiko bleibt.
- Latenz- und Spoofing-Risiko bei L2s und asymmetrischen Flashblocks: Market Maker können Spreads am Blockende eng quotieren und zu Beginn des nächsten Blocks spreizen, wodurch Taker negativ slippte.
FAQ zu Proprietary AMMs
- Worin unterscheidet sich ein PropAMM fundamental von einem klassischen RFQ-System (wie UniswapX)? Bei RFQs werden Quotes off-chain verhandelt und bilateral gesettelt, was die Liquidität unvollständig komponierbar macht. PropAMMs halten Liquidität und Ausführungslogik in On-Chain-Smart-Contracts, die von Aggregatoren und Smart Contracts atomar in Multi-Hop-Transaktionen integriert werden können.
- Warum schützt das Revertieren bei veralteter Blocknummer einen Market Maker auf Ethereum nicht vollständig? Ein Revert verhindert toxische Arbitrage-Flows bei verpassten Slots, schützt den Market Maker jedoch nicht vor selektiver Ausführung innerhalb desselben Slots (Sub-Slot Reordering durch den Builder) und führt zu fehlgeschlagenen Transaktionen für Endnutzer.
- Welche Rolle spielt EIP-7805 (FOCIL) für PropAMMs? FOCIL zwingt Proposer über ein verteiltes Validator-Komitee, Transaktionen aus Inclusion Lists in den Block aufzunehmen. Es verhindert reine Zensur, löst jedoch nicht das „Top-of-Block“-Garantieproblem, das Market Maker für verzugsfreie Parameter-Updates benötigen.
Fazit
Die Kombination aus theoretischer Fundierung (LVR) und empirischen Daten (Solana-Marktanteile, Ethereum-Builder-Implementierungen) zeigt, dass PropAMMs eine entscheidende Brücke zwischen off-chain-RFQ-Systemen und traditionellen, passiven AMMs bilden. Auf Solana ermöglichen extrem günstige Oracle-Updates eine fast-realtime-Preisaktualisierung, wodurch ein großer Teil des DEX-Volumens (30-50 %) von PropAMMs dominiert wird. Auf Ethereum erfordern aktuelle PBS-Strukturen vertrauensbasierte Builder-Schnittstellen (Titan, Quasar), die zwar die LVR-Leckage reduzieren, aber neue Zentralisierungs- und Reordering-Risiken einführen. Protokoll-Mechanismen wie FOCIL und zukünftige In-Protocol ACE-Lösungen könnten diese Risiken mindern, während sie gleichzeitig die Zensur-Resistenz stärken. Insgesamt verdeutlichen die vorliegenden Fakten, dass die Migration zu aktiven, on-chain-fähigen Market-Making-Modellen unvermeidlich ist, jedoch sorgfältig mit Governance- und Infrastruktur-Designs abgestimmt werden muss, um die Balance zwischen Effizienz, Dezentralisierung und Sicherheit zu wahren.