Ich glaube, dass Cross-Chain-Design oft missverstanden wird, weil sich viele auf Geschwindigkeit und Gebühren konzentrieren, während sie ignorieren, wo das eigentliche Risiko liegt.
Die meisten Bridges setzen darauf, dass Liquidität irgendwo bereitsteht, um Transfers zu ermöglichen. Das funktioniert, bis die Liquidität knapp, fragmentiert oder von einer kleinen Gruppe von Akteuren abhängig ist, die sich wie erwartet verhalten.
Dusk’s CCT-Modell geht einen anderen Weg. Anstatt durch einen Pool zu wandern, wird das Asset aus dem Verkehr auf einer Kette entfernt und auf einer anderen Kette durch einen Burn-und-Mint-Prozess neu erstellt.
Der Tradeoff ist interessant.
Du bist nicht auf verfügbare Liquidität angewiesen und musst dir keine Sorgen über Slippage machen. Aber das macht das System nicht risikofrei. Die entscheidende Annahme verlagert sich auf die Frage, ob das Burn-Ereignis korrekt verifiziert wird und ob der Mint-Prozess wie beabsichtigt über die Chains hinweg ausgeführt wird.
Mit anderen Worten: Die Frage lautet nicht mehr „Gibt es genug Kapital auf der anderen Seite?“
Sie lautet: „Kann das System mit Gewissheit beweisen, dass die Supply zerstört wurde, bevor anderswo neue Supply erscheint?“
Das fühlt sich weniger nach einem Liquiditätsproblem an und mehr nach einem Koordinations- und Finalitätsproblem.
Mich interessiert, wie Dusk Edge Cases behandelt, in denen eine Seite die endgültige Bestätigung erreicht, während der entsprechende Mint verzögert oder unterbrochen bleibt.
#dusk @Dusk $DUSK
Die meisten Bridges setzen darauf, dass Liquidität irgendwo bereitsteht, um Transfers zu ermöglichen. Das funktioniert, bis die Liquidität knapp, fragmentiert oder von einer kleinen Gruppe von Akteuren abhängig ist, die sich wie erwartet verhalten.
Dusk’s CCT-Modell geht einen anderen Weg. Anstatt durch einen Pool zu wandern, wird das Asset aus dem Verkehr auf einer Kette entfernt und auf einer anderen Kette durch einen Burn-und-Mint-Prozess neu erstellt.
Der Tradeoff ist interessant.
Du bist nicht auf verfügbare Liquidität angewiesen und musst dir keine Sorgen über Slippage machen. Aber das macht das System nicht risikofrei. Die entscheidende Annahme verlagert sich auf die Frage, ob das Burn-Ereignis korrekt verifiziert wird und ob der Mint-Prozess wie beabsichtigt über die Chains hinweg ausgeführt wird.
Mit anderen Worten: Die Frage lautet nicht mehr „Gibt es genug Kapital auf der anderen Seite?“
Sie lautet: „Kann das System mit Gewissheit beweisen, dass die Supply zerstört wurde, bevor anderswo neue Supply erscheint?“
Das fühlt sich weniger nach einem Liquiditätsproblem an und mehr nach einem Koordinations- und Finalitätsproblem.
Mich interessiert, wie Dusk Edge Cases behandelt, in denen eine Seite die endgültige Bestätigung erreicht, während der entsprechende Mint verzögert oder unterbrochen bleibt.
#dusk @Dusk $DUSK