Kite kann Agenten beim Bezahlen helfen. Aber wer entscheidet, ob die Arbeit erledigt wurde?
Eine schnelle Antwort bedeutet nicht immer, dass jemand die Arbeit ordnungsgemäß erledigt hat.
Angenommen, ich lasse einen Agenten für Marktdaten in Echtzeit bezahlen. Er erhält fast sofort eine Antwort, aber die Zahlen sind eine Stunde alt. Der Anbieter kann sagen, dass er die Daten geliefert hat. Mein Agent kann sagen, dass er die Daten erhalten hat. Doch das Einzige, was ich brauchte – aktuelle Preise –, fehlte.
Das ist der Aspekt von Kite, der mich interessiert. Das vorgeschlagene Zahlungssystem kann Bedingungen an eine Dienstleistung knüpfen, statt jede abgeschlossene Zahlung als Beweis dafür zu behandeln, dass alles gut gelaufen ist.
Aber ich komme immer wieder auf einen Punkt zurück: Wer legt diese Bedingungen fest?
Wenn ich für aktuelle Preise bezahle, möchte ich einen Zeitstempel und eine klare Begrenzung dafür, wie alt die Daten sein dürfen. Eine schnelle Antwort mit veralteten Zahlen sollte nicht als erfolgreich erbrachte Dienstleistung gelten.
Und selbst wenn ich eine Rückerstattung bekomme: Was passiert, wenn mein Agent auf Grundlage dieser Informationen bereits eine Entscheidung getroffen hat?
Das Geld zurückzubekommen, macht nicht alles wieder gut.
Die größere Herausforderung besteht für mich nicht darin, Agenten dazu zu bringen, für Dienstleistungen zu bezahlen. Es geht darum sicherzustellen, dass sie tatsächlich das bekommen, wofür sie bezahlt haben.
Würdest du einem Anbieter Geld zahlen, der pünktlich geantwortet, aber veraltete Informationen geschickt hat?
🔥 Gainers are moving fast today! $AGT is up almost 95%, while $Q is up 58%. $EPIC , $ICNT, $AVA , $GTC, $SAND and others are also showing strong moves. I’m watching these coins to see which one can keep the momentum going. 🚀 $AVA $EPIC
Ich habe mir gerade diese drei Charts angesehen, und der Kaufdruck ist heute wahnsinnig stark!
$AGT +139.43% | $0.0400
AGT hat einen gewaltigen Sprung von etwa $0.016 auf $0.0425 gemacht. Die Käufer haben kräftig zugegriffen, aber der lange obere Docht lässt mich vermuten, dass es zuerst zu einem Rücksetzer kommen könnte.
$ICNT +31.54% | $0.1493
ICNT ist endlich aus seinem langen Abwärtstrend ausgebrochen. Ich halte nach einer Long-Position Ausschau, wenn die Käufer diesen Ausbruch weiter verteidigen. Der nächste Widerstand liegt bei $0.1554.
$TIA +28.85% | $0.6878
TIA wirkt auf mich stärker. Höhere Tiefs, stetige Käufe und jetzt ein Test bei $0.7147. Ich tendiere hier zu einer Long-Position, besonders wenn der Kurs über dieses Hoch ausbricht.
Von diesen drei gefällt mir der Chart von TIA im Moment am besten. $TIA $DUSK
Welche Coin wird als Nächstes am stärksten steigen?
Ich versuchte zu verstehen, warum Dusk zwei verschiedene Möglichkeiten hat, Werte zu senden – und die Antwort war nicht so einfach, wie ich erwartet hatte.
Moonlight ist öffentlich und nutzerkontobasiert.
Phoenix ist geschützt und nutzt Zero-Knowledge-Beweise.
Zuerst klingt das so, als wäre Phoenix im Grunde nur die private Version von Moonlight.
Ganz so einfach ist es nicht.
Mit Moonlight kann man den Absender, den Empfänger, den Betrag und den Nonce direkt On-Chain sehen.
Phoenix arbeitet dagegen mit geschützten Notizen (Shielded Notes). Die Transaktion belegt, dass der Ausgabenvorgang gültig ist, ohne diese Details öffentlich offenzulegen. Außerdem verwendet sie Nullifier, sodass eine Notiz nicht einfach zweimal ausgegeben werden kann.
Auch wenn beides als Transaktionen bezeichnet wird, erledigen sie also unterschiedliche Aufgaben.
Da ist noch ein weiteres Detail, das ich interessant fand.
Dusk empfiehlt Moonlight für Exchange-Integrationen, weil öffentliche Konten viel einfacher zu scannen und abzugleichen sind. Phoenix benötigt ein anderes Custody- und Scanning-Setup, weil die relevanten Transaktionsinformationen nicht in gleicher Weise öffentlich dort vorliegen.
Das bedeutet nicht, dass Phoenix schlechter ist.
Wenn der gesamte Zweck Vertraulichkeit ist, dann ist das Verbergen der Information die Funktion.
Aber es führt zu einem anderen operativen Problem.
Privatsphäre erfordert Rechenleistung.
Dusk hat sogar dedizierte Prover-Infrastruktur, um die Zero-Knowledge-Beweise zu erzeugen, die Phoenix nutzt. In der aktuellen Prover-Dokumentation wird ein Mindestbedarf von 4 CPU-Kernen und 8 GB RAM genannt und es wird darauf hingewiesen, dass die Beweiserzeugung single-threaded ist.
Das hat mich dazu gebracht, nicht nur auf die Transaktionsanzahl zu schauen.
1 Phoenix-Transaktion und 1 Moonlight-Transaktion erhöhen beide den Zähler um eins, aber sie repräsentieren nicht die gleiche Art von Arbeit.
Daher würde ich nicht nur darauf achten, ob Dusk mehr Transaktionen bekommt.
Ich würde darauf achten, wie viel private Aktivität das Netzwerk bewältigen kann, bevor die zusätzliche Beweis-Rechenlast anfängt, zum limitierenden Faktor zu werden.
An genau dieser Stelle wird der Unterschied zwischen Moonlight und Phoenix viel interessanter.
#dusk @Dusk Ich habe damit begonnen, mir Dusk Privacy als eine einfache Frage anzusehen:
„Wie viele Transaktionsdaten werden verborgen?“
Das stellte sich jedoch als das falsche Maß heraus.
Dusk verfügt über öffentliche Moonlight-Konten und geschützte Phoenix-Überweisungen. Bei Phoenix sind Absender, Empfänger und der Betrag nicht öffentlich sichtbar. Aber das heißt nicht, dass die Transaktion zu einem Informations-Schwarzloch wird.
Der spannendere Teil ist die kontrollierte Sichtbarkeit.
Eine Partei kann Zugriff auf Ansichten nutzen oder selektive Offenlegung anwenden, wenn tatsächlich Belege benötigt werden. Citadel geht die Idee noch weiter, indem es jemandem ermöglicht, nachzuweisen, dass er über einen gültigen Nachweis verfügt, ohne die zugrunde liegenden persönlichen Daten on-chain offenzulegen.
Das eigentliche Maß ist also nicht „wie privat die Kette ist?“
Sondern:
„Wie viel Information muss offengelegt werden, um etwas zu beweisen?“
Dieser Unterschied ist wichtig, weil regulierte Finanzsysteme normalerweise nicht mit beiden Extremen funktionieren können.
Volle Transparenz kann Salden und Geschäftspartner offenlegen.
Volle Intransparenz kann Eignungsprüfungen und Compliance erschweren.
Selektive Offenlegung liegt zwischen diesen beiden.
Ein unangenehmer Punkt ist, dass mehr Privatsphäre ein System nicht automatisch besser macht. Der echte Test kommt dann, wenn mehrere Parteien unterschiedliche Teile derselben Transaktionsdaten benötigen.
Ich beobachte, ob Dusk diese Offenlegung auf ein Minimum beschränken kann, während reale Marktprozesse skaliert werden. $DUSK $SOL $BTC
Denn die spannende Frage lautet inzwischen nicht mehr, ob Daten verborgen werden können.
Sondern, ob das System beweisen kann, was bewiesen werden muss, ohne alles andere offenzulegen.
Was ist für datenschutzorientierte Finanzen am wichtigsten?
#dusk @Dusk Gestern Abend habe ich in den NPEX-Partnerdokumenten von Dusk nachgelesen und bin dabei in die Annahme hineingeraten, dass „Tokenisierung einer Sicherheit“ im Grunde bedeutet, einen übertragbaren Token zu prägen und das war’s. Dann habe ich mir angesehen, was sie tatsächlich versprechen zu automatisieren, und der Umfang ist größer als eine reine Transferfunktion. Eine Dividendenzahlung, ein Kupon bei einer Anleihe, ein Aktiensplit, eine erzwungene Stornierung von Anteilen – das sind keine einfachen Übertragungen. Das sind vom Emittenten ausgelöste Ereignisse, die gleichzeitig jeden Inhaber erreichen müssen, ohne Opt-out. Die eigenen Zahlen von Dusk dazu sind es wert, genauer betrachtet zu werden: Die Automatisierung der Dividendenausschüttung kann die damit verbundenen Kosten im Vergleich zu papierbasierter Verarbeitung um bis zu 90 Prozent senken, und der Dokumentationsaufwand für KMU bei der Tokenisierung von Eigenkapital fällt um 20 bis 30 Prozent. Das klingt nach dem Gewinn, aber die Zahl, die mich innehalten ließ, war eine andere. Eine Senkung der Kosten um 90 Prozent spielt nur dann eine Rolle, wenn die Logik für 100 Prozent der Inhaber korrekt ausgeführt wird – denn eine Dividende, die auch nur eine Wallet verfehlt, ist kein Rabatt, sondern ein Compliance-Versagen. Traditionelle Märkte absorbieren dieses Risiko über Batch-Abstimmungen, bei denen Fehler erkannt und korrigiert werden, bevor die Abwicklung finalisiert. On-chain erzwingt das XSC-Vertragsmodell von Dusk diese Ereignisse kryptografisch auf Protokollebene – das entfernt das Risiko der Abstimmung, nimmt aber zugleich das Sicherheitsnetz weg, das für diese Rolle genutzt wurde. Worauf ich jetzt achte, ist nicht, ob Dusk eine Dividende günstiger verarbeiten kann, sondern ob ein Emittent eine Corporate Action ändern oder rückgängig machen kann, nachdem sie bereits on-chain ausgeführt wurde. Denn im traditionellen Finanzwesen werden Fehler von Menschen behoben, und Blockchains beheben sie durch Unveränderlichkeit. Zählt es als Fortschritt, wenn man das Sicherheitsnetz zusammen mit dem Mehraufwand entfernt – oder ist es nur eine andere Art von Risiko, die weiter nach unten verlagert wurde? @Dusk #dusk $DUSK
#dusk @Dusk Ich bin heute aufgewacht und ehrlich gesagt fühlte sich der Markt an wie halb verschlafen, halb wach. Diese seltsame Stimmung, in der sich nichts bewegt, aber auch nichts tot ist. Also habe ich statt Chart- Doomscrolling Citadel 2s Doku wieder aufgeschlagen—frag nicht warum, es fühlte sich einfach gut an, etwas Technisches zu lesen.
Ich habe versucht, den exakten Punkt zu finden, an dem Citadel eigentlich entscheidet, ob einem Nutzer Zugriff gewährt wird. Ich bin weiter gescrollt, habe ständig darauf gehofft, ihn zu erwischen. Doch nie.
Turns out: Das war nie Citadels Aufgabe.
Der Nutzer weist nach, dass er eine gültige Lizenz besitzt, ohne zu verraten, wer er ist; der Lizenzvertrag auf Dusk bestätigt das; ein Nullifier wird angehängt; ein Session-Cookie wird ausgestellt. Liest sich wie „Zugriff gewährt“, oder?
Aber der letzte Schritt im Ablauf ist der, den niemand erwähnt. Der Service Provider holt sich diese Session, prüft das Cookie lokal und trifft dann seine eigene Entscheidung, ob er den Service tatsächlich freischaltet. Citadel bestätigt nur, dass die Credentials echt sind und nicht schon wiederverwendet wurden. Es sagt nichts darüber, ob diese Credentials überhaupt gut genug für das sind, was der SP will.
Kleine Unterscheidung, aber sie verändert, worum sich das Ganze eigentlich dreht. Eine gültige Session sagt dir, dass der Beweis korrekt von jemandem erzeugt wurde, der eine echte Lizenz besitzt—ohne doppeltes Ausgeben. Sie sagt aber nicht, ob dieses Attribut-Set zu dem passt, was dieser konkrete SP heute verlangt. Das eine ist ein Matheproblem; Dusk löst es einmal und fertig. Das andere ist ein Business-Call: Jeder SP macht das selbst, und es kann sich schon morgen ändern, ohne dass man das Beweissystem überhaupt anfassen muss.
Worauf ich ein Auge habe, ist nicht, wie schnell Beweise auf Dusk generiert werden. Sondern ob SPs wirklich echte Policy-Logik auf Citadel aufbauen—oder ob die Verifikation still und leise zu einem weiteren „Pass/Fail“-Gate mit zusätzlichen Schritten wird.
Wenn ein System beweisen kann, dass etwas wahr ist, aber nicht entscheiden kann, was diese Wahrheit bedeutet, dann fühlt es sich so an, als wäre der echte Engpass nie der Beweis gewesen. Es war immer die Partei, die die Frage stellt.
$DUSK
$TUT
$PORTAL
Wohin sollte als Nächstes das Zugriffsmodell von Citadel 2 gehen?
Ich habe damit begonnen, mir Dusk’s „~10s deterministische Abrechnung“ anzusehen, und zunächst klang es wie eine einfache Geschwindigkeitskennzahl.
Aber bei regulierten Märkten ist der wichtigere Teil nicht die 10 Sekunden.
Sondern das, was nach diesen Sekunden passiert.
DuskDS verwendet Succinct Attestation, wobei ein Block den Ablauf Vorschlag → Validierung → Ratifizierung durchläuft, bevor er final wird. Einmal finalisiert gibt es keine normale Reorg mehr, auf die man warten müsste.
Das verändert die Art, wie man über Abrechnung nachdenkt.
Wenn ein Asset und der Zahlungs-Leg so entworfen sind, dass sie gemeinsam abgewickelt werden, dann ist ein vorhersehbarer Endzustand wichtiger als nur zu sagen „Transaktionen sind schnell“.
Aber es gibt einen wichtigen Detailpunkt, den ich nicht ignorieren würde.
@Dusk hat DuskVM und DuskEVM als separate Ausführungspfade. DuskVM wird direkt über DuskDS abgewickelt, während DuskEVM einen eigenen Sequencer und ein eigenes Finalitätsmodell hat.
Also „Dusk hat deterministische Finalität“ ist allein nicht genug Information.
Die eigentliche Frage ist:
Welcher Teil des Workflows verlässt sich tatsächlich auf DuskDS-Finalität?
10 Sekunden lassen sich leicht zitieren.
Die schwierigere Kennzahl ist, wie konsistent der gesamte Workflow unter realen Marktbedingungen einen einzigen Endzustand erreicht.
#termmax @TermMax Ich habe mir die Live-Zahlen von @TermMax angesehen, statt nur die Risikomitteilung zu lesen. Das TVL liegt bei 31,22 Mio. $, ist in den letzten 30 Tagen um 7,2 % gefallen – vom Peak nahe 49–55 Mio. $, wobei der geliehene Wert mitgezählt wird. Normales Atmen für Lending mit festem Zinssatz, nicht der spannende Teil. Was mich gestoppt hat, war die Oracle-Konfigurationsseite.
#TermMax läuft Chainlink und RedStone als primäre Feeds, Standard-Setup. Aber die Heartbeat-Werte für MC_PTs, ETH+, xUSD und mehrere PT-Tokens liegen alle bei 86400. Das sind 24 Stunden zwischen garantierten Updates, außer es löst zuerst eine Abweichungs-Schwelle aus. In einem Tag kann bei einer gehebelt positionierten Konstruktion viel passieren, ohne dass dabei die Preis-Feed-Bepreisung, auf die geschaut wird, jemals erreicht wird.
Backup-Feeds erzählen eine zweite Geschichte. USDS hat Chainlink als primär und Chronicle als Backup. MC_PTs hat keine gelistet. Ein Feed, kein Fallback – für ein Asset, das aktiv als Sicherheiten eingesetzt wird.
Die Liquidationsformel macht das konkret. Die liquidierte Sicherheit wird berechnet als Schuldbetrag mal Schuldpreis mal Penalty, geteilt durch den Preis der Sicherheit. Der Sicherheitenpreis steht im Nenner. Wenn dieser Preis zu niedrig reinkommt – veraltet oder verglitcht –, schrumpft der Nenner und der liquidierte Betrag wächst. Die Formel führt korrekt aus. Die Eingabe war falsch.
Auch nicht nur hypothetisch. Im März führte ein Konfigurationsfehler in Oracles von Aave zu einer falschen Preisbildung für wstETH und löste Liquidationen im Umfang von 26,4 Mio. $ über 34 Konten in 15 Minuten aus, wobei Bots knapp 499 ETH einfingen. Anderes Protokoll, gleiche Mechanik: Das Liquidations-Engine vertraute dem Preis, der ihm gegeben wurde.
Der physische Auslieferungsmechanismus von TermMax hilft im Nachhinein, indem er anteilig Sicherheiten verteilt, statt einen schlechten Schuldsaldo stehen zu lassen. Das schützt das Protokoll. Es macht jedoch keine Liquidation rückgängig, die durch eine falsche Zahl ausgelöst wurde.
Nicht das Heartbeat an sich beobachte ich – jede Oracle hat eines. Sondern ob Abweichungs-Schwellen tatsächlich schnellere Updates auf volatilen Märkten erzwingen und wie viele mit nur einem Feed laufen, ohne Backup.
Das TVL zeigt, was angekommen ist. Es sagt nichts darüber, welche Märkte nur einen festgefrorenen Preis davon entfernt sind, eine Liquidation zu erleiden, die nicht hätte passieren dürfen.
#dusk @Dusk Ich habe damit begonnen, Dusk’s öffentliche und geschützte Kontoeinrichtung anzusehen, und mein erster Eindruck war einfach: Nutzer bekommen eine Wahlmöglichkeit. Moonlight für Transparenz und Phoenix für Privatsphäre. Je nachdem umschalten, was Compliance oder Komfort erfordert. Flexibilität als das Verkaufsargument.
Aber die beiden Kontotypen teilen nicht dasselbe Sicherheitsmodell, und genau das lohnt es sich zu vertiefen. Eine Moonlight-Transaktion ist kontobasiert und wird mit einer standardmäßigen BLS-Signatur geprüft. Phoenix-Transaktionen tragen einen Zero-Knowledge-Beweis, der erst bestehen muss, bevor er in den Mempool gelangt. Ein Beweis muss festlegen, dass die geschützte Transaktion gültig ist. Wenn dieses Beweissystem eine Schwäche hat, übernimmt die geschützte Seite dieses Risiko.
Das ist nicht rein theoretisch. Im April 2022 hat Dusk eine kritische Schwachstelle in der PLONK-Implementierung offengelegt, die gefälschte Beweise ermöglichen konnte. Dieses Problem wurde behoben, und Dusk hat seitdem seine Beweis-Infrastruktur weiter ausgebaut. Das signaturbasierte Modell von Moonlight war nicht von dieser spezifischen Kategorie von PLONK-Implementierungsrisiko betroffen.
Das bedeutet nicht, dass Phoenix kaputt ist. ZK-Systeme gehen mit unterschiedlichen kryptografischen Annahmen ein, und diese Annahmen müssen fortlaufend überprüft werden, während ihnen immer mehr Wert zugewiesen wird. Entscheidend wäre letztlich, ob der Sicherheitsprozess mit der Menge an realer Aktivität Schritt hält, die die geschützte Seite nutzt.
Ich beobachte, wie sich die Phoenix-Nutzung im Laufe der Zeit im Verhältnis zu Moonlight entwickelt. $DUSK
$BTC
$SOL
Wenn mehr echter Wert anfängt, über Phoenix zu fließen: Wird sich dann sein Datenschutzvorteil gegenüber der zusätzlichen kryptografischen Abhängigkeit lohnen?
#termmax @TermMax Ich finde die Art, wie @TermMax Upgrades handhabt, ziemlich interessant. Die wichtigste Protokoll-Logik bleibt unveränderlich. Aber zwei wichtige Verträge können dennoch aktualisiert werden: der AccessManager und der TermMaxRouter. Das ergibt für mich Sinn, weil nicht alles dieselbe Flexibilität erfordert. Wenn die Kernlogik sich leicht ändern ließe, müssten Nutzer mehr Vertrauen in zukünftige Upgrades setzen. Aber wenn sich niemals etwas ändern ließe, könnte es schwierig werden, wichtige Probleme zu beheben. TermMax hält den Kern fest und ermöglicht gleichzeitig, dass diese beiden Verträge bei Bedarf aktualisiert werden. Das ist eine einfache Idee, aber eine wichtige für ein DeFi-Protokoll. #TermMax Was bevorzugst du?
Gestern dachte ich, dass ein Blockchain-Identitätssystem vor allem beweisen müsse, dass jemand berechtigt ist, auf etwas zuzugreifen. Ich habe Identität hauptsächlich durch diese Brille betrachtet, weshalb mich die Idee, Berechtigungsnachweise auf der Kette abzulegen, ziemlich schnell überzeugte.
Doch als ich tiefer in Citadel 2 eintauchte, begann ich zu erkennen, dass das eigentliche Problem darin liegt, was preisgegeben wird, wenn man einen Berechtigungsnachweis vorlegt. Citadel 2 wird nicht nur dazu gebaut, zu verifizieren, dass jemand eine gültige Lizenz besitzt, sondern auch darum, die Lizenz und ihre zugrunde liegenden Attribute privat zu halten. Dieser Aspekt hat mir klar gemacht, dass das Vorweisen von etwas und das Offenlegen der Informationen hinter diesem Nachweis tatsächlich zwei sehr unterschiedliche Dinge sind.
Es lohnt sich außerdem, darüber nachzudenken, dass Citadel 2 diesen Prozess über Zero-Knowledge-Proofs ermöglichen will – zusammen mit von LP signierten Lizenzen und der On-Chain-Sitzungsverifikation. Einmal dachte ich, wenn eine Blockchain einen Identitätsanspruch öffentlich verifizieren kann, dann sollte das ausreichen. Aber für echte Dienste ist das Veröffentlichen persönlicher Attribute oder sogar des exakten Berechtigungsnachweises auf der Kette manchmal nicht die praktischste Wahl. Ein Dienst muss möglicherweise nur wissen, dass ein Nutzer gültig ist, während der Nutzer möglicherweise nicht alles über sich preisgeben möchte.
Von dort aus begann ich, Citadel 2 weniger wie ein typisches „On-Chain-Identität“-System zu sehen. Die eigentliche Ambition scheint darin zu bestehen, nachzuweisen, dass ein Nutzer über einen gültigen Berechtigungsnachweis verfügt, ohne den Berechtigungsnachweis selbst offenzulegen – und dennoch die finale Zugangsentscheidung beim Diensteanbieter zu belassen.
Ich weiß immer noch nicht, ob dieses Datenschutzmodell für echte Dienste einfach genug ist, um es im großen Maßstab zu übernehmen. Vielleicht ist das das Nächste, worauf es sich lohnt zu achten. $DUSK $BTC $TRUMP
Ich bin mit der Annahme reingegangen, dass der Zinssatz im Grunde nur eine Zahl ist, die an den Kredit angehängt ist. Dann habe ich mir angeschaut, was passiert, wenn die Bestellung größer wird.
Der Teil, der meine Aufmerksamkeit geweckt hat, ist, dass TermMax nicht den gleichen Zinssatz über die gesamte Bestellung hinweg beibehalten muss.
Kreditgeber können eine Kurve festlegen, bei der sich der Zinssatz ändert, sobald mehr von ihrer Liquidität in Anspruch genommen wird. Kreditnehmer können dasselbe mit ihrem Borrowing-APR (Kreditaufnahme-Zinssatz) tun.
So kann eine kleine Bestellung einen bestimmten Zinssatz erhalten, während eine viel größere Bestellung weiter entlang der Kurve wandert und einen anderen Zinssatz bekommt.
Das ergibt tatsächlich Sinn, wenn man an Liquidität denkt.
Je mehr der verfügbaren Liquidität du verbrauchst, desto wichtiger wird die Preisgestaltung. @TermMax nutzt diese kurvenbasierten Bereiche, um Order-Maker definieren zu lassen, wie sich die Zinssätze über die Bestellung hinweg verändern.
Was ich hier im Auge behalten würde, ist nicht nur der beworbene APR.
Sondern wo sich deine Bestellung auf der Kurve befindet.
Würdest du lieber eine kleinere Summe zu einem besseren Zinssatz nehmen oder die Größe erhöhen, in dem Wissen, dass sich der Zinssatz bewegen kann?
#dusk @Dusk Ich dachte früher, dass die Tokenisierung die größte Herausforderung für RWA ist.
Je mehr ich mir das ansehe, desto weniger glaube ich, dass das stimmt.
Ein Asset onchain zu bringen ist das eine.
Der schwierigere Teil ist alles darum herum.
Wer kann es kaufen? Wer kann es halten? Was sollte privat bleiben? Was muss offengelegt werden? Wie laufen die Assets und die Zahlungen gemeinsam ab?
Die meisten RWA-Projekte starten mit dem Asset.
Was mich an Dusk interessiert, ist, dass es mit dem finanziellen Workflow rund um dieses Asset beginnt.
Citadel übernimmt Identität und selektive Offenlegung. Phoenix kann Übertragungen abgeschirmt lassen, während Moonlight öffentliche Abläufe unterstützt. DuskDS übernimmt Abwicklung und Finalität, während DuskEVM Entwicklern eine EVM-Umgebung bietet.
Nehmen wir einen tokenisierten Fonds.
Ein Investor muss möglicherweise nachweisen, dass er berechtigt ist, ohne seine gesamte Identität oder seine finanzielle Historie offenzulegen. Das Asset kann Übertragungsregeln haben, während die Zahlung und das Asset durch denselben finanziellen Workflow laufen können.
Dann gibt es noch Dusk Trade.
Es fokussiert die praktische Seite: Investoren onboarden, Berechtigung prüfen, handeln, Zahlungen, Abwicklung und erforderliche Offenlegungen.
Das verändert, wie ich mir Dusk vorstelle.
Die Frage ist nicht nur:
„Können wir echte Assets onchain bringen?“
Sondern:
„Können diese Assets tatsächlich onchain funktionieren – innerhalb echter Finanzregeln?“
Das ist das schwierigere Problem.
Und $Dusk hat auch innerhalb des Netzwerks eine Rolle. Es wird für Gas und Staking verwendet – und verbindet den Token mit echter Netzwerkaktivität, statt nur ein Ticker zu sein, der an das Projekt angehängt ist.
Das Risiko bleibt dennoch die Adoption.
Gute Infrastruktur schafft nicht automatisch echte finanzielle Aktivität. Dusk muss weiterhin beweisen, dass Entwickler, Emittenten und Institutionen es tatsächlich nutzen wollen.
#termmax @TermMax Ein Thema, über das ich bei DeFi immer wieder nachdenke, ist, wie stark sich der Zinssatz ändern kann, nachdem man eine Position eingegangen ist.
Man könnte mit einem Zinssatz starten, der attraktiv aussieht, aber ein paar Marktbewegungen später können die Zahlen völlig anders wirken.
Darum finde ich die Debatte „Festzins vs. variabler Zinssatz“ so spannend.
Variable Zinsen geben dir zwar Flexibilität, bringen aber auch Unsicherheit mit.
Bei TermMax ist die Idee eine andere. Feste Zinsmärkte machen Nutzern die Kredit- oder Konditionen für eine festgelegte Laufzeit bekannt – statt ständig mit wechselnden Zinssätzen zu tun zu haben.
Ich denke, diese Art von Planbarkeit könnte für Menschen nützlich sein, die größere Positionen verwalten.
Allerdings birgt das weiterhin Risiken. Liquidität und Laufzeit spielen eine Rolle, und Festzinsen sind nicht automatisch in jedem Markt besser. #TermMax @TermMax Was würdest du wählen?
Aber wo passt Atomic Settlement in der Praxis eigentlich in Dusk? Früher dachte ich, Lieferung gegen Zahlung sei ziemlich einfach. Der Käufer zahlt, der Verkäufer liefert das Asset, und sobald beide Seiten fertig sind, ist auch die Abwicklung erledigt. Ich habe mir nicht wirklich Gedanken darüber gemacht, was dazwischen passieren könnte. Dann habe ich mir Atomic Settlement genauer angesehen und gemerkt, dass die Lücke zwischen Zahlung und Lieferung tatsächlich sehr wichtig sein kann. Was mich besonders angesprochen hat, ist die grundlegende Idee, dass beide Seiten gemeinsam abwickeln sollten. Die Zahlung sollte nicht abgeschlossen werden, während das Asset noch darauf wartet, geliefert zu werden, und das Asset sollte sich nicht bewegen, während die Zahlung noch unsicher ist. Seitdem sehe ich DvP anders. Bei tokenisierten Wertpapieren geht es nicht nur darum, das Asset auf die Blockchain zu bringen. Es braucht einen Mechanismus, damit Zahlung und Übertragung des Assets denselben Endzustand erreichen, ohne dass in der Mitte eine Seite ungeschützt bleibt. Und genau hier wird Dusk für mich interessant. Wenn regulierte Assets auf die Kette gehen, kann die Abwicklung nicht getrennt von Privatsphäre und Compliance betrachtet werden. Die richtigen Parteien müssen möglicherweise verifizieren können, was passiert ist, ohne dass jedes Transaktionsdetail öffentlich gemacht wird. Ich bin nach wie vor neugierig darauf, wie das in der echten Nutzung funktioniert. Das Konzept ergibt für mich Sinn, aber der eigentliche Test ist, was passiert, wenn tatsächlich regulierte Assets und Zahlungen gemeinsam zu einer Abwicklung kommen. @Dusk #dusk $DUSK
Ich dachte früher, dass Leverage in DeFi im Grunde nur eine Sache ist.
Kreditmittel aufnehmen, eine größere Position eingehen und das Risiko verwalten.
Aber wenn man sich TermMax ansieht, gibt es tatsächlich mehrere Möglichkeiten, Leverage zu nutzen – je nachdem, was man erreichen möchte.
Wenn du etwas Einfaches willst, bietet dir der One-Click GT-Kauf eine direkte Möglichkeit, ein gehebeltes Exposure zu erhalten, ohne erst durch ein kompliziertes Setup zu gehen.
Wenn das Geld in eine andere Investition außerhalb von TermMax fließt, macht ein Darlehen mit festem Zinssatz mehr Sinn, weil du die Kosten für die Kreditaufnahme bereits kennst.
Du kannst auch alles innerhalb von TermMax lassen, indem du Kreditaufnahme und Investieren in derselben Strategie kombinierst.
Dann gibt es noch zinstragende Sicherheiten.
Statt dass deine Sicherheiten einfach nur dort liegen und nichts tun, können sie weiterhin Rendite erwirtschaften, während du gleichzeitig geliehenes Kapital nutzt.
Und für jemanden, der deutlich mehr Leverage möchte, geht das mit rekursivem Leverage noch weiter, indem der Kreditaufnahmeprozess wiederholt wird.
Aber dieser Ansatz ist auch mit deutlich höherem Risiko verbunden, daher ist er definitiv nicht für alle geeignet.
Das ist wahrscheinlich der Teil, zu dem ich mit @TermMax immer wieder zurückkomme.
Es ist nicht nur eine einzige Art, Leverage zu erhalten. Du kannst das Setup danach auswählen, wo du das Kapital einsetzen willst und wie viel Risiko du bereit bist einzugehen. #TermMax
Ich habe mir das Dusk-Ökosystem wieder angesehen und etwas entdeckt, das ich wahrscheinlich vorher übersehen hätte. Es ist leicht, bei Dusk nur auf die Chain selbst zu schauen, aber die Anwendungen, die darum herum gebaut werden, erzählen eine etwas andere Geschichte.
Sozu ist ein Beispiel dafür. Es bietet Menschen die Möglichkeit, an Dusk-Staking teilzunehmen, ohne ihre eigene Infrastruktur betreiben zu müssen. Das klingt nach einer kleinen Sache, aber wenn man diese technische Hürde entfernt, kann Staking für mehr Menschen zugänglich werden.
Dann gibt es PieSwap, eine Community-DEX, die auf DuskEVM für Swaps und Liquidität aufgebaut ist. Das ist der Teil, der mich mehr interessiert, denn sobald eine EVM-Umgebung anfängt, Anwendungen in ihrer Umgebung hervorzubringen, wird das Netzwerk mehr als nur etwas, worauf man staked.
Dusk Domains fügt noch eine weitere Ebene hinzu – mit .dusk-Namen für Wallets, Contracts und Anwendungen. Kleine Bausteine wie diese wirken für sich genommen nicht riesig, aber zusammen sorgen sie dafür, dass sich das Ökosystem besser nutzbar anfühlt. @Dusk #dusk $DUSK
$PORTAL
$GPS
Trotzdem komme ich immer wieder auf eine Frage zurück: Welcher Teil des Dusk-Ökosystems hat deiner Meinung nach das größte Potenzial?
WARUM ICH IMMER WIEDER ZU DUSK-AUDITS ZURÜCKKEHRE Ich habe in letzter Zeit tiefer in @Dusk gegraben und ehrlich gesagt hat mich der Audit-Teil mehr gefesselt, als ich erwartet hatte Wenn Menschen über eine Blockchain sprechen, geht das Gespräch normalerweise direkt auf Geschwindigkeit, Privatsphäre oder darauf, was man darauf aufbauen kann Aber für die finanzielle Infrastruktur denke ich, dass es noch eine andere Frage gibt, die genauso wichtig ist Können die Menschen dem System darunter tatsächlich vertrauen? Genau dort fangen Sicherheit und Zuverlässigkeit an, mehr zu sein als nur schöne Worte Dusk arbeitet an Anwendungsfällen im Finanzbereich, bei denen ein kleiner Fehler viel mehr bedeuten kann als nur eine fehlgeschlagene Transaktion. Daher ist es wichtig, das Netzwerk und seine Komponenten durch unabhängige Audits prüfen zu lassen Natürlich heißt ein Audit nicht, dass alles automatisch für immer sicher ist Dinge ändern sich, Code ändert sich und neue Risiken tauchen auf Was mir wichtig ist, ist, dass Sicherheit als fortlaufender Bestandteil beim Aufbau des Netzwerks behandelt wird – nicht als etwas, das erst am Ende hinzugefügt wird, nur um gut dazustehen Und deshalb gefällt mir wahrscheinlich auch die einfache Idee hinter diesem Bild Sicherheit. Zuverlässigkeit. Vertrauen. Damit Onchain-Finanzierung wirklich wachsen kann, denke ich, dass diese drei zusammenkommen müssen #dusk
$DUSK
$HEMI
$AIO
Würdest du einer finanziellen Blockchain ohne ordentliche, unabhängige Audits vertrauen – egal wie gut sich die Technologie anhört?
#dusk Mein Freund hat mir von der Kadcast-Architektur erzählt @Dusk und meinte so: okay, ich schaue mir das selbst an, weil ich es ehrlich gesagt am Anfang nicht wirklich verstanden habe. Also verwendet Dusk Kadcast zum Senden von Blöcken, Transaktionen und Konsensabstimmungen. Das Interessante daran ist, dass es nicht einfach dieselbe Nachricht an jeden Nachbarn schickt. Es nutzt Kademlia und XOR-Distanz, um auszuwählen, welche Peers die Nachricht weiterleiten sollen. Dann gibt es diese Multicast-Baum-Sachen bei denen sich die Nachricht von näheren Peers zu Knoten bewegt, die weiter entfernt sind . So werden weniger unnötige Nachrichten im gesamten Netzwerk herumgeschickt . Außerdem fand ich den Teil zur Fehlertoleranz ziemlich spannend . Wenn einige Knoten offline gehen, können andere Peers immer noch helfen, die Nachricht weiterzuleiten, und es gibt auch eine Datenschutzseite, weil die Nachricht durch verschiedene ausgewählte Knoten weitergeleitet wird, wodurch die ursprüngliche Quelle schwerer auszumachen ist . Ehrlich gesagt dachte ich, Kadcast sei nur so ein Begriff fürs Netzwerken, aber hier passiert tatsächlich ziemlich viel. Das lässt mich darüber nachdenken, wie viel von so etwas zählt, wenn das Dusk-Netzwerk viel geschäftiger wird. $DUSK