_Jason

#dusk $DUSK @Dusk
found a piece of the dusk stack this week that hadnt come up yet in anything ive covered so far - custody, specifically how NPEX actually holds and controls the digital assets involved, rather then just how trading or issuance works.
the answer is a combination of two things - Dusk Vault, described as dusk's institution grade custody solution, and Cordial Treasury, a self hosted wallet technology built by Cordial Systems that dusk partnered with specifically for this.
whats notable is why self hosted mattered so much here specifically. NPEX, being a regulated financial institution, prioritizes maintaining direct control over its own technology stack, and explicitly wants to avoid the risks that come with third party SaaS custody solutions. thats a real institutional constraint, not a preference - handing custody infrastructure over to some external saas provider introduces a dependency and risk surface a regulated exchange generally doesnt want.
cordial treasury solves that by being self hosted and on premises, meaning NPEX runs it themselves rather then relying on someone else's hosted service. cordial specifically is described as capable of adding support for new networks within weeks, which is what made a smooth integration with dusk's L1 possible on a reasonable timeline.
worth noting cordial isnt some unproven vendor either - theyve worked with figure markets and figure.com, which has facilitated the origination of over $20 billion in private credit on chain. thats a meaningful existing track record to be bringing into a regulated exchange integration.
and NPEX here isnt just a client using this custody setup, its also positioned as validating it - using dusk vault themselves is presented as proof of the infrastructure's reliability and security for other institutions considering the same setup.

#dusk @Dusk $DUSK

#dusk $DUSK @Dusk last topic ive got queued this week, and it ties a lot of the earlier posts together - the actual division of labor between DuskDS, DuskEVM, and the bridge. ive referenced all three individually over the past two weeks without ever laying them out side by side as three separately named responsibilities.
DuskDS is consensus, settlement, and data availability. this is the base layer doing the heavy lifting i covered back on day one - the thing DuskEVM transactions ultimately settle against, the source of truth for finality.
DuskEVM is ethereum compatible smart contract execution. this is the application layer, where solidity contracts actually run, where the sequencer processes transactions and batches them for publishing back to DuskDS.
the bridge is the third, easy to overlook piece - it moves DUSK and messages between the two environments. without this specifically named as its own component, DUSK used for gas on DuskEVM and DUSK on the dusk L1 would just be two disconnected things, not one asset usable across both environments.
why does splitting these into three named pieces matter instead of just saying "the dusk blockchain" as one thing - because each piece has a genuinely different job and can be reasoned about separately. settlement guarantees live in DuskDS. execution and contract logic live in DuskEVM. asset and message movement between them lives specifically in the bridge. if something goes wrong or youre trying to understand where a specific guarantee actually comes from (is my transaction final, is my contract executing correctly, did my DUSK actually move), you can point to exactly which of the three components is responsible for that specific guarantee, instead of treating the whole stack as one undifferentiated black box.
#dusk @Dusk $DUSK

#dusk @Dusk follow up to yesterdays CCIP post, because i noticed dusk actually adopted two separate chainlink data products alongside CCIP, DataLink and Data Streams, and i almost lumped them together as "the same price feed thing" before realizing they solve different problems.
DataLink is specifically what delivers official NPEX exchange data directly onto the blockchain. its described as serving as the exclusive on chain data oracle for the platform — meaning this isnt generic aggregated market data from somewhere, its NPEX's own regulated exchange data, brought on chain through one specific official channel.
Data Streams is the other piece, and its job is different — low latency, high frequency price updates, specifically built to support compliant, high performance defi and institutional trading applications. this is the "how fast can price info actually move" layer, rather then the "whose data is this and is it official" layer that DataLink handles.
why have both instead of one generic feed — because they're answering two different questions. DataLink answers "is this verified, official, regulated exchange data" (a compliance/authenticity question). Data Streams answers "how quickly and frequently can that pricing information update for active trading use" (a performance question). a regulated market genuinely needs both answered well, sourcing that's provably legitimate, and speed thats good enough for real trading, not just one or the other.
together these make dusk and NPEX what's specifically called official data publishers for regulatory grade financial information on chain. for developers that means you can build real time, compliant, transparent financial products powered by data thats actually sourced from the official exchange, not scraped or approximated from somewhere else.

$DUSK

#dusk $DUSK @Dusk

"cross chain interoperability" gets thrown around so much as a phrase that it basically stops meaning anything specific, so today i wanted to actually look at why dusk picked chainlink CCIP by name instead of just accepting the buzzword.
turns out there were several concrete reasons actually given, not just a vague gesture at "interoperability is good."
first — issuer retained control. dusk and NPEX keep full ownership of their token contracts under CCIP, with programmatic controls like rate limits and upgrade paths built in. thats meaningfully different from handing control over to some external bridge mechanism.
second — reach and staying power. CCIP already supports 65+ blockchains and keeps expanding, which matters for long term interoperability without needing to compromise issuer control to get that reach.
third — CCIP runs on the same resilient oracle infrastructure thats already securing billions across defi, described as "always on," so its not some new unproven infra being trusted with regulated assets for the first time.
fourth — defense in depth security, meaning multiple layers of monitoring and validation protecting cross chain activity,even during volatile market conditions specifically, which matters more for regulated securities then it would for a random defi token.
fifth, and this one is a specific mechanism not just a principle — zero slippage transfers via the CCT (cross chain token) burn/mint model,which removes dependence on third party liquidity pools entirely for moving tokens across chains.
practically what this enables —tokenized assets issued on DuskEVM can move securely between chains and stay composable across defi ecosystems,and DUSK itself can move between networks like ethereum and solana using that same CCT standard.
so the actual answer to "why chainlink" wasnt one reason,it was a stack of specific technical and governance reasons that happen to matter more when the assets involved are regulated securities rather then speculative tokens.

#dusk $DUSK
@Dusk

#dusk @Dusk kept seeing "NPEX partnership" als eine Schlagzeilen-Faktum ohne viel Substanz dahinter und bin deshalb heute tatsächlich hingegangen und habe mir angesehen, was NPEX ist und was diese Partnerschaft konkret festgelegt hat.

NPEX ist eine echte, regulierte Wertpapierbörse, die in den Niederlanden operiert. Sie ist als Multilateral Trading Facility (MTF) lizenziert und wird von der niederländischen Aufsichtsbehörde für Finanzmärkte (AFM) beaufsichtigt. Das ist kein Krypto-natives Unternehmen, das sich mal vorsichtig in DeFi hineintastet, sondern ein bestehender Bestandteil klassischer Finanzinfrastruktur. Auch das Ausmaß ist greifbar – über 200 Millionen Euro an vermitteltem Finanzierungskapital für 100+ KMU und ein Netzwerk von 17.500+ aktiven Investoren, die es bereits nutzen.

Was die Partnerschaft laut Dusk tatsächlich festgelegt hat, ist Europas erste blockchainbasierte Wertpapierbörse – das heißt: NPEX nutzt Dusk, um regulierte Finanzinstrumente auszugeben, zu handeln und zu tokenisieren, statt dass Dusk versucht, NEXPs bestehende Nutzer davon zu überzeugen, irgendwohin neu zu migrieren.

Es gibt eine Einordnung vom CEO von Dusk dazu, die ich als nützliches Denkmodell ansehe: ein Vergleich mit einer Buchhandlung. Andere RWA-Protokolle werden so beschrieben, dass sie nach Platz in den Regalen suchen (also zu versuchen, Assets auf ihrer Chain gelistet zu bekommen), während Dusk stattdessen zur Struktur wird, die die gesamte Sammlung beherbergt. Das bedeutet: Das Spiel ist nicht „Überzeuge NPEX, Assets auf Dusk als eine Option unter vielen zu listen“, sondern „Werde die zugrunde liegende Infrastruktur, auf der NPEX selbst läuft.“

Das ist ein deutlich anderes Geschäftsmodell als bei den meisten RWA-Projekten, die ich gesehen habe: Die meisten versuchen, direkt Assets/Listings anzuziehen. Das ist eher ein Einbetten auf der Infrastrukturebene einer Börse, die bereits reguliert ist und bereits echtes Investoren-Volumen hat, statt einen neuen Marktplatz von Grund auf aufzubauen und darauf zu hoffen, dass Liquidität auftaucht.

$DUSK

#dusk @Dusk wollte heute etwas langsamer machen an einem Wort, das im gesamten RWA-Bereich ziemlich locker verwendet wird – „Tokenisierung“. Dusk zerlegt das tatsächlich in drei unterschiedliche Dinge, und als ich sie getrennt vor mir sah, haben viele dieser vagen Marketingformulierungen anderswo plötzlich Sinn ergeben.

Erstens ist da Digitalisierung. Das ist im Grunde die Verlagerung der Verwaltung von Vermögensgegenständen – also der Asset-Registrierung – von Papier oder manuellen Prozessen in digitale Systeme. Man denkt dabei an entmaterialisierte Wertpapiere, die in einem zentralen Register verwaltet werden. Der Lebenszyklus des Vermögensgegenstands und die zwischengeschalteten Akteure bleiben normalerweise exakt gleich; nur das Speichermedium ändert sich.

Zweitens ist Tokenisierung – der Begriff, den die meisten eigentlich meinen, wenn sie „Tokenisierung“ nur so nebenbei sagen. Dabei wird ein Token ausgegeben, der einen Vermögenswert repräsentiert oder einen Anspruch darauf. Der Token kann programmierbar sein und sich leichter in Anwendungen integrieren lassen; regulierte Vermögenswerte, die auf diesem Modell basieren, setzen jedoch häufig weiterhin auf bestehende Verwahr-, Registrierungs- und Settlement-Prozesse, die außerhalb der Kette stattfinden (off chain). Der Token ist dabei eine Art Hülle, kein Ersatz für das zugrunde liegende System der Aufzeichnungen.

Drittens – und das ist der Punkt, an dem Dusk sich tatsächlich verortet – ist die native Emission. Das bedeutet, dass der Vermögensgegenstand selbst auf der Kette erstellt und verwaltet wird: Emission, Übertragungen, Serviceleistungen und Settlement können direkt rund um das Ledger stattfinden, statt einen Token als Hülle um irgendein separates off-chain System zu verwenden.

Warum diese Unterscheidung praktisch wirklich zählt: Native Emission wird als Ansatz beschrieben, die Abhängigkeit von getrennten Verwahr- und Register-Schichten zu verringern (je nach rechtlicher Ausgestaltung). Außerdem kann sie die Übergaben zwischen Emission, Transfer, Servicing und Settlement reduzieren, weil weniger doppelte Datensätze existieren, wenn der gesamte Ablauf von Anfang an nativ auf der Kette lebt. Allein Tokenisierung bringt dir das nicht; du musst oft weiterhin zwischen dem Token und dem realen, zugrunde liegenden Vermögenswert abgleichen, der irgendwo anders sitzt.

Wenn Dusk also über regulierte Märkte spricht, geht es nicht wirklich darum, Vermögenswerte in Tokens einzupacken. Es geht vielmehr um die tiefere Variante, bei der der Lebenszyklus des Vermögenswerts selbst von Anfang an um On-Chain-Workflows neu designt wird.

$DUSK

#termmax @TermMax Lass uns den Ausfallmodus untersuchen, den niemand testet, bis es zu spät ist: Liquidation bei dünner Liquidität.

Standardmechanismus, Schritt für Schritt. Der Wert der Sicherheiten fällt unter die Schwelle. Das Protokoll verkauft Sicherheiten zwangsweise auf dem offenen Markt. Der Erlös erstattet den Kreditgebern. Auf dem Papier, sauber. Jetzt die echten Crash-Bedingungen hinzufügen: Volatilitätsspitzen, Käufer verschwinden, Orderbücher werden genau dann ausgedünnt, wenn der Verkaufsdruck seinen Höhepunkt erreicht. Der erzwungene Verkauf läuft in dieses Vakuum hinein und realisiert Preise weit unter dem fairen Wert. Schlimmer noch: Der Verkauf selbst vertieft den Crash und löst weitere Liquidationen aus. Eine Kaskade. Der Mechanismus, der dazu dient, Kreditgeber zu schützen, wird zum Verstärker ihrer Verluste.

Quantifizieren wir die Kernabhängigkeit, dann ist der Fehler offensichtlich: Traditionelle Liquidationen funktionieren nur, wenn in dem Moment der Liquidation ausreichend Liquidität vorhanden ist. Das ist eine Annahme, keine Garantie, und sie scheitert genau dann, wenn sie am dringendsten gebraucht wird. Deshalb schränken konventionelle Plattformen Sicherheiten auf eine Handvoll hochliquider Kryptowährungen ein. Nicht Vorliebe. Strukturelle Notwendigkeit. Ihr gesamtes Solvenzmodell hängt davon ab, dass Sicherheiten schnell abverkauft werden können.

Jetzt, TermMax' Alternative, ganz unverblümt: Physische Lieferung.

Bei signifikanter Volatilität oder geringer Liquidität zwingt TermMax nicht zum Verkauf. Die Sicherheiten selbst werden direkt an die Kreditgeber als Ausgleich geliefert. Verfolge, was das verändert. Kein Feuerverkauf, also keine Realisierung von Bottom-Tick-Preisen. Kein Dump, also kein Beitrag zur Kaskade. Der Kreditgeber erhält das Asset und kontrolliert den Zeitpunkt des Ausstiegs und verwandelt einen erzwungenen Verlust im schlechtesten Moment in eine Halteentscheidung nach seinem eigenen Zeitplan.

Und die zweite Ebene ist die größere Story: Entferne die Abhängigkeit von sofortiger Liquidität, und das Universum der Sicherheiten wird größer. Realweltliche Assets. Tokens mit geringer Liquidität. Kategorien, die anderswo strukturell ausgeschlossen sind, werden hier tragfähig.

Die komplette Serie in einer Zeile: vereinfachte Ausführung, feste Raten, tokenisierte Positionen, wettbewerbsfähige Preise und ein Liquidationsmodell, das für tatsächliche Crashes gebaut ist – statt für ideale. Das Design fügt sich zusammen.

Das war die ganze Analyse. TermMax hat den Stack neu gedacht.

#termmax @TermMax Bruder, kurze Geschichte. In meiner Gegend gibt es zwei Läden.

Laden eins: ein Festpreis-Board, kein Verhandeln. Du fragst den Typen: „Yaar, thoda kam karo“, und er zeigt auf die Tafel, als wäre das eine Gerichtsverfügung. Was da steht, ist final. Laden zwei: der richtige Basar. Zehn Verkäufer, gleiche Produkte, unterschiedliche Preise. Du gehst rum, vergleichst, feilschst und DU GEWINNST. Wo kaufst du ein? Ganz genau. Jeder kennt die Antwort.

Jetzt kommt das Ding, das dir niemand sagt: Die meisten DeFi-Plattformen sind Laden eins.

Dein Borrowing-Zins, dein Lending-Zins, alles davon kommt aus einer einzigen mathematischen Formel, die eine AMM-Kurve heißt. Die Formel verkündet die Zahlen, und das war’s. Board-Preis, final, keine Diskussion. Und das Hässliche daran? Diese Formel bildet den echten Markt nicht mal richtig ab. Sie berechnet nur das, wozu sie ursprünglich eingerichtet wurde. So kommst du am Ende bei Konditionen an, die dir kein echter Mensch anbieten würde, weil auf der anderen Seite ja auch kein echter Mensch sitzt. Nur Mathe mit Einstellung.

TermMax macht aus Laden eins den kompletten Basar, und ich sag dir ganz genau wie.

Auf TermMax setzen Market Maker sogenannte Range Orders. Ganz simpel: Jeder Market Maker baut seinen eigenen Stand auf. „Ich leihe zu diesem Satz, in diesem Bereich, mit diesen Konditionen.“ Der nächste bietet was anderes an. Der dritte wieder was anderes. TermMax sammelt ALL diese Angebote an einem Ort. Wenn du also zum Leihen oder Verleihen kommst, starrst du nicht auf ein einziges Board. Du läufst durch einen ganzen Basar voller Zinsen, und du suchst dir das Angebot aus, das zu DIR passt.

Und weil diese Market Maker um dein Geschäft konkurrieren, bleiben die Konditionen ehrlich. Konkurrenz, Bruder. Der älteste Trick im Buch – und er funktioniert immer noch besser als jede Formel.

Ein Preis ist eine Order. Viele Preise sind ein Markt. So einfach.

Morgen, letzter Tag, und das ist das Krasseste: was TermMax macht, wenn der Markt komplett einbricht. Das willst du nicht verpassen. Chai ready. Bis dann.

#dusk @Dusk ist diese Woche einen Schritt zurück von dem Krypto-Zeug gegangen und hat sich Dusk Trade im Speziellen angesehen, weil ich denke, dass man leicht annehmen kann, dass „tokenisierte Asset-Plattform“ einfach nur bedeutet, dass „irgendwo ein Token-Contract existiert“, und das ist wirklich nicht das, was Dusk Trade tatsächlich ist.

Dusk Trade liegt über dem Basisprotokoll als Anwendungsschicht – es ist ausdrücklich nicht das Basisprotokoll selbst. Es wird als Produktschicht beschrieben, die den Dusk-Stack darunter nutzt. Was es tatsächlich abdeckt, ist ein vollständiger Satz an Workflows: das Auffinden tokenisierter Finanz-Assets, das Verbinden einer Wallet, das Abschließen von Onboarding- oder Berechtigungsprüfungen, das Kaufen oder Verkaufen, das Koordinieren der Asset-Leg- und Payment-Leg-Seite eines Trades sowie das Bereitstellen der richtigen Informationen für Emittenten, Venues, Investoren oder andere autorisierte Parteien.

Dieser letzte Punkt ist der, bei dem ich denke, dass die eigentliche Aussage gemacht wird. Bei regulierten Assets ist das schwierige Problem fast nie der Token-Contract allein – sondern der vollständige Markt-Workflow darum herum. Wer kann auf das Asset zugreifen? Wer kann es halten oder übertragen? Was ist öffentlich vs. vertraulich? Was kann selektiv offengelegt werden? Wie werden Zahlungs- und Asset-Settlement tatsächlich miteinander koordiniert? Und wie interagieren Emittenten/Venues/Investoren alle innerhalb derselben Umgebung, ohne sich dabei in die Anforderungen der jeweils anderen hineinzudrücken.

Dusk Trade ist also nicht „ein weiteres DEX-Frontend“, sondern speziell für Märkte gebaut, in denen Logik zu Berechtigung und Offenlegung rund um das Asset existieren muss – und nicht nur Logik für die Übertragung. Ein generischer Token-Contract hat standardmäßig nichts davon eingebaut; du würdest alles selbst von Grund auf für jedes einzelne regulierte Asset bauen müssen, wenn der darunterliegende Stack es nicht bereits bereitstellt.

Was ich immer noch versuche festzunageln: Wie konfigurierbar diese Berechtigungs-/Offenlegungsschicht tatsächlich pro Asset ist, denn unterschiedliche regulierte Instrumente (Aktien vs. Anleihen vs. Fonds) haben vermutlich sehr unterschiedliche Compliance-Anforderungen.

$DUSK

#dusk @Dusk

ich bin die ganze Woche um die Hedger-Zahl herumgewandert, ohne mich tatsächlich auf eine bestimmte Zahl festzulegen, die ich für wichtiger halte, als die Leute ihr zugestehen – der Beweiszeit. konkret: schnelles In-Browser-Beweisen, unter 2 Sekunden, clientseitig.
kurzer Kontext dazu, warum diese Zahl überhaupt zählt. Datenschutztechnologie, die auf Zero-Knowledge-Beweisen aufbaut, hatte in der Vergangenheit ein echtes Usability-Problem: Einen Beweis zu erzeugen kann rechnerisch schwer sein. Und wenn das bedeutet, dass man jedes Mal lange warten muss (oder einen leistungsstarken Server braucht, der es für einen übernimmt), sobald man etwas Privates tun möchte, ist das ein Dealbreaker für eine echte Übernahme – unabhängig davon, wie stichhaltig die zugrunde liegende Kryptografie auch ist. „technisch privat, praktisch aber unbrauchbar“ hat bereits viele solide Datenschutzsysteme ausgebremst.
Hedger setzt genau hier an: mit leichten Schaltungen, die eine clientseitige Beweiserzeugung unter 2 Sekunden ermöglichen. Dass es clientseitig ist, ist genauso wichtig wie die Geschwindigkeit – denn hier wird kein Beweis auf einem Server erzeugt und an dich zurückgeschickt, sondern das passiert direkt in deinem eigenen Browser. Das hat auch direkte Auswirkungen auf das Vertrauen: Du gibst die zugrunde liegenden privaten Eingaben nicht an einen Drittserver weiter, nur um den Beweis berechnen zu lassen.

warum das tatsächlich mit allem verknüpft, was ich diese Woche sonst noch abgedeckt habe – verschleierte Orderbücher, vertrauliche Übertragungen, alles beruht darauf, dass Beweise schnell genug erzeugt werden, damit sich die Nutzung der privaten Variante eines Workflows nicht spürbar langsamer anfühlt als die nicht-private. Ein Beweis auf der Browser-Seite von 2 Sekunden (oder weniger) ist das, was „Datenschutz per Default“ realistisch wirken lässt, statt „Datenschutz als langsame, nervige Opt-in-Option“.

beschrieben ganz schlicht als das Ermöglichen einer nahtlosen Nutzererfahrung im großen Maßstab – und ich denke, genau das ist der eigentliche Punkt hier. Die Kryptografie muss korrekt sein, aber das allein reicht nicht. Sie muss auch schnell genug sein, damit Menschen nicht aus Ungeduld daran vorbeirouten.


$DUSK

#termmax @TermMax

Bro, weißt du, was so ein Biryani-Päckchen ist? Das mit der Masala-Soße. Irgendjemands dadi hat 50 Jahre gebraucht, um diese Gewürzmischung zu perfektionieren, und jetzt sitzt das ganze Rezept in einem einzigen Päckchen. Du brauchst diese 50 Jahre nicht. Du brauchst ein Päckchen und ein bisschen Verstand.

Behalt das im Kopf, denn TermMax hat das Gleiche mit DeFi gemacht. Zweimal.

Zwei Tokens: FT und GT. Lass mich sie dir aufschlüsseln wie einem Freund – nicht wie einem Whitepaper.

FT ist der Fixed-Rate Token. Und das ist im Grunde Kreditvergabe in Päckchenform. Früher: irgendwo einzahlen, die schwankende Rate wie ein Habicht im Blick behalten, jeden Tag Stress. FT-Variante: du hältst einen Token, der schon alles enthält – fester Ertrag, feste Laufzeit, fertig beim Fälligkeitszeitpunkt. Kaufen, behalten, einlösen. Das ist die ganze Aufgabe. Kein Beobachten, kein Raten, was du verdienst. Der Token weiß es. Es steht drin.

Jetzt GT, der Gearing Token – der hier ist der Brocken. Erinnerst du dich an Tag 1? Dieses Looping-Albtraumding: hier leihen, dort tauschen, einzahlen, wiederholen – zehn Transaktionen, drei Protokolle, ein Kopfschmerz? GT stopft DIESE komplette gehebelt positionierte Strategie in einen einzigen Token. Das Collateral, der geliehene Betrag, die Hebelwirkung – alles ist verpackt. Du machst nur einen Trade, und zack: du hältst eine vollständige Strategie, für die früher ein Abend und halbe deine geistige Gesundheit draufging.

Ein Trade, bro. EINE.

Und hier kommt der Teil, der für Leute wie uns wirklich zählt: Wenn die ganze Strategie einfach ein Token ist, kannst du mit einem Klick einsteigen und mit einem Klick wieder raus. Kein Zerpflücken von zehn Positionen in umgekehrter Reihenfolge mitten in der Nacht. Du weißt immer ganz genau, was du besitzt – denn was du besitzt, ist genau eins.

Das Komplizierte ist nicht verschwunden. Es ist nur in das Päckchen gewandert. Dadis Rezept, erinnerst du dich?

Morgen: wie TermMax dir tatsächlich erlaubt, deine RATE auszuwählen – statt einfach das zu akzeptieren, was die Maschine vorgibt. Das wird spicy. Chai bereit. Bis dann.

Bro, stell dir das vor. Du mietest eine Wohnung, vereinbarst 30k im Monat, schüttelst die Hand, ziehst ein. Und dann klopft im nächsten Monat der Vermieter: „Es sind jetzt 55k.“ Monat drauf: „80k, Marktbedingungen yaar.“ Würdest du nicht durchdrehen, oder? Du würdest sagen, das ist Wahnsinn, niemand kann so leben.

Glückwunsch. Genau so funktioniert das Leihen in den meisten DeFi-Systemen.

Das nennen sie variable Zinssätze. Klingt harmlos, fast sanft. Variabel. Wie ein Boot. Aber was es eigentlich bedeutet, ist: Der Zinssatz, zu dem du heute geliehen hast, hat morgen keinerlei Loyalität dir gegenüber. Ich habe gesehen, wie Leute eine gehebelte Position bei 4% eröffnen, sich zwei Wochen lang wie Genies fühlen, dann aber beobachten, wie der Zinssatz sich in einer Marktpanik verdreifacht und jeden einzelnen Rupie ihres Gewinns auffressen. Und niemand hat sie gewarnt, weil niemand konnte. Das ist das ganze Problem. Selbst das Protokoll weiß nicht, wie der Zinssatz morgen sein wird.

Wie plant man bitte so irgendwas? Kurz gesagt: gar nicht. Du schaust einfach den ganzen Tag auf dein Handy, als würde es dir Geld schulden.

Deshalb haben mich die festen Zinssätze von TermMax wirklich beeindruckt. Kein Drama, kein Gimmick, einfach ein unkompliziertes Geschäft: Du leihst zu einem festen Zinssatz für eine feste Laufzeit, und dieser Zinssatz ist gesperrt. Gesperrt heißt gesperrt. Der Preis, den du am ersten Tag siehst, ist der Preis am letzten Tag. Auf der Kreditgeber-Seite genauso. Du kennst deine exakte Rendite, bevor du überhaupt klickst. Du kannst dir buchstäblich die Rechnung auf einer Serviette machen: Kosten so viel, verdienst so viel, Gewinn ist so viel. Fertig.

So hat normale Finanzwirtschaft im Grunde für immer funktioniert, übrigens. Feste Hypotheken, feste Festgeldanlagen. DeFi hat die Basics vergessen, während es fancy Zeug hinterherjagt.

TermMax hat sich erinnert.

Morgen erkläre ich die zwei Tokens, die hinter den Kulissen das ganze Spiel am Laufen halten, FT und GT. Klingt technisch, ich mache es einfach, versprochen. Chai bereit. Bis dann.
#termmax @TermMax

hat die ganze Woche lang um Hedger herumkreist, ohne sich jemals wirklich auf eine bestimmte Zahl festzulegen, von der ich denke, dass sie mehr Bedeutung hat, als die Leute ihr zugestehen – Beweiszeit. Konkret: schneller In-Browser-Beweis, unter 2 Sekunden, clientseitig.
Kurzer Kontext, warum diese Zahl überhaupt so wichtig ist. Privacy-Tech, das auf Zero-Knowledge-Proofs basiert, hat historisch gesehen ein echtes Usability-Problem: Das Erzeugen eines Beweises kann rechnerisch schwer sein, und wenn das bedeutet, dass man jedes Mal sehr lange warten muss (oder einen leistungsstarken Server braucht, der das für einen übernimmt), nur um etwas Privates zu tun, ist das ein K.O.-Kriterium für eine tatsächliche Einführung – egal wie solide die Kryptografie darunter ist. „technisch privat, praktisch aber nicht nutzbar“ hat schon viele ansonsten solide Privacy-Systeme zerstört.
Hedger setzt genau hier an: mit leichten Schaltungen, die die clientseitige Beweiserzeugung in unter 2 Sekunden ermöglichen. Clientseitig ist hier genauso wichtig wie die Geschwindigkeit – denn das ist kein Beweis, der auf irgendeinem Server erzeugt und dann zu dir zurückgeschickt wird, sondern er passiert direkt in deinem eigenen Browser. Das hat auch echte Auswirkungen auf Vertrauen: Du gibst die zugrunde liegenden privaten Eingaben nicht an einen Drittserver weiter, nur um den Beweis berechnen zu lassen.
Warum das tatsächlich mit allem anderen zusammenhängt, das ich diese Woche abgedeckt habe – verschleierte Orderbooks, vertrauliche Transfers, all das hängt davon ab, dass Beweise schnell genug generiert werden, sodass die private Version eines Workflows sich nicht spürbar langsamer anfühlt als die nicht-private Version. Ein 2-Sekunden-(oder weniger-)Browser-seitiger Beweis sorgt dafür, dass „Privacy by default“ realistisch wirkt – statt „Privacy als langsame, nervige Option, die man erst umständlich einschalten muss“.
Ganz einfach beschrieben: Es geht darum, eine nahtlose Nutzererfahrung im großen Maßstab zu ermöglichen – und das ist meiner Meinung nach der eigentliche Punkt. Die Kryptografie muss zwar korrekt und tragfähig sein, aber das allein reicht nicht: Sie muss auch schnell genug sein, dass Menschen nicht aus Ungeduld daran vorbeirouten.
Ich bin gespannt, welche Designentscheidungen bei der Schaltung tatsächlich dafür sorgen, dass man von „typischer zk-Proving-Zeit“ auf unter 2 Sekunden kommt – das ist eine echte, bedeutende Lücke im Vergleich zu dem, was ich von der Proving-Zeit anderswo verstehe.

#dusk @Dusk $DUSK

#dusk $DUSK @Dusk

heute wollte ich eine bestimmte Formulierung verstehen, die ich an Hedger "verschleierte Orderbücher" angebunden sah, denn für sich genommen klingt das fast widersprüchlich—ist der Sinn eines Orderbuchs nicht gerade, dass Menschen es sehen können?

herausgestellt hat sich, dass der Teil "verschleiert" nicht darum geht, zu verbergen, dass Handel stattfindet, sondern darum, Absicht und insbesondere Risikoexponierung zu verbergen—und das ist von der Logik her ziemlich institutionell, sobald man darüber nachdenkt, für wen das tatsächlich relevant ist.

wenn du ein großer institutioneller Trader bist und eine beträchtliche Order in ein vollständig sichtbares Orderbuch platzierst, können andere Teilnehmer sie sehen und reagieren, bevor deine Order überhaupt ausgeführt wird—durch Front-Running oder auch einfach dadurch, dass sich Marktteilnehmer insgesamt anders verhalten, weil sie jetzt deine Position oder Absicht kennen. Das ist ein echter Kostenfaktor für Institutionen, wenn sie bedeutende Größen bewegen. Und genau das wird als zentrale Funktion für den institutionellen Handel beschrieben: Sie verhindert Marktmanipulation und schützt die Teilnehmer davor, Absichten oder Exponierung offenzulegen.

hier kommt Hedger wieder ins Spiel: In den letzten zwei Tagen ging es um den vertraulichen Teil der Asset-Eigentümerschaft und -Übertragungen (bestände, Beträge, Salden bleiben Ende-zu-Ende verschlüsselt). Genau das macht verschleierte Orderbücher technisch überhaupt erst möglich. Man kann ein Orderbuch nämlich nicht sinnvoll verschleiern, wenn die zugrunde liegenden Salden und Übertragungen, die diese Orders stützen, vollständig on-chain sichtbar sind.

es lohnt sich, präzise zu sein, wo das Ganze aktuell steht: Die Doku beschreibt Hedger so, dass es die Grundlage für die bevorstehende Bereitstellung von verschleierten Orderbüchern legt. Daher liest es sich eher wie eine Basis-Infrastruktur, die bereits vorhanden ist—statt dass die Orderbuch-Funktion selbst heute schon live ist.

was ich als Nächstes sehen möchte, ist, wie das eigentliche Produkt für ein verschleiertes Orderbuch aussieht, sobald es ausgeliefert wird, und ob die Privatsphäre dort pro Order per Opt-in erfolgt oder standardmäßig für alles gilt.

#dusk @Dusk $DUSK

Follow-up zu gestern, weil ich bemerkt habe, dass Hedger ständig mit etwas namens Zedger verglichen wird, und ich den Unterschied tatsächlich erst heute verstanden habe — herausgestellt hat sich, dass es ein wirklich ehrlicher Trade-off ist, nicht nur „eine neue Sache ersetzt eine alte“.

Zedger wurde speziell für UTXO-basierte Layer gebaut. Dieses Modell lässt sich von Natur aus für vollständige Anonymität nutzen, da UTXOs keine gleiche, persistente Identität mit sich tragen wie ein Konto über Transaktionen hinweg.

Hedger ist anders — aus Notwendigkeit, nicht aus Wahl wirklich — denn es wurde für volle EVM-Kompatibilität gebaut, was bedeutet, dass man in einem kontobasierten Modell arbeitet. Und das kontobasierte Modell lässt einfach nicht dieselbe vollständige Anonymität zu, die ein UTXO-System wie Zedger bieten kann. Das wird ziemlich direkt gesagt, statt darüber hinwegzugehen, was ich respektiere — das kontobasierte Modell der EVM verhindert vollständige Anonymität, eine Fähigkeit, die Zedger immer noch hat.

Also: Wofür kaufst du den Trade-off eigentlich, wenn du vollständige Anonymität aufgibst? Hedger liefert immer noch vollständigen Transaktionsschutz (Bestände, Beträge und Salden bleiben Ende-zu-Ende verschlüsselt), aber eben, während es sich direkt in Standard-Ethereum-Tools integriert — Foundry, Hardhat, die üblichen Wallets und Libraries. Es wird als skalierbar, auditierbar und von Tag eins an leicht zu übernehmen beschrieben, genau weil man dafür nicht auf das EVM-Tooling-Ökosystem verzichten muss, um dorthin zu gelangen.

Die eigentliche Gegenüberstellung ist also nicht „Hedger ist strikt besser als Zedger“, sondern: „Unterschiedliche Basismodelle erzwingen unterschiedliche Datenschutz-Obergrenzen, und Hedger optimiert für EVM-Kompatibilität und Geschwindigkeit bei der Einführung innerhalb der Obergrenze, die das Kontomodell zulässt, statt vollständige Anonymität zu jagen — mit dem Preis, dass diese Kompatibilität verloren geht.“

Bin neugierig, ob Zedger irgendwo im Dusk-Stack noch aktiv ist, oder ob es eher ein Vorgänger ist, der gerade ausgemustert wird, während DuskEVM zur primären Anwendungsschicht wird.

#dusk @Dusk $DUSK

Ich wollte heute Hedger wirklich richtig verstehen, statt es nur als „Dämmerungs-Privatsache für DuskEVM“ zu kennen, denn die Kryptografie dahinter ist deutlich mehrschichtiger, als ich beim Einstieg erwartet hatte.

Die meisten DeFi-Privacy-Systeme, die ich kenne, setzen vor allem auf Zero-Knowledge-Beweise: damit weist man nach, dass eine Berechnung korrekt durchgeführt wurde, ohne dabei die Eingaben offenzulegen – das ist der Kern des Werkzeugs. Hedger macht aber nicht dabei halt: Es kombiniert mehrere Techniken miteinander, statt nur eine auszuwählen.

Der erste Baustein ist homomorphe Verschlüsselung, konkret auf Basis von ElGamal über ECC. Das ermöglicht, Berechnungen direkt auf verschlüsselten Werten durchzuführen, ohne sie jemals entschlüsseln zu müssen, um die Mathematik zu machen. Das ist etwas anderes als „erst im Nachhinein beweisen, dass die Rechnung korrekt war“ – es ist eher: „Rechne die Mathematik, während die Zahlen die ganze Zeit verborgen bleiben“.

Der zweite Baustein sind weiterhin Zero-Knowledge-Beweise, die darauf aufsetzen: Sie belegen die Korrektheit der Berechnungen, ohne die zugrunde liegenden Eingaben offenzulegen. Das ist der gleiche allgemeine Zweck wie immer, nur dass es hier mit der homomorphen Ebene zusammenspielt, statt alles allein zu tragen.

Der dritte Baustein ist ein hybrides UTXO-/Account-Modell. Das unterstützt die Komponierbarkeit über Schichten hinweg und sorgt dafür, dass sich das Ganze sauber in reale Finanzsysteme integrieren lässt, statt in ein einziges Transaktionsmodell-„Korsett“ eingesperrt zu sein.

Warum sich die Mühe machen, drei Dinge zu kombinieren, statt einfach wie alle anderen nur zk zu verwenden? Die Einordnung, die ich gesehen habe, war: gleichzeitig Privatsphäre, Performance und Compliance auszubalancieren – nicht nur Privatsphäre isoliert. Regulierte Finanzanwendungen brauchen Nachvollziehbarkeit neben Vertraulichkeit, und das Stapeln mehrerer kryptografischer Techniken scheint der Weg zu sein, beides zu erhalten, ohne dass sich das eine gegenseitig untergräbt.

Ich will es immer noch besser verstehen: Fügt die Kombination dieser Techniken spürbaren zusätzlichen Rechenaufwand hinzu im Vergleich zu einem reinen zk-Ansatz, oder sind die Performance-Kosten in der Praxis ungefähr vergleichbar.

#dusk @Dusk $DUSK

eine frage, die mir nach dem gestrigen post gekommen ist: wenn ihr auf dusk aufbaut – wie entscheidet man dann tatsächlich zwischen DuskEVM und DuskVM? denn beide werden als optionen erwähnt und es ist nicht sofort ersichtlich, welche davon „die richtige“ ist.

herausgestellt hat sich, dass es überhaupt keine besser-gegen-schlechter-situation ist – es ist rein zweckgebunden, und die kriterien sind ziemlich klar, sobald man sie einmal auflistet.

DuskEVM ist die richtige wahl, wenn ihr solidity oder vyper nutzen wollt, foundry/hardhat/viem/ethers verwenden möchtet oder einfach standard-evm-wallets und bestehende ethereum-bibliotheken nutzen wollt, ohne Anpassungen. im Grunde: Wenn euer team den EVM-stack bereits kennt und dieses wissen direkt mit rüberbringen möchte, dann ist das eure spur.

DuskVM ist die andere option – und zwar speziell für rust/wasm-verträge. die unterscheidung, die hier wirklich zählt, ist nicht nur „eine andere sprache“: DuskVM-verträge werden direkt auf dem Dusk L1 selbst ausgeführt und können sich eng mit den nativen Transaktionsmodellen von duskds, den Protokoll-Assets, den Privacy-Funktionen und den Zero-Knowledge-Fähigkeiten integrieren. wenn ihr also etwas baut, das direkt mit dusk’s privacy oder dem zk-stack interagieren muss – statt nur über eine EVM-kompatible schicht – dann ist DuskVM der ort, an dem diese zugriffe tatsächlich stattfinden.

das mentale modell, zu dem ich letztlich gekommen bin: DuskEVM tauscht etwas tiefe L1-integration gegen volle kompatibilität mit tooling, das eure teams bereits kennen. DuskVM tauscht diese vertrautheit gegen einen direkteren, stärker nativen zugang zu dem, was dusk’s L1 selbst einzigartig macht. keine der beiden ist die „fortgeschrittene“ oder „einfache“ option – sie lösen lediglich unterschiedliche vorgaben, je nachdem, was ihr baut und was euer team bereits weiß.

eine sache interessiert mich aber noch – kann eine einzelne anwendung realistisch beides nutzen? also z. B. eine evm-ausgerichtete frontend, die auf DuskEVM basiert, aber darunter trotzdem etwas DuskVM-natives berühren muss – oder ist das in der praxis eher kein unterstütztes muster.

#dusk $DUSK
@Dusk

Ich bin heute damit beschäftigt gewesen, mir Schritt für Schritt anzusehen, wie DuskEVM eine Transaktion tatsächlich von Anfang bis Ende verarbeitet. Der Grund: Ich habe immer wieder „Rollup“ gelesen, aber ohne dass die konkreten Mechanismen wirklich erklärt wurden. Also dachte ich mir, ich verfolge es selbst.

Es beginnt damit, dass du eine Transaktion an den DuskEVM-Sequencer übermittelst – dieser Teil ist vertraut, wenn du irgendetwas anderes mit einem Rollup berührt hast, also eine Standard-Solidity/EVM-Transaktion, noch nichts Exotisches. Von dort aus nimmt die Execution Layer die Transaktion in einen L2-Block auf. Bis hierhin ist es einfach normales Rollup-Verhalten, das auf der Execution-Seite schnell abläuft.

Spannender wird es bei den nächsten zwei Schritten. Der Batcher nimmt die Transaktionsdaten und veröffentlicht sie in DuskDS – das ist Dusk’ eigentliche Konsens-, Settlement- und Data-Availability-Layer, also genau die Ebene, die die ganze schwere Arbeit im Hintergrund erledigt. Danach sind State-Commitments und Fault Proofs das, was den resultierenden DuskEVM-Status tatsächlich wieder mit dem DuskDS-Settlement verbindet.

Der praktische Punkt, der meiner Meinung nach am wichtigsten ist: Inklusion und Settlement sind hier ausdrücklich unterschiedliche Phasen – nicht dasselbe Ding mit zwei Namen. Dass deine Tx schnell in einen L2-Block aufgenommen wird, passiert zügig, aber das ist nicht dasselbe wie „settled“. Und die Doku ist hier ziemlich klar: Wenn du etwas baust, das Werte zwischen DuskEVM und dem Dusk L1 bewegt, solltest du den tatsächlichen Protokoll- oder Wallet-Status prüfen – nicht einfach davon ausgehen, dass etwas endgültig ist, nur weil seit einer gewissen Zeit etwas vergangen ist.

Das ist eine Unterscheidung, die viele Leute meiner Ansicht nach überspringen, wenn sie „fast rollup“ hören und annehmen, dass allein die Geschwindigkeit automatisch Finalität bedeutet. Dem ist nicht so – zumindest nicht nur dadurch.

Trotzdem möchte ich noch herausfinden, wie die tatsächliche typische Lücke zwischen Inklusion und vollständigem Settlement in der Praxis aussieht. Die Doku beschreibt zwar die Phasen, aber keine konkreten Zeitangaben.

#dusk @Dusk $DUSK

die letzte angle, die ich diese woche auf dem plan hatte, und ich denke, dass sie tatsächlich wichtig ist, um die tradeoffs hier fair zu beurteilen – wie vergleicht sich TBV mit DLCs (discreet log contracts), also dem älteren und einfacheren bitcoin-kollateralmodell, das viele leute bereits kennen.

ein DLC ist im kern ein vertrag zwischen zwei parteien. bob und larry einigen sich im voraus auf eine bestimmte menge möglicher ergebnisse; ein oracle signiert später genau das ergebnis, das tatsächlich eingetreten ist. diese signatur bestimmt dann, wie eine vorher vereinbarte bitcoin-auszahlung zwischen ihnen aufgeteilt wird. das gibt es schon länger, es ist relativ einfach nachzuvollziehen, und es ist wirklich hart im einsatz getestet – im vergleich zu etwas wie TBV, das sich noch durch den testnet-prozess bewegt.

also wo liegt der tatsächliche unterschied, was jeweils geleistet werden kann. ein DLC ist grundsätzlich bilateral und in den ergebnissen begrenzt – es sind bob und larry, die sich auf eine feste menge von outcomes einigen, die im voraus festgelegt wird. es funktioniert hervorragend für dinge, die nach einem muster geformt sind wie „ist ereignis X passiert: ja oder nein, dann entsprechend auszahlen“. was es jedoch nicht wirklich kann, ist universelle programmierbarkeit oder zu ermöglichen, dass derselbe bitcoin als kollateral über mehrere verschiedene anwendungen hinweg dient, ohne jedes mal einen brandneuen vertrag neu auszuhandeln.

TBV verfolgt etwas strukturell anderes – kollateral, das über eine breitere defi-landschaft hinweg nutzbar ist (kredite heute, stablecoins/derivate/versicherungen als erwähnte zukunftsrichtungen), verifiziert über beweisen für den tatsächlichen smart-contract-zustand, statt über ein fest vorab zwischen zwei namentlich genannten parteien vereinbartes outcome-set.

ich versuche hier ehrlich zu sein, statt TBV einfach als strikt besser zu pitchen – dass DLCs einfacher und stärker erprobt sind, ist ein echter vorteil, besonders für etwas, das eher eng bilateral ausgerichtet ist. TBV gibt etwas von dieser simplizität zugunsten von allgemeingültigkeit und defi-komponierbarkeit auf. verschiedene werkzeuge, die für unterschiedliche probleme geformt sind, kein strikter upgrade-pfad von dem einen zum anderen.

das ist das komplette set an angles, die ich diese woche aus den docs und dem whitepaper herausgezogen hatte.

#baby $BABY
-@BabylonLabs_io

Der letzte Winkel, den ich diese Woche vorgemerkt hatte, und der ist meiner Meinung nach tatsächlich wichtig, um hier fair die Abwägungen zu betrachten: Wie schneidet TBV im Vergleich zu DLCs (discreet log contracts) ab? Das ist ein älteres und einfacheres Bitcoin-Kollateralmodell, das viele Leute bereits kennen.

Ein DLC ist im Kern ein Vertrag zwischen zwei Parteien. Bob und Larry einigen sich im Voraus auf eine Reihe möglicher Ergebnisse. Ein Orakel signiert später genau das Ergebnis, das tatsächlich eingetreten ist, und diese Signatur bestimmt, wie eine vorab vereinbarte Bitcoin-Zahlung zwischen ihnen aufgeteilt wird. Das gibt es schon länger, es ist relativ einfach, darüber nachzudenken, und es ist im echten Einsatz wirklich bewährt – verglichen mit etwas wie TBV, das sich noch durch den Testnet-Zyklus bewegt.

Wo liegt also der tatsächliche Unterschied darin, was jeweils möglich ist? Ein DLC ist grundsätzlich bilateral und durch das Ergebnis begrenzt – es sind Bob und Larry, die sich auf eine feste Menge von Ergebnissen einigen, die im Voraus festgelegt wird. Das funktioniert hervorragend für Dinge, die wie „Ist Ereignis X eingetreten: ja oder nein?“ geformt sind, und entsprechend wird ausgezahlt. Was es aber nicht wirklich macht, ist allgemeine Programmierbarkeit oder die Möglichkeit, dass sich dasselbe Bitcoin als Sicherheiten über mehrere unterschiedliche Anwendungen hinweg nutzen lässt, ohne jedes Mal erneut einen komplett neuen Vertrag auszuhandeln.

TBV geht strukturell einen anderen Weg: Kollateral, das über eine breitere DeFi-Landschaft hinweg nutzbar ist (Kredite heute, Stablecoins/Derivate/Versicherung als erwähnte zukünftige Richtungen). Das wird über Beweise des tatsächlichen Smart-Contract-Zustands verifiziert – nicht über eine fest vorab vereinbarte Ergebnismenge zwischen zwei namentlich benannten Parteien.

Ich versuche hier ehrlich zu sein, statt TBV nur als streng besser zu verkaufen: Dass DLCs einfacher und erprobter sind, ist ein echter Vorteil – insbesondere für etwas, das eng bilateral ist. TBV handelt einen Teil dieser Einfachheit gegen Allgemeingültigkeit und DeFi-Komponierbarkeit ein. Unterschiedliche Werkzeuge, geformt für unterschiedliche Probleme – kein strikter Upgrade-Pfad von dem einen zum anderen.

Das war die vollständige Liste der Blickwinkel, die ich diese Woche aus den Docs und dem Whitepaper herausgezogen hatte.

#baby $BABY
@BabylonLabs_io