Eyani Sorkar

I’m playing Binance Summer Camp! Learning, exploring, and completing new challenges along the way. Let’s see how far we can go! #BinanceSummerCamp #BinanceSummerCamp

#dusk $DUSK @Dusk hat vor Kurzem an grenzüberschreitendem E-Commerce herumgebastelt. In unserem Chat hat er beiläufig gesagt: „Am nervigsten ist gerade KYC – wenn man auf eine neue Plattform wechselt, muss man jedes Mal wieder Ausweis und Kontoauszüge neu einreichen, und die Unterlagen sind überall verstreut. Ich habe in meinem Kopf sofort Dusk’s Citadel-Protokoll aufblitzen sehen. Ich bin zurück und habe in meinen Notizen nachgeschaut – je mehr ich darüber nachdachte, desto klarer wurde mir, dass das im Grunde derselbe Graben ist wie sein Ärger.“

Der Kern von Citadel ist „doppelte Offenlegung“ zu vermeiden. Beim herkömmlichen KYC sammelt und speichert jede Plattform deine Identitätsdaten für sich. Je weiter die Daten verstreut sind, desto mehr Risikopunkte für Leaks und Missbrauch gibt es. Citadel setzt auf den Ansatz von Zero-Knowledge-Beweisen: Du musst nur beweisen, dass „du eine Compliance-Prüfung bei einer bestimmten Institution bestanden hast“ – aber du musst nicht die Originaldaten wie Ausweis, Adresse oder Vermögensdetails bei jeder neuen Plattform erneut einreichen. Die Aufsichtsbehörden bekommen ihr „grünes Licht“, aber deine konkreten Informationen werden nicht für alle sichtbar ausgerollt.

Als mein „Täter“-Verwandter das hörte, war seine erste Reaktion: „Aber wie weiß die Plattform, dass du nicht geschummelt hast?“ Genau das trifft den Punkt. Zero-Knowledge kann beweisen, dass „eine bestimmte Aussage wahr ist“, aber es kann dir nicht dabei helfen zu beurteilen, ob „die ausstellende Stelle selbst vertrauenswürdig ist“. Wenn die Institution, die die Prüfung ursprünglich gemacht hat, ein Problem hat – zum Beispiel angegriffen wird oder von Anfang an nicht ernsthaft geprüft hat – dann ist das Vertrauen, das auf ihrer Signatur beruht, auch mit noch so ausgefeilter Beweiskonstruktion am Fundament trotzdem leer. Das ist im Grunde dasselbe Problem wie bei meiner früheren Grübelei über Phoenix/Moonlight beim Umwandeln über Konten hinweg oder über Sozu-Flüssigkeits-Staking-Zertifikate, die sich lösen – die Mathematik auf Protokollebene ist noch so hübsch, wenn irgendwo in der vorgelagerten Kette selbst etwas schiefgeht.

Und in der Realität gibt es noch ein noch unangenehmeres Problem: In unterschiedlichen Rechtsräumen ist die Definition von „Compliance“ ohnehin nicht einheitlich. Die MiCA der EU, die KYC-Standards in den USA und die regulatorischen Maßstäbe in Asien unterscheiden sich überall. Citadel beweist „Konformität mit einem bestimmten Standard“. Aber wenn eine Institution Kunden aus mehreren Rechtsräumen gleichzeitig bedienen will: Welcher Standard soll dann verwendet werden, um diesen Beweis zu erzeugen? Und wer entscheidet im Streitfall, welche Auswertung der Prüfung in einem Rechtsraum für einen anderen gilt? Dafür gibt es aktuell keine klar erkennbare Antwort.

Ich denke immer noch darüber nach: Klingt eine Zero-Knowledge-Compliance-Bescheinigung nicht nach einer perfekten Zwischenlösung – wird damit nur das alte Problem „Wem vertrauen wir, dass er die Prüfung durchführt?“ unter die Oberfläche verlagert und mit einer anderen technischen Verpackung versehen?

@Dusk $DUSK #dusk #Binance

#dusk $DUSK @Dusk 那晚很晚了,城市外面已经安静下来,我却还盯着一张本不该在这个点看的表格。发行计划表通常不会让人熬夜,但这次它做到了。我坐着盯了好一会儿才动笔。平静地,不带多余的杂音。

Hier gibt es eine Spannung, über die kaum jemand offen spricht. DUSK ist auf 1 Milliarde Tokens gedeckelt: 500 Millionen sind bereits im Umlauf, die restlichen 500 Millionen werden in einem Zeitraum von 18 bis 36 Jahren schrittweise freigegeben. Das ist kein kurzfristiges „Release-zu-der-Klippe“-Szenario, sondern eine bewusst verlangsamte Kurve – damit Staker über Jahrzehnte hinweg kontinuierlich Rewards erhalten, ohne dass es die Liquidität einmalig hart trifft. Klingt verantwortungsvoll, sogar ein bisschen genau richtig langweilig.

Aber eine stabile Freigabe ist nur dann harmlos, wenn die Nachfrage mithält. Und hier ist die Nachfrage nicht das reine Handelsvolumen von Privatanlegern, sondern dass Institutionen tatsächlich Netzwerkressourcen nutzen, Assets ausgeben, abwickeln und handeln – sodass laufend echte Gebühren anfallen, von denen Staker profitieren. Das ist die Uhr für „Business-Umsetzung“, nicht die Uhr für „Marktzyklus“. Der Takt von Institutionen hängt vom Zeitplan der Rechtsprüfung, den Lizenzprozessen und den internen Risk-Management-Gremien ab; der Emissionsplan muss sich nicht danach richten, ob die Rechtsabteilung schon fertig ist.

Das eigentliche Problem ist also nicht: „Wird Dusk übernommen?“ Das können fast alle Projekte behaupten, die ernsthaft Infrastruktur aufbauen. Die eigentliche Frage lautet: Kann das institutionelle Handelsvolumen innerhalb eines Zeitfensters entstehen, das mit der Timeline konkurrieren kann, mit der über dreißig Jahre emittiert wird? Wenn die Emission wie geplant läuft und Institutionen dauerhaft eher dünn vertreten sind, verdienen Staker im Grunde Rendite auf einer leeren Autobahn mit Gebühren.

Das bringt mich auf einen Vermieter: Er hat einen 30‑jährigen Mietvertrag mit sehr guten Konditionen unterschrieben, aber in den ersten Jahren gibt es erst einmal eine Leerstandsphase – während er die Hypothek trägt und gleichzeitig hofft, dass wirklich ein Mieter auftaucht.

Ich glaube nicht, dass das zeigt, dass das Modell von Dusk grundsätzlich falsch ist. Langfristige Emissionskurven sind eine rationale, nicht überstürzte Art des Aufbaus. Aber „rational“ und „dringend“ waren nie dasselbe; der Markt belohnt normalerweise nur das Letztere.

Also – glaubt hier wirklich jemand ernsthaft, dass das institutionelle Handelsvolumen so schnell innerhalb des Zeitraums auf den Plan kommt, der für Inhaber von Coins wirklich zählt? Oder setzen wir eigentlich alle stillschweigend auf einen Punkt, der sich über Jahrzehnte zieht, und tun dabei so, als würden wir gerade einen ganz normalen Zyklus traden?

@Dusk $DUSK #dusk

#dusk $DUSK @Dusk Letzte Nacht habe ich nachgesehen, nach welchem Mechanismus eine von Dusk ausgegebene Wertpapier-Emission tatsächlich zur Compliance gezwungen wird. Eigentlich dachte ich, das dürfte Off-Chain passieren – also vermutlich würde irgendein Registrierungs-/Zulassungssystem vor einer Überweisung erst die Berechtigung prüfen, so läuft es bei den meisten Plattformen für tokenisierte Vermögenswerte. Ergebnis: Die Regeln liegen gar nicht Off-Chain.

XSC, also der geheime Wertpapier-Vertragsstandard von Dusk, erlaubt es dem Emittenten, Compliance-Bedingungen direkt in den Token selbst einzubetten – ein Wertpapier kann so programmiert werden, dass es nur zwischen qualifizierten, in der Whitelist geführten Inhabern übertragen werden kann. Diese Prüfung läuft auf Protokollebene ab, nicht indem man im Nachhinein noch einen zusätzlichen Genehmigungsprozess drüberlegt. Die Einschränkung folgt dem Vermögenswert – nicht indem irgendwo anders in einer Datenbank verfolgt wird, wer überhaupt berechtigt ist, ihn zu halten.

Das ist nicht der Ausfallmodus, den ich erwartet hatte. Die meisten „Compliance“-Tokenisierungsansätze, die ich gelesen habe, haben nämlich eine Lücke: Der Token wird on-chain transferiert, aber die eigentliche Berechtigungsprüfung passiert in einem Off-Chain-System, das on-chain gar nicht verifizierbar ist. Wenn dieses System ausfällt, wenn Daten veralten oder wenn es schlicht nicht abgefragt wird, kann on-chain nichts mehr verhindern, dass die Übertragung trotzdem durchrutscht.

In den Design-Details ist eine Sache besonders auffällig: Dieser Standard muss auch den Fall von verlorenen privaten Schlüsseln behandeln, und zwar so, dass dabei keine gesetzlichen Pflichten des Emittenten verletzt werden. Wenn ein Aktionär den Zugriff verliert, schreibt das Wertpapierrecht trotzdem vor, dass er nicht dadurch automatisch sein gesamtes Eigentum verliert. XSC muss dem Emittenten ausreichend Kontrolle geben, um genau das umzusetzen – aber diese Kontrolle darf wiederum kein Hintertürchen werden und damit die Grundannahme „on-chain erzwungene Durchsetzung“ selbst untergraben.

Das erinnert mich an ein Gebäude: Der Aufzug lässt sich nicht einfach durch einen vielleicht gerade abwesenden Sicherheitsdienst unten öffnen, sondern die Karte wird erst direkt am Aufzugseinlass geprüft.

Man muss allerdings klar sagen: Was ich gelesen habe, sind die behaupteten Designziele dieses Standards. Ich habe nicht aus eigener Sicht gesehen, wie ein echter Aktionärsdatensatz im Grenzfall an die Realität stößt – wie es sich bei echtem Schlüsselverlust oder bei Änderungen der Gerichtsbarkeit in tatsächlich regulierten Vermögenswerten konkret verhält, habe ich keine realen Fälle gesehen.

Ich denke auch noch darüber nach: Wird die Berechtigungsprüfung auf Token-Ebene wirklich die Compliance-Lücke schließen – oder wird das Problem nur dorthin verschoben, „wer“ die in den Token eingebettete Regel aktualisieren darf, und „wie schnell“ diese Aktualisierung möglich ist?

@Dusk $DUSK #dusk #BinanceSquareFamily

#dusk $DUSK @Dusk Gestern habe ich nachgesehen, wie Moonlight und Phoenix eigentlich miteinander verbunden sind. Ich hatte zunächst vermutet, dass es wohl ähnlich wie die meisten „Dual-Mode“-Systeme funktioniert – man wählt bei der Registrierung einen Pfad, bleibt im Grunde dauerhaft dort, und wenn man wechseln will, dann läuft das wie ein manuelles Schritt-für-Schritt-Verfahren über etwas Ähnliches wie eine Cross-Chain-Brücke. Doch so ist es nicht.

Es gibt eine Funktion namens convert, die DUSK auf atomarer Ebene zwischen zwei Zuständen austauschen kann: Phoenix (verdeckte/geschützte Zustände) und Moonlight (öffentlich). Pro Umschlag gibt es keinen separaten Bridge-Contract, keinen Zwischen-Puffer mit verpackten Assets, und auch keine „Asset schwebt dazwischen“-Phase. Du beweist, dass du auf der Seite, in die du umwandeln willst, die Eigentumsrechte hast – dann gehen die Mittel direkt über.

Das sieht auf den ersten Blick nicht so aus. Die meisten Chains, die „optionale Privatsphäre“ anbieten, machen daraus zwei halb unabhängige Systeme: hier ein Shielded-Fonds-Pool, dort ein öffentlicher Kontostand. Das Umschalten fühlt sich dann eher an wie „erst abheben, dann einzahlen“ – zwei getrennte Ereignisse, mit einem zusätzlichen Zeitfenster, in dem etwas schiefgehen kann. Hier hingegen ist es eine einzige atomare Operation auf der Ebene des Transfer Contract. Während der Umwandlung befindet sich kein Asset jemals in einem „unterwegs“-Zwischenzustand.

Diese Sache ist besonders wichtig für die zuvor erwähnte interne/organisatorische Arbeitsumgebung. Ein Fonds erhält Einzahlungen über Moonlight öffentlich, und muss anschließend einen Teil der Positionen in Phoenix-geschützte Salden übertragen, um eine Transaktion auszuführen, die nicht gesehen werden soll. Das ist keine „Brückenkonstruktion“ zwischen zwei Produkten, sondern eine Operation auf derselben Buchhaltung – durchgehend nachweisbar.

Das erinnert mich an den Unterschied in derselben Bankfiliale: Geld vom Girokonto ins Schließfach zu verschieben versus Geld per Überweisung an eine andere Institution zu schicken und anschließend wieder zurück. Im ersten Fall bleiben die Mittel die ganze Zeit beim selben Verwahrer; es gibt kein solches Zeitfenster, in dem das Geld technisch „bei einem unbestimmten Dritten“ liegt.

Man muss aber auch klar sagen: Ich habe diese Inhalte aus den Design-Notizen zur convert-Funktion in den Engineering-Update-Logs gelesen, nicht daraus, dass ich es selbst in einem echten Wallet praktisch durchgespielt habe. Wie es sich unter realer Transaktionslast verhält, und ob es bei teilweisen Konvertierungen Randfälle gibt – das habe ich nicht verifiziert.

Ich frage mich außerdem: Wenn man geschützte und öffentliche Salden auf demselben atomaren Abrechnungs-Track hält, senkt das wirklich das operative Risiko für Institutionen? Oder sorgt „jederzeit umwandelbar“ eher dafür, dass Aufsichtsbehörden stärker genau diesen Umwandlungsakt beobachten – statt jede einzelne der beiden Statusarten separat?

@Dusk $DUSK #dusk #Binance

#dusk $DUSK @Dusk Ich habe nach der Chainlink-Partnerschaft gesucht und dabei mit der üblichen Geschichte gerechnet: „Wir haben Price Feeds für DeFi integriert.“ Tatsächlich ist es aber noch spezifischer: Chainlink DataLink ist so eingerichtet, dass es offizielle NPEX-Börsendaten On-Chain liefert — positioniert als exklusiver Oracle für diese Daten auf Dusk. Nicht generische Marktpreise. Der eigene Datenfeed der regulierten Börse.
Dieser Unterschied ist wichtiger, als es klingt. Die meisten DeFi-Price-Feeds aggregieren Off-Chain-Quellen und hoffen, dass sie korrekt sind. Was NPEX hier liefert, sind Daten aus einem eigenen Orderbook einer lizenzierten MTF — also dieselben Zahlen, für die die Börse unter ihrer Lizenz verantwortlich ist. Chainlink Data Streams schiebt das anschließend als Low-Latency, High-Frequency Updates nach vorn — das ist vor allem dann relevant, wenn die Quelle diejenige ist, der ein Emittent oder ein Auditor in einem Streit vertrauen würde.
Das verändert, was ein „Oracle“ für regulierte Assets leisten muss. Auf einer normalen DeFi-Chain muss ein Oracle vor allem schwer zu manipulieren sein. Hier muss es nachvollziehbar auf einen realen, lizenzierten Datenanbieter zurückgehen — der Feed muss als Beweismittel standhalten, nicht nur als Zahl, die ein Smart Contract auslesen kann.
Das hat mich an den Unterschied zwischen der Temperaturanzeige einer Wetter-App und einer offiziellen Messstation erinnert, die in einem Rechtsstreit über einen verspäteten Flug als Nachweis verwendet wird. Beide zeigen eine Zahl an. Nur eine davon ist als Aufzeichnung dessen zulässig, was passiert ist.
Da ist noch ein zweiter Punkt, den ich nicht erwartet hatte: Chainlinks CCIP wird außerdem für grenzüberschreitende Transfers des DUSK-Tokens selbst genutzt — wobei Dusk die Eigentums- und Rate-Limit-Kontrollen für die Token-Contracts beibehält, statt das an eine gebündelte Bridge abzugeben. Anderes Problem, derselbe Partner: verifizierte Daten auf der einen Seite, kontrollierte Token-Bewegungen auf der anderen.
Noch eine Anmerkung: Das wird weiterhin als Integration „in Arbeit“ im Rahmen des NPEX-Onboardings beschrieben, nicht als vollständig Live-Feed, den ich selbst verifiziert habe — ob die Daten unter realen Streit- oder Audit-Bedingungen standhalten, kann ich von außen nicht bestätigen.
Ich drehe es noch im Kopf: Macht es das Ganze vertrauenswürdiger, wenn man das Oracle an die Daten einer einzigen regulierten Börse koppelt? Oder verlagert es einfach nur das Problem „Vertrauen in eine Quelle“ statt es zu beseitigen?

#dusk $DUSK @Dusk Gestern, als ich nach den Anbindungsmöglichkeiten von NPEX gesucht habe, dachte ich zunächst, der Abschnitt zum Custody-Setup würde der am wenigsten spannende Teil sein – „Geldbörsenverwahrung von Vermögenswerten“ klingt so offensichtlich, dass niemand sich dafür extra hinsetzt und einen Artikel schreibt. Dann stellte sich heraus: NPEX betreibt kein eigenes Custody-System, sondern hat einen Kooperationspartner namens „Cordial Systems“ gewählt. Und genau der Grund für diese Wahl ist der Teil, der wirklich zu schreiben ist.

Am Anfang dachte ich, institutionelles Custody sei im Grunde nur „eine etwas sicherere Exchange-Wallet“. Aber Cordial bietet tatsächlich Self-Custody bzw. ein lokal bereitgestelltes Custody-Modell: Die Institution betreibt intern die MPC-Wallet-Infrastruktur – statt die privaten Schlüssel an einen Dritten zur Verwahrung abzugeben. Cordials eigene Beschreibung ist zudem sehr klar: Man betreibt diese Technologie selbst und ist dabei nicht von schweren Drittanbieter-„Zwischenschritten“ abhängig.

Wenn man das einmal sauber auseinander hat, wird klar, wer NPEX ist: NPEX ist keine Krypto-nativen Exchange, die einfach Blockchain „drüberstülpt“, sondern eine Wertpapierbörse mit einer MTF-Lizenz – sie trägt daher ohnehin die regulatorischen Verpflichtungen rund um die Frage, wer die Vermögenswerte der Kunden kontrollieren kann. Wenn ein Drittanbieter-Custodian die privaten Schlüssel im Namen verwahrt, wird damit genau diese Art von Gegenparteirisiko wieder eingeführt, die das regulierte Finanzsystem eigentlich bekämpfen will. Self-Custody bedeutet, dass NPEX die operative Kontrolle behält – und nicht die „Nervenzentren“ an einen Zwischenakteur abgibt, in der Hoffnung, der werde schon nicht ausfallen oder den Zugriff nicht vorübergehend einfrieren.

Das erinnert mich an den Unterschied zwischen: sich eine Bank-Box mieten und statt dessen einen eigenen Safe vor Ort installieren. Beide können Vermögenswerte aufbewahren – aber nur der zweite lässt einen nicht allein wegen einer Entscheidung eines Dritten ausgesperrt zurück.

Nachdem das klar war, ergibt sich auch, warum man das als „Zero-Trust“-Custody bezeichnet – und nicht nur als „sicheres“ Custody. Der Schwerpunkt liegt nicht darin, Hacker abzuwehren, sondern die Abhängigkeit davon zu entfernen, ob ein einzelner Custody-Anbieter überhaupt „mitspielt“. Das ist ein ganz anderer Bedrohungsrahmen als bei den meisten Wallet-Designs für Privatanleger.

Man muss aber auch sagen: Diese Inhalte stammen aus Kooperationsankündigungen und aus Cordials eigener Produktvorstellung. Ich habe die tatsächlichen Custody-Workflows nicht mit eigenen Tests verifiziert – wie sich das bei realen institutionellen Handelsvolumina verhält, kann ich von außen nicht bestätigen.

Und ich frage mich noch: Bedeutet Self-Custody für eine regulierte Börse wirklich eine echte Risikoreduktion – oder wird damit nur die operative Last von einem spezialisierten Custody-Anbieter auf das eigene Technikteam von NPEX verlagert?

@Dusk $DUSK #dusk

#dusk $DUSK @Dusk Gestern habe ich nach Unterlagen zu Dusk Payments gesucht. Ursprünglich dachte ich, EURQ sei einfach noch ein weiterer an den Euro gekoppelte Stablecoin; in der On-Chain-Finanzinfrastruktur gibt es davon ohnehin viele, und meistens ist es nur ein Preisinstrument zur Verankerung. Nachdem ich jedoch die Informationen zum Emittenten Quantoz gelesen hatte, merkte ich: Diese Einschätzung war falsch.

EURQ ist kein Stablecoin, sondern ein Token für E-Geld (EMT). Der Unterschied klingt vielleicht nicht so akademisch—doch Stablecoins sind typischerweise private Emissionen, bei denen der Emittent eine „1:1-Ablösung“ zusagt; im Hintergrund vertraut man dabei auf die Reserven und die Reputation des Emittenten. EMTs sind dagegen im Rahmen einer regulierten Rechtsordnung anerkannte E-Geld-Instrumente; im Kern sind sie viel näher an digital dargestelltem gesetzlichem Euro als an einem Token, das nur den Euro-Kurs nachverfolgt. Dieser Unterschied mag in normalen Zahlungsfällen kaum ins Gewicht fallen, aber im Szenario der Wertpapierabwicklung macht er einen völlig anderen Unterschied.

Das führt mich zu einer Frage, an die ich vorher nicht gedacht hatte: Selbst wenn man eine Kette so aufsetzt, dass Aktien und Anleihen vollständig als Besitzrechte abgebildet und übertragen werden, und man dafür alles „on-chain“ bringt—wenn das Geld, das zur Abwicklung verwendet wird, immer noch „ein bestimmter privater Stablecoin“ ist, löst die Kette eigentlich nur die Hälfte des Compliance-Problems: Die Vermögensseite ist compliant, aber der Cash-Bein ist es nicht.

NPEX ist als regulierte MTF-Handelsbörse nicht in der Lage, bei Wertpapierabwicklungen ein gewöhnliches Stablecoin-Projekt als Gegenpartei für den Cash-Bestand zu verwenden. Deshalb ist der Kooperationspartner auch kein beliebiges Stablecoin-Projekt, sondern ein Emittent von E-Geld, der ebenfalls im MiCA-Rahmen anerkannt ist.

Das brachte mich auf den Gedanken an den Unterschied zwischen „frei konvertierbarer Währung“ und „Rechnungseinheit“ im grenzüberschreitenden Handel. Letztere lässt sich überall zum Preisstellen verwenden, aber wenn es dann wirklich zur Verrechnung kommt, akzeptieren die Banken nur erstere.

Nachdem ich das durchdacht hatte, fand ich es ziemlich schlüssig: Eine Kette, die Abwicklung auf MTF-Niveau ermöglichen will, ist dann nicht vollständig—wenn nur entweder das Asset-Bein oder das Cash-Bein reguliert ist. EURQ ergänzt nicht nur Liquidität, sondern die Compliance-Qualifikation des Cash-Beins.

Ich muss allerdings dazusagen: Was ich bisher gesehen habe, sind weiterhin nur offizielle Mitteilungen des Emittenten und der Börse. Wie EURQ sich in der tatsächlichen Wertpapierabwicklung konkret verhält—wie es um Abwicklungsverzögerungen steht und welches Kontrahentenrisiko besteht—dafür habe ich keine unabhängigen verifizierten Daten erhalten.

Ich denke noch weiter darüber nach: Wenn sowohl das Cash-Bein als auch das Asset-Bein auf dem gleichen Compliance-Niveau gemacht werden können, bedeutet das dann, dass „On-Chain-MTF“ der echten Anerkennung durch Regulierungsstellen nur noch den Nachweis des Handelsvolumens fehlt? Oder lauern dazwischen noch Fallstricke, die ich bisher nicht gesehen habe?

@Dusk $DUSK #dusk

#dusk $DUSK @Dusk Ich habe immer wieder gedacht, dass ein regulierter Asset-Transfer genauso funktioniert wie ein normaler Token-Transfer: erst signieren, dann broadcasten und anschließend herausfinden, ob es funktioniert hat.
Dann fiel mir auf, dass die spannendere Frage auch zuerst kommen kann: Darf der Empfänger es überhaupt empfangen?
Bei regulierten Assets können Eignungskriterien und Übertragungsbeschränkungen vor der Einreichung des Transfers geprüft werden, statt das Problem erst zu entdecken, nachdem die Transaktion fehlgeschlagen ist.
Das verändert die Art des Fehlers. Ein normaler Token fragt „Kann diese Adresse empfangen?“ Ein reguliertes Asset muss möglicherweise fragen: „Ist diese Adresse rechtlich berechtigt, dieses Asset gerade jetzt zu empfangen?“
Wie das Überprüfen deines Ausweises, bevor du zu einer gesperrten Tür gehst, statt erst am Eingang herauszufinden, dass du nicht reindarfst.
Genau hier wird Dusk’s Ansatz für mich interessant: Compliance ist nicht unbedingt ein „Formular“ neben der Transaktion. Die Regel kann Teil der Transferlogik des Assets werden.
Ich frage mich nur: Macht es die Märkte mit regulierten Assets tatsächlich reibungsloser, wenn man die Eignungsprüfungen früher durchführt – oder wird die Komplexität einfach besser versteckt?

#dusk $DUSK @Dusk Ich habe gestern Abend im Dusk’s Citadel-Papier herumgestöbert—halb auf der Suche nach etwas anderem—und bin an einer Zeile hängen geblieben, die länger war, als ich vorhatte. Was ein KYC-Zertifikat auf diesem Ding tatsächlich ist, strukturell. Nicht die Marketing-Version, das eigentliche Objekt.

Es ist ein NFT. Der gleiche Standard wie bei jedem Profilbild-Collectible, das du schon gesehen hast, wie jemand damit angibt. Das ist es, was deine Compliance-Lizenz darunter trägt.

Hat einen Moment gedauert, bis ich begriffen habe, warum das nicht völlig verrückt ist. Überall sonst ist der ganze Wert eines NFTs das Sichtbar-Machen—genau darum geht’s: Du willst, dass Leute wissen, dass du es besitzt. Citadel dreht das absichtlich um. Das Value-Feld des NFTs ist eine Stealth-Adresse, nichts ist mit einer echten Identität verknüpft. Und wenn du die Lizenz wirklich verwendest, zeigst du das NFT überhaupt nicht: Du weist den Besitz mit einem Zero-Knowledge-Proof nach, und ein privates Session-Cookie sorgt dafür, dass du beim nächsten Mal nicht ständig diesen Proof erneut erbringen musst. Keine Galerie. Keine Spur. Genau das eine, wodurch ein NFT anderswo überhaupt ein NFT ist—das jeder sehen kann, der sieht, wer es hält—fehlt hier.

Dann saß ich da und merkte: KYC und „beweise, dass du ein Collectible besitzt“ sind keine unterschiedlichen Probleme, sobald man einmal unter die Haube schaut. Beides braucht nur einen Nachweis für ein Zertifikat, ohne dass jemand live für dich bürgt. NFTs haben den Ownership-Proof-Teil schon vor Jahren geknackt. Citadel hat nur den Teil weggelassen, ihn vorzuzeigen—weil es für eine Lizenz, bei der das nie der Punkt war, vor allem die Haftungsfrage war.

Sollte klar sagen, was ich geprüft habe und was nicht. Ich habe bestätigt, dass die Architektur so ist, wie Dusk sie beschreibt: das NFT, die Stealth-Adresse, der Session-Cookie-Flow. Was ich nicht prüfen konnte, ist, ob das auch standhält, wenn echte Umsätze dort durchlaufen. Ob genügend Transaktionen über die Zeit hinweg einem entschlossenen Beobachter etwas zum Puzzeln liefern, selbst ohne jemals die Lizenz selbst zu sehen. Ich habe nichts gefunden, das das anspricht, also werde ich nicht so tun, als wüsste ich es.

Ich grüble noch darüber, ob diese Lücke für jemanden, der einmal durch das Onboarding klickt, überhaupt eine Rolle spielt—oder ob sie erst Jahre später real wird, für wen auch immer gerade die Kryptografie stresst, sobald genug Volumen da ist, um sie dagegen zu testen.

@Dusk

#dusk $DUSK Ich habe mir die NPEX-Partnerschaft angesehen, in der Erwartung, dass die Schlagzeilenzahl sich auf Assets bezieht — genau diese Zahl wird doch von allen zitiert: 300 Mio. EUR+ geplant onchain. Was mich dann wirklich gestoppt hat, war eine andere Zahl, die direkt daneben stand: NPEX hat bereits heute über 200 Mio. € eingesammelt und 17.500+ aktive Investoren direkt an der Börse selbst. Das ist keine Prognose. Das ist ein bestehender, lizenzierter Markt mit echten Menschen, die bereits drin sind.

Dadurch wurde mir klar, was „Assets erben die NPEX-Lizenz“ tatsächlich bedeutet, sobald man sich damit befasst. Dusk schafft keine regulatorische Legitimität von Grund auf neu. Es leiht sie sich — die MTF-, Broker- und ECSP-Lizenzen gehören zu NPEX, einem Unternehmen, das existierte und operierte, bevor all das überhaupt onchain ging. Was zu Dusk übergeht, ist nicht nur Kapital, sondern ein bereits regulierter Markt, der beschließt, seinen bestehenden rechtlichen Status in neue Schienen einzuspeisen.

Ich hatte angenommen, eine Partnerschaft wie diese würde bedeuten, dass das Onchain-Produkt im Grunde schon fertig ist und nur noch auf Integrationsarbeit wartet. Ist es aber nicht. Es ist noch nicht live. All diese bestehende Größenordnung — die 200 Mio. €, die 17.500 Investoren — sitzt derzeit auf der traditionellen Infrastruktur von NPEX, nicht auf der von Dusk.

Das erinnerte mich an eine lang etablierte Bank, die ankündigt, dass sie auf ein neues Core-Banking-System umstellt. Die Bank ist real, die Kunden sind real, die Einlagen sind real. An der Tatsache ändert das nichts: Das Migrieren tatsächlicher regulierter Infrastruktur, von der echte Kontoinhaber abhängen, damit sie korrekt funktioniert, dauert deutlich länger als die Partnerschaftsankündigung.

Ergibt Sinn, warum es so aufgebaut ist. Eine regulierte Börse kann ihr Geschäft nicht einfach über Nacht in eine neue Kette einpacken — jeder dieser 17.500 Investoren ist durch Regeln geschützt, die sich sauber auf das abbilden müssen, was das alte System ersetzt, sonst ist die Lizenz selbst in Gefahr.

Ich drehe immer noch die Frage im Kopf, wie viel von Dusk’ tatsächlicher Glaubwürdigkeit in der nahen Zukunft darauf beruht, dass NPEX diese Migration sauber hinbekommt — und wie viel von der Aufregung wirklich auf eine Lizenz fällt, die aktuell noch komplett off-chain läuft.

@Dusk $DUSK #dusk

#dusk $DUSK Ich wollte herausfinden, warum Dusk auf seiner nativen Ebene überhaupt zwei getrennte Transaktionsmodelle betreibt – schließlich klang Phoenix, das „Shielded“-Modell, so, als würde es den Datenschutz bereits abdecken. Tatsächlich war Phoenix früher die ganze Geschichte, und das war ein Problem.

Phoenix funktionierte ursprünglich wie ein vollständiges Anonymitätsprotokoll – derselben Kategorie wie Zcash: Es gab keine Möglichkeit, eine Zahlung einem Absender nachzuverfolgen. Das wurde jedoch bewusst zurückgedreht. Sender-zu-Empfänger-Identifizierbarkeit wurde hinzugefügt, um das Token regelkonform zu halten – nachdem man erkannt hatte, dass genau die Art von Asset, die vollständig unnachverfolgbar ist, eine Exchange-Listing-Anfrage sehr schnell zurückziehen lässt. Direkt danach kam Moonlight – ein komplett öffentliches, kontobasiertes Modell, das neben Phoenix liegt, mit einer One-Click-Konvertierung zwischen beiden.

Ich hatte angenommen, dass eine datenschutzorientierte Chain ihre Privatsphäre einfach weiter verschärft. Dusk ging jedoch bewusst den umgekehrten Weg: Zuerst baute man die vollständig anonyme Version, stieß dann aber auf die Realität, dass keine regulierte Exchange etwas listen will, das sie nicht überwachen kann, und ergänzte deshalb ein transparentes zweites Modell, damit Nutzer je nach Bedarf jederzeit in die Sichtbarkeit wechseln können.

Es fühlt sich an, als hätte man beides – ein nummeriertes Konto und ein normales Girokonto bei derselben Bank – mit einem Button für Überweisungen am selben Tag zwischen ihnen. Nicht weil eines der Konten kaputt ist. Sondern weil manche Zahlungen leise bleiben müssen und andere eine Belegkette brauchen, und es die Größenordnung dieser Lücke falsch einschätzt, wenn man jede Transaktion durch denselben Modus zwingt.

Ergibt Sinn, sobald man sich anschaut, für wen das tatsächlich gebaut ist. Eine rein anonyme Chain ist in dem Moment eine Haftung, in dem eine Institution nachweisen muss, woher die Gelder stammen. Eine rein transparente dagegen unterläuft den eigentlichen Grund, warum es überhaupt Privacy-Technologie gibt. Dass der Nutzer pro Transaktion auswählen kann – statt einmal für die ganze Chain – ist der Teil, der sich für tatsächliche regulierte Nutzung gebaut anfühlt, statt für theoretischen Datenschutz.

Ich bin immer noch am Abwägen, ob die meisten Nutzer am Ende beide absichtlich verwenden, sobald Mainnet live ist, oder ob Moonlight still und einfach zum Default wird, weil es unkomplizierter ist, während Phoenix nur dann erreicht wird, wenn jemand es ganz konkret braucht. @Dusk

Ich wollte mir ansehen, wie eine tokenisierte Anleihe tatsächlich abgewickelt wird, und erwartete, dass am Ende das Token selbst das letzte Wort hat – ich besitze das Token, ich besitze den Vermögenswert, fertig. Stimmt aber meistens nicht.

Die meiste Tokenisierung läuft weiterhin so, dass die echte Abwicklung über ein CSD erfolgt, also über dieselbe zentrale Wertpapierverwahrstelle, die traditionelle Börsen seit Jahrzehnten nutzen. Das Token on-chain ist eine Darstellung, die auf dieses System zurückverweist. Der tatsächliche rechtliche Eigentumsübergang passiert aber weiterhin off-chain – auf den alten Schienen, mit der alten Geschwindigkeit. „Sofortige“ Abwicklung bei vielen tokenisierten RWAs ist also nicht wirklich sofort – es ist nur eine schneller wirkende Oberfläche über einem genauso langsamen Back-End.

Native Emission ist Dusk’s Antwort auf diese konkrete Lücke – keine Neubezeichnung von Tokenisierung. Der Vermögenswert wird direkt on-chain erstellt, sodass der Ledger-Eintrag auf nichts anderes zeigen muss – er ist Abwicklung, Eigentumsnachweis und Compliance-Check zugleich, an einem Ort, auf einmal.

Erinnerte mich daran, wie man sofort eine Trackingnummer bekommt, wenn man online etwas bestellt – während das Paket tatsächlich erst später im LKW ist. Das eine sagt dir, dass etwas kommt. Das andere ist das Ding selbst. Die meisten tokenisierten RWAs sind die Trackingnummer. Native Emission soll der LKW sein.

Erklärt auch, warum das bisher fast niemand wirklich richtig macht. Wenn man das CSD entfernt, muss die Kette selbst die gesamte Compliance- und Abwicklungslast tragen, die eine regulierte Börse früher an Legacy-Infrastruktur abgegeben hat – das ist ein deutlich härteres Problem, als nur ein Token zu prägen, das einen Off-Chain-Vermögenswert gespiegelt abbildet.

Ich denke aber noch darüber nach, wie viele Emittenten tatsächlich bereit sind, auf diesen Legacy-Rückfall zu verzichten. Ein CSD ist zwar langsam, aber es sind auch Jahrzehnte von juristischem Präzedenzfall, die jede Transaktion absichern. Ersetzt native Emission dieses Vertrauen tatsächlich – oder verlagert es nur die Last, die es nachzuweisen gilt, auf ein System ohne bisherige Historie?

@Dusk $DUSK #dusk

#dusk $DUSK

Ich habe Hedger, Dusk‘ neue Privacy-Layer für die EVM-Seite, angeschaut und erwartet, dass er so funktioniert wie die meisten vertraulichen Transaktionssysteme, die ich zuvor gesehen habe: Betrag verstecken, verbergen, wer beteiligt ist, fertig. So ist es nicht.

Dusk hat bereits ein Datenschutz-Tool für seine native Layer namens Zedger, und Zedger kann volle Anonymität liefern — denn die native Layer nutzt ein UTXO-Modell, denselben strukturellen Trick, auf den Zcash und Monero setzen, um die Verbindung zwischen Absender und Empfänger vollständig zu durchbrechen. Hedger kann das nicht. Es ist für die EVM-Seite gebaut, die auf einem kontobasierten Modell läuft. Und ein kontobasiertes Modell bedeutet: Jede Transaktion ist aus Designgründen immer noch an eine sichtbare Adresse gebunden. Kein UTXO-Shuffling, hinter das man sich verstecken könnte.

Stattdessen macht Hedger etwas bewusst Engeres: Es versteckt den Betrag — mithilfe homomorpher Verschlüsselung in Kombination mit Zero-Knowledge-Proofs, um zu beweisen, dass eine Transaktion gültig ist, ohne die Zahl offenzulegen, während Absender- und Empfängeradressen weiterhin sichtbar bleiben. Vertraulich, nicht anonym.

Es erinnerte mich an einen Kontoauszug, bei dem die Transaktionsbeträge geschwärzt sind, aber die Kontonamen oben weiterhin stehen. Du siehst genau, wer von wem bezahlt hat. Du kannst nur nicht sehen, wie viel. Für ein persönliches Wallet könnte sich das wie ein halbes Privacy-Tool anfühlen. Für einen regulierten Finanzmarkt ist das allerdings die einzige Datenschutz-Variante, die ein Regulator absegnen würde — du musst wissen, wer handelt, nicht die Größe des Trades.

Erklärt auch, warum Dusk zwei getrennte Systeme gebaut hat. Zedger‘ volle Anonymität passt zur nativen Layer von Dusk, bei der das gesamte Design bei „Privacy zuerst“ beginnt. Hedgers engere Vertraulichkeit passt zu DuskEVM, wo der ganze Zweck darin besteht, in die vorhandenen Ethereum-Tools und kontobasierten Standards einzusteigen, die Institutionen bereits verwenden — volle Anonymität war von Anfang an nicht mit diesem Ausgangspunkt kompatibel.

Ich überlege immer noch, ob „vertraulich, aber nicht anonym“ am Ende die nützlichere Designentscheidung für die institutionelle Übernahme ist — oder ob es einfach bedeutet, dass Hedger Privacy mit einem Sternchen ist, über das die meisten, die darüber posten, vermutlich gar nicht nachdenken bzw. es nicht lesen.

#dusk $DUSK @Dusk

Ich bin heute in mein TBV-Testnet-Vault gegangen, um meine TBV-Testnet-Vault zurückzulösen, und erwartete, dass das BTC sofort wieder landet, sobald ich die Transaktion bestätigt habe – genau wie bei jeder anderen DeFi-Auszahlung, die ich bisher gemacht habe. Hat es nicht. Es gibt eine eingebaute Wartezeit, bevor die Auszahlung tatsächlich durchgeht, selbst bei einer komplett legitimen Inanspruchnahme.

Ich habe herausgefunden, dass diese Verzögerung kein Testnet-„Lag“ ist, sondern eine sogenannte Claim-Delay – und die ist bewusst eingebaut: ein Zeitfenster, das es ausschließlich den anderen Vault-Teilnehmern geben soll, um den Anspruch anzufechten, falls etwas nicht stimmt, bevor sich das Bitcoin wirklich in Bewegung setzt. Selbst wenn nichts falsch ist, muss ein echter Claimsteller dennoch warten, weil das Protokoll im Voraus keine Möglichkeit hat zu wissen, dass genau dieser Anspruch der „saubere“ ist.

Hat mich dazu gebracht, noch etwas anderes nachzuprüfen, was ich angenommen hatte – nämlich ob mein gesperrtes BTC jemals irgendwo anders wiederverwendet werden könnte, während es dort stillliegt, so wie Sicherheiten in vielen traditionellen, und sogar in einigen DeFi-Kreditmodellen, stillschweigend re-hypothecated werden. Babylons eigene Antwort ist ganz klar: Das geht nicht. Nicht gepoolt, nicht fungibel, nicht re-hypothecated – per Design.

Es fühlte sich an wie ein Schließfach, bei dem die Bank die Inhalte nicht sofort herausgibt, sobald du deinen Ausweis zeigst – sie halten es kurz zurück, falls jemand anderes mit einem legitimen Anspruch auf dieses Fach zuerst etwas sagen muss. Langsamer, als einfach deine Sachen zu greifen. Aber es bedeutet, dass niemand unbemerkt mit Inhalten davongeht, die eigentlich unantastbar sein sollten, während du nicht hingeschaut hast.

Das sind zwei übereinander gestapelte Garantien, nicht eine. Das BTC kann nicht hinter deinem Rücken wiederverwendet werden. Und selbst wenn du derjenige bist, der es rechtmäßig herausnimmt, nimmt das System dir trotzdem nicht einfach sofort alles ab – aus Prinzip.

Trotzdem wälzt es den tatsächlichen Tradeoff um: Ein System, das jegliche Re-Hypothecations verweigert, ist sicherer, aber es verzichtet auch auf genau diese Art von Kapital-Effizienz, die stBTC-ähnliche Produkte für viele erst so attraktiv gemacht hat. Ist das die richtige Entscheidung für ein Protokoll, das sich noch selbst beweisen will – oder macht das Entfernen dieser Effizienz TBV schwieriger, mit schneller werdenden, lockereren Wettbewerbern mitzuhalten, sobald die auftauchen?

@BabylonLabs_io $BABY #baby

Ich habe heute versucht, denselben TBV-Testnet-Vault auf einen zweiten Lending-Markt zu zeigen, nachdem ich meine Aave-v4-Position glattgestellt hatte. Ich dachte mir, dass ich einfach das gleiche Collateral-Record irgendwo anders neu ausrollen kann, ohne das ganze Peg-in nochmal zu machen. In der App gibt es dafür keine Option. Ich habe herumgeklickt und nach einer Einstellung gesucht, die ich übersehen hatte—irgendeinen Schalter, um zu einem bestehenden Vault ein zweites Protokoll hinzuzufügen. Ich habe dann testweise ein komplett neues Peg-in von Grund auf gestartet, nur um zu prüfen, ob sich ein frischer Vault anders verhält. Beide Male dieselbe Wand.

Ich hab eine Weile damit gesessen, bis es wirklich Klick machte: Das ist kein fehlendes Feature, sondern eine absichtlich eingebaute Grenze. Ein Vault, eine App, Ende—und wenn du einen zweiten Use Case willst, dann pegest du nochmal von Null an.

Ich bin davon ausgegangen, dass der ganze Sinn von „programmierbarem Bitcoin-Collateral“ darin besteht, es zu stapeln—also dass man denselben BTC, der eingesteckt ist, in so viele Protokolle wie möglich einbindet, je komposabler desto besser. In Wahrheit ist es das Gegenteil: Ein einzelner Vault, der gleichzeitig zwei Apps ausgesetzt ist, bedeutet zwei unterschiedliche Liquidations-Logiken und zwei verschiedene Exit-Regeln, die beide denselben BTC beanspruchen. Babylon hat diese Tür nicht aus Versehen halb offen gelassen. Sie ist zu.

Es fühlte sich an wie ein Vermieter, der dir nicht erlaubt, eine Wohnung unterzuvermieten, solange dein eigener Mietvertrag aktiv ist—selbst an jemanden Seriösen, selbst nur kurzfristig. Nicht weil der zweite Mieter riskant wäre. Sondern weil zwei Personen mit einem gleichzeitigen, laufenden Anspruch auf ein und dieselbe Einheit das eigentliche Risiko sind, egal wer sie sind.

Ergibt Sinn, wenn man darüber nachdenkt, speziell bei Bitcoin. Komposabilität ist normalerweise DeFi’s großes Versprechen, aber die Spending-Bedingungen eines UTXO sind im Moment seiner Erstellung festgelegt. Zwei live Protokolle bedeuten zwei Sätze von Exit-Regeln, die versuchen, ein einziges Lock gleichzeitig zu steuern, und falls sie sich jemals darüber uneinig sind, wer was triggern darf, gibt es keinen Patch, der das nachträglich fixt—Bitcoin macht keine Upgrades an einem Script, das einmal bereits festgeschrieben ist.

Ich bin immer noch nicht sicher, ob das ein Limit der Testnet-Phase ist, das später gelockert wird, oder ein permanenter Tradeoff—Komposabilität wird bewusst aufgegeben, insbesondere weil darunter Bitcoin steckt und nicht ein EVM-Asset, das diese Art von Komplexität sicher „absorbieren“ kann.

@BabylonLabs_io $BABY #baby

Ich bin heute auf dem TBV-Testnetz zu einer neuen Vault gegangen, um etwas einzuzahlen, und die App hat mich aufgehalten, bevor ich einfach nur eine Zahl eingeben konnte – sie wollte die Einzahlung stattdessen in zwei separate Vaults aufteilen, anstatt in eine.

Ich habe erst nicht verstanden, warum, bis ich die Bezeichnungen gelesen habe. Die eine heißt „Opfer-Vault“, ist so dimensioniert, dass sie das abdeckt, was das Protokoll als Erstes einziehen will, falls etwas schiefgeht, und sie steht zuerst in der Liquidationsreihenfolge. Die andere heißt „geschützte Vault“ und hält den Rest; sie steht an zweiter Stelle. Die App akzeptiert nicht einfach nur Sicherheiten. Sie entscheidet im Voraus, welcher Teil meines BTC als Erstes den Treffer abbekommt – bevor überhaupt eine Position offen ist.

Erinnerte mich an einen Boxer, der seine führende Hand fest umwickelt, noch bevor der Kampf überhaupt beginnt. Nicht weil die führende Hand schwächer wäre – sondern weil sie als Erste Kontakt bekommt, also genau dafür wird sie gebaut. Noch ist nichts geworfen worden. Die Strategie ist schon im Wrap eingebaut.

Die meisten Lending-Protokolle behandeln deine Sicherheiten als einen einheitlichen Haufen – die Liquidation frisst proportional hinein, ohne Vorausplanung. TBV hat offenbar entschieden, dass das nicht gut genug ist. Es will einen bestimmten Verlust-Absorber vor den Sicherheiten platzieren, um die du dich eigentlich kümmern willst; das wird beim Einzahlen festgelegt, nicht erst während der Liquidation improvisiert.

Ich bin heute nur noch bis zur Dimensionierung der Opfer-Vault gekommen, bevor mir die Zeit ausgegangen ist. Ich konnte nicht wirklich testen, was passiert, wenn die Opfer-Vault vollständig eingezogen wird und meine Position immer noch im Minus ist – ob die Liquidationsreihenfolge der geschützten Vault wirklich unangetastet bleibt, oder ob „zweiter in der Reihe“ trotzdem „irgendwann an der Reihe“ bedeutet, wenn die Opfer-Seite nicht genug ist.

Ich bin neugierig, ob schon jemand eine Position tatsächlich über die Opfer-Vault hinaus in die geschützte geschoben hat und wie das aussah.

@BabylonLabs_io $BABY #baby $SKYAI $VIC #Binance

Ich habe heute auf meiner Testnet-Position den Bereich „Loans“ geöffnet, nur um zu beobachten, wie sich mein Health Factor bewegt – und bin in ein komplett anderes Loch gefallen: die Spoke-Liste der Hub.

Aave v4 liquidiert hier nicht auf die normale Art BTC. Es gibt eine separate Entität namens BTCVaultSwap, die als eigener WBTC-Spoke registriert ist und direkt am Hub neben meinem Collateral sitzt. Das ist der Liquiditätsanbieter, der Sofort-Liquidationen möglich macht – er zahlt dem Liquidator sofort in WBTC aus, sobald mein Health Factor 1,0 überschreitet, während mein echtes BTC auf Bitcoin bleibt und sich nur auf einer langsameren Zeitleiste entwindet.

Aber das ist nur eine von zwei Türen nach draußen. Der andere Weg, die direkte Redemption, ist für niemanden geöffnet – er ist auf Application Vault Keepers beschränkt, also Parteien, die buchstäblich bei der Erstellung meines Vaults anwesend waren und dessen Bitcoin-Redemption-Key besitzen. Ich kann für diese Route nicht irgendeinen zufälligen Liquidator wählen – es muss jemand sein, der bereits ab Tag eins in meinem Vault hinterlegt ist.

Es fühlte sich an, als hätte meine Wohnung zwei Ausgänge: Nur einer ist eine Tür, die jeder mit einem Schlüssel benutzen kann – die andere geht nur für die Person auf, die beim Bau des Gebäudes dort stand.

Der Collateral-Factor liegt bei 78%, der maximale Liquidationsbonus ist auf 10% gedeckelt, also kann ich die exakte Rechnung beobachten, die entscheidet, wann das auslöst. Aber hängen geblieben ist nicht die Mathematik – sondern dass hier „trustless“ nur für eine der beiden Ausgänge vollständig gilt. BTCVaultSwap ist Open Market, ohne Erlaubnis. Application Vault Keepers sind eine geschlossene Menge, die im Moment festgelegt wird, in dem ich den Vault öffne – nicht etwas, das später ein Markt entscheidet.

Niemand kann mein BTC auf die eine oder die andere Weise stehlen, und das ist real. Aber ich hatte angenommen, „trustless“ würde bedeuten, dass jeder Pfad gleichermaßen offen ist – und das ist nicht so. Eine Tür ist ein Markt. Die andere ist eine Gästeliste, in die ich mich beim Check-in eingetragen habe.

Ich arbeite immer noch daran heraus, ob das eine echte Einschränkung ist oder einfach so aussieht, wenn „trustless“ nicht überall permissionless ist. Bin gespannt, ob Application Vault Keepers so fest bleiben, sobald die Mainnet-Liquidität echtes Geld ist.

@BabylonLabs_io $BABY #baby $IDOL $UAI

Ich bin heute wieder ins Aave-v4-Testnetz zurückgegangen, diesmal mit dem Ziel, eine Liquidation für meine native-BTC-Position zu erzwingen, statt einfach dabei zuzusehen, wie der Vault dort untätig herumsteht. Ich wollte sehen, was auf dem Weg raus tatsächlich passiert — nicht nur, wie es von außen aussieht.

Mit Wrapped BTC ist eine Liquidation sofort — das ERC-20 wird in derselben Transaktion beschlagnahmt und verkauft, ohne Wartezeit. Native BTC über ein Trustless Bitcoin Vault funktioniert nicht auf diese Weise. Die Sicherheiten liegen in einem Taproot-Skript direkt auf Bitcoin selbst, daher bedeutet das Auflösen einer Position, dass man über die bei der Einzahlung eingerichteten vordefinierten Exit-Pfade routet, die BitVM3 gesetzt hat — nicht über eine einfache On-Chain-Beschlagnahme. Diese Sicherheit ist im Voraus fest eingebaut. Die Geschwindigkeit nicht.

Erinnert mich an den Unterschied zwischen meiner Schwester und meinem Bruder, wenn einer von beiden mir Geld schuldet. Meine Schwester überwweist es mir per Venmo sofort zurück, sobald ich frage. Mein Bruder sagt: „Ja, ich regel das“, und technisch macht er es auch immer — nur dauert es ein paar Tage und erfordert noch eine Erinnerung per Textnachricht. Gleiche Schuld, gleicher Vertrauensrahmen, aber eine völlig andere Geschwindigkeit bei der Eintreibung. Native BTC fühlt sich für mich an wie mein Bruder. Die Rückzahlung steht nicht zur Debatte. Nur der Zeitpunkt.

Das ist ein seltsames Trade-off für einen Lending-Markt. Liquidationen gibt es, um das Protokoll genau in dem Moment zu schützen, in dem es schnell gehen muss — bei einem volatilen Rückgang, einer Spirale aus uneinbringlichen Schulden. Wenn das Beschlagnahmen nativer BTC-Sicherheiten strukturell langsamer ist als das Beschlagnahmen von Wrapped BTC, dann schätzt die Spoke-Bepreisung dieses Assets nicht nur das Bitcoin-Risiko, wie ich es gestern im Kopf hatte. Sie bepreist auch eine Liquidationsverzögerung, mit der ERC-20-Sicherheiten nie umgehen mussten.

Im Testnetz ist allerdings noch nicht klar, wie groß diese Verzögerung in der Praxis tatsächlich ist, weil bisher nichts schnell genug in Bewegung geraten ist, um sie richtig zu strapazieren. Aber wenn Liquidationen langsamer und teurer in der Ausführung sind, bedeutet das dann nicht, dass native BTC langfristig eine höhere Risikoprämie tragen sollte als Wrapped BTC — und nicht eine niedrigere — obwohl es das „echte“ Asset ist?

@BabylonLabs_io $BABY #baby #Babylon $KOMA $1000RATS

Habe einen weiteren XPDUSDT-Long basierend auf meinem Trading-Plan eröffnet. Das Setup hat nicht wie geplant funktioniert, also bin ich frühzeitig mit einem kontrollierten Verlust ausgestiegen, statt die Emotionen die Oberhand gewinnen zu lassen. Jeder Trade liefert wertvolles Feedback, und ein konsequentes Risikomanagement ist der Schlüssel zum langfristigen Erfolg. #ShareMyTradFi