Können Multi-Asset-Perps zu einer eigenständigen Kategorie werden? Diese Frage kann im Moment niemand beantworten.
Aber man kann anhand von drei Design-Herausforderungen rückwärts prüfen, ob Hertzflows Mainnet-Launch diese Hürden überwinden kann.
Erste Herausforderung: Soll der LP-Pool isoliert werden?
Die Volatilität von Kryptowährungen ist nicht in derselben Größenordnung wie bei FX (Devisen).
Wenn BTC an einem Tag um 15% fällt, ist das normal. Wenn USDJPY an einem Tag um 1,5% fällt, ist das schon eine große Bewegung.
Wenn man beides in denselben LP-Pool legt, kann es beim Liquidationsfall der Krypto-Positionen passieren, dass die Liquidations-Engine die LP-Liquidität frisst, während FX-Positionen kaum bewegt werden. Dadurch wird der LP-Pool von der Krypto-Volatilität „gefangen“.
Der Vorschlag von @Hertzflow_xyz ist eine mehrstufige Isolation: Unterschiedliche Assets laufen in jeweils eigenen Pools, und LPs wählen selbst, welches Risiko sie tragen wollen. Die Richtung ist richtig.
Aber nach der Isolation entstehen neue Probleme: Bei FX und Gold sind die täglichen Schwankungen klein und das Handelsvolumen ist über längere Zeit eher niedrig. Dadurch kann die Liquidität in den isolierten Pools ausdünnen—große Orders rutschen stärker (höherer Slippage) und werden teils sogar direkt abgelehnt.
Daher braucht man je nach Asset-Klasse unterschiedliche Mindest-Tiefen-Schwellen, oder man gibt LPs in niedrig-volatile Pools höhere Fee-Splits, um Liquidität anzuziehen. Sogar eine begrenzte, poolübergreifende Liquiditätsleihe könnte erlaubt werden.
Außerdem gibt es in der Vault-Aggregationsebene das Problem, dass bei extremen Marktphasen das Rebalancing verzögert ist. Da Strategiepools auf der Basis der jeweils isolierten Pools beruhen: Wenn der Krypto-Pool „explodiert“, kann der Rebalancing-Befehl dann sofort ausgeführt werden? Und bleibt er nicht etwa on-chain hängen? Das muss man mit Stresstests verifizieren.
Zweite Herausforderung: Soll die Cross-Asset-Liquidation miteinander gekoppelt sein?
Die Doku betont zwar die Marktisolation, aber innerhalb desselben Kontos kann es weiterhin kontoebene Risikoprüfungen geben.
Wird ein BTC-Liquidationsfall eine starke Prüfung oder ein mitbetroffener Deleveraging (mitverknüpfter Rückzug) für die Gold-Position auslösen? Wenn es gekoppelt ist, muss man für Trader einen klaren, unabhängigen Margin-Schalter bereitstellen. Wenn es nicht gekoppelt ist, muss sichergestellt werden, dass ein einzelner Pool-„Crash“ andere Pools nicht indirekt über Shared Oracles oder die Liquidations-Engine beeinflusst.
Derzeit ist in den öffentlich verfügbaren Dokumenten nicht klar beschrieben, wie die endgültige Risikoisolation auf Konto- und Positionslevel umgesetzt wird. Nach dem Mainnet-Launch muss man sich an tatsächlichem Vertragsverhalten orientieren.
Von Nutzern aus dem Testnet gibt es Rückmeldungen: Bei High-Leverage-Closings gibt der Frontend angezeigte Liquidationskurs eine Drift von 2 bis 3 Sekunden gegenüber dem tatsächlichen Ausführungskurs. Ursache ist, dass das Frontend die Ereignisse on-chain nicht schnell genug abfragt (Polling hinterherhinkt).
Das Mainnet muss auf Millisekunden-Niveau optimieren, sonst bricht die User Experience bei High-Leverage-Usern direkt zusammen.
Auch in extremen „Doppelschlag“-Szenarien muss man es vorher entwerfen. Am 5. August 2024 fiel der Nikkei um 12%—BTC fiel an dem Tag von 60.000 auf 49.000, USDJPY von 146 auf 141.
Wenn es an dem Tag einen Multi-Asset-Perp laufen gab, müssen Liquidations-Durchsatz, Oracle-Update-Frequenz und LPs’ Fähigkeit zur sofortigen Nachfüllung alles abfangen. Empfehlung: Priorität auf die Behandlung hochvolatiler Assets legen und eine Circuit-Breaker-Mechanik hinzufügen.
Dritte Herausforderung: Kann ein Oracle gleichzeitig so viele Assets bedienen?
Hertzflow nutzt Multi-Oracle-Cross-Validation, hauptsächlich Pyth.
Aber die Update-Frequenzen von FX, Aktien und Rohstoffen, die Feiertags-/Handelsschlussregeln, und der Umgang mit anormalen Kurs-Sprüngen unterscheiden sich komplett von Kryptowährungen.
Im Testnet wurde während einer Pyth-Panne bereits Wartungsfall ausgelöst. Was man tun muss: je Asset-Klasse eigene Oracle-Gewichte definieren, Konfidenzintervalle dynamisch anpassen und Fallback-Quellen automatisch umschalten.
Hebel muss man ernst nehmen. Auf der Website wird „bis zu 1000x“ beworben, im GitBook steht „500x“. In der Praxis unterscheiden sich die Limits je nach Asset und Modus. Die finalen Parameter im Mainnet liegen beim offiziellen Stand.
Für Nicht-Krypto-Assets sollte man die Obergrenze verpflichtend senken: 100x bis 200x ist bei FX sinnvoll—nur für Krypto sind höhere Werte erlaubt. Andernfalls ist Oracle-Verzögerung bei High Leverage ein Disaster-Verstärker.
Harte Mindestanforderungen vor dem Mainnet-Launch:
Erstens: Bis Anfang August 2026 gibt es weiterhin keine öffentlich zugänglichen Third-Party-Audit-Reports. Dass alle Kernmodule—Liquidation, Rebalancing, Withdrawal-Limits, Permission-/Rollen-Logik—vollständig abgedeckt sind, ist eine harte Untergrenze. Das ist eine der härtesten Anforderungen vor dem Mainnet.
Zweitens: Bei hoher Utilization oder wenn Trader viel „floating profit“ haben, gibt es bei Withdrawals Obergrenzen. Dafür braucht man transparentere Echtzeit-Anzeige der verfügbaren Beträge und man muss Drucktestszenarien simulieren wie „Trader erzielen kollektiv Gewinne und wollen gleichzeitig abziehen“.
Drittens: So gut das Testnet auch sein mag—im frühen Mainnet reichen die initialen Tiefen möglicherweise nicht aus. Frühzeitige LP-Incentive-Mechanismen, höhere Fee-Splits, zeitlich begrenztes Depth-Mining: Das entscheidet darüber, ob nach dem Mainnet wirklich Liquidität da ist oder ob die Story erzählt ist und das Geld wieder abzieht.
Zurück zur Anfangsfrage: Können Multi-Asset-Perps eine eigenständige Kategorie werden?
Der Bedarf ist real. Makro-Trader müssen ohnehin mehrere Märkte gleichzeitig beobachten. Dass ein einzelnes Terminal alle Positionen verwaltet und die Effizienz erhöht, ist real.
Aber ob Liquidation und LP gleichzeitig unterschiedliche Volatilitäten in den Griff bekommen, ist die Lebensader. Vor dem Live-Handling im Mainnet müssen diese Anpassungen sitzen—sonst ist das Risiko deutlich größer als die oberflächliche Effizienz.
Wenn es hingegen gelingt, definiert es nicht nur Hertzflow, sondern wird zum Standard für die gesamte Kategorie.
https://testnet.hertzflow.xyz
@Hertzflow_xyz
Aber man kann anhand von drei Design-Herausforderungen rückwärts prüfen, ob Hertzflows Mainnet-Launch diese Hürden überwinden kann.
Erste Herausforderung: Soll der LP-Pool isoliert werden?
Die Volatilität von Kryptowährungen ist nicht in derselben Größenordnung wie bei FX (Devisen).
Wenn BTC an einem Tag um 15% fällt, ist das normal. Wenn USDJPY an einem Tag um 1,5% fällt, ist das schon eine große Bewegung.
Wenn man beides in denselben LP-Pool legt, kann es beim Liquidationsfall der Krypto-Positionen passieren, dass die Liquidations-Engine die LP-Liquidität frisst, während FX-Positionen kaum bewegt werden. Dadurch wird der LP-Pool von der Krypto-Volatilität „gefangen“.
Der Vorschlag von @Hertzflow_xyz ist eine mehrstufige Isolation: Unterschiedliche Assets laufen in jeweils eigenen Pools, und LPs wählen selbst, welches Risiko sie tragen wollen. Die Richtung ist richtig.
Aber nach der Isolation entstehen neue Probleme: Bei FX und Gold sind die täglichen Schwankungen klein und das Handelsvolumen ist über längere Zeit eher niedrig. Dadurch kann die Liquidität in den isolierten Pools ausdünnen—große Orders rutschen stärker (höherer Slippage) und werden teils sogar direkt abgelehnt.
Daher braucht man je nach Asset-Klasse unterschiedliche Mindest-Tiefen-Schwellen, oder man gibt LPs in niedrig-volatile Pools höhere Fee-Splits, um Liquidität anzuziehen. Sogar eine begrenzte, poolübergreifende Liquiditätsleihe könnte erlaubt werden.
Außerdem gibt es in der Vault-Aggregationsebene das Problem, dass bei extremen Marktphasen das Rebalancing verzögert ist. Da Strategiepools auf der Basis der jeweils isolierten Pools beruhen: Wenn der Krypto-Pool „explodiert“, kann der Rebalancing-Befehl dann sofort ausgeführt werden? Und bleibt er nicht etwa on-chain hängen? Das muss man mit Stresstests verifizieren.
Zweite Herausforderung: Soll die Cross-Asset-Liquidation miteinander gekoppelt sein?
Die Doku betont zwar die Marktisolation, aber innerhalb desselben Kontos kann es weiterhin kontoebene Risikoprüfungen geben.
Wird ein BTC-Liquidationsfall eine starke Prüfung oder ein mitbetroffener Deleveraging (mitverknüpfter Rückzug) für die Gold-Position auslösen? Wenn es gekoppelt ist, muss man für Trader einen klaren, unabhängigen Margin-Schalter bereitstellen. Wenn es nicht gekoppelt ist, muss sichergestellt werden, dass ein einzelner Pool-„Crash“ andere Pools nicht indirekt über Shared Oracles oder die Liquidations-Engine beeinflusst.
Derzeit ist in den öffentlich verfügbaren Dokumenten nicht klar beschrieben, wie die endgültige Risikoisolation auf Konto- und Positionslevel umgesetzt wird. Nach dem Mainnet-Launch muss man sich an tatsächlichem Vertragsverhalten orientieren.
Von Nutzern aus dem Testnet gibt es Rückmeldungen: Bei High-Leverage-Closings gibt der Frontend angezeigte Liquidationskurs eine Drift von 2 bis 3 Sekunden gegenüber dem tatsächlichen Ausführungskurs. Ursache ist, dass das Frontend die Ereignisse on-chain nicht schnell genug abfragt (Polling hinterherhinkt).
Das Mainnet muss auf Millisekunden-Niveau optimieren, sonst bricht die User Experience bei High-Leverage-Usern direkt zusammen.
Auch in extremen „Doppelschlag“-Szenarien muss man es vorher entwerfen. Am 5. August 2024 fiel der Nikkei um 12%—BTC fiel an dem Tag von 60.000 auf 49.000, USDJPY von 146 auf 141.
Wenn es an dem Tag einen Multi-Asset-Perp laufen gab, müssen Liquidations-Durchsatz, Oracle-Update-Frequenz und LPs’ Fähigkeit zur sofortigen Nachfüllung alles abfangen. Empfehlung: Priorität auf die Behandlung hochvolatiler Assets legen und eine Circuit-Breaker-Mechanik hinzufügen.
Dritte Herausforderung: Kann ein Oracle gleichzeitig so viele Assets bedienen?
Hertzflow nutzt Multi-Oracle-Cross-Validation, hauptsächlich Pyth.
Aber die Update-Frequenzen von FX, Aktien und Rohstoffen, die Feiertags-/Handelsschlussregeln, und der Umgang mit anormalen Kurs-Sprüngen unterscheiden sich komplett von Kryptowährungen.
Im Testnet wurde während einer Pyth-Panne bereits Wartungsfall ausgelöst. Was man tun muss: je Asset-Klasse eigene Oracle-Gewichte definieren, Konfidenzintervalle dynamisch anpassen und Fallback-Quellen automatisch umschalten.
Hebel muss man ernst nehmen. Auf der Website wird „bis zu 1000x“ beworben, im GitBook steht „500x“. In der Praxis unterscheiden sich die Limits je nach Asset und Modus. Die finalen Parameter im Mainnet liegen beim offiziellen Stand.
Für Nicht-Krypto-Assets sollte man die Obergrenze verpflichtend senken: 100x bis 200x ist bei FX sinnvoll—nur für Krypto sind höhere Werte erlaubt. Andernfalls ist Oracle-Verzögerung bei High Leverage ein Disaster-Verstärker.
Harte Mindestanforderungen vor dem Mainnet-Launch:
Erstens: Bis Anfang August 2026 gibt es weiterhin keine öffentlich zugänglichen Third-Party-Audit-Reports. Dass alle Kernmodule—Liquidation, Rebalancing, Withdrawal-Limits, Permission-/Rollen-Logik—vollständig abgedeckt sind, ist eine harte Untergrenze. Das ist eine der härtesten Anforderungen vor dem Mainnet.
Zweitens: Bei hoher Utilization oder wenn Trader viel „floating profit“ haben, gibt es bei Withdrawals Obergrenzen. Dafür braucht man transparentere Echtzeit-Anzeige der verfügbaren Beträge und man muss Drucktestszenarien simulieren wie „Trader erzielen kollektiv Gewinne und wollen gleichzeitig abziehen“.
Drittens: So gut das Testnet auch sein mag—im frühen Mainnet reichen die initialen Tiefen möglicherweise nicht aus. Frühzeitige LP-Incentive-Mechanismen, höhere Fee-Splits, zeitlich begrenztes Depth-Mining: Das entscheidet darüber, ob nach dem Mainnet wirklich Liquidität da ist oder ob die Story erzählt ist und das Geld wieder abzieht.
Zurück zur Anfangsfrage: Können Multi-Asset-Perps eine eigenständige Kategorie werden?
Der Bedarf ist real. Makro-Trader müssen ohnehin mehrere Märkte gleichzeitig beobachten. Dass ein einzelnes Terminal alle Positionen verwaltet und die Effizienz erhöht, ist real.
Aber ob Liquidation und LP gleichzeitig unterschiedliche Volatilitäten in den Griff bekommen, ist die Lebensader. Vor dem Live-Handling im Mainnet müssen diese Anpassungen sitzen—sonst ist das Risiko deutlich größer als die oberflächliche Effizienz.
Wenn es hingegen gelingt, definiert es nicht nur Hertzflow, sondern wird zum Standard für die gesamte Kategorie.
https://testnet.hertzflow.xyz
@Hertzflow_xyz