#shareyouropinion
shareyouropinion
9,042 Aufrufe
35 Kommentare
Hot
Zuletzt
Verifiziert
Ich habe letzte Nacht einen früheren Transparenzbericht gefunden, den ich zuvor nicht gelesen hatte, und das hat verändert, wie ich verstehe, was Newton tatsächlich ist. Newton wurde ursprünglich gar nicht als Compliance-Policy-Engine konzipiert.
Die Offenlegung aus dem Oktober 2025 beschreibt das ursprüngliche Design als einen Keystore-Rollup, der für das Key-Management gebaut wurde – mit Fokus auf verifizierbare Automatisierung und delegierte Autorisierung für KI-Agenten.
Die Kernidee war, dass Agenten Onchain-Aktionen ausführen können – durch kontrollierte, kryptografisch verifizierte Berechtigungen, die an die Key-Management-Infrastruktur gekoppelt sind.
Der Wendepunkt kam, als das Team erkannte, dass dieselben zugrunde liegenden Bausteine für verifizierbare Automatisierung und delegierte Autorisierung weit über das Agent-Key-Management hinausgehen und zu einem allgemeinen Rahmenwerk für die Policy-Durchsetzung werden konnten – über Stablecoins, RWAs und den gesamten breiteren Asset-Markt hinweg.
Der Keystore-Rollup wurde zur Grundlage für etwas viel Größeres: eine Policy-Engine, die regelt, welche Aktionen unter welchen Bedingungen stattfinden dürfen – mit welchen Attestierungen.
Das ist ein deutlich anderer Ausgangspunkt als das, was das Whitepaper, das ich ursprünglich gelesen habe, vermuten ließ.
Ich glaube tatsächlich, dass diese Geschichte wichtig ist, um die Architekturentscheidungen von Newton zu verstehen – das BLS-Attestation-Modell, das Operator-Quorum-Design, die Betonung von Agent Commerce als Use Case. Das sind keine Entscheidungen, die zuerst auf Compliance ausgerichtet waren. Es sind Entscheidungen für Key-Management und Agentenautorisierung, die später auf Compliance-Use-Cases verallgemeinert wurden.
Was ich noch nicht ausgearbeitet habe, ist, wie viel von der aktuellen Architektur noch Annahmen aus dem ursprünglichen Keystore-Rollup-Design trägt, die für eine Compliance-First-Policy-Engine möglicherweise nicht optimal sind – ob der Pivot eine saubere Neuentwicklung war oder eine Erweiterung der ursprünglichen technischen Grundlage.
#ShareYourOpinion
$EVAA $LAB
Wie denkst du, wie sich die Architektur von Newton weiterentwickelt hat?
@NewtonProtocol $NEWT #Newt
Die Offenlegung aus dem Oktober 2025 beschreibt das ursprüngliche Design als einen Keystore-Rollup, der für das Key-Management gebaut wurde – mit Fokus auf verifizierbare Automatisierung und delegierte Autorisierung für KI-Agenten.
Die Kernidee war, dass Agenten Onchain-Aktionen ausführen können – durch kontrollierte, kryptografisch verifizierte Berechtigungen, die an die Key-Management-Infrastruktur gekoppelt sind.
Der Wendepunkt kam, als das Team erkannte, dass dieselben zugrunde liegenden Bausteine für verifizierbare Automatisierung und delegierte Autorisierung weit über das Agent-Key-Management hinausgehen und zu einem allgemeinen Rahmenwerk für die Policy-Durchsetzung werden konnten – über Stablecoins, RWAs und den gesamten breiteren Asset-Markt hinweg.
Der Keystore-Rollup wurde zur Grundlage für etwas viel Größeres: eine Policy-Engine, die regelt, welche Aktionen unter welchen Bedingungen stattfinden dürfen – mit welchen Attestierungen.
Das ist ein deutlich anderer Ausgangspunkt als das, was das Whitepaper, das ich ursprünglich gelesen habe, vermuten ließ.
Ich glaube tatsächlich, dass diese Geschichte wichtig ist, um die Architekturentscheidungen von Newton zu verstehen – das BLS-Attestation-Modell, das Operator-Quorum-Design, die Betonung von Agent Commerce als Use Case. Das sind keine Entscheidungen, die zuerst auf Compliance ausgerichtet waren. Es sind Entscheidungen für Key-Management und Agentenautorisierung, die später auf Compliance-Use-Cases verallgemeinert wurden.
Was ich noch nicht ausgearbeitet habe, ist, wie viel von der aktuellen Architektur noch Annahmen aus dem ursprünglichen Keystore-Rollup-Design trägt, die für eine Compliance-First-Policy-Engine möglicherweise nicht optimal sind – ob der Pivot eine saubere Neuentwicklung war oder eine Erweiterung der ursprünglichen technischen Grundlage.
#ShareYourOpinion
$EVAA $LAB
Wie denkst du, wie sich die Architektur von Newton weiterentwickelt hat?
@NewtonProtocol $NEWT #Newt
Original design mostly remaine
0%
Major redesign after the pivot
0%
A blend of both approaches
33%
Not enough information yet
67%
3 Stimmen • Abstimmung beendet
Traditionelle KYC-AML-Operationswirklichkeit vs. Haftungslücke im Credential-Modell von Newton
Ich habe letzte Woche mit einem Compliance-Officer-Freund das Identitätsmodell von Newton durchgespielt – jemand, der KYC-Programme bei einem regulierten Unternehmen betreibt – und die Lücke zwischen dem, was Newton beschreibt, und dem, was Compliance-Teams operativ tun, war größer als ich erwartet hatte.
Traditionelles KYC/AML: Onboard-Kunde sammelt Dokumente, prüft sie gegen Sanktionsdatenbanken, bewertet das Risiko, speichert den Datensatz. Transaktion wird nachträglich erkannt; Datei prüfen; Review-Historie schreiben; Bericht erstellen; SAR-Datei.
Manuelle, dokumentenlastige Papierkette, die Auditoren akzeptieren. Die Bank ist verantwortlich. Sie hat die Prüfung gemacht. Sie trägt das Ergebnis.
N ewtons Modell: Credential, ausgestellt von einem Drittanbieter-KYC-Provider, das vom Nutzer gehalten und von Operatoren in einer TEE-Enklave gegen eine Richtlinie innerhalb von Sekunden bewertet wird. Das Compliance-Receipt ist die Audit-Spur.
Tempo und Automatisierung sind real. Erste Frage, die mein Compliance-Officer-Freund gestellt hat: Wer ist verantwortlich, wenn Newton sagt, dass das Credential gültig ist, aber die Daten des Ausstellers falsch waren? In Newtons Modell hat der Aussteller es ausgestellt, Operatoren haben es evaluiert, Smart Contract hat es durchgesetzt. Die Verantwortungskette ist länger und weniger klar.
Ich denke tatsächlich, dass die Haftungsverteilung die praktisch wichtigste Designfrage für die institutionelle Einführung ist – nicht die technische Fähigkeit, sondern wer die Haftung trägt, wenn eine von Newton attestierte Transaktion sich als nicht compliant herausstellt.
Was ich noch nicht herausgearbeitet habe, ist, ob die Compliance-Receipts von Newton regulatorische Haftungsanforderungen erfüllen oder nur dokumentieren, dass eine Prüfung durchgeführt wurde – und ob das dasselbe ist.
$LAB $HMSTR #shareyouropinion
@NewtonProtocol $NEWT #Newt
Ich habe letzte Woche mit einem Compliance-Officer-Freund das Identitätsmodell von Newton durchgespielt – jemand, der KYC-Programme bei einem regulierten Unternehmen betreibt – und die Lücke zwischen dem, was Newton beschreibt, und dem, was Compliance-Teams operativ tun, war größer als ich erwartet hatte.
Traditionelles KYC/AML: Onboard-Kunde sammelt Dokumente, prüft sie gegen Sanktionsdatenbanken, bewertet das Risiko, speichert den Datensatz. Transaktion wird nachträglich erkannt; Datei prüfen; Review-Historie schreiben; Bericht erstellen; SAR-Datei.
Manuelle, dokumentenlastige Papierkette, die Auditoren akzeptieren. Die Bank ist verantwortlich. Sie hat die Prüfung gemacht. Sie trägt das Ergebnis.
N ewtons Modell: Credential, ausgestellt von einem Drittanbieter-KYC-Provider, das vom Nutzer gehalten und von Operatoren in einer TEE-Enklave gegen eine Richtlinie innerhalb von Sekunden bewertet wird. Das Compliance-Receipt ist die Audit-Spur.
Tempo und Automatisierung sind real. Erste Frage, die mein Compliance-Officer-Freund gestellt hat: Wer ist verantwortlich, wenn Newton sagt, dass das Credential gültig ist, aber die Daten des Ausstellers falsch waren? In Newtons Modell hat der Aussteller es ausgestellt, Operatoren haben es evaluiert, Smart Contract hat es durchgesetzt. Die Verantwortungskette ist länger und weniger klar.
Ich denke tatsächlich, dass die Haftungsverteilung die praktisch wichtigste Designfrage für die institutionelle Einführung ist – nicht die technische Fähigkeit, sondern wer die Haftung trägt, wenn eine von Newton attestierte Transaktion sich als nicht compliant herausstellt.
Was ich noch nicht herausgearbeitet habe, ist, ob die Compliance-Receipts von Newton regulatorische Haftungsanforderungen erfüllen oder nur dokumentieren, dass eine Prüfung durchgeführt wurde – und ob das dasselbe ist.
$LAB $HMSTR #shareyouropinion
@NewtonProtocol $NEWT #Newt
Punkte- und Belohnungsprogramme in DeFi schaffen Compliance-Sonderfälle. Newtons Identität und Compliance-Domänen sind nicht eindeutig dafür ausgelegt, diese zu adressieren.
Ein Punkteprogramm verteilt Credits oder Token an Wallets basierend auf der Protokollaktivität. In beiden Fällen lautet die Compliance-Frage, ob das empfangende Wallet berechtigt ist, den verteilten Wert zu erhalten.
Die Compliance für Sanktionen gilt für Belohnungs-Distributionen genauso wie für jede andere Wertübertragung.
Ob Newtons Compliance-Domäne eine Sanktionsprüfung für Transaktionen zur Belohnungsverteilung erzwingen kann, insbesondere für die ausgehende Übertragung von Belohnungen von einem Protokoll an ein Wallet, ist in der Dokumentation nicht klar beschrieben.
Die Richtung ist entscheidend.
Die meisten Newton-Anwendungsfälle beinhalten, dass ein Wallet geprüft wird, bevor es eine Transaktion an ein Protokoll sendet.
Ein Rewards-Airdrop funktioniert in die entgegengesetzte Richtung.
Ob das Durchsetzungsmodell auf von Protokollen initiierte ausgehende Übertragungen anwendbar ist, ist eine strukturelle Frage darüber, wie die Richtlinienprüfung ausgelöst wird.
Keine Antwort dazu findet sich in der aktuellen Dokumentation. Der Sonderfall ist real genug, um für jedes DeFi-Protokoll relevant zu sein, das aktive Rewards-Programme betreibt.
@NewtonProtocol $NEWT $LAB $HMSTR #ShareYourOpinion
#Newt #NEWT
Müssen Rewards überprüft werden?
Ein Punkteprogramm verteilt Credits oder Token an Wallets basierend auf der Protokollaktivität. In beiden Fällen lautet die Compliance-Frage, ob das empfangende Wallet berechtigt ist, den verteilten Wert zu erhalten.
Die Compliance für Sanktionen gilt für Belohnungs-Distributionen genauso wie für jede andere Wertübertragung.
Ob Newtons Compliance-Domäne eine Sanktionsprüfung für Transaktionen zur Belohnungsverteilung erzwingen kann, insbesondere für die ausgehende Übertragung von Belohnungen von einem Protokoll an ein Wallet, ist in der Dokumentation nicht klar beschrieben.
Die Richtung ist entscheidend.
Die meisten Newton-Anwendungsfälle beinhalten, dass ein Wallet geprüft wird, bevor es eine Transaktion an ein Protokoll sendet.
Ein Rewards-Airdrop funktioniert in die entgegengesetzte Richtung.
Ob das Durchsetzungsmodell auf von Protokollen initiierte ausgehende Übertragungen anwendbar ist, ist eine strukturelle Frage darüber, wie die Richtlinienprüfung ausgelöst wird.
Keine Antwort dazu findet sich in der aktuellen Dokumentation. Der Sonderfall ist real genug, um für jedes DeFi-Protokoll relevant zu sein, das aktive Rewards-Programme betreibt.
@NewtonProtocol $NEWT $LAB $HMSTR #ShareYourOpinion
#Newt #NEWT
Müssen Rewards überprüft werden?
🔘 Always
67%
🔘 High-value only
33%
🔘 Never
0%
🔘 Depends on rules
0%
6 Stimmen • Abstimmung beendet
Lies die Governance-Dokumentation noch einmal letzte Nacht, weil ich annehmen konnte, dass die bereits bestehende Governance etwas bedeutete. Sie bedeutet, dass etwas entworfen wird.
Der von Newton beschriebene Vorschlagslebenszyklus hat fünf Stufen. Idee – informeller Austausch ohne formelles Verfahren. RFC – Request for Comments, ein strukturiertes Dokument, das eine Änderung vorschlägt. NIP – Newton Improvement Proposal: die formalisierte Version eines RFC, die bereit zur Prüfung ist.
Community-Diskussion – eine offene Phase für Feedback, bevor abgestimmt wird. Token-House-Abstimmung – findet off-chain über Snapshot statt, wobei NEWT-Staker über das NIP abstimmen.
Das ist der vollständige, so gestaltete Ablauf.
Was ich bei meinem ersten Lesen verpasst habe: Dieser Pipeline-Ablauf existiert zwar im Dokument, aber das Token House selbst – also das Gremium, das tatsächlich abstimmt – existiert noch nicht als operierende Struktur. Derzeit trifft der Foundation Board Entscheidungen. Der von dem Dokument als Phase 0 bezeichnete Zustand ist der aktuelle, nicht der angestrebte.
Einzelheiten wie diese verändern, wie ich jede Governance-Behauptung in den Newton-Materialien lese.
Ich finde es tatsächlich gut, dass das Dokument explizit diese Unterscheidung macht – Phase-0-Sprache, nicht vage: Community-gesteuertes Marketing. Es ist selten, dass man sieht, wie ein Projekt seinen eigenen aktuellen Zentralisierungsstatus so direkt mit einem Projektnamen benennt.
Was ich noch nicht herausgefunden habe, ist, was genau den Übergang von Phase 0 zu Phase 1 auslöst – ob es ein festes Zeitfenster ist, eine Dezentralisierungs-Kennzahl oder vollständig im Ermessen des Foundation Boards liegt.
$TAC $LAB #ShareYourOpinion
@NewtonProtocol $NEWT #Newt
Der von Newton beschriebene Vorschlagslebenszyklus hat fünf Stufen. Idee – informeller Austausch ohne formelles Verfahren. RFC – Request for Comments, ein strukturiertes Dokument, das eine Änderung vorschlägt. NIP – Newton Improvement Proposal: die formalisierte Version eines RFC, die bereit zur Prüfung ist.
Community-Diskussion – eine offene Phase für Feedback, bevor abgestimmt wird. Token-House-Abstimmung – findet off-chain über Snapshot statt, wobei NEWT-Staker über das NIP abstimmen.
Das ist der vollständige, so gestaltete Ablauf.
Was ich bei meinem ersten Lesen verpasst habe: Dieser Pipeline-Ablauf existiert zwar im Dokument, aber das Token House selbst – also das Gremium, das tatsächlich abstimmt – existiert noch nicht als operierende Struktur. Derzeit trifft der Foundation Board Entscheidungen. Der von dem Dokument als Phase 0 bezeichnete Zustand ist der aktuelle, nicht der angestrebte.
Einzelheiten wie diese verändern, wie ich jede Governance-Behauptung in den Newton-Materialien lese.
Ich finde es tatsächlich gut, dass das Dokument explizit diese Unterscheidung macht – Phase-0-Sprache, nicht vage: Community-gesteuertes Marketing. Es ist selten, dass man sieht, wie ein Projekt seinen eigenen aktuellen Zentralisierungsstatus so direkt mit einem Projektnamen benennt.
Was ich noch nicht herausgefunden habe, ist, was genau den Übergang von Phase 0 zu Phase 1 auslöst – ob es ein festes Zeitfenster ist, eine Dezentralisierungs-Kennzahl oder vollständig im Ermessen des Foundation Boards liegt.
$TAC $LAB #ShareYourOpinion
@NewtonProtocol $NEWT #Newt
fang klein an. KI-Agenten, die in DeFi Trades generieren, sind niemals dann algorithmisches Trading im traditionellen Finanzwesen, und die Compliance-Infrastruktur rund um sie ist deutlich weniger entwickelt.
zoom out newtons Policy-Layer adressiert die Frage der Transaktions-Ebene nach der Compliance: Klärt diese konkrete Transaktion die definierten Regeln? Das ist eine Ebene dessen, was traditionelle Compliance für algorithmischen Handel erfordert.
#NEWT
die Ebenen darüber sind unterschiedlich. Compliance für traditionelles algorithmisches Trading erfordert Modell-Dokumentation, Audit-Trails, die ausgeführte Trades mit konkreten Modellentscheidungen verknüpfen, sowie eine Killswitch-Funktion zur menschlichen Intervention, wenn sich das Modell unerwartet verhält.
#newt
keines davon wird durch die Vorabsetzungs- (Pre-Settlement-) Durchsetzung auf einzelnen Transaktionen abgedeckt.
zoom out weiter: Wenn KI-Agentenhandel in DeFi skaliert, werden Regulierer Anforderungen ähnlich zu denen stellen, die für algorithmischen Handel in traditionellen Märkten gelten. newtons Infrastruktur ist eine notwendige Komponente dieses Compliance-Stacks. sie als allein ausreichend zu betrachten, wäre eine wesentliche Lücke für jedes regulierte Unternehmen, das KI-Agenten in DeFi nutzt.
#ShareYourOpinion $LAB $HMSTR
@NewtonProtocol $NEWT #Newt
zoom out newtons Policy-Layer adressiert die Frage der Transaktions-Ebene nach der Compliance: Klärt diese konkrete Transaktion die definierten Regeln? Das ist eine Ebene dessen, was traditionelle Compliance für algorithmischen Handel erfordert.
#NEWT
die Ebenen darüber sind unterschiedlich. Compliance für traditionelles algorithmisches Trading erfordert Modell-Dokumentation, Audit-Trails, die ausgeführte Trades mit konkreten Modellentscheidungen verknüpfen, sowie eine Killswitch-Funktion zur menschlichen Intervention, wenn sich das Modell unerwartet verhält.
#newt
keines davon wird durch die Vorabsetzungs- (Pre-Settlement-) Durchsetzung auf einzelnen Transaktionen abgedeckt.
zoom out weiter: Wenn KI-Agentenhandel in DeFi skaliert, werden Regulierer Anforderungen ähnlich zu denen stellen, die für algorithmischen Handel in traditionellen Märkten gelten. newtons Infrastruktur ist eine notwendige Komponente dieses Compliance-Stacks. sie als allein ausreichend zu betrachten, wäre eine wesentliche Lücke für jedes regulierte Unternehmen, das KI-Agenten in DeFi nutzt.
#ShareYourOpinion $LAB $HMSTR
@NewtonProtocol $NEWT #Newt
Verifiziert
Das Whitepaper „The Trustless Bitcoin Vaults (TBV)“ macht in Abschnitt 5 etwas bemerkenswertes deutlich: Es nennt „Open Participation“ als ausgewiesenen Vorteil und spezifiziert im selben Abschnitt „whitelisted liquidators“ als das tatsächliche Mechanismus-Element.@BabylonLabs_io
Der Vorteilspunkt ist ganz explizit darin, wen „open participation“ abdecken soll: Liquidatoren, Kreditnehmer und Entwickler – alle sollen mit minimalem Onboarding in das Protokoll einsteigen. Der Liquidations-Flow ein paar Absätze weiter oben ist ebenso eindeutig: Liquidationen werden von whitelisted liquidators ausgeführt – einer definierten, permissionierten Menge – und nicht von irgendwem, der eine unterbesicherte Position schließen möchte.$BABY
Nicht zu sagen, dass das Whitelisting von Liquidatoren unvernünftig ist: Liquidation bedeutet, echtes Kapital schnell zu halten und zu bewegen, und die Prüfung von Teilnehmern für diese Rolle ist gängige Praxis über sämtliche Lending-Protokolle hinweg – onchain oder off.
Auch nicht zu behaupten, dass die beiden Aussagen mühelos zusammenpassen: Der Vorteil nennt Liquidatoren als „open participants“ – das Mechanismus-Element schränkt sie ein. Beides kann nicht gleichzeitig vollständig wahr sein: „Open“ trägt in diesem Bullet mehr Gewicht, als die Whitelist es stützt.#baby
Es könnte eine Lösung geben, falls die Whitelist selbst leicht zu betreten ist – etwa die k-von-n-Ko-Signatur-Sets, bei denen jede Person eintreten kann. Dann wären minimaler Onboarding-Aufwand und „whitelisted“ im Grunde dasselbe, nur aus zwei unterschiedlichen Blickwinkeln. Aber im Whitepaper wird nie erklärt, wie ein Liquidator tatsächlich whitelisted wird.
Also: Kann man überhaupt ein Liquidator werden, oder endet „open participation“ bei der Whitelist? Abschnitt 5 nennt den Vorteil und die Schranke auf derselben Seite – und verbindet die beiden nie miteinander.
$UAI $BANK
#ShareYourOpinion
#ShareYourVote
Der Vorteilspunkt ist ganz explizit darin, wen „open participation“ abdecken soll: Liquidatoren, Kreditnehmer und Entwickler – alle sollen mit minimalem Onboarding in das Protokoll einsteigen. Der Liquidations-Flow ein paar Absätze weiter oben ist ebenso eindeutig: Liquidationen werden von whitelisted liquidators ausgeführt – einer definierten, permissionierten Menge – und nicht von irgendwem, der eine unterbesicherte Position schließen möchte.$BABY
Nicht zu sagen, dass das Whitelisting von Liquidatoren unvernünftig ist: Liquidation bedeutet, echtes Kapital schnell zu halten und zu bewegen, und die Prüfung von Teilnehmern für diese Rolle ist gängige Praxis über sämtliche Lending-Protokolle hinweg – onchain oder off.
Auch nicht zu behaupten, dass die beiden Aussagen mühelos zusammenpassen: Der Vorteil nennt Liquidatoren als „open participants“ – das Mechanismus-Element schränkt sie ein. Beides kann nicht gleichzeitig vollständig wahr sein: „Open“ trägt in diesem Bullet mehr Gewicht, als die Whitelist es stützt.#baby
Es könnte eine Lösung geben, falls die Whitelist selbst leicht zu betreten ist – etwa die k-von-n-Ko-Signatur-Sets, bei denen jede Person eintreten kann. Dann wären minimaler Onboarding-Aufwand und „whitelisted“ im Grunde dasselbe, nur aus zwei unterschiedlichen Blickwinkeln. Aber im Whitepaper wird nie erklärt, wie ein Liquidator tatsächlich whitelisted wird.
Also: Kann man überhaupt ein Liquidator werden, oder endet „open participation“ bei der Whitelist? Abschnitt 5 nennt den Vorteil und die Schranke auf derselben Seite – und verbindet die beiden nie miteinander.
$UAI $BANK
#ShareYourOpinion
#ShareYourVote
Anyone can liquidate
60%
Whitelist is required
20%
Needs clarification
20%
5 Stimmen • Abstimmung beendet
Ich bin zurückgegangen und habe diesen Wochenende tatsächlich den Testnet-Ablauf durchlaufen, statt nur aus zweiter Hand darüber zu lesen. Ich dachte, angenommenes Anschauen des Video-Guides würde ausreichen, um die Mechanik zu verstehen. Es war nicht .
Das öffentliche Testnet für natives, über Aave v4 durch Trustless Bitcoin Vaults (TBV) abgesichertes Borrowing ermöglicht es dir, Test-BTC in einen Vault zu deponieren, ihm beim Verifizieren On-Chain zuzusehen und dann genau so dagegen zu leihen, wie es im Whitepaper beschrieben wird: collBTC-Minting und Lending. Wenn man zuerst Test-Token aus dem Faucet holt und dann die Einzahlung im Explorer nachverfolgt, wird aus der abstrakten Idee „Vault wird verifiziert“ „collBTC wird gemintet“ – die Beschreibung in den Docks wirkt wie eine echte Abfolge von Schritten statt wie ein Schaubild.
Mir ist der Punkt erst klar geworden, nachdem ich die Light-Client-Verifikationsstufe selbst gemacht habe: Sie ist nicht instant, so wie sich eine normale Token-Übertragung anfühlt. Es gibt eine echte Wartezeit zwischen der Einzahlung und dem Zeitpunkt, an dem das collBTC dann auftaucht und nutzbar ist.
Ich glaube sogar, dass es, wenn man das selbst durchläuft, später verändert, wie man die Whitepaper-Abschnitte liest: Die Settlement- und Liquidation-Flows hören auf, abstrakte Diagramme zu sein, sobald man eine Einzahlung einmal durch dieselben Schritte beobachtet hat.
Was ich noch nicht herausgearbeitet habe, ist, ob die Timings der Testnets sich so anfühlen werden wie das, was Mainnet tatsächlich bietet – oder ob die Testnet-Infrastruktur schneller oder langsamer läuft als eine Live-Deployment.
Es gibt außerdem ein Feedback-Formular, das neben der Testnet-App verlinkt ist, falls du den Ablauf selbst durchgehst – das lohnt sich auf jeden Fall, wenn dir etwas auffällt, das nicht zu den Docks passt.
$EUL $ON #shareyouropinion
@BabylonLabs_io $BABY #baby
Das öffentliche Testnet für natives, über Aave v4 durch Trustless Bitcoin Vaults (TBV) abgesichertes Borrowing ermöglicht es dir, Test-BTC in einen Vault zu deponieren, ihm beim Verifizieren On-Chain zuzusehen und dann genau so dagegen zu leihen, wie es im Whitepaper beschrieben wird: collBTC-Minting und Lending. Wenn man zuerst Test-Token aus dem Faucet holt und dann die Einzahlung im Explorer nachverfolgt, wird aus der abstrakten Idee „Vault wird verifiziert“ „collBTC wird gemintet“ – die Beschreibung in den Docks wirkt wie eine echte Abfolge von Schritten statt wie ein Schaubild.
Mir ist der Punkt erst klar geworden, nachdem ich die Light-Client-Verifikationsstufe selbst gemacht habe: Sie ist nicht instant, so wie sich eine normale Token-Übertragung anfühlt. Es gibt eine echte Wartezeit zwischen der Einzahlung und dem Zeitpunkt, an dem das collBTC dann auftaucht und nutzbar ist.
Ich glaube sogar, dass es, wenn man das selbst durchläuft, später verändert, wie man die Whitepaper-Abschnitte liest: Die Settlement- und Liquidation-Flows hören auf, abstrakte Diagramme zu sein, sobald man eine Einzahlung einmal durch dieselben Schritte beobachtet hat.
Was ich noch nicht herausgearbeitet habe, ist, ob die Timings der Testnets sich so anfühlen werden wie das, was Mainnet tatsächlich bietet – oder ob die Testnet-Infrastruktur schneller oder langsamer läuft als eine Live-Deployment.
Es gibt außerdem ein Feedback-Formular, das neben der Testnet-App verlinkt ist, falls du den Ablauf selbst durchgehst – das lohnt sich auf jeden Fall, wenn dir etwas auffällt, das nicht zu den Docks passt.
$EUL $ON #shareyouropinion
@BabylonLabs_io $BABY #baby
Governance-Power-Dynamik: Wer kontrolliert Quorum-Schwellen, Fee Splits und die Operator-Zulassung?
Der Teil, den niemand in Newtons Governance anspricht, ist die Frage, wer tatsächlich die Parameter kontrolliert, die am meisten zählen.
Drei Governance-Bereiche: Richtlinien-Standards, Operator-Zulassung und Protokoll-Upgrades. Was in der Diskussion fehlt, ist, was diese Bereiche eigentlich steuern.
Quorum-Schwellen: Konfigurierbar pro Aufgabe, festgelegt durch die Governance, bestimmen die ökonomische Sicherheit jeder Attestation im Netzwerk.
Fee Splits: Konfigurierbar, festgelegt durch die Governance, bestimmen die Operator-Ökonomik. Operator-Zulassung: Durch das Governance-Framework des Protokolls geregelt, bestimmt, wer überhaupt Gebühren verdient.
Schauen wir uns an, wer NEWT hält.
Operatoren setzen NEWT ein. Operatoren verdienen Gebühren. Operatoren müssen NEWT halten, um teilnehmen zu können. Wenn Operatoren unverhältnismäßige NEWT-Bestände im Vergleich zu anderen Token-Inhabern haben, haben sie einen unverhältnismäßigen Einfluss auf die Governance-Stimmen, die ihre eigenen Quorum-Schwellen und Fee Splits festlegen.
Nicht so, dass das ungewöhnlich wäre: Die meisten Proof-of-Stake-Governance-Modelle haben in irgendeiner Form dieses Problem. Validatoren in anderen Netzwerken stimmen über Parameter ab, die die Validator-Ökonomie beeinflussen.
#newt
Nicht, dass das zwangsläufig ein Fehler ist: Dass Operatoren „Skin in the Game“ über NEWT-Bestände haben, könnte ihre Interessen mit der langfristigen Gesundheit der Netzwerke ausrichten – statt mit kurzfristigem „Extraction“.
#NEWT
Was ich noch nicht ausgearbeitet habe, ist, ob Newton irgendeinen spezifischen Mechanismus entwickelt hat, um zu verhindern, dass Operatoren gemeinsam dafür stimmen, Quorum-Schwellen zu senken – wodurch ihre eigene operative Belastung sinkt, während gleichzeitig auf leise Weise die Netzwerksicherheit abnimmt.
#shareyouropinion $HMSTR $LAB
@NewtonProtocol $NEWT #Newt
Der Teil, den niemand in Newtons Governance anspricht, ist die Frage, wer tatsächlich die Parameter kontrolliert, die am meisten zählen.
Drei Governance-Bereiche: Richtlinien-Standards, Operator-Zulassung und Protokoll-Upgrades. Was in der Diskussion fehlt, ist, was diese Bereiche eigentlich steuern.
Quorum-Schwellen: Konfigurierbar pro Aufgabe, festgelegt durch die Governance, bestimmen die ökonomische Sicherheit jeder Attestation im Netzwerk.
Fee Splits: Konfigurierbar, festgelegt durch die Governance, bestimmen die Operator-Ökonomik. Operator-Zulassung: Durch das Governance-Framework des Protokolls geregelt, bestimmt, wer überhaupt Gebühren verdient.
Schauen wir uns an, wer NEWT hält.
Operatoren setzen NEWT ein. Operatoren verdienen Gebühren. Operatoren müssen NEWT halten, um teilnehmen zu können. Wenn Operatoren unverhältnismäßige NEWT-Bestände im Vergleich zu anderen Token-Inhabern haben, haben sie einen unverhältnismäßigen Einfluss auf die Governance-Stimmen, die ihre eigenen Quorum-Schwellen und Fee Splits festlegen.
Nicht so, dass das ungewöhnlich wäre: Die meisten Proof-of-Stake-Governance-Modelle haben in irgendeiner Form dieses Problem. Validatoren in anderen Netzwerken stimmen über Parameter ab, die die Validator-Ökonomie beeinflussen.
#newt
Nicht, dass das zwangsläufig ein Fehler ist: Dass Operatoren „Skin in the Game“ über NEWT-Bestände haben, könnte ihre Interessen mit der langfristigen Gesundheit der Netzwerke ausrichten – statt mit kurzfristigem „Extraction“.
#NEWT
Was ich noch nicht ausgearbeitet habe, ist, ob Newton irgendeinen spezifischen Mechanismus entwickelt hat, um zu verhindern, dass Operatoren gemeinsam dafür stimmen, Quorum-Schwellen zu senken – wodurch ihre eigene operative Belastung sinkt, während gleichzeitig auf leise Weise die Netzwerksicherheit abnimmt.
#shareyouropinion $HMSTR $LAB
@NewtonProtocol $NEWT #Newt
Verifiziert
Es gibt einen Datensatz im Whitepaper, den die meisten Menschen überspringen: Eine Übersicht über 166 Blockchain-Netzwerke. Sechzehn davon verfügen über die integrierte Möglichkeit zum Einfrieren von Vermögenswerten.
Neunzehn weitere könnten es mit minimalen Änderungen ermöglichen.
Fünfunddreißig Netzwerke, bei denen die Permissionless-Bedingungen nur teilweise gelten.
Newton verwendet dies, um ein zentrales Problem zu formulieren: Auf UI-Ebene sind Kontrollen unzureichend, aber auch die Annahme ist falsch, dass Blockchain-Schienen neutral seien.
Ein Netzwerk mit Einfriermöglichkeit kann die Einhaltung auf eine Weise erzwingen, die intransparent ist und von der Person kontrolliert wird, die die Einfrierbefugnis innehat – ohne kryptografische Verantwortlichkeit.
N ewtons Antwort ist: Durchsetzung auf der Policy-Ebene, nicht auf der Protokollebene. Autorisierungslogik ist in Rego prüfbar. Das Operator-Set ist dezentral. Compliance-Quittungen onchain. Das verhindert nicht, dass ein Netzwerk Vermögenswerte einfrieren kann, aber es macht Compliance-Entscheidungen von dem Protokoll abtrennbar und prüfbar – selbst wenn die Kette nicht neutral ist.
Keine vollständige Lösung. Eine zusätzliche Verantwortungsebene auf dem Problem darüber.
#NEWT
Ich denke tatsächlich, dass die Einfrierdaten das Problem, das Newton löst, neu rahmen: weniger darum, Compliance zu Permissionless-Schienen hinzuzufügen, und mehr darum, Compliance transparent zu machen, wenn die Schienen selbst möglicherweise nicht transparent sind.
#newt
Die Frage ist, ob die Policy-Ebene von Newton eine sinnvolle Verantwortlichkeit bietet, wenn die zugrunde liegende Kette weiterhin einseitige Einfrierrrechte hat – oder ob eine Compliance-Quittung irrelevant wird, wenn Vermögenswerte ohnehin eingefroren werden können.
#ShareYourOpinion
@NewtonProtocol $NEWT #Newt
$LAB $HMSTR
Neunzehn weitere könnten es mit minimalen Änderungen ermöglichen.
Fünfunddreißig Netzwerke, bei denen die Permissionless-Bedingungen nur teilweise gelten.
Newton verwendet dies, um ein zentrales Problem zu formulieren: Auf UI-Ebene sind Kontrollen unzureichend, aber auch die Annahme ist falsch, dass Blockchain-Schienen neutral seien.
Ein Netzwerk mit Einfriermöglichkeit kann die Einhaltung auf eine Weise erzwingen, die intransparent ist und von der Person kontrolliert wird, die die Einfrierbefugnis innehat – ohne kryptografische Verantwortlichkeit.
N ewtons Antwort ist: Durchsetzung auf der Policy-Ebene, nicht auf der Protokollebene. Autorisierungslogik ist in Rego prüfbar. Das Operator-Set ist dezentral. Compliance-Quittungen onchain. Das verhindert nicht, dass ein Netzwerk Vermögenswerte einfrieren kann, aber es macht Compliance-Entscheidungen von dem Protokoll abtrennbar und prüfbar – selbst wenn die Kette nicht neutral ist.
Keine vollständige Lösung. Eine zusätzliche Verantwortungsebene auf dem Problem darüber.
#NEWT
Ich denke tatsächlich, dass die Einfrierdaten das Problem, das Newton löst, neu rahmen: weniger darum, Compliance zu Permissionless-Schienen hinzuzufügen, und mehr darum, Compliance transparent zu machen, wenn die Schienen selbst möglicherweise nicht transparent sind.
#newt
Die Frage ist, ob die Policy-Ebene von Newton eine sinnvolle Verantwortlichkeit bietet, wenn die zugrunde liegende Kette weiterhin einseitige Einfrierrrechte hat – oder ob eine Compliance-Quittung irrelevant wird, wenn Vermögenswerte ohnehin eingefroren werden können.
#ShareYourOpinion
@NewtonProtocol $NEWT #Newt
$LAB $HMSTR
Yes — transparency matters
50%
No — freezing wins always
25%
Depends on jurisdiction
25%
Only with independent ops
0%
4 Stimmen • Abstimmung beendet
Die Fee-Routing-Sektion von Babylons enthält eine ganz bestimmte Zeile, die man zweimal lesen sollte
Automatisierte On-Chain-Auktion, bei der in BTC denominierten Gebühren für BABY versteigert werden und die Gewinner, die BABY ersteigern, programmgesteuert verbrannt werden.
Keine Ermessensentscheidungen. Kein Komitee, das festlegt, wie viel oder wann verbrannt wird. Nur eine mechanische Auktion, die direkt an die Protokollnutzung gekoppelt ist.
Das ist eine konkrete Designentscheidung und kein generisches Deflations-Tokenomics-Claim. Wenn die Aktivität von Trustless Bitcoin Vaults (TBV) wächst, werden mehr Vaults erstellt, mehr BTC-gestützte Kredite vergeben und mehr Rückkäufe durchgeführt. Dann werden die in BTC generierten Gebühren über diese Auktion geroutet und BABY wird dem Umlauf entfernt – als direkte Funktion der tatsächlichen Nutzung, statt nach einem festen Emissionsplan.
Ich sage nicht, dass das irgendeine Garantie für den Tokenwert bedeutet. Nutzungsabhängige Burns hängen weiterhin davon ab, dass die Nutzung tatsächlich in einem bedeutenden Maßstab stattfindet, und im Whitepaper steht ausdrücklich, dass Gebührenstrukturen und Staking-Regeln weiterhin aktiv gestaltet werden und einer Governance-Freigabe unterliegen.
Und ich sage auch nicht, dass es eine kleine Detailfrage ist. Die Kopplung der Token-Burn-Mechanik an nachgewiesene Protokollnutzung – statt an ein Marketing-Versprechen oder einen festen Zeitplan – ist ein ehrlicheres Signal zum Monitoring als die meisten Tokenomics-Claims in diesem Bereich.
Was ich noch nicht ausgearbeitet habe: Ob dieser Auktionsmechanismus bereits bei einem Live-Deployment aktiviert wurde oder ob er weiterhin eines der Vorschläge ist, die noch unter Design-Diskussion stehen – zusammen mit dem Rest des Fee-Routing-Frameworks.
@BabylonLabs_io $BABY #baby
#ShareYourOpinion
$BANK
$DEXE
Automatisierte On-Chain-Auktion, bei der in BTC denominierten Gebühren für BABY versteigert werden und die Gewinner, die BABY ersteigern, programmgesteuert verbrannt werden.
Keine Ermessensentscheidungen. Kein Komitee, das festlegt, wie viel oder wann verbrannt wird. Nur eine mechanische Auktion, die direkt an die Protokollnutzung gekoppelt ist.
Das ist eine konkrete Designentscheidung und kein generisches Deflations-Tokenomics-Claim. Wenn die Aktivität von Trustless Bitcoin Vaults (TBV) wächst, werden mehr Vaults erstellt, mehr BTC-gestützte Kredite vergeben und mehr Rückkäufe durchgeführt. Dann werden die in BTC generierten Gebühren über diese Auktion geroutet und BABY wird dem Umlauf entfernt – als direkte Funktion der tatsächlichen Nutzung, statt nach einem festen Emissionsplan.
Ich sage nicht, dass das irgendeine Garantie für den Tokenwert bedeutet. Nutzungsabhängige Burns hängen weiterhin davon ab, dass die Nutzung tatsächlich in einem bedeutenden Maßstab stattfindet, und im Whitepaper steht ausdrücklich, dass Gebührenstrukturen und Staking-Regeln weiterhin aktiv gestaltet werden und einer Governance-Freigabe unterliegen.
Und ich sage auch nicht, dass es eine kleine Detailfrage ist. Die Kopplung der Token-Burn-Mechanik an nachgewiesene Protokollnutzung – statt an ein Marketing-Versprechen oder einen festen Zeitplan – ist ein ehrlicheres Signal zum Monitoring als die meisten Tokenomics-Claims in diesem Bereich.
Was ich noch nicht ausgearbeitet habe: Ob dieser Auktionsmechanismus bereits bei einem Live-Deployment aktiviert wurde oder ob er weiterhin eines der Vorschläge ist, die noch unter Design-Diskussion stehen – zusammen mit dem Rest des Fee-Routing-Frameworks.
@BabylonLabs_io $BABY #baby
#ShareYourOpinion
$BANK
$DEXE
Anmelden und weiter Inhalte entdecken