Ich habe mit dem Staking von RLS schon in der Phase der Zusagen begonnen; es war einfach zur Gewohnheit geworden, die offiziellen Materialien durchzugehen. Nachdem der Name „Sovereign“ aufkam, blieb die Diskussion größtenteils bei der Frage: „Ist das nicht nur ein neuer Name?“ Ich finde, die Frage ist falsch gestellt. Der Name ist nicht wichtig; wichtig ist, was darunter ausgetauscht wurde, und wie viel eine Institution bei der Due Diligence selbst prüfen und nachvollziehen kann. In diesem Beitrag habe ich jedes einzelne Zahlenbeispiel mit einer konkreten Quelle versehen. Du kannst das Ganze Schritt für Schritt genau so replizieren.
Zuerst eine Sache vorweg: Letzte Woche habe ich einen Artikel über Prüfbarkeit/„Auditability“ geschrieben. Es ist möglich, dass manche Leser ihn gesehen haben, daher hier noch ein Hinweis.
Der Großteil dessen, was in diesem Beitrag steht, ist neu: es stammt aus dem Code-Repository von Axyl, den Audit-Verzeichnissen innerhalb des Repos sowie aus der Dokumentseite zu den Axyl-Performance-Benchmarks. Diese drei Stellen hatte ich zuvor nicht berührt. Nur das kleine Kapitel zur Key-Delegation knüpft an die Schlussfolgerungen aus dem vorherigen Beitrag an; dort werde ich es entsprechend markieren. Ich trenne Neu und Alt, weil die Leser selbst zwischen „Was ich diese Woche herausgefunden habe“ und „Was ich vorher bereits recherchiert habe“ unterscheiden können sollen.
Zuerst die Zeitleiste richtig einordnen.
Das ist keine Umbenennung.
Axyl wurde Ende April 2026 zuerst auf dem Rayls-öffentlichen Mainnet live geschaltet. Die Migration von Sovereign zu Axyl erfolgte im Juli 2026 – also nach der Einführung im öffentlichen Chain. Die offizielle Dokumentation schreibt, dass die Migration in Phasen durchgeführt wird; währenddessen laufen die Institutionen ganz normal weiter. Erst nachdem die Basis komplett ausgetauscht war, entstand der neue Name.
Im Abschnitt „What changed“ der Dokumentation stehen fünf Punkte. Darunter habe ich zwei ausgewählt und erläutere sie, weil diese beiden Änderungen die Situation der Institutionen verändern – nicht nur Parameter im technischen Stack.
Änderung eins: Von einem einzelnen Node zu einem Komitee
Wörtliches Zitat aus der Dokumentation: Der frühere Rayls-Sovereign-Ledger lief in Form eines einzelnen Geth-Nodes mit einem einzelnen Validator. Axyl nutzt eine byzantinertolerante Konsensstruktur über mehrere Komitees; damit trifft das Risiko der Single-Node-Verfügbarkeit nicht mehr zu. In demselben Abschnitt steht außerdem: EVM-Nodes wurden von Geth auf Reth umgestellt; Clique-Proof-of-Authority wurde durch Axyl ersetzt.
Ich bin in das Repository gegangen und habe nachgesehen, was Axyl ist: Ein in Rust geschriebener Protokoll-Client. Ein einzelnes Binärprogramm „rayls-network“ führt beide Hälften gleichzeitig aus: die Konsens-Ebene ist die Implementierung von Narwhal und Bullshark und läuft über libp2p mit QUIC; die Execution-Ebene ist auf reth und alloy aufgebaut und erzeugt Standard-Ethereum-EVM-Blöcke. Die Nodes sind in Validatoren und Observer unterteilt; Letztere folgen per State-Synchronisierung der Chain, treten aber nicht dem Komitee bei. Das Tooling ist auf Rust 1.91 festgelegt.
Für eine Bank liegt die Bedeutung dieses Punktes nicht im Durchsatz, sondern in der operativen Resilienz. Das Ledger eines einzelnen Nodes mit einem einzelnen Validator: Ein Maschinen-Ausfall bringt das Ledger zum Stillstand, ohne Redundanz – und genau das ist eine der schwierigsten Designarten, die man einem Regulator erklären muss. Wenn man stattdessen ein Komitee nutzt, verwandelt sich dieses Problem von „keine Antwort“ zu „es gibt einen Standard-Antwortweg“. Byzantine Fault Tolerance ist eine Sprache, die Risiko- und Compliance-Abteilungen gleichermaßen kennen.
Auch die Kosten sind konkret. Die im Repository-README angegebene empfohlene Mindestkonfiguration: 8 physische Kerne, 16 GiB RAM, 500 GiB SSD, mindestens 10 Gbps Bandbreite – und das ist die Anforderung pro Komiteemitglied, nicht für eine einzelne Maschine. Die Dokumentation gibt außerdem eine zweistufige Bereitstellungskonfiguration für das Sovereign-Ledger selbst an: leichtgewichtig 2 vCPU, 4 GB, 100 GB; enterprise ab 4 Kernen, 16 GB, 500 GB.
Und es gibt noch eine Stelle, die leicht übersehen wird: Das private Network Hub wurde nicht mitgetauscht. Das Dokument erklärt separat, dass es weiterhin Besu und den Proof-of-Authority-Mechanismus (maßgeblichen/autoritativen Beweis) betreibt und nicht von der Axyl-Migration beeinflusst wird. Die eigene Schicht der Institution ist jetzt byzantinertolerant (BFT), die Schicht zwischen Institutionen nutzt weiterhin den Proof-of-Authority; die Vertrauensmodelle der beiden Schichten sind unterschiedlich, daher sollten sie bei der Bewertung getrennt betrachtet werden.
Änderung zwei: Die Schlüssel wurden aus der Transportkomponente herausgelöst.
Dieser Abschnitt knüpft an das Ergebnis meines vorherigen Textes an; es sind keine neuen Findings dieser Woche. Ich stelle ihn hierher, weil die brief-Anforderung verlangte, zwei Änderungen zu nennen – und dieser Punkt ist tatsächlich einer der fünf.
Der betreffende Punkt in der Dokumentation besagt: Das Key-Management-Modul wird zu „Cryptographic Trust Suite“ – einer entkoppelten Schlüssel-Hosting-Komponente. Der Relayer verarbeitet oder speichert die Schlüssel nicht mehr direkt. In meinem vorherigen Text habe ich diese Aussage im Quellcode nachgeprüft; die „cryptography“-Verzeichnisse in den beiden Repositories „relayer“ und „governance services“ passen dazu.
Für Institutionen hat das zwei Bedeutungen. Erstens: Relayer ist die Außenkommunikation – die am stärksten exponierte Komponente. In der alten Struktur berührt es sowohl Schlüssel als auch Transport; in der neuen Struktur kommt es nicht an die Schlüssel heran. Wenn die Transportstrecke kompromittiert wird, heißt das dann nicht mehr, dass auch die Schlüssel kompromittiert sind. Zweitens: Die Schlüsselverwaltung ist austauschbar (plug-and-play) und kann in das KMS oder den Hardware-Sicherheitsmodul eingebunden werden, das die Institution ohnehin bereits nutzt. Dadurch decken die vorhandenen Audit-Spuren der Institution die Schlüsseloperationen von Rayls ab – es ist nicht nötig, dafür eine neue Audit-Fläche aufzubauen.
Wirklich neue Materialien diese Woche: das Audit-Verzeichnis.
Im Axyl-Repository gibt es ein Verzeichnis audits/. Darin liegen eine README und drei PDFs. Ich habe die README gelesen; der Inhalt ist deutlich konkreter als der Satz „es wurden bereits dritte Audits durchgeführt“.
Alle drei Berichte wurden von Halborn erstellt. Das Zeitfenster für die Behebungen liegt zwischen Februar und März 2026. Die erneute Review zur Validierung der Korrekturen wird im Zeitraum April bis Mai abgeschlossen.
Der Dateiname für das Dokument zum Konsensprotokoll lautet halborn-2026-03-consensus-protocol.pdf. Der Bereich umfasst konsensbezogenen Rust-Codepfade, Zertifikatsynchronisation, Gossip-Verarbeitung und die Verwaltung der Validator-Schlüssel. Laufzeit: 2. März bis 20. März. 5 Findings: davon 1 kritisch, 3 mittel, 1 niedrig. Alle wurden behoben.
Das Dokument für die Netzwerk-Knoten ist halborn-2026-03-network-node.pdf. Der Bereich umfasst die Netzwerk-, Worker-, Status-Synchronisations-, Ausführungs-, Orchestrierungs- und Speicher-Module. Laufzeit: 18. Februar bis 24. März. 22 Findings: davon 1 kritisch, 2 hoch, 7 mittel, 6 niedrig, 6 hinweisend (indikativ). 20 Behebungen, 2 niedriges Risiko akzeptiert.
智能vertrag-Dokument ist halborn-2026-03-smart-contracts.pdf. Der Bereich umfasst die Verträge unter rayls-contracts/src/, darunter ConsensusRegistry, StakeManager, DelegationPool sowie Verträge zur Gebührenaufteilung usw. Laufzeit: 2. März bis 13. März. 15 Findings: davon 1 kritisch, 2 hoch, 7 mittel, 2 niedrig, 3 hinweisend (indikativ). 14 Behebungen (Fixes), 1 mittleres Risiko akzeptiert.
Zusammen ergeben sich 42 Findings: 3 kritisch, 4 hoch, 17 mittel, 9 niedrig, 9 hinweisend. 39 behoben, 3 Risikoakzeptanzen. Alle drei kritischen Schweregrade wurden vollständig gelöst.
Ich habe diese Zahlen einzeln aufgelistet, weil es für den Einkauf völlig unterschiedliche Fragen sind, ob „ein Audit durchgeführt wurde“ und „was genau wurde auditiert, wie lange, wie viele Findings gab es und wie viele davon nicht behoben wurden“. Die erste Frage können fast alle Projekte mit „Ja“ beantworten. Die zweite können deutlich weniger beantworten – und hier ist jede einzelne Angabe öffentlich nachvollziehbar. Alle drei kritischen Schweregrade wurden behoben: Das ist ein messbar positives Faktum.
In derselben README wird noch etwas offengelegt
Diesen Abschnitt halte ich für den nützlichsten für die Due Diligence im ganzen Text.
Die README enthält einen Abschnitt, der sich speziell mit dem Problem von Commit-Historie und Pull-Request-Referenzen beschäftigt. Sinngemäß heißt es im Original: Diese Audits wurden für nicht veröffentlichte, private Repositories durchgeführt. Als das Projekt open-sourced wurde, wurde die Repository-Historie zu einem einzigen Initial-Commit komprimiert. Daher können die im Bericht als Nachweis für Korrekturen zitierten Commit-Hashes und Pull-Request-Links in diesem öffentlichen Repository nicht aufgelöst werden.
Rayls erklärt außerdem: Alle von Halborn verifizierten Korrekturen sind im initialen Commit des öffentlichen Repositories enthalten – und die Zeit dieses Commits liegt nach dem Zeitraum der erneuten Korrekturüberprüfung. Das PDF wurde exakt so veröffentlicht, wie Halborn es erstellt hat, ohne Änderungen.
Für eine Organisation, die Due Diligence (Prüfung) durchführt, ist das eine konkrete und reale Einschränkung: Der Bericht ist lesbar und unmodifiziert, aber die Korrektur-Beweiskette, auf die der Bericht verweist, lässt sich im öffentlichen Repository nicht nachvollziehen. Du kannst sehen, dass Halborn sagt, ein Problem sei behoben, aber du kannst nicht dem Link folgen, um die tatsächlichen Code-Änderungen dieser Behebung zu prüfen.
Ich möchte betonen, dass es sich nicht um ein Verbergen handelt – im Gegenteil: Rayls hat das in der README selbst proaktiv klargeschrieben, inklusive der Gründe und der Kompensationshinweise. Ich habe es nur deshalb ausgeführt, weil das die erste Frage ist, die das Security-Team stellen wird – und die Antwort steht bereits dort, nur in einer Datei, die die meisten nicht öffnen.
Diese Durchsatz-Zahl – die Bedingungen sind ebenfalls öffentlich.
Diesen Punkt sage ich separat, weil die Community-Zusammenfassung im August ihn ausdrücklich beim Namen genannt hat: Zwei TPS-Zahlen kursieren, und man zitiert meist die größere davon.
Ich habe die drei Quellen einmal sauber gegeneinander abgeglichen. Offizielle Dokumentation: Beim Thema Sovereign-Performance steht dort „Axyl: 15.000+ TPS, subsekundäre Finalität“. Axyl-Repository-README: Dort steht als Ziel „10.000+ TPS“, und die Formulierung ist „targets“ – Zielwerte, nicht Messwerte. Und die Bedingungen sind an der dritten Stelle: ein Dokument namens „Axyl Performance Benchmarks“. Dort steht auf dieser Seite explizit, dass es sich um Prototyp-Benchmark-Tests der Konsens-Ebene handelt. Die aufgezeichneten Bedingungen sind: vier-Node-Komites, 512-Byte-Transaktionen, 500 KB Batch-Größe, maximale 50 ms Batch-Verzögerung. Außerdem gibt es separat Konsensdaten für ein Testnetz.
Also lautet die vollständige Formulierung: Konsens-Ebene – Prototyp-Benchmarks unter diesen vier Bedingungen, nicht End-to-End-Produktionstestwerte. Es muss außerdem darauf hingewiesen werden: Die konkreten Werte auf dieser Seite werden als Bild bereitgestellt. Ich kann die Zahlen im Bild nicht lesen; bestätigen kann ich nur die Bedingungen selbst.
Nebenbei ein Beleg, den ich selbst durch Ausprobieren erhalten habe. Am 12. September habe ich das stats-Interface des Public-Chain-Explorers abgerufen; die gemittelte Blockzeit lag bei etwa 500 Millisekunden. Das passt zur Aussage im Bereich „unter einer Sekunde“ (subsekundär), und jede Person kann mit demselben Interface das selbst einmal nachsehen. Die Blockzeit ist nicht gleichbedeutend mit Transaktionsfinalität, aber sie ist zumindest ein unabhängig messbarer Wert und nicht nur eine Weitergabe.
Ein Detail, das ein Einkaufsteam zwar fragt, aber selten thematisiert wird
Die Lizenz von Axyl ist BUSL-1.1, eine kommerzielle Sourcecode-Lizenz – nicht im üblichen Sinn Open Source.
Der Abschnitt „Repository-Lizenz“ ist sehr konkret: Erlaubte produktive Nutzungen sind das Ausführen von Nodes im Rayls-öffentlichen Mainnet und auf den offiziellen Testnets, einschließlich der vier Typen Validator, Observer, Relayer und RPC. Andere produktive Nutzungen benötigen eine kommerzielle Lizenz. Nach vier Jahren ab der ersten Veröffentlichung jedes Releases öffentlich wird das Änderungsdatum festgelegt; danach erfolgt der Übergang zu Apache 2.0.
Wenn man weiterliest: Eine Bank betreibt Axyl in ihrer eigenen Sovereign-Deployment-Umgebung – das gehört zu anderen produktiven Nutzungsfällen.
Das ist keine Kritik. Rayls hat nach außen selbst bereits gesagt: Die Kern-Plattform ist open source, während Axyl und Enygma kommerzielle Komponenten sind. BUSL plus vier Jahre bis zur Umstellung auf Apache ist in der Branche ein etabliertes Vorgehen. Ich habe es nur aufgeschrieben, weil der Begriff „Open Source“ in der Verbreitung häufig so verstanden wird, als dürfte man ihn beliebig verwenden – und die Grenzen stehen in der Lizenzdatei ganz klar.
Woher der Code kommt – das sagt das Repository selbst.
Die Danksagungen im Axyl-Repository sind auffallend offen. Der Rust-Teil im Konsensbereich leitet sich vom Telcoin Network ab; dieses wiederum basiert auf Sui, konkret auf dessen Narwhal- und Bullshark-Komponenten. Rayls hat darauf aufbauend eine große Umstrukturierung und Änderungen vorgenommen. Die Implementierung von Bullshark leitet sich stark von den Sui-Codebasen von Mysten Labs ab – unter Grundlage von Apache 2.0. Die Execution Layer nutzt reth und alloy. Das LayerZero OFT-Interface behält die ursprüngliche MIT-Lizenz.
Die „Stammbaum“-Herleitung sauber zu dokumentieren ist für das Vertrauen eines Engineering-Teams meist einfacher als zu behaupten, alles sei komplett selbst entwickelt, denn der Auditor kann entlang dieser Linie die Reife des Upstreams nachvollziehen.
Welche Punkte sind neu, welche setzen fort, welche konnte ich nicht verifizieren
Neue Recherche in dieser Woche: der vollständige Inhalt der Axyl-Repository-README – inklusive Architektur, Rollen, Konfiguration, Lizenz und Danksagungen; die drei Berichtstabellen in audits/README.md sowie die Erklärung zur Komprimierung der Commit-Historie; doc/index.md – der Systemüberblick; die Benchmark-Bedingungen auf der Seite Axyl Performance Benchmarks; die fünf Punkte „What changed“ in der offiziellen Dokumentation zur Rayls-Sovereign-Seite sowie die zweistufige Bereitstellungskonfiguration.
In Fortsetzung des vorherigen: die Key-Grenzen von „Cryptographic Trust Suite“ sowie die Aussage, dass der Relayer die Schlüssel nicht besitzt/verwaltet – das hatte ich letzte Woche in den Quellcodes der beiden Repositories „relayer“ und „governance services“ nachgeprüft. In diesem Abschnitt gibt es keine neuen Belege.
Meine Schlussfolgerung: Der Hauptwert darin, von einem einzelnen Node auf ein Komitee umzustellen, liegt eher in der operativen Resilienz als im Durchsatz. Dass die Korrektur-Beweiskette im öffentlichen Repository nicht nachvollziehbar ist, ist eine praktische Einschränkung auf der Due-Diligence-Ebene. Das saubere Dokumentieren der Code-Herkunft ist ein positives Signal.
Signal. In diesen drei Unterlagen steht das so nicht.
Nicht verifizieren konnte ich Folgendes: Ich habe keinen Beleg dafür, dass irgendeine Institution diese Konfiguration tatsächlich in der Praxis ausführt. Alles, worüber in diesem Text gesprochen wird, bezieht sich auf die in Dokumenten und Code aufgezeichneten Fähigkeiten.
Reproduktionspfad: GitHub „suche nach raylsnetwork/axyl“, zwei Dateien im Repository-Root – README und audits/README.md – decken die meisten Zahlen in diesem Text ab. Offizielle Dokumentation: suche nach „Rayls Sovereign“ und „Axyl Performance Benchmarks“ – das sind zwei Seiten. Für die Blockzeit die /api/v2/stats des Mainnet-Blockexplorers aufrufen.
