Binance Square
Neeeno
26.4k Beiträge

Neeeno

Square Verified+
Unwanted
1.0K+ Following
66.5K+ Follower
62.2K+ Like gegeben
Beiträge
PINNED
·
--
$TRUMP +36%, MAGMA +29%, $ZEC +23%… 😂 Ich habe meine Polygon-Kampagnenbelohnungen die letzten 6 Monate gehalten und auf genau diesen einen guten Pump gewartet. 😭 Ursprünglich dachte ich, eine Wallet mit einem dApp zu verbinden sei im Grunde nur eine einzige Berechtigung. Der Nutzer verbindet, die Anwendung sieht das Konto, und jede spätere Aktion läuft über diese Beziehung. je mehr ich in die neue @Dusk_Foundation Wallet geschaut habe, desto mehr wirkte es so, als sei das Verbinden nur der Anfang des Berechtigungsmodells. Über $DUSK Connect kann ein dApp Profilzugriff, Signaturen, Transaktionen, Contract Calls oder eine geschützte Empfangsadresse anfordern. Aber das Anfordern einer Aktion gibt der Anwendung nicht die Schlüssel des Nutzers. Die Schlüssel bleiben lokal. Dusk sagt, dass Erweiterungs-Builds sie mit PBKDF2 und AES-GCM schützen, während native Builds Stronghold mit Argon2 verwenden. Die Wallet enthält außerdem Auto-Lock, ein Backoff bei fehlgeschlagenem Unlock und Berechtigungen, die auf jede anfordernde Origin zugeschnitten sind. #dusk Das hat meine Sicht auf den dApp-Zugriff verändert. Eine verbundene Seite kann so zugelassen werden, dass sie eine Aktion anfordern darf, ohne die Autorität zu erhalten, sie still und heimlich auszuführen. Die Wallet bleibt die Genehmigungsgrenze. Was meine Aufmerksamkeit nicht nur auf die lokale Schlüsselspeicherung gelenkt hat. Sondern darauf, wie stark die Sicherheit jetzt davon abhängt, was der Genehmigungsbildschirm kommuniziert. Ein privater Schlüssel kann geschützt bleiben, während der Nutzer trotzdem eine irreführende Contract-Call-Anfrage genehmigt, eine unlesbare Nachricht oder eine unerwartete Kontoanfrage. Per-Origin-Berechtigungen beschränken, welche Seite Zugriff erhält, aber sie können nicht beweisen, dass jede Anfrage von dieser Seite sicher ist. Das Wallet-Repository trennt Genehmigungen für Transaktionen, lesbare und undurchsichtige Nachrichten, Authentifizierungs-Signings, Contract Calls und geschützte Adressen. Aber Dusk Connect und die neue Wallet wurden für die Entwicklervorschau eingeführt, daher muss diese Berechtigungserfahrung sich noch über echten dApps und echtes Nutzerverhalten hinweg bewähren. Schafft das Vorhalten der Schlüssel lokal und die Berechtigungen pro Origin die richtige Sicherheitsgrenze, oder wird eher die Klarheit jedes einzelnen Genehmigungsbildschirms entscheidend sein als der darunterliegende Verbindungsstandard?? {spot}(POLUSDT) {future}(MAGMAUSDT)
$TRUMP +36%, MAGMA +29%, $ZEC +23%… 😂

Ich habe meine Polygon-Kampagnenbelohnungen die letzten 6 Monate gehalten und auf genau diesen einen guten Pump gewartet. 😭

Ursprünglich dachte ich, eine Wallet mit einem dApp zu verbinden sei im Grunde nur eine einzige Berechtigung.

Der Nutzer verbindet, die Anwendung sieht das Konto, und jede spätere Aktion läuft über diese Beziehung.

je mehr ich in die neue @Dusk Wallet geschaut habe, desto mehr wirkte es so, als sei das Verbinden nur der Anfang des Berechtigungsmodells.

Über $DUSK Connect kann ein dApp Profilzugriff, Signaturen, Transaktionen, Contract Calls oder eine geschützte Empfangsadresse anfordern.

Aber das Anfordern einer Aktion gibt der Anwendung nicht die Schlüssel des Nutzers.

Die Schlüssel bleiben lokal. Dusk sagt, dass Erweiterungs-Builds sie mit PBKDF2 und AES-GCM schützen, während native Builds Stronghold mit Argon2 verwenden. Die Wallet enthält außerdem Auto-Lock, ein Backoff bei fehlgeschlagenem Unlock und Berechtigungen, die auf jede anfordernde Origin zugeschnitten sind. #dusk

Das hat meine Sicht auf den dApp-Zugriff verändert.
Eine verbundene Seite kann so zugelassen werden, dass sie eine Aktion anfordern darf, ohne die Autorität zu erhalten, sie still und heimlich auszuführen.

Die Wallet bleibt die Genehmigungsgrenze.
Was meine Aufmerksamkeit nicht nur auf die lokale Schlüsselspeicherung gelenkt hat.

Sondern darauf, wie stark die Sicherheit jetzt davon abhängt, was der Genehmigungsbildschirm kommuniziert.
Ein privater Schlüssel kann geschützt bleiben, während der Nutzer trotzdem eine irreführende Contract-Call-Anfrage genehmigt, eine unlesbare Nachricht oder eine unerwartete Kontoanfrage. Per-Origin-Berechtigungen beschränken, welche Seite Zugriff erhält, aber sie können nicht beweisen, dass jede Anfrage von dieser Seite sicher ist.

Das Wallet-Repository trennt Genehmigungen für Transaktionen, lesbare und undurchsichtige Nachrichten, Authentifizierungs-Signings, Contract Calls und geschützte Adressen.

Aber Dusk Connect und die neue Wallet wurden für die Entwicklervorschau eingeführt, daher muss diese Berechtigungserfahrung sich noch über echten dApps und echtes Nutzerverhalten hinweg bewähren.

Schafft das Vorhalten der Schlüssel lokal und die Berechtigungen pro Origin die richtige Sicherheitsgrenze, oder wird eher die Klarheit jedes einzelnen Genehmigungsbildschirms entscheidend sein als der darunterliegende Verbindungsstandard??

🔐 Local key storage
🌐 Per-site permissions
👀 Clear approval screens
🧠 User judgment
10 Stunde(n) übrig
PINNED
·
--
Verifiziert
#termmax @termmax Der Ausdruck „Liquidations-freie Leverage“ klang fast widersprüchlich, als ich ihn zum ersten Mal auf @TermMax Alpha gesehen habe. Also habe ich nachgeschaut, was TermMax damit wirklich meint. Der Zeitpunkt machte die Frage noch relevanter: Am 17. August ging der TermMax × Binance Wallet Booster live, was frischen Fokus auf das Protokoll lenkte, während Alpha weiterhin Teil des TermMax-Produktstapels ist. Alpha strukturiert die Leverage nicht um eine kontinuierlich überwachte Kollateralposition. TermMax definiert Long als den Kauf einer Call-Option und Short als den Kauf einer Put-Option. Der Käufer zahlt im Voraus eine Prämie, und TermMax beschreibt diese Prämie als die Eröffnungskosten und den maximalen Verlust für den Optionskäufer. Moment mal. Dadurch wurde mir das Design viel klarer. Der wichtige Punkt ist nicht, dass TermMax das Risiko entfernt hat. Es hat geändert, wie die Kehrseite definiert ist. Für den Alpha-Käufer ist das konventionelle Kollateral-Liquidationsrisiko entfernt, weil es keinen Margin-Saldo gibt, der sich in Richtung einer Wartungsschwelle bewegt. Der Betrag, der dem Risiko ausgesetzt ist, ist stattdessen durch die Prämie begrenzt, die für die Option gezahlt wurde. Diese Prämie kann jedoch weiterhin verloren gehen, wenn die Option ausläuft, ohne genug Wert zu haben. Und die andere Seite des Trades trägt weiterhin Exponierung. TermMax verbindet diese Seite über Dual Investment: Liquiditätsanbieter übernehmen das entgegengesetzte Auszahlungsprofil zu Long-/Short-Käufern und verdienen Rendite, die durch die Optionsnachfrage finanziert wird. Also macht Alpha die Leverage nicht risikofrei. Es ersetzt die vertraute Struktur mit Liquidationsschwellen durch vordefinierte Optionsauszahlungen zwischen Käufern und Liquiditätsanbietern. Ursprünglich habe ich „liquidationsfrei“ einfach als ein Feature zur Risikoreduktion gelesen. Jetzt finde ich, dass TermMax Alpha interessanter ist als eine Form der Risiko-Transformation. Ist die Definition des maximalen Verlusts vor dem Einstieg in ein klareres Leverage-Modell, oder verlagert es die Risiken, die Trader bewerten müssen, lediglich an eine andere Stelle? @termmax #TermMax
#termmax @TermMax

Der Ausdruck „Liquidations-freie Leverage“ klang fast widersprüchlich, als ich ihn zum ersten Mal auf @TermMax Alpha gesehen habe.

Also habe ich nachgeschaut, was TermMax damit wirklich meint.

Der Zeitpunkt machte die Frage noch relevanter: Am 17. August ging der TermMax × Binance Wallet Booster live, was frischen Fokus auf das Protokoll lenkte, während Alpha weiterhin Teil des TermMax-Produktstapels ist.

Alpha strukturiert die Leverage nicht um eine kontinuierlich überwachte Kollateralposition.

TermMax definiert Long als den Kauf einer Call-Option und Short als den Kauf einer Put-Option. Der Käufer zahlt im Voraus eine Prämie, und TermMax beschreibt diese Prämie als die Eröffnungskosten und den maximalen Verlust für den Optionskäufer.

Moment mal.

Dadurch wurde mir das Design viel klarer.

Der wichtige Punkt ist nicht, dass TermMax das Risiko entfernt hat. Es hat geändert, wie die Kehrseite definiert ist.

Für den Alpha-Käufer ist das konventionelle Kollateral-Liquidationsrisiko entfernt, weil es keinen Margin-Saldo gibt, der sich in Richtung einer Wartungsschwelle bewegt. Der Betrag, der dem Risiko ausgesetzt ist, ist stattdessen durch die Prämie begrenzt, die für die Option gezahlt wurde.

Diese Prämie kann jedoch weiterhin verloren gehen, wenn die Option ausläuft, ohne genug Wert zu haben.

Und die andere Seite des Trades trägt weiterhin Exponierung.

TermMax verbindet diese Seite über Dual Investment: Liquiditätsanbieter übernehmen das entgegengesetzte Auszahlungsprofil zu Long-/Short-Käufern und verdienen Rendite, die durch die Optionsnachfrage finanziert wird.

Also macht Alpha die Leverage nicht risikofrei.

Es ersetzt die vertraute Struktur mit Liquidationsschwellen durch vordefinierte Optionsauszahlungen zwischen Käufern und Liquiditätsanbietern.

Ursprünglich habe ich „liquidationsfrei“ einfach als ein Feature zur Risikoreduktion gelesen.

Jetzt finde ich, dass TermMax Alpha interessanter ist als eine Form der Risiko-Transformation.

Ist die Definition des maximalen Verlusts vor dem Einstieg in ein klareres Leverage-Modell, oder verlagert es die Risiken, die Trader bewerten müssen, lediglich an eine andere Stelle?

@TermMax #TermMax
·
--
$ENA +46%, $PROM +36%, $NEIRO +31%, ZORA +31% 😂🚀 In der Zwischenzeit schaue ich mir die Gewinnerliste an wie eine Restaurantkarte: „Welche davon bestelle ich, bevor sie schlecht wird?“ 🤡 Wem würdest du bei diesen Preisen NICHT vertrauen? 👀
$ENA +46%, $PROM +36%, $NEIRO +31%, ZORA +31% 😂🚀

In der Zwischenzeit schaue ich mir die Gewinnerliste an wie eine Restaurantkarte:

„Welche davon bestelle ich, bevor sie schlecht wird?“ 🤡

Wem würdest du bei diesen Preisen NICHT vertrauen? 👀
😭 ENA
47%
🍭 PROM
13%
🐕 NEIRO
24%
🔮 ZORA
16%
989 Stimmen • Abstimmung beendet
·
--
#dusk $DUSK @Dusk_Foundation fast mein gesamtes Portfolio in Staub verwandelt Ich machte gerade einen Dusk-Trading-Task und habe aus Versehen eine viel größere Position geöffnet, als ich beabsichtigt hatte 😭 Zum Glück habe ich rechtzeitig gemerkt, dass es zu groß ist, und sie geschlossen, bevor sie mich liquidieren konnte. Bachat Hogai... i habe mich gefragt, wann eine vorgeschlagene Änderung an @Dusk eigentlich Teil des Protokolls wird. Offenbar ist das Schreiben eines überzeugenden DIP nur der Anfang. Ein Dusk Improvement Proposal durchläuft die Phasen Idee, Entwurf und Feedback, bevor es bei Staging ankommt. Wenn der Vorschlag eine technische Umsetzung beinhaltet, dann wird es in dieser Staging-Phase auf das Nocturne-Testnetz gestellt für eine letzte Runde Tests und Feedback. Erst nachdem es Konsens erhalten hat und seine Liefergegenstände in die Produktionsumgebung übergehen, wird der Vorschlag Aktiv. das ist eine wichtige Trennung. Ein zusammengeführtes Dokument kann die Spezifikation und die Argumentation hinter einer Änderung bewahren, aber das bedeutet nicht automatisch, dass bereits jeder Node diese Regel auf dem Mainnet befolgt. Proposal-Reife und Aktivierung in der Produktion sind unterschiedliche Zustände. Der Prozess hat außerdem einen Weg der Inaktivität. Ein Vorschlag, der nicht mehr weiterentwickelt wird, kann Stagnant werden. Wenn er dort länger als sechs Monate bleibt, kann er als Dead markiert werden. So bewahrt das Archiv Ideen, die nicht weiter vorankamen, statt dafür zu sorgen, dass jeder alte Vorschlag für immer als „offen“ aussieht. Ich mag die Historie, die dadurch entsteht: Motivation, Spezifikation, Kompatibilität, Tests, Sicherheitsüberlegungen und Implementierungsreferenzen bleiben an der Entscheidung verknüpft. Aber ein strukturierter Eintrag nimmt der Sache nicht die Bewertung. Editor:innen und Mitwirkende müssen immer noch entscheiden, wann Feedback ausreicht, ob ein Konsens existiert und ob die Umsetzung tatsächlich den schriftlich festgehaltenen Vorschlag erfüllt. Erleichtert der DIP-Lifecycle die Prüfung von Protokolländerungen – oder verlagert er die schwierigsten Governance-Entscheidungen in Übergänge, die allein durch Dokumentation nicht aufgelöst werden können?? #dusk @Dusk_Foundation
#dusk $DUSK @Dusk fast mein gesamtes Portfolio in Staub verwandelt

Ich machte gerade einen Dusk-Trading-Task und habe aus Versehen eine viel größere Position geöffnet, als ich beabsichtigt hatte 😭
Zum Glück habe ich rechtzeitig gemerkt, dass es zu groß ist, und sie geschlossen, bevor sie mich liquidieren konnte. Bachat Hogai...

i habe mich gefragt, wann eine vorgeschlagene Änderung an @Dusk eigentlich Teil des Protokolls wird.

Offenbar ist das Schreiben eines überzeugenden DIP nur der Anfang.

Ein Dusk Improvement Proposal durchläuft die Phasen Idee, Entwurf und Feedback, bevor es bei Staging ankommt. Wenn der Vorschlag eine technische Umsetzung beinhaltet, dann wird es in dieser Staging-Phase auf das Nocturne-Testnetz gestellt für eine letzte Runde Tests und Feedback.

Erst nachdem es Konsens erhalten hat und seine Liefergegenstände in die Produktionsumgebung übergehen, wird der Vorschlag Aktiv.

das ist eine wichtige Trennung.

Ein zusammengeführtes Dokument kann die Spezifikation und die Argumentation hinter einer Änderung bewahren, aber das bedeutet nicht automatisch, dass bereits jeder Node diese Regel auf dem Mainnet befolgt. Proposal-Reife und Aktivierung in der Produktion sind unterschiedliche Zustände.

Der Prozess hat außerdem einen Weg der Inaktivität.

Ein Vorschlag, der nicht mehr weiterentwickelt wird, kann Stagnant werden. Wenn er dort länger als sechs Monate bleibt, kann er als Dead markiert werden. So bewahrt das Archiv Ideen, die nicht weiter vorankamen, statt dafür zu sorgen, dass jeder alte Vorschlag für immer als „offen“ aussieht.

Ich mag die Historie, die dadurch entsteht: Motivation, Spezifikation, Kompatibilität, Tests, Sicherheitsüberlegungen und Implementierungsreferenzen bleiben an der Entscheidung verknüpft.

Aber ein strukturierter Eintrag nimmt der Sache nicht die Bewertung. Editor:innen und Mitwirkende müssen immer noch entscheiden, wann Feedback ausreicht, ob ein Konsens existiert und ob die Umsetzung tatsächlich den schriftlich festgehaltenen Vorschlag erfüllt.

Erleichtert der DIP-Lifecycle die Prüfung von Protokolländerungen – oder verlagert er die schwierigsten Governance-Entscheidungen in Übergänge, die allein durch Dokumentation nicht aufgelöst werden können??

#dusk @Dusk
·
--
Mujhy kun nikala kia itna bura hon mein @Binance baby .. Warum gibst du meinem Konto keine Reichweite? Hat mein Konto den Algorithmus persönlich beleidigt oder was? 😂💔 Reichweite bekomme ich nicht mal so einfach, Schritt für Schritt. Nicht alle meine Fehler—deine Unhöflichkeit, baby, wann bist du so geworden? Ich bin sehr traurig, Binance wieder zu verlassen. Das ist nicht fair. Zum dritten Mal disqualifiziert. Warum, wenn man so hart arbeitet? Wenn man sowieso disqualifizieren wollte, wozu dann? Auch mit fast keiner Reichweite habe ich gekämpft und irgendwie meinen Rang gehalten. Wofür? Nur um die Disqualifikations-Achievement nochmal freizuschalten? 😂🏆 Ich gehe nicht spielen—ich bin einfach raus. Es geht schon. Denk an mich in deinen Gebeten. Bleib gesegnet 💕 #BinanceSquareTalks #Binance
Mujhy kun nikala kia itna bura hon mein @Binance baby ..

Warum gibst du meinem Konto keine Reichweite? Hat mein Konto den Algorithmus persönlich beleidigt oder was? 😂💔 Reichweite bekomme ich nicht mal so einfach, Schritt für Schritt. Nicht alle meine Fehler—deine Unhöflichkeit, baby, wann bist du so geworden?

Ich bin sehr traurig, Binance wieder zu verlassen. Das ist nicht fair.

Zum dritten Mal disqualifiziert. Warum, wenn man so hart arbeitet? Wenn man sowieso disqualifizieren wollte, wozu dann?

Auch mit fast keiner Reichweite habe ich gekämpft und irgendwie meinen Rang gehalten. Wofür?
Nur um die Disqualifikations-Achievement nochmal freizuschalten? 😂🏆

Ich gehe nicht spielen—ich bin einfach raus. Es geht schon. Denk an mich in deinen Gebeten.

Bleib gesegnet 💕 #BinanceSquareTalks #Binance
·
--
Eröffnete die Top-Gewinner von Binance und anscheinend hatte wirklich jeder Frühstück mit Raketenbrennstoff. 😭🚀 $AVAAI +49% $ACE +37% $ONG +35% Und BOME hat irgendwie zwei Versionen von sich selbst auf die Party gebracht. 😂 Während ich diese Charts anstarre: „Zu spät zum Longen… zu gruselig zum Shorten… perfekter Zeitpunkt, um einfach absolut nichts zu tun.“ 🤡 Aber die Schwerkraft ist geduldig. 💀📉 Welche Person/Option wird zuerst gedemütigt? 👀 {spot}(BOMEUSDT)
Eröffnete die Top-Gewinner von Binance und anscheinend hatte wirklich jeder Frühstück mit Raketenbrennstoff. 😭🚀

$AVAAI +49%
$ACE +37%
$ONG +35%

Und BOME hat irgendwie zwei Versionen von sich selbst auf die Party gebracht. 😂

Während ich diese Charts anstarre:

„Zu spät zum Longen… zu gruselig zum Shorten… perfekter Zeitpunkt, um einfach absolut nichts zu tun.“ 🤡

Aber die Schwerkraft ist geduldig. 💀📉

Welche Person/Option wird zuerst gedemütigt? 👀
🚀 AVAAI
44%
🔥 ACE
13%
📈 ONG
10%
🐸 BOME
33%
30 Stimmen • Abstimmung beendet
·
--
🎙️ Analysiere die Kurzgeschichte „Dusk“ von Hoorain
avatar
Beenden
02 h 55 m 56 s
526
2
0
·
--
Verifiziert
#dusk $DUSK $BTW wieder ganz oben unter den Verlierern $BOME wird erneut bei 0.0014 einschlagen gehe long Ich habe die Dusk-Aufgabe erledigt, indem ich ihren neuesten Beitrag zum SME-Finanzieren gelesen habe, und ein Satz hat mich immer wieder zurückgezogen. Bruchteilseigentum spielt eine begrenzte Rolle. Das klingt fast unangenehm in einem RWA-Markt, in dem das Aufteilen eines Vermögenswerts in kleinere Teile oft als der eigentliche Durchbruch verkauft wird. Dusk’ Argument ist eher fundiert. Kleinere Einheiten können den Betrag senken, der nötig ist, um teilzunehmen, aber sie können keine Investorennachfrage, keine Rechtssicherheit oder Liquidität im Sekundärmarkt herstellen. Ein Wertpapier eines privaten Unternehmens wird nicht plötzlich liquide, nur weil sein Eigentum in mehr Token aufgeteilt wurde. Moment mal. Das bedeutet: Zugänglichkeit und Investierbarkeit sind nicht dasselbe. Damit Tokenisierung für KMUs wirklich zählt, sagt Dusk, dass der gesamte Eigentums-Lebenszyklus funktionieren muss: Emission, Investorberechtigung, Eigentumsaufzeichnungen, Übertragungen, Dividenden, Stimmrechte und Abwicklung müssen rund um einen gemeinsamen Datensatz zusammenpassen. Der Vermögenswert braucht außerdem verantwortliche Betreiber, berechtigte Käufer, eine zuverlässige Zahlungsinfrastruktur und eine autorisierte Handelsplattform. Ich mag diese Einordnung, weil sie den Fokus von dem leichtesten Teil wegbringt, der sich demonstrieren lässt. Das Erstellen kleinerer Einheiten ist sichtbar. Einen regulierten Markt um diese Einheiten herum aufzubauen, ist viel schwieriger. Selbst bei vollständiger Infrastruktur hängt die Liquidität immer noch davon ab, dass es tatsächlich Käufer und Verkäufer gibt, die den Vermögenswert zu Preisen wollen, bei denen Trades stattfinden können. Technologie kann Abgleich und Zugangshürden reduzieren, aber sie kann keinen Markt herbeizwingen. Gibt Dusk’ Ansatz über den kompletten Lebenszyklus den SME-Wertpapieren einen realistischen Weg zu breiterem Investorenzugang, oder bleibt die Nachfrage die Einschränkung, die die Tokenisierung selbst nicht lösen kann?? Dusk SME-Tokenisierung: größte Hürde? #dusk @Dusk_Foundation {future}(AVAAIUSDT) {future}(MAGMAUSDT)
#dusk $DUSK $BTW wieder ganz oben unter den Verlierern $BOME wird erneut bei 0.0014 einschlagen gehe long

Ich habe die Dusk-Aufgabe erledigt, indem ich ihren neuesten Beitrag zum SME-Finanzieren gelesen habe, und ein Satz hat mich immer wieder zurückgezogen.

Bruchteilseigentum spielt eine begrenzte Rolle.

Das klingt fast unangenehm in einem RWA-Markt, in dem das Aufteilen eines Vermögenswerts in kleinere Teile oft als der eigentliche Durchbruch verkauft wird.

Dusk’ Argument ist eher fundiert.

Kleinere Einheiten können den Betrag senken, der nötig ist, um teilzunehmen, aber sie können keine Investorennachfrage, keine Rechtssicherheit oder Liquidität im Sekundärmarkt herstellen. Ein Wertpapier eines privaten Unternehmens wird nicht plötzlich liquide, nur weil sein Eigentum in mehr Token aufgeteilt wurde.

Moment mal.

Das bedeutet: Zugänglichkeit und Investierbarkeit sind nicht dasselbe.

Damit Tokenisierung für KMUs wirklich zählt, sagt Dusk, dass der gesamte Eigentums-Lebenszyklus funktionieren muss: Emission, Investorberechtigung, Eigentumsaufzeichnungen, Übertragungen, Dividenden, Stimmrechte und Abwicklung müssen rund um einen gemeinsamen Datensatz zusammenpassen.

Der Vermögenswert braucht außerdem verantwortliche Betreiber, berechtigte Käufer, eine zuverlässige Zahlungsinfrastruktur und eine autorisierte Handelsplattform.

Ich mag diese Einordnung, weil sie den Fokus von dem leichtesten Teil wegbringt, der sich demonstrieren lässt.

Das Erstellen kleinerer Einheiten ist sichtbar. Einen regulierten Markt um diese Einheiten herum aufzubauen, ist viel schwieriger.

Selbst bei vollständiger Infrastruktur hängt die Liquidität immer noch davon ab, dass es tatsächlich Käufer und Verkäufer gibt, die den Vermögenswert zu Preisen wollen, bei denen Trades stattfinden können. Technologie kann Abgleich und Zugangshürden reduzieren, aber sie kann keinen Markt herbeizwingen.

Gibt Dusk’ Ansatz über den kompletten Lebenszyklus den SME-Wertpapieren einen realistischen Weg zu breiterem Investorenzugang, oder bleibt die Nachfrage die Einschränkung, die die Tokenisierung selbst nicht lösen kann??
Dusk SME-Tokenisierung: größte Hürde?

#dusk @Dusk
🔘 Investor demand
60%
🔘 Regulatory clarity
10%
🔘 Secondary liquidity
20%
🔘 Full lifecycle infra
10%
20 Stimmen • Abstimmung beendet
·
--
#termmax $BTW dumped really hard 😭 Ich hab dir gesagt, du sollst diese Münze bei 0,70 $ shorten, aber du hast Hoffnung über Profit gestellt 😂 jetzt gibt dir das Chart die Lektion gratis. Heute bin ich ziemlich tief in @termmax material eingestiegen, weil alle ständig darüber reden, festezinsige Positionen einzugehen. Kaum jemand scheint sich dafür zu interessieren, was passiert, wenn jemand vor Ablauf der Laufzeit aussteigen will. Smart Unwind ist das Seltsame daran. Lässt man einen frühen Exit nicht einfach als „zurückzahlen und schließen“ zu, ermöglicht das Design einem Leverager, eine Ziel-APR oder einen Sicherheiten-/Schuldenpreis festzulegen. Wenn diese Bedingung attraktiv wird, kann ein anderer Teilnehmer die bestehende Position übernehmen. Dieser zweite Auslöser hat mich erwischt. Er hängt nicht nur davon ab, dass die Sicherheit an Wert gewinnt. Wenn die Kreditaufnahmekosten stark genug steigen, könnte ein neuer Kreditnehmer lieber die bestehende Position mit einem Aufpreis übernehmen, statt frische Schulden zu den neuen Konditionen zu eröffnen. So kann eine alte Position mit festem Zinssatz genau deshalb zu wertvollem „Bestandsinventar“ werden, weil ihre Finanzierungskonditionen früher fixiert wurden. Und wenn diese Position den Besitzer wechselt, kann die ursprüngliche geliehene Liquidität auf die Kreditgeberseite zurückfließen und möglicherweise erneut verwendet werden, noch bevor das ursprüngliche Fälligkeitsdatum erreicht ist. Hmm. Das ist eine andere Art, über festverzinsliche Schulden nachzudenken. Der Kredit hört auf, nur etwas zu sein, das bis zum Ablauf einfach da liegt, und beginnt sich zu verhalten wie übertragbare Liquidität, sobald die Marktbedingungen passen. Löst es, bestehende Schulden übertragbar zu machen, das Problem der niedrigen Umschlagshäufigkeit bei befristetem Lending? Oder wird es zur neuen Engstelle, den richtigen Übernahme-Partner zu finden?? @termmax #TermMax {future}(MAGMAUSDT) {future}(AVAAIUSDT) {spot}(BOMEUSDT) Was ist für TermMax Smart Unwind am wichtigsten?
#termmax $BTW dumped really hard 😭 Ich hab dir gesagt, du sollst diese Münze bei 0,70 $ shorten, aber du hast Hoffnung über Profit gestellt 😂 jetzt gibt dir das Chart die Lektion gratis.

Heute bin ich ziemlich tief in @TermMax material eingestiegen, weil alle ständig darüber reden, festezinsige Positionen einzugehen. Kaum jemand scheint sich dafür zu interessieren, was passiert, wenn jemand vor Ablauf der Laufzeit aussteigen will.

Smart Unwind ist das Seltsame daran.

Lässt man einen frühen Exit nicht einfach als „zurückzahlen und schließen“ zu, ermöglicht das Design einem Leverager, eine Ziel-APR oder einen Sicherheiten-/Schuldenpreis festzulegen. Wenn diese Bedingung attraktiv wird, kann ein anderer Teilnehmer die bestehende Position übernehmen.

Dieser zweite Auslöser hat mich erwischt. Er hängt nicht nur davon ab, dass die Sicherheit an Wert gewinnt. Wenn die Kreditaufnahmekosten stark genug steigen, könnte ein neuer Kreditnehmer lieber die bestehende Position mit einem Aufpreis übernehmen, statt frische Schulden zu den neuen Konditionen zu eröffnen.

So kann eine alte Position mit festem Zinssatz genau deshalb zu wertvollem „Bestandsinventar“ werden, weil ihre Finanzierungskonditionen früher fixiert wurden.

Und wenn diese Position den Besitzer wechselt, kann die ursprüngliche geliehene Liquidität auf die Kreditgeberseite zurückfließen und möglicherweise erneut verwendet werden, noch bevor das ursprüngliche Fälligkeitsdatum erreicht ist.

Hmm. Das ist eine andere Art, über festverzinsliche Schulden nachzudenken. Der Kredit hört auf, nur etwas zu sein, das bis zum Ablauf einfach da liegt, und beginnt sich zu verhalten wie übertragbare Liquidität, sobald die Marktbedingungen passen.

Löst es, bestehende Schulden übertragbar zu machen, das Problem der niedrigen Umschlagshäufigkeit bei befristetem Lending? Oder wird es zur neuen Engstelle, den richtigen Übernahme-Partner zu finden?? @TermMax #TermMax




Was ist für TermMax Smart Unwind am wichtigsten?
🔄 Better capital turnover
57%
🤝 Enough takeover demand
14%
⚖️ Both equally
29%
7 Stimmen • Abstimmung beendet
·
--
🎙️ Handel im Dämmerlicht
avatar
Beenden
03 h 05 m 18 s
541
4
0
·
--
#dusk Das Anhören des Dusk x Binance AMA heute hat mich zurück zu einer Frage gebracht, die mit dem Einbringen regulierter Märkte on-chain zu tun hat: Geht es darum, bestehende Assets zu tokenisieren, oder werden sie dort tatsächlich ausgegeben? Moment, Short $BTW , Long $MUBARAK 😭 Falls du noch ein paar Extra-Gelder in der Ecke versteckt hast, eröffne vielleicht einen Swing-Trade in $STAR. Sieht das Portfolio rot aus? Gib ihm eine STAR-Therapie 🌟 Früher dachte ich, dass native Emission nur eine technischere Art sei, Tokenisierung zu sagen. @Dusk_Foundation s Dokumentation zieht eine schärfere Linie. Tokenisierung erzeugt ein On-Chain-Token, das ein Asset oder einen Anspruch repräsentiert, das/die in einem separaten Register, Verwahrungssystem oder Abwicklungsprozess weiterhin existiert. Das Token wird programmierbar, aber zwei Datensätze können bestehen bleiben: was die Blockchain sagt und was das externe System erkennt. Native Emission verändert diese Beziehung. Das Asset selbst wird on-chain erstellt und verwaltet. Emission, Transfers, Service und Abwicklung können so gestaltet werden, dass sie sich am Ledger orientieren, statt das Token als Hülle für ein anderes System der Datenhaltung zu behandeln. Da hat sich für mich der Unterschied nicht mehr nur wie Semantik angefühlt. Ein tokenisiertes Asset kann sich schnell on-chain bewegen, während Marktteilnehmer es dennoch mit Verwahrstellen, Registern oder Clearing-Infrastruktur anderswo abgleichen. Native Emission kann diese Übergaben reduzieren, weil der Lebenszyklus auf derselben Infrastruktur beginnt, auf der Eigentumswechsel stattfinden und Abwicklung erfolgt. Aber weniger doppelte Datensätze machen das On-Chain-System auch umso folgenreicher. Wenn das Ledger zur primären Umgebung für das Asset wird, dann können Zugriffskontrollen, Corporate Actions, Offenlegung, Wiederherstellung und rechtliche Anerkennung nicht mehr als später hinzukommende Integrationen behandelt werden. Sie werden Teil des operativen Asset-Designs von Anfang an. Tokenisierung kann die Verteilung modernisieren, ohne den alten Workflow vollständig zu ersetzen. Native Emission stellt die Frage, ob dieser zweite Workflow überhaupt noch existieren muss Ist es so, dass das Ausgeben eines Assets direkt auf $DUSK das Abgleichproblem an der Quelle beseitigt oder die Korrektheit des On-Chain-Lebenszyklus zu einer noch größeren institutionellen Abhängigkeit macht? {future}(STARUSDT)
#dusk Das Anhören des Dusk x Binance AMA heute hat mich zurück zu einer Frage gebracht, die mit dem Einbringen regulierter Märkte on-chain zu tun hat:

Geht es darum, bestehende Assets zu tokenisieren, oder werden sie dort tatsächlich ausgegeben?

Moment, Short $BTW , Long $MUBARAK 😭

Falls du noch ein paar Extra-Gelder in der Ecke versteckt hast, eröffne vielleicht einen Swing-Trade in $STAR.

Sieht das Portfolio rot aus? Gib ihm eine STAR-Therapie 🌟
Früher dachte ich, dass native Emission nur eine technischere Art sei, Tokenisierung zu sagen.

@Dusk s Dokumentation zieht eine schärfere Linie.

Tokenisierung erzeugt ein On-Chain-Token, das ein Asset oder einen Anspruch repräsentiert, das/die in einem separaten Register, Verwahrungssystem oder Abwicklungsprozess weiterhin existiert.

Das Token wird programmierbar, aber zwei Datensätze können bestehen bleiben: was die Blockchain sagt und was das externe System erkennt.

Native Emission verändert diese Beziehung.

Das Asset selbst wird on-chain erstellt und verwaltet. Emission, Transfers, Service und Abwicklung können so gestaltet werden, dass sie sich am Ledger orientieren, statt das Token als Hülle für ein anderes System der Datenhaltung zu behandeln.

Da hat sich für mich der Unterschied nicht mehr nur wie Semantik angefühlt.

Ein tokenisiertes Asset kann sich schnell on-chain bewegen, während Marktteilnehmer es dennoch mit Verwahrstellen, Registern oder Clearing-Infrastruktur anderswo abgleichen. Native Emission kann diese Übergaben reduzieren, weil der Lebenszyklus auf derselben Infrastruktur beginnt, auf der Eigentumswechsel stattfinden und Abwicklung erfolgt.

Aber weniger doppelte Datensätze machen das On-Chain-System auch umso folgenreicher.

Wenn das Ledger zur primären Umgebung für das Asset wird, dann können Zugriffskontrollen, Corporate Actions, Offenlegung, Wiederherstellung und rechtliche Anerkennung nicht mehr als später hinzukommende Integrationen behandelt werden. Sie werden Teil des operativen Asset-Designs von Anfang an.

Tokenisierung kann die Verteilung modernisieren, ohne den alten Workflow vollständig zu ersetzen.

Native Emission stellt die Frage, ob dieser zweite Workflow überhaupt noch existieren muss

Ist es so, dass das Ausgeben eines Assets direkt auf $DUSK das Abgleichproblem an der Quelle beseitigt oder die Korrektheit des On-Chain-Lebenszyklus zu einer noch größeren institutionellen Abhängigkeit macht?
Removes reconciliation
33%
Reduces manual handoffs
22%
Shifts dependency on-chain
0%
Does both
45%
9 Stimmen • Abstimmung beendet
·
--
🎙️ ⚡ Live jetzt: $DUSK Trading Hub + Dusk-Updates
cover
Beenden
02 h 39 m 47 s
1.4k
9
5
·
--
#termmax habe vergessen, über @termmax bcz zu posten Ich war beschäftigt in meinem $BTW $STAR handel, der DCA in star macht, damit ich meinen Einstieg mit Gewinn schließen kann zurück zu @termmax Etwas dazu, was die aktuellen Zahlen von @TermMax betrifft, hat mich dazu gebracht, die Protokollskala von den Protokollökonomiken zu trennen. Drittanbieter-Tracking zeigt derzeit ungefähr 32,06 Mio. $ TVL und 22,08 Mio. $ an aktiven Krediten. Aber derselbe Datensatz erfasst etwa 16,81 T$ an Protokolleinnahmen in den letzten 30 Tagen und ungefähr 375,57 T$ kumulativ. Ich glaube nicht, dass sich diese Zahlen perfekt zusammen bewegen sollen. TVL sagt mir, wie viel Wert in den Verträgen steckt. Aktive Kredite geben Auskunft über ausstehende Schulden. Einnahmen messen, was das Protokoll selbst tatsächlich aus der Aktivität erfasst. drei verschiedene Dinge. Deshalb beantwortet mir eine größere TVL-Zahl allein nicht die wirtschaftliche Frage. Kapital kann in ein Protokoll hineinfließen, ohne dass dadurch die gleiche Menge an Kreditaufnahme entsteht, und Kreditaktivität führt nicht notwendigerweise eins zu eins zu erfassten Einnahmen. Der spannende Test ist, ob sich diese Ebenen im Laufe der Zeit gemeinsam entwickeln – statt ob eine einzige Schlagzeilen-Zahl groß wird. Führt wachsendes Kapital und ausstehende Schuld irgendwann zu einer stärkeren Protokoll-Einnahmenbasis, oder kann TermMax erheblich skalieren, während die Wertabschöpfung vergleichsweise dünn bleibt?? @termmax Während TermMax skaliert: Was ist am wichtigsten? $HEMI bereit, wieder abzuheben {spot}(EDENUSDT) {future}(JCTUSDT) {spot}(GPSUSDT)
#termmax habe vergessen, über @TermMax bcz zu posten Ich war beschäftigt in meinem $BTW $STAR handel, der DCA in star macht, damit ich meinen Einstieg mit Gewinn schließen kann zurück zu @TermMax

Etwas dazu, was die aktuellen Zahlen von @TermMax betrifft, hat mich dazu gebracht, die Protokollskala von den Protokollökonomiken zu trennen.

Drittanbieter-Tracking zeigt derzeit ungefähr 32,06 Mio. $ TVL und 22,08 Mio. $ an aktiven Krediten.

Aber derselbe Datensatz erfasst etwa 16,81 T$ an Protokolleinnahmen in den letzten 30 Tagen und ungefähr 375,57 T$ kumulativ.

Ich glaube nicht, dass sich diese Zahlen perfekt zusammen bewegen sollen.

TVL sagt mir, wie viel Wert in den Verträgen steckt. Aktive Kredite geben Auskunft über ausstehende Schulden. Einnahmen messen, was das Protokoll selbst tatsächlich aus der Aktivität erfasst.

drei verschiedene Dinge.

Deshalb beantwortet mir eine größere TVL-Zahl allein nicht die wirtschaftliche Frage. Kapital kann in ein Protokoll hineinfließen, ohne dass dadurch die gleiche Menge an Kreditaufnahme entsteht, und Kreditaktivität führt nicht notwendigerweise eins zu eins zu erfassten Einnahmen.

Der spannende Test ist, ob sich diese Ebenen im Laufe der Zeit gemeinsam entwickeln – statt ob eine einzige Schlagzeilen-Zahl groß wird.

Führt wachsendes Kapital und ausstehende Schuld irgendwann zu einer stärkeren Protokoll-Einnahmenbasis, oder kann TermMax erheblich skalieren, während die Wertabschöpfung vergleichsweise dünn bleibt??

@TermMax

Während TermMax skaliert: Was ist am wichtigsten?

$HEMI bereit, wieder abzuheben

◉ Higher TVL
67%
◉ More active loans
11%
◉ Stronger protocol revenue
5%
◉ All three growing together
17%
18 Stimmen • Abstimmung beendet
·
--
#dusk $DUSK Heute werde ich $MUUB .$1000RATS kaufen. Es ist gleich so weit, dass es abgeworfen wird, und ich warte darauf, um zu einem perfekten Zeitpunkt einzusteigen. Ich habe darüber nachgedacht, dass ein Validator-Schlüssel eine Aufgabe hat: zu beweisen, dass der Node für die Teilnahme am Konsens berechtigt ist. Das Node-Setup von Dusk hat diese Annahme weniger angenehm gemacht. Ein Dusk-Stake kann zwei getrennte Rollen beinhalten. Der Konsensschlüssel bleibt beim Node und wird verwendet, um abzustimmen und Blöcke zu signieren. Der Owner-Key steuert die Möglichkeit, den Stake zu entsperren und die Gelder auszuzahlen. Wenn ein Operator keinen separaten Owner angibt, wird der Konsensschlüssel standardmäßig zum Owner. Das ist einfacher, weil es nur eine Adresse zu verwalten gibt. Aber dadurch werden auch zwei sehr unterschiedliche Arten von Autorität zusammengeführt. Wenn der Online-Node kompromittiert wird, bedeutet das möglicherweise nicht mehr, dass man nur die Fähigkeit erhält, in den Konsens einzugreifen. Wenn derselbe Schlüssel die Eigentümerschaft kontrolliert, könnte ein Angreifer potenziell auch den Stake aussetzen und die Gelder des Operators abziehen. Dusk empfiehlt daher, die Rollen zu trennen. Der Operator kann eine andere Adresse aus demselben Mnemonic wie der Owner zuweisen, während der Konsensschlüssel weiterhin für den Node verfügbar bleibt. Das reduziert, was ein gestohlener Node-Schlüssel tun kann. Aber die Trennung ist nicht vollständig, wenn das Mnemonic noch auf dem Server gespeichert ist. Dusk’ Leitfaden sagt, dass das Modell am effektivsten ist, wenn das Mnemonic nicht auf dem Node bleibt oder wenn das Wallet ein starkes Passwort verwendet, das sich vom Passwort des Konsensschlüssels unterscheidet. Was meine Aufmerksamkeit geweckt hat, war, wie das sicherere Design mehr operative Verantwortung schafft. Der Owner-Key muss geschützt und wiederherstellbar bleiben, wenn der Operator den Stake entsperren oder erneut staken muss. Die Trennung der Schlüssel begrenzt eine einzige Kompromittierung, aber der Verlust der Offline-Autorität schafft einen ganz anderen Ausfall. Gibt die Trennung der Konsensaktivität von der Stake-Eigentümerschaft den Operatoren die richtige Sicherheitsgrenze, oder wird die Wiederherstellung des Owner-Keys zur wichtigeren operativen Risikoquelle?? #dusk @Dusk_Foundation Dusk Validator Key Setup: Was ist wichtiger? {future}(AIOUSDT) {spot}(ACEUSDT) {future}(CLOUSDT)
#dusk $DUSK Heute werde ich $MUUB .$1000RATS kaufen. Es ist gleich so weit, dass es abgeworfen wird, und ich warte darauf, um zu einem perfekten Zeitpunkt einzusteigen.

Ich habe darüber nachgedacht, dass ein Validator-Schlüssel eine Aufgabe hat: zu beweisen, dass der Node für die Teilnahme am Konsens berechtigt ist.

Das Node-Setup von Dusk hat diese Annahme weniger angenehm gemacht.

Ein Dusk-Stake kann zwei getrennte Rollen beinhalten.

Der Konsensschlüssel bleibt beim Node und wird verwendet, um abzustimmen und Blöcke zu signieren. Der Owner-Key steuert die Möglichkeit, den Stake zu entsperren und die Gelder auszuzahlen.

Wenn ein Operator keinen separaten Owner angibt, wird der Konsensschlüssel standardmäßig zum Owner. Das ist einfacher, weil es nur eine Adresse zu verwalten gibt.

Aber dadurch werden auch zwei sehr unterschiedliche Arten von Autorität zusammengeführt.

Wenn der Online-Node kompromittiert wird, bedeutet das möglicherweise nicht mehr, dass man nur die Fähigkeit erhält, in den Konsens einzugreifen. Wenn derselbe Schlüssel die Eigentümerschaft kontrolliert, könnte ein Angreifer potenziell auch den Stake aussetzen und die Gelder des Operators abziehen.

Dusk empfiehlt daher, die Rollen zu trennen. Der Operator kann eine andere Adresse aus demselben Mnemonic wie der Owner zuweisen, während der Konsensschlüssel weiterhin für den Node verfügbar bleibt.

Das reduziert, was ein gestohlener Node-Schlüssel tun kann.

Aber die Trennung ist nicht vollständig, wenn das Mnemonic noch auf dem Server gespeichert ist. Dusk’ Leitfaden sagt, dass das Modell am effektivsten ist, wenn das Mnemonic nicht auf dem Node bleibt oder wenn das Wallet ein starkes Passwort verwendet, das sich vom Passwort des Konsensschlüssels unterscheidet.

Was meine Aufmerksamkeit geweckt hat, war, wie das sicherere Design mehr operative Verantwortung schafft.

Der Owner-Key muss geschützt und wiederherstellbar bleiben, wenn der Operator den Stake entsperren oder erneut staken muss. Die Trennung der Schlüssel begrenzt eine einzige Kompromittierung, aber der Verlust der Offline-Autorität schafft einen ganz anderen Ausfall.

Gibt die Trennung der Konsensaktivität von der Stake-Eigentümerschaft den Operatoren die richtige Sicherheitsgrenze, oder wird die Wiederherstellung des Owner-Keys zur wichtigeren operativen Risikoquelle??

#dusk @Dusk
Dusk Validator Key Setup: Was ist wichtiger?


🔘 Limiting node-key damage
58%
🔘 Protecting owner-key recove
17%
🔘 Both are equally critical
0%
🔘 One key is simpler
25%
12 Stimmen • Abstimmung beendet
·
--
Verifiziert
#termmax ursprünglich dachte ich, ein Timelock sei im Grunde nur eine Verzögerung, die auf jede Änderung an sensiblen Tresoren aufgeschlagen wird. TermMax macht das nicht ganz so. Für wichtige Kurator-Änderungen ist der normale Weg: einreichen, warten und dann akzeptieren. Während dieser Wartezeit kann ein Guardian eine ausstehende Änderung widerrufen. aber der Teil, der mich erwischt hat, ist die Asymmetrie. Änderungen, die TermMax als risikoreduzierend einstuft, können sofort passieren. Eine Erhöhung des Timelocks, das Senken der Performance-Gebühr oder das Entfernen eines Marktes von der Whitelist braucht nicht dieselbe Verzögerung. Warte gerade $APR right now Geht man in die andere Richtung, werden die Regeln strenger. Eine Verringerung des Timelocks, das Erhöhen der Performance-Gebühren, das Hinzufügen eines Marktes zur Whitelist oder das Ändern des Guardians erfordern die volle Wartezeit. ich finde die Logik eigentlich gut. Das System tut nicht so, als hätte jede Governance-Aktion identisches Risiko. Es macht es einfacher, sich aus einem Exposure zurückzuziehen, statt es auszubauen. Trotzdem heißt das, dass die Sicherheit teilweise davon abhängt, ob das Protokoll die Richtung jeder Parameteränderung korrekt klassifiziert hat. Ein Timelock kann eine Aktion verlangsamen, aber er kann nicht entscheiden, ob die Aktion selbst sinnvoll ist. $CLO to the moon Schafft eine asymmetrische Verzögerung eine stärkere Sicherheitsgrenze für Tresore, oder legt sie zu viel Gewicht darauf, wie jede Governance-Änderung klassifiziert wird?? #TermMax @termmax TermMax’ asymmetrischer Timelock ist… {spot}(TUTUSDT) {spot}(ACEUSDT) {future}(AIOUSDT)
#termmax ursprünglich dachte ich, ein Timelock sei im Grunde nur eine Verzögerung, die auf jede Änderung an sensiblen Tresoren aufgeschlagen wird.

TermMax macht das nicht ganz so.

Für wichtige Kurator-Änderungen ist der normale Weg: einreichen, warten und dann akzeptieren. Während dieser Wartezeit kann ein Guardian eine ausstehende Änderung widerrufen.

aber der Teil, der mich erwischt hat, ist die Asymmetrie.

Änderungen, die TermMax als risikoreduzierend einstuft, können sofort passieren. Eine Erhöhung des Timelocks, das Senken der Performance-Gebühr oder das Entfernen eines Marktes von der Whitelist braucht nicht dieselbe Verzögerung. Warte gerade $APR right now

Geht man in die andere Richtung, werden die Regeln strenger. Eine Verringerung des Timelocks, das Erhöhen der Performance-Gebühren, das Hinzufügen eines Marktes zur Whitelist oder das Ändern des Guardians erfordern die volle Wartezeit.

ich finde die Logik eigentlich gut.

Das System tut nicht so, als hätte jede Governance-Aktion identisches Risiko. Es macht es einfacher, sich aus einem Exposure zurückzuziehen, statt es auszubauen.

Trotzdem heißt das, dass die Sicherheit teilweise davon abhängt, ob das Protokoll die Richtung jeder Parameteränderung korrekt klassifiziert hat. Ein Timelock kann eine Aktion verlangsamen, aber er kann nicht entscheiden, ob die Aktion selbst sinnvoll ist. $CLO to the moon

Schafft eine asymmetrische Verzögerung eine stärkere Sicherheitsgrenze für Tresore, oder legt sie zu viel Gewicht darauf, wie jede Governance-Änderung klassifiziert wird??
#TermMax @TermMax
TermMax’ asymmetrischer Timelock ist…


🛡️ Smarter vault protection
67%
⚠️ Too reliant on classificati
10%
🤝 A reasonable balance
9%
🤔 Need to study it more
14%
21 Stimmen • Abstimmung beendet
·
--
$TUT war vor ein paar Tagen unter den größten Verlierern bei -43%… Jetzt liegt es bei +42% unter den Top-Gewinnern. 😭😂 Krypto hat wirklich gesagt: Charakterentwicklung. 💀📈 Währenddessen stoßen $GPS +35% und $STAR R +24% zur Party. Wer verliert zuerst die Schwerkraft? 👀
$TUT war vor ein paar Tagen unter den größten Verlierern bei -43%…

Jetzt liegt es bei +42% unter den Top-Gewinnern. 😭😂

Krypto hat wirklich gesagt: Charakterentwicklung. 💀📈

Währenddessen stoßen $GPS +35% und $STAR R +24% zur Party.

Wer verliert zuerst die Schwerkraft? 👀
🚀 TUT
70%
🛰️ GPS
12%
⭐ STAR
10%
🤡 The one I buy
8%
119 Stimmen • Abstimmung beendet
·
--
#termmax aufgeregt über diese @termmax -Kampagne, bevor ich irgendetwas poste, lass mich erst mal meine $GPS n $VELVET Trade-Buch machen und etwas Gewinn sichern 😜 das habe ich früher gedacht: Liquidation hat nur einen Job. Genug Sicherheiten verkaufen, die Schulden zurückzahlen, fertig. je mehr ich in @termmax hineingeschaut habe, desto klarer wurde mir, dass sein Mechanismus zur physischen Lieferung genau für die Situation existiert, in der dieses saubere Ende nicht eintritt. Ein TermMax-Darlehen kann in die Liquidation gehen, wenn sein LTV die LLTV-Schwelle erreicht oder wenn die Rückzahlung bei Fälligkeit verpasst wird. Wenn das Darlehen jedoch noch immer nicht bezahlt ist oder nach dem Liquidationsfenster nur teilweise liquidiert wurde, greift die physische Lieferung. das war der Teil, zu dem ich immer wieder zurückgekommen bin. Anstatt zu verlangen, dass jedes verbleibende Stück Sicherheit zuerst verkauft wird, kann der Redemption-Pool sowohl zugrunde liegende Schuld-Token als auch Sicherheiten-Token enthalten. FT-Inhaber lösen gegen diesen Pool anteilig ein, entsprechend ihrem Anteil an den ausstehenden FT. ich sehe die Logik. Die Rückgewinnung hängt nicht vollständig davon ab, Sicherheiten in der schlechtesten möglichen Minute durch die verfügbare Liquidität zu pressen. aber der Tradeoff verschwindet nicht. Der Kreditgeber hat die Rückzahlung im Schuld-Asset erwartet und könnte am Ende stattdessen selbst einen Teil der Sicherheiten halten. TermMax verändert, wie eine unvollständige Liquidation abgewickelt wird – nicht die Tatsache, dass der Kreditgeber Exposure übernehmen kann, die er ursprünglich gar nicht halten wollte. Macht die physische Lieferung gescheiterte Liquidationen widerstandsfähiger – oder verlagert sie einfach das verbleibende Liquiditätsproblem vom Protokoll auf den Kreditgeber?? #TermMax @termmax {future}(BEATUSDT) $STAR es pumpt wieder – ich hoffe, dass diesmal mein Einstieg geschlossen wird Physische Lieferung nach gescheiterter Liquidation?
#termmax aufgeregt über diese @TermMax -Kampagne, bevor ich irgendetwas poste, lass mich erst mal meine $GPS n $VELVET Trade-Buch machen und etwas Gewinn sichern 😜

das habe ich früher gedacht: Liquidation hat nur einen Job.

Genug Sicherheiten verkaufen, die Schulden zurückzahlen, fertig.

je mehr ich in @TermMax hineingeschaut habe, desto klarer wurde mir, dass sein Mechanismus zur physischen Lieferung genau für die Situation existiert, in der dieses saubere Ende nicht eintritt.

Ein TermMax-Darlehen kann in die Liquidation gehen, wenn sein LTV die LLTV-Schwelle erreicht oder wenn die Rückzahlung bei Fälligkeit verpasst wird. Wenn das Darlehen jedoch noch immer nicht bezahlt ist oder nach dem Liquidationsfenster nur teilweise liquidiert wurde, greift die physische Lieferung.

das war der Teil, zu dem ich immer wieder zurückgekommen bin.

Anstatt zu verlangen, dass jedes verbleibende Stück Sicherheit zuerst verkauft wird, kann der Redemption-Pool sowohl zugrunde liegende Schuld-Token als auch Sicherheiten-Token enthalten. FT-Inhaber lösen gegen diesen Pool anteilig ein, entsprechend ihrem Anteil an den ausstehenden FT.

ich sehe die Logik. Die Rückgewinnung hängt nicht vollständig davon ab, Sicherheiten in der schlechtesten möglichen Minute durch die verfügbare Liquidität zu pressen.

aber der Tradeoff verschwindet nicht.

Der Kreditgeber hat die Rückzahlung im Schuld-Asset erwartet und könnte am Ende stattdessen selbst einen Teil der Sicherheiten halten. TermMax verändert, wie eine unvollständige Liquidation abgewickelt wird – nicht die Tatsache, dass der Kreditgeber Exposure übernehmen kann, die er ursprünglich gar nicht halten wollte.

Macht die physische Lieferung gescheiterte Liquidationen widerstandsfähiger – oder verlagert sie einfach das verbleibende Liquiditätsproblem vom Protokoll auf den Kreditgeber??
#TermMax @TermMax
$STAR es pumpt wieder – ich hoffe, dass diesmal mein Einstieg geschlossen wird

Physische Lieferung nach gescheiterter Liquidation?
🅰️ Better recovery mechanism
85%
🅱️Shift liquidity risk lender
15%
20 Stimmen • Abstimmung beendet
·
--
#dusk $DUSK $GPS bereit, höher zu fliegen und noch höher — bald wird es den Himmel berühren. Aber die Zeile, die mich aufgehalten hat, war in @Dusk_Foundation ’s W3sper-Dokumentation nicht das Thema Unterschreiben. Es ging um die Warnung, dass ein Transaction Builder (Transaktions-Builder) keine Wallet ist. W3sper stellt einer Anwendung Low-Level-Tools bereit, um sich mit Rusk zu verbinden, den Status abzufragen und Transaktionen zu erstellen. Aber wenn ein Client ohne eine Wallet-Erweiterung signieren möchte, muss er die Bausteine liefern, für die W3sper sich ausdrücklich nicht verantwortlich macht. Dazu gehören ein speicherbarer, wiederherstellbarer Key-Storage und ein synchronisiertes Treasury hinter seinem „Bookkeeper“ — einschließlich der Kontostands- und Nonce-State-Daten, die benötigt werden, um eine gültige Transaktion zu bauen. Ein neu generiertes Profil allein reicht nicht aus. Es kann die Identität enthalten, die nötig ist, um ein Konto abzuleiten, aber es hat keinen synchronisierten „Bookkeeper“-Eintrag. Ohne den aktuellen Zustand kann der Transaktions-Builder die für die Übertragung erforderlichen Gelder oder die Nonce nicht zuverlässig bestimmen. Das war die Grenze, die ich fast übersehen hätte. Signieren zeigt, welcher Schlüssel eine Transaktion autorisiert hat. Synchronisation sagt dem Signer, was er gerade jetzt gültig autorisieren kann. Ich mag, dass W3sper die Bausteine offenlegt, ohne stillschweigend so zu tun, als würde es sicheren Storage und Wallet-Recovery heimlich lösen. Aber eine Headless-Anwendung, die diese Kontrolle wählt, übernimmt diese Verantwortlichkeiten eben auch explizit. Macht die Trennung von Transaktionskonstruktion vom Wallet-Status W3sper zu sichererer Infrastruktur — oder macht sie Custom Signer leichter, die man falsch bauen kann?? #dusk @Dusk Dusk W3sper’s Trennung ist… $VELVET wieder ausgeschüttet — kompletter Desaster
#dusk $DUSK
$GPS bereit, höher zu fliegen und noch höher — bald wird es den Himmel berühren. Aber die Zeile, die mich aufgehalten hat, war in @Dusk ’s W3sper-Dokumentation nicht das Thema Unterschreiben.

Es ging um die Warnung, dass ein Transaction Builder (Transaktions-Builder) keine Wallet ist.

W3sper stellt einer Anwendung Low-Level-Tools bereit, um sich mit Rusk zu verbinden, den Status abzufragen und Transaktionen zu erstellen. Aber wenn ein Client ohne eine Wallet-Erweiterung signieren möchte, muss er die Bausteine liefern, für die W3sper sich ausdrücklich nicht verantwortlich macht.

Dazu gehören ein speicherbarer, wiederherstellbarer Key-Storage und ein synchronisiertes Treasury hinter seinem „Bookkeeper“ — einschließlich der Kontostands- und Nonce-State-Daten, die benötigt werden, um eine gültige Transaktion zu bauen.

Ein neu generiertes Profil allein reicht nicht aus.

Es kann die Identität enthalten, die nötig ist, um ein Konto abzuleiten, aber es hat keinen synchronisierten „Bookkeeper“-Eintrag. Ohne den aktuellen Zustand kann der Transaktions-Builder die für die Übertragung erforderlichen Gelder oder die Nonce nicht zuverlässig bestimmen.

Das war die Grenze, die ich fast übersehen hätte.

Signieren zeigt, welcher Schlüssel eine Transaktion autorisiert hat.

Synchronisation sagt dem Signer, was er gerade jetzt gültig autorisieren kann.

Ich mag, dass W3sper die Bausteine offenlegt, ohne stillschweigend so zu tun, als würde es sicheren Storage und Wallet-Recovery heimlich lösen. Aber eine Headless-Anwendung, die diese Kontrolle wählt, übernimmt diese Verantwortlichkeiten eben auch explizit.

Macht die Trennung von Transaktionskonstruktion vom Wallet-Status W3sper zu sichererer Infrastruktur — oder macht sie Custom Signer leichter, die man falsch bauen kann??

#dusk @Dusk

Dusk W3sper’s Trennung ist…

$VELVET wieder ausgeschüttet — kompletter Desaster
Safer infrastructure
62%
Easier to misuse
14%
Both at once
10%
Builder dependent
14%
29 Stimmen • Abstimmung beendet
·
--
Verifiziert
#dusk $PORTAL ist heute in Flammen originally dachte ich, dass ein Upgrade eines Nodes bei @Dusk bedeutet, dass man das Binary ersetzt und die gleiche Maschine mit der gleichen Rolle neu startet. eine Warnung im Operator-Guide hat mich da umdenken lassen. @Dusk_Foundation s Installer bewahrt Consensus-Keys, den Chain-Status und die ausgewählte Service-Konfiguration. Aber er erzeugt ganz bewusst Dateien wie rusk.toml, genesis.toml und die Rusk-systemd-Unit neu. Am wichtigsten ist jedoch: Der Operator muss die bestehenden Netzwerk- und Feature-Flags des Nodes wiederholen. wait let me book my profit in $CYS Wenn ein Archiv-Operator den Installer erneut ausführt, ohne "--feature archive", wird die Installation durch das Standard-Rusk-Binary ersetzt. Die Maschine kann möglicherweise weiterhin laufen, sich mit Peers verbinden und die Blockhöhe vorantreiben, aber sie bietet dann nicht mehr die Archiv-Funktionalität, auf die die Anwendungen angewiesen waren. das ist der Teil, der hängen blieb. Dusk reduziert das Upgrade-Risiko, indem es Ersatz-Binaries herunterlädt und verifiziert, bevor Rusk gestoppt wird. Außerdem lässt es den Service danach gestoppt, damit der Operator die erzeugte Konfiguration prüfen kann, bevor er ihn wieder online bringt. Aber Automatisierung kann nicht entscheiden, welche alten benutzerdefinierten Einstellungen weiterhin gültig sind. Dusk warnt Operatoren ausdrücklich, die vorherige rusk.toml zu vergleichen und nur die Einstellungen erneut anzuwenden, die sie noch brauchen—nicht die gesamte alte Datei in die neue Konfiguration zu kopieren. Eine erfolgreiche Installation ist also nicht das Gleiche wie ein korrekt wiederhergestellter Service. Macht das Neugenerieren der Konfiguration Dusk-Node-Upgrades sauberer und sicherer, oder ist das Erhalten der vorgesehenen Rolle des Nodes der wichtigste Operator-Check?? #dusk @Dusk_Foundation k $DUSK Was ist nach einem Dusk-Node-Upgrade am wichtigsten? {future}(HUSDT) {spot}(DOLOUSDT) {future}(AIOUSDT)
#dusk $PORTAL ist heute in Flammen originally dachte ich, dass ein Upgrade eines Nodes bei @Dusk bedeutet, dass man das Binary ersetzt und die gleiche Maschine mit der gleichen Rolle neu startet.

eine Warnung im Operator-Guide hat mich da umdenken lassen.

@Dusk s Installer bewahrt Consensus-Keys, den Chain-Status und die ausgewählte Service-Konfiguration. Aber er erzeugt ganz bewusst Dateien wie rusk.toml, genesis.toml und die Rusk-systemd-Unit neu.

Am wichtigsten ist jedoch: Der Operator muss die bestehenden Netzwerk- und Feature-Flags des Nodes wiederholen. wait let me book my profit in $CYS

Wenn ein Archiv-Operator den Installer erneut ausführt, ohne "--feature archive", wird die Installation durch das Standard-Rusk-Binary ersetzt. Die Maschine kann möglicherweise weiterhin laufen, sich mit Peers verbinden und die Blockhöhe vorantreiben, aber sie bietet dann nicht mehr die Archiv-Funktionalität, auf die die Anwendungen angewiesen waren.

das ist der Teil, der hängen blieb.

Dusk reduziert das Upgrade-Risiko, indem es Ersatz-Binaries herunterlädt und verifiziert, bevor Rusk gestoppt wird. Außerdem lässt es den Service danach gestoppt, damit der Operator die erzeugte Konfiguration prüfen kann, bevor er ihn wieder online bringt.

Aber Automatisierung kann nicht entscheiden, welche alten benutzerdefinierten Einstellungen weiterhin gültig sind. Dusk warnt Operatoren ausdrücklich, die vorherige rusk.toml zu vergleichen und nur die Einstellungen erneut anzuwenden, die sie noch brauchen—nicht die gesamte alte Datei in die neue Konfiguration zu kopieren.

Eine erfolgreiche Installation ist also nicht das Gleiche wie ein korrekt wiederhergestellter Service.

Macht das Neugenerieren der Konfiguration Dusk-Node-Upgrades sauberer und sicherer, oder ist das Erhalten der vorgesehenen Rolle des Nodes der wichtigste Operator-Check??

#dusk @Dusk k $DUSK

Was ist nach einem Dusk-Node-Upgrade am wichtigsten?


🎯 Preserving the node’s role
50%
🧹 Clean regenerated config
28%
✅ Both are equally critical
5%
👀 Just restart and pray 😂
17%
18 Stimmen • Abstimmung beendet
·
--
$HEMI +53%, $COW +31%, $AIO +30%… die heutigen Gewinner sind aufgewacht und haben gegen die Shorts „Gewalt“ gewählt. 😭🚀 Vor allem COW gibt heute keine Milch—es gibt grüne Kerzen. 🐄😂 Aber wir wissen, wie solche Geschichten manchmal enden… Welche kommt als Erste der Gravitation zuvor? 👀
$HEMI +53%, $COW +31%, $AIO +30%… die heutigen Gewinner sind aufgewacht und haben gegen die Shorts „Gewalt“ gewählt. 😭🚀

Vor allem COW gibt heute keine Milch—es gibt grüne Kerzen. 🐄😂

Aber wir wissen, wie solche Geschichten manchmal enden…

Welche kommt als Erste der Gravitation zuvor? 👀
🐄 COW
36%
🚀 HEMI
39%
🤖 AIO
19%
💀 All together
6%
53 Stimmen • Abstimmung beendet
Anmelden und weiter Inhalte entdecken
Krypto-Nutzer weltweit auf Binance Square kennenlernen
⚡️ Bleib in Sachen Krypto stets am Puls.
💬 Die weltgrößte Kryptobörse vertraut darauf.
👍 Erhalte verlässliche Einblicke von verifizierten Creators.
E-Mail-Adresse/Telefonnummer
Sitemap
Cookie-Präferenzen
Nutzungsbedingungen der Plattform