Binance Square
#voteyouropinion

voteyouropinion

167 Aufrufe
3 Kommentare
Mirza_X_Mustafa
·
--
Lies die Q4-2025-Reports zur Oracle-Integration die Liste zweimal, weil bei mir beim ersten Durchgang etwas nicht zusammengepasst hat. Newton hat jetzt zwei separate KYC-orientierte Identitätsoracles: Persona und Veriff – und ich gehe davon aus, dass sich ein Protokoll auf eines festlegen würde. Persona wurde in Q1 2026 angekündigt. Veriff erscheint im Q4-2025-Report – das bedeutet, dass es Persona ungefähr ein Vierteljahr vorausgeht. Diese Reihenfolge ist wichtig: Veriff ist kein redundanter Zusatz nach Persona, das bereits existierte. Persona kam danach. Also warum pflegt man zwei Identitätsverifizierungs-Oracles, die eine ähnliche Arbeit leisten. Der Report rahmt das Oracle-Modell von Newton als neutrale Policy-Schicht über heterogene Systeme hinweg – statt als Bestätigung für eine bestimmte Anwendung. Die gleiche Formulierung mit dem Hinweis zur Nicht-Unterstützung, wie sie in der früheren Analyse der beispielhaften Nicht-Endorsement-Rahmung verwendet wurde. Wenn man das gegen diese Rahmung liest: Zwei KYC-Anbieter sind keine Redundanz, sondern ihre Optionālität. Ein Policy-Autor, der einen Compliance-Stack aufbaut, wählt, welcher Identitätsverifizierungsanbieter zu den bestehenden Beziehungen oder regulatorischen Anforderungen passt: Veriff für die Dokumentationsstandards einer Jurisdiktion, Persona für andere – oder beides, je nachdem, welchen Vendor ein bestimmtes Institut bereits im Vertrag hat. Ich denke tatsächlich, dass das neu rahmt, wie man die X-Ankündigungen interpretieren sollte, mit denen Newton integriert. Nicht individuell, sondern gemeinsam: Das Muster ist nicht „Newton hat den besten KYC-Vendor ausgewählt“. Vielmehr baut Newton eine Art Menü, und Policy-Autoren wählen daraus basierend auf ihren eigenen bestehenden Vendor-Beziehungen und den Bedürfnissen in den jeweiligen Jurisdiktionen. Was ich noch nicht geklärt habe, ist, ob die Persona- und Veriff-Daten innerhalb einer einzigen Policy zusammengesetzt werden können – also ob es eine Einigung zwischen beiden braucht – oder ob man entweder das eine oder das andere akzeptiert. Und außerdem: Muss ein Policy-Autor genau ein Identitätsoracle pro Policy auswählen und darf nicht gleichzeitig auf beide verweisen. Warum denkst du, dass Newton sowohl Persona als auch Veriff integriert? #ShareYourVote #VoteYourOpinion $DODO $XEC @NewtonProtocol $NEWT #Newt
Lies die Q4-2025-Reports zur Oracle-Integration die Liste zweimal, weil bei mir beim ersten Durchgang etwas nicht zusammengepasst hat. Newton hat jetzt zwei separate KYC-orientierte Identitätsoracles: Persona und Veriff – und ich gehe davon aus, dass sich ein Protokoll auf eines festlegen würde.

Persona wurde in Q1 2026 angekündigt. Veriff erscheint im Q4-2025-Report – das bedeutet, dass es Persona ungefähr ein Vierteljahr vorausgeht. Diese Reihenfolge ist wichtig: Veriff ist kein redundanter Zusatz nach Persona, das bereits existierte. Persona kam danach.

Also warum pflegt man zwei Identitätsverifizierungs-Oracles, die eine ähnliche Arbeit leisten.

Der Report rahmt das Oracle-Modell von Newton als neutrale Policy-Schicht über heterogene Systeme hinweg – statt als Bestätigung für eine bestimmte Anwendung. Die gleiche Formulierung mit dem Hinweis zur Nicht-Unterstützung, wie sie in der früheren Analyse der beispielhaften Nicht-Endorsement-Rahmung verwendet wurde.

Wenn man das gegen diese Rahmung liest: Zwei KYC-Anbieter sind keine Redundanz, sondern ihre Optionālität. Ein Policy-Autor, der einen Compliance-Stack aufbaut, wählt, welcher Identitätsverifizierungsanbieter zu den bestehenden Beziehungen oder regulatorischen Anforderungen passt: Veriff für die Dokumentationsstandards einer Jurisdiktion, Persona für andere – oder beides, je nachdem, welchen Vendor ein bestimmtes Institut bereits im Vertrag hat.

Ich denke tatsächlich, dass das neu rahmt, wie man die X-Ankündigungen interpretieren sollte, mit denen Newton integriert. Nicht individuell, sondern gemeinsam: Das Muster ist nicht „Newton hat den besten KYC-Vendor ausgewählt“. Vielmehr baut Newton eine Art Menü, und Policy-Autoren wählen daraus basierend auf ihren eigenen bestehenden Vendor-Beziehungen und den Bedürfnissen in den jeweiligen Jurisdiktionen.

Was ich noch nicht geklärt habe, ist, ob die Persona- und Veriff-Daten innerhalb einer einzigen Policy zusammengesetzt werden können – also ob es eine Einigung zwischen beiden braucht – oder ob man entweder das eine oder das andere akzeptiert. Und außerdem: Muss ein Policy-Autor genau ein Identitätsoracle pro Policy auswählen und darf nicht gleichzeitig auf beide verweisen.

Warum denkst du, dass Newton sowohl Persona als auch Veriff integriert?
#ShareYourVote #VoteYourOpinion $DODO $XEC
@NewtonProtocol $NEWT #Newt
Vendor optionality
0%
Better security
100%
Regional compliance
0%
1 Stimmen • Abstimmung beendet
Teilweise korrekt
Ich schaue diese Woche in den Credit-Underwriting-Abschnitt von Newton, weil das der eine Use Case ist, der nicht in das Compliance- bzw. Durchsetzungs-Framework passt. Und ich wollte verstehen, was er anders macht. #NEWT Traditionelles Credit Scoring: Zentrale Kreditauskunfteien sammeln Finanzhistorien, führen ein proprietäres Modell aus, geben einen Score aus und die Kreditgeber legen daraus die Konditionen fest. Die Daten verlassen die Auskunftei nicht. Das Modell ist undurchsichtig. Der Kreditnehmer kann nicht nachprüfen, wie ihr Score berechnet wurde, oder die Eingaben anfechten. #newt Was genau ändert sich also mit Newtons Modell. Eine Policy-Engine bewertet Credentials, die Kredit-Historie, die Einkommensverifikation und den Wert der Sicherheiten und gibt eine Credit-Band aus, die die verfügbaren Konditionen bestimmt. Die Credentials sind verifizierbar. Die Policy-Logik ist in Rego auditierbar. Was der Kreditgeber sieht, ist Nicht ein Score aus einer Blackbox – es ist ein attestiertes Ergebnis aus einer Policy, die sie selbst verfasst haben und die sie einsehen können. Ich finde den Auditierbarkeits-Aspekt hier sogar spannender als den Datenschutz-Aspekt. Das Problem beim traditionellen Credit Scoring ist nicht nur die Zentralisierung, sondern dass weder Kreditnehmer noch Regulierer die Eingaben oder die Logik verifizieren können. Newton macht beides prüfbar. Was ich noch nicht erklärt gesehen habe, ist, ob die On-Chain-Credit-Bewertung die verhaltensbezogene Tiefe einbauen kann, die traditionelles Scoring vorhersagend macht, oder ob verifizierbare Credentials auf einfachere Bestätigungen beschränkt sind, die das vollständige Kreditbild verfehlen. @NewtonProtocol $NEWT #Newt $HMSTR {future}(HMSTRUSDT) $LAB {alpha}(560x7ec43cf65f1663f820427c62a5780b8f2e25593a) #VoteYourOpinion
Ich schaue diese Woche in den Credit-Underwriting-Abschnitt von Newton, weil das der eine Use Case ist, der nicht in das Compliance- bzw. Durchsetzungs-Framework passt. Und ich wollte verstehen, was er anders macht.
#NEWT
Traditionelles Credit Scoring: Zentrale Kreditauskunfteien sammeln Finanzhistorien, führen ein proprietäres Modell aus, geben einen Score aus und die Kreditgeber legen daraus die Konditionen fest. Die Daten verlassen die Auskunftei nicht. Das Modell ist undurchsichtig. Der Kreditnehmer kann nicht nachprüfen, wie ihr Score berechnet wurde, oder die Eingaben anfechten.
#newt
Was genau ändert sich also mit Newtons Modell.
Eine Policy-Engine bewertet Credentials, die Kredit-Historie, die Einkommensverifikation und den Wert der Sicherheiten und gibt eine Credit-Band aus, die die verfügbaren Konditionen bestimmt. Die Credentials sind verifizierbar. Die Policy-Logik ist in Rego auditierbar. Was der Kreditgeber sieht, ist
Nicht ein Score aus einer Blackbox – es ist ein attestiertes Ergebnis aus einer Policy, die sie selbst verfasst haben und die sie einsehen können.

Ich finde den Auditierbarkeits-Aspekt hier sogar spannender als den Datenschutz-Aspekt. Das Problem beim traditionellen Credit Scoring ist nicht nur die Zentralisierung, sondern dass weder Kreditnehmer noch Regulierer die Eingaben oder die Logik verifizieren können.

Newton macht beides prüfbar.

Was ich noch nicht erklärt gesehen habe, ist, ob die On-Chain-Credit-Bewertung die verhaltensbezogene Tiefe einbauen kann, die traditionelles Scoring vorhersagend macht, oder ob verifizierbare Credentials auf einfachere Bestätigungen beschränkt sind, die das vollständige Kreditbild verfehlen.

@NewtonProtocol $NEWT #Newt
$HMSTR
$LAB
#VoteYourOpinion
Regulator can't verify inputs
0%
Borrower can't challenge it
0%
Centralized data control
100%
Opaque black box model
0%
1 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