Solanas Ledger kann nun verbergen, wie viel Geld zwischen zwei Parteien bewegt wurde – aber nicht, wer diese Parteien sind. Das ist der zentrale Kompromiss von Privacy Rings, dem Confidential-Transfer-System, das der Solana-Infrastrukturanbieter Helius am 10. November in seinem Launch-Beitrag vorgestellt hat.

Der permissionlose Standard-Ring funktioniert als Shielded Pool: Verschlüsselte Guthaben liegen auf Solanas eigenem Ledger, Transfers werden in gewöhnlichen Solana-Transaktionen abgewickelt, und Zero-Knowledge-Proofs verifizieren jede Bewegung. Drei Produkte haben ihn bereits übernommen – Decrypt, das Confidential Transfers in seinem Geldkonto nutzt; die Ore Mining- und Staking-App; und Aurora Intents, das Assets aus anderen Chains direkt in ein verschlüsseltes Guthaben liefert.

Für Wallets, die nie optieren, ändert sich nichts. Eine bestehende Solana-Adresse behält ihre öffentliche Historie, und Privatsphäre beginnt erst, wenn Gelder in ein privates Guthaben bewegt werden – und selbst dann nur für die Felder, die der Ring zu verschlüsseln vorgesehen ist. Welche Felder das sind und wer sie weiterhin lesen kann, bestimmt, wie viel Schutz das System tatsächlich bietet.

Zahlungen an unvorbereitete Empfänger nehmen den öffentlichen Weg

Das Detail, das Lohn- und Treasury-Teams am ehesten überrascht, findet sich in Helius' Produkt-FAQ: Wenn der Empfänger einer Zahlung keine Private Wallet besitzt, verwandelt die Privacy API die Zahlung in eine Auszahlung an die öffentliche Adresse des Empfängers. Das Geld kommt an – aber auf dem öffentlichen Weg, auf dem Asset und Betrag für jeden sichtbar sind.

Helius' Transfer-Anleitung erklärt, warum diesen Fallback gibt. Ein privater Transfer wird an eine Shielded-Adresse adressiert – ein Bündel aus Signing-, Nullifier- und Viewing Keys, das der Empfänger in einem Registrierungseintrag veröffentlicht – und die verschlüsselte Ausgabe ist an den Viewing Key dieses Empfängers gebunden. Wer nie einen registriert hat, besitzt kein privates Guthaben, in dem die Gelder landen könnten. Helius' Landingpage ist zutreffend, wenn sie sagt, dass Empfänger keine spezielle Wallet benötigen, um Gelder zu empfangen; es ist die Privatsphäre dieses Empfangs, nicht der Empfang selbst, die von der Einrichtung abhängt.

Für eine Anwendung wird der Status des Empfängers damit Teil des Zahlungsbildschirms. Ein Sender, der eine bekannte Solana-Adresse sieht und annimmt, dass der Betrag verschlüsselt wird, könnte gerade eine öffentliche Überweisung genehmigen. Die sinnvolle Konstruktion ist, vor der Signaturanforderung anzuzeigen, welcher Weg ausgeführt wird, und den öffentlichen Weg zu einer expliziten Wahl statt zu einem stillen Standard zu machen. Genau aus diesem Grund baut Helius eine eingebettete Private Wallet, die beide Guthabenstypen hält, und nennt Backpack, Squads, Jupiter, DFlow und Titan als Teams, die an Integrationen arbeiten. Bis die Wallet eines Empfängers privaten Empfang unterstützt, ist der Fallback der Weg, den ihre Zahlungen nehmen – was den Rollout dieser Integrationen zur praktischen Schwelle dafür macht, wie viel eines Zahlungsflusses auf dem verschlüsselten Weg bleiben kann.

Was die Chain auf dem privaten Weg weiterhin zeigt

Selbst wenn beide Seiten vollständig eingerichtet sind, ist der Standard-Ring vertraulich statt anonym. Helius' Anleitungen legen die Sichtbarkeit jedes Schritts dar, und das Muster ist das, was ein Chain-Analyst erwarten würde: Die Enden der Reise sind öffentlich, die Mitte ist verschlüsselt.

• Deposit — öffentlich: einzahlende Adresse, Asset, Betrag; verschlüsselt: das resultierende private Guthaben.
• Privater Transfer — öffentlich: Sender- und Empfängeradressen, Gebührenzahler; verschlüsselt: Asset, Betrag, optionales Memo.
• Auszahlung — öffentlich: abhebende Adresse, Ziel, Asset, Betrag; verschlüsselt: das verbleibende private Guthaben.

Die Aufstellung stützt sich auf Helius' Deposit-, Transfer- und Auszahlungs-Anleitungen für den Standard-Ring und deckt nur die direkte Onchain-Sichtbarkeit ab; Rückschlüsse aus anderen Aufzeichnungen sind eine separate Frage.

Man betrachte ein Unternehmen, das die Lohnabrechnung aus einer Treasury-Wallet finanziert, die bereits mit seinem Namen verknüpft ist. Die Bewegung von 30.000 USDC in ein privates Guthaben veröffentlicht diese Zahl beim Deposit. Die darauffolgenden Gehaltsüberweisungen verbergen jeweils den Betrag, sodass niemand einzelne Lohnzahlungen vom Ledger ablesen kann. Lesbar ist die Form: eine bekannte Unternehmensadresse, die am selben Tag jedes Monat denselben Dutzend Adressen zahlt. Wenn je einer dieser Empfänger mit einer Person in Verbindung gebracht wurde, ist der verschlüsselte Betrag das Einzige, was zwischen diesem Muster und einer Gehaltsschätzung steht – und die Schätzung wird genauer, sobald ein Mitarbeiter auf ein öffentliches Guthaben abhebt, denn der abgehobene Betrag ist sichtbar. Ein wiederkehrender Empfänger könnte ebenso ein Lieferant sein, also beweist die Chain nie ein Beschäftigungsverhältnis, aber das Eingrenzen von Möglichkeiten ist genau das, was Analytics-Firmen verkaufen. Coindoo hat dieselbe Identitätsspur in seiner Berichterstattung über COTIs Ansatz für private Zahlungen nachgezeichnet.

Zwei kleinere Details verschärfen das Bild. Der Gebührenzahler eines privaten Transfers ist eine öffentliche Solana-Adresse, und Helius erlaubt einem Gas-Sponsor, diese zu übernehmen – was bedeutet, dass ein Unternehmen, das Gebühren für Mitarbeiter übernimmt, seinen Namen an jede Transaktion hängt, selbst wenn es nicht der Sender ist. Das Memo-Feld wird, sofern genutzt, zusammen mit dem Betrag verschlüsselt, sodass eine Rechnungsreferenz privat reist, während die beiden Adressen, die sie austauschen, es nicht tun.

Wer außer der Chain den Betrag lesen kann

Ein Feld Onchain zu verschlüsseln, entscheidet, was die Öffentlichkeit sieht. Es sagt nichts darüber aus, wen der Nutzer hineingelassen hat. Helius' Verschlüsselungs-Dokumentation gliedert die Frage in Ebenen, und die Ebene, die ein Unternehmen tatsächlich verhandelt, ist die mittlere: delegierter Zugriff.

• Gegenpartei — sieht die Transaktion, an der sie beteiligt war; der Empfang einer Zahlung öffnet nichts Weiteres in der Wallet des Senders.
• Delegierter Viewing Key — ein vom Nutzer autorisierter Anbieter kann Guthaben und Historie lesen, aber keine Gelder bewegen.
• Transaktions-Viewing Key — gibt nur eine einzelne Transaktion frei, etwa eine Rechnung an einen Prüfer ohne den Rest des Ledgers.
• Ramp-Anbieter — eine Fiat-On- oder Off-Ramp hält den Onchain-Abschnitt verschlüsselt, bearbeitet aber die Bankseite und kennt deren Details.

Standardmäßig bleibt der Viewing Key auf dem Gerät des Nutzers, und die Entschlüsselung erfolgt lokal; Helius erzeugt Proofs und leitet Transaktionen weiter, hält aber niemals Schlüssel. Die Delegation ist der Punkt, an dem die Buchhaltung, die Treasury-Software oder ein Abstimmungsdienst eines Unternehmens eine Kopie dieses Schlüssels erhält. Die praktische Folge ist eine sauberere Trennung, als die meisten Finanzteams sie von einer Bank bekommen: Ein Buchhalter kann vollen Lesezugriff auf ein privates Ledger erhalten, ohne eine Zahlung genehmigen zu können, und einer Gegenpartei kann eine einzelne Position daraus gezeigt werden. Die Kehrseite: Jede Delegation ist eine dauerhafte Offenlegung, sodass ein Unternehmen, das mehreren Dienstleistern Viewing Keys aushändigt, still das Publikum wieder aufgebaut hat, das es verkleinern wollte.

Wie sich dies von Solanas bestehenden Confidential Transfers unterscheidet

Solana bietet bereits Betrags-Verschleierung durch die Confidential-Transfer-Erweiterung in Token Extensions, daher ist die Frage, was Rings hinzufügt, berechtigt. Die Erweiterung funktioniert pro Token: Ein Emittent aktiviert sie auf einem Mint, und Halter dieses Mints können Guthaben shielden und Beträge transferieren, während der Token selbst und die Gegenparteien sichtbar bleiben. Rings fungieren als Pool, der SOL-, SPL- und Token-2022-Assets ohne Beteiligung des Emittenten akzeptiert, das Asset ebenso wie den Betrag verschlüsselt und private Guthaben anderen Programmen über Cross-Program Invocations zugänglich macht – der Mechanismus, den Helius für private Escrows, Swaps und Besicherung vorschlägt. Beide Ansätze lassen die beiden Adressen offen; Rings erweitern, was zwischen ihnen liegt.

Custom Rings und die Audits

Anonymität auf Adressenebene steht auf der Roadmap, nicht auf dem Mainnet. Helius' Custom-Rings-Dokumentation beschreibt institutionell betriebene Rings, die wie der Standard vertraulich oder anonym konfiguriert werden können, mit verschlüsselten Sender- und Empfängerdaten und Transfers, die über einen Relayer eingereicht werden. Jeder ergänzt einen Auditor-Key mit Lesezugriff unter einer von der Institution festgelegten Richtlinie, dazu Onchain-Allowlists, Blocklists, Freezes und zusätzliche Signaturanforderungen. Transfers über Rings hinweg folgen den Regeln des Quell-Rings und können ein Standard-Ring-Guthaben mit einem Custom Ring in einer einzigen Transaktion kombinieren. Helius nennt für den angestrebten Mainnet-Release Q4 2026, die Audits laufen noch.

Der aktive Standard-Ring hat drei unabhängige Audits durch Certora, ZK Security und OtterSec durchlaufen, und das Trusted Setup für seine Circuits wurde von Ingenieuren der Solana Foundation, Blueshift, Zcash, Certora, OtterSec und ZK Security durchgeführt. Solche Multi-Party-Setups sind eine Standardsicherungsmaßnahme in Zero-Knowledge-Systemen – die Parameter werden gemeinsam erzeugt, sodass kein einzelner Teilnehmer allein das besitzt, was nötig wäre, um Proofs zu fälschen – und Zcashs Präsenz auf der Liste ist bemerkenswert, da dieses Projekt Shielded Pools auf einer öffentlichen Blockchain maßgeblich voranbracht hat. Die formale Verifizierung der Programme und Circuits läuft, mit einer Fertigstellung, die Helius bis Ende 2026 erwartet. Zusammen mit dem Q4-2026-Ziel für Custom Rings macht das 2026 zum Jahr, in dem die beiden verbleibenden Meilensteine der Roadmap zu beobachten sind: Anonymität auf Adressenebene und formale Verifizierung.

Drei Fragen vor der Signatur

Eine Privacy-Rings-Zahlung ist genau in drei Dimensionen privat, und der Sender kontrolliert nur eine davon. Welchen Weg die Zahlung nimmt, entscheidet die Wallet des Empfängers. Welche Adressen erscheinen, entscheidet die Chain. Wer sonst den Betrag entschlüsseln kann, liegt beim Sender – über die Schlüssel, die er zu delegieren wählt.

Jede auf Rings aufgebaute Anwendung sollte diese drei Fragen auf dem Bestätigungsbildschirm beantworten: privater Weg oder öffentliche Auszahlung, welche Felder sichtbar bleiben und wer bereits einen Viewing Key besitzt. Einen Betrag zu verbergen, ist nützlich. Genauso genau zu wissen, was sichtbar bleibt, macht die Verbergung verlässlich.