> ## Documentation Index > Fetch the complete documentation index at: https://www.helius.dev/docs/llms.txt > Use this file to discover all available pages before exploring further. # Private Wallet > Fügen Sie einer vorhandenen Solana-Wallet Unterstützung für die erlaubnisfreie vertrauliche Ring hinzu. Erstellen Sie private Wallets, empfangen und senden Sie private Transaktionen. Ein privates Wallet besteht aus einem Solana-Schlüsselpaar zum Signieren, einem Nullifier-Schlüssel und einem Anzeigeschlüssel zur Verschlüsselung – zusammen bilden diese Schlüssel das geschützte Schlüsselpaar. Ihr Schlüsselmanagement hält das geschützte Schlüsselpaar. Der Wallet-Code verwendet die Privacy Interface und SDK, um private Transaktionen zu erstellen. Schlüsselmanagement und das Privacy SDK verbinden sich über die Privacy Interface. Das Privacy SDK ruft die Privacy API auf. Die Privacy API übermittelt die Transaktion an Solana. Die Integration ermöglicht Ihren Nutzern Folgendes: 1. Erstellen Sie ein selbstverwaltetes privates Wallet 2. Empfangen Sie private Überweisungen mit einer Solana-Adresse 3. Hinterlegen Sie Token in einem privaten Guthaben 4. Senden Sie privat an eine Solana-Adresse 5. Abheben an jede Solana-Adresse 6. Entschlüsseln Sie private Guthaben und Transaktionshistorie lokal Die Integration umfasst: 1. [**Geschütztes Schlüsselpaar**](#integrieren-sie-das-geschützte-schlüsselpaar) – in Ihrem Schlüsselmanagement zur Verschlüsselung 2. [**Privacy Interface und SDK**](#integrieren-sie-die-privacy-interface-und-sdk) – um private Transaktionen zu erstellen 3. [**Benutzerabläufe**](#integrieren-sie-benutzerabläufe) – zur Integration in Ihr Wallet ## Kontext für Ihr KI {`--- description: Add a Private Wallet to an existing Solana wallet allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__helius-docs --- ## Add a Private Wallet to an existing Solana wallet Voice: - Point. Then a short, self-contained explanation in a real sentence. - No fill words. Current Page: https://www.helius.dev/docs/privacy/integration/wallet.md Implement in this sequence. Do not skip or rearrange: 1. Shielded keypair derivation 2. Privacy Interface in key management 3. User flows. Context: - Docs index: https://www.helius.dev/docs/privacy.md - Spec: https://github.com/helius-labs/zolana/blob/main/docs/spec.md - MCP: https://www.helius.dev/docs/privacy/ai-tools.md - Packages: @heliuslabs/zolana, @solana/kit · zolana-client, zolana-interface, zolana-keypair, zolana-transaction - Examples: https://github.com/helius-labs/zolana-examples/tree/main/typescript-client · https://github.com/helius-labs/zolana-examples/tree/main/rust-client Key APIs: ShieldedKeypairLike, ViewingKeyLike, ShieldedKeypairTrait, ViewingKeyTrait, createZolanaClient. Flow APIs: the pages linked from the docs index. ### 1. Index project - Grep \`ShieldedKeypairLike|ViewingKeyLike|createZolanaClient|@heliuslabs/zolana|zolana-keypair|TSPP/derive\` across src/ - Glob \`**/*.{ts,tsx,js,rs}\` · read package.json / Cargo.toml - Identify: existing Solana key management, seed vs hardware/MPC, account index, send path, balance/history UI - Task subagent if multiple packages ### 2. Read references - WebFetch the current page — both interface languages, both derivation tabs - WebFetch the docs index — follow the pages for the sequence above. Add on-/off-ramp only if selected in step 3 - WebFetch the spec when protocol behavior is ambiguous (registry, spends, encryption) - TaskCreate one todo per phase below ### 3. Clarify intention - AskUserQuestion: Are you using TypeScript or Rust? - AskUserQuestion: Are you a seed-based wallet, creating tests, or a non-seed-based wallet? - Seed-based wallet → derive from the seed phrase - Tests → derive from a fixed message - Non-seed-based wallet → derive from a fixed message - AskUserQuestion: Do you want on-/off-ramp? - AskUserQuestion: Localnet or devnet? - Summarize. Wait for confirmation before planning ### 4. Create plan - Do not edit unrelated files. Do not add dead code. - Take existing code byte for byte. Do not invent APIs, files, or helpers that are not on the fetched pages or in the repo. - Every claimed path, symbol, and line number comes from step 1 or 2. If it was not read, do not write it. - ASCII tree of files to add or change. One line per file: path, then what that file does. - Follow the sequence. If unclear, AskUserQuestion. Present the plan. Wait for approval. ### 5. Implement - TS: Bash \`pnpm add @heliuslabs/zolana @solana/kit\` if missing - Rust: add the crates from the SDK page linked from the docs index - Follow the approved plan. Write/Edit. Do not replace the Solana keypair - TaskUpdate each step ### 6. Verify - Every interface method for the chosen language is implemented - No secrets in logs or network payloads - TS: Bash \`tsc --noEmit\` + existing tests - Rust: Bash \`cargo check\` + \`cargo test\` if tests exist - TaskUpdate complete ### Tools - mcp__helius-docs for docs pages - mcp__deepwiki__ask_question("helius-labs/zolana", "") - WebFetch \`https://www.helius.dev/docs/.md\` - Task subagent for parallel Grep/Read/WebFetch - TaskList for remaining work Invariants: - Wallet holds the shielded keypair. Never send key material to the Privacy API. - Implement every method on the chosen language's interface. Do not copy Rust-only methods (\`sign_hash\`, \`nullifier_key\`) onto TypeScript. - Viewing-key operations are local and synchronous. A sign-only custodian is invalid. - Use only APIs from the current page, the docs index, and the flow pages in the sequence. If an API is not there, stop and AskUserQuestion. - Do not log mnemonic, nullifier, viewing key, or the \`TSPP/derive/v1\` signature. - Language is TypeScript or Rust, not both. - Assets are SOL, SPL, and Token-2022. - Every Solana public key of the user can add a Private Wallet. One Solana address maps to one Shielded Address. - When the recipient of a private transfer does not have a Private Wallet, the Privacy API can resolve the transfer to a private-to-public withdrawal. We recommend requesting a separate user signature in the UI to ensure the user does not withdraw to a public balance by accident.`} ```text theme={"system"} description: Add a Private Wallet to an existing Solana wallet allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__helius-docs --- ## Add a Private Wallet to an existing Solana wallet Voice: - Point. Then a short, self-contained explanation in a real sentence. - No fill words. Current Page: https://www.helius.dev/docs/privacy/integration/wallet.md Implement in this sequence. Do not skip or rearrange: 1. Shielded keypair derivation 2. Privacy Interface in key management 3. User flows. Context: - Docs index: https://www.helius.dev/docs/privacy.md - Spec: https://github.com/helius-labs/zolana/blob/main/docs/spec.md - MCP: https://www.helius.dev/docs/privacy/ai-tools.md - Packages: @heliuslabs/zolana, @solana/kit · zolana-client, zolana-interface, zolana-keypair, zolana-transaction - Examples: https://github.com/helius-labs/zolana-examples/tree/main/typescript-client · https://github.com/helius-labs/zolana-examples/tree/main/rust-client Key APIs: ShieldedKeypairLike, ViewingKeyLike, ShieldedKeypairTrait, ViewingKeyTrait, createZolanaClient. Flow APIs: the pages linked from the docs index. ### 1. Index project - Grep \`ShieldedKeypairLike|ViewingKeyLike|createZolanaClient|@heliuslabs/zolana|zolana-keypair|TSPP/derive\` across src/ - Glob \`**/*.{ts,tsx,js,rs}\` · read package.json / Cargo.toml - Identify: existing Solana key management, seed vs hardware/MPC, account index, send path, balance/history UI - Task subagent if multiple packages ### 2. Read references - WebFetch the current page — both interface languages, both derivation tabs - WebFetch the docs index — follow the pages for the sequence above. Add on-/off-ramp only if selected in step 3 - WebFetch the spec when protocol behavior is ambiguous (registry, spends, encryption) - TaskCreate one todo per phase below ### 3. Clarify intention - AskUserQuestion: Are you using TypeScript or Rust? - AskUserQuestion: Are you a seed-based wallet, creating tests, or a non-seed-based wallet? - Seed-based wallet → derive from the seed phrase - Tests → derive from a fixed message - Non-seed-based wallet → derive from a fixed message - AskUserQuestion: Do you want on-/off-ramp? - AskUserQuestion: Localnet or devnet? - Summarize. Wait for confirmation before planning ### 4. Create plan - Do not edit unrelated files. Do not add dead code. - Take existing code byte for byte. Do not invent APIs, files, or helpers that are not on the fetched pages or in the repo. - Every claimed path, symbol, and line number comes from step 1 or 2. If it was not read, do not write it. - ASCII tree of files to add or change. One line per file: path, then what that file does. - Follow the sequence. If unclear, AskUserQuestion. Present the plan. Wait for approval. ### 5. Implement - TS: Bash \`pnpm add @heliuslabs/zolana @solana/kit\` if missing - Rust: add the crates from the SDK page linked from the docs index - Follow the approved plan. Write/Edit. Do not replace the Solana keypair - TaskUpdate each step ### 6. Verify - Every interface method for the chosen language is implemented - No secrets in logs or network payloads - TS: Bash \`tsc --noEmit\` + existing tests - Rust: Bash \`cargo check\` + \`cargo test\` if tests exist - TaskUpdate complete ### Tools - mcp__helius-docs for docs pages - mcp__deepwiki__ask_question("helius-labs/zolana", "") - WebFetch \`https://www.helius.dev/docs/.md\` - Task subagent for parallel Grep/Read/WebFetch - TaskList for remaining work Invariants: - Wallet holds the shielded keypair. Never send key material to the Privacy API. - Implement every method on the chosen language's interface. Do not copy Rust-only methods (\`sign_hash\`, \`nullifier_key\`) onto TypeScript. - Viewing-key operations are local and synchronous. A sign-only custodian is invalid. - Use only APIs from the current page, the docs index, and the flow pages in the sequence. If an API is not there, stop and AskUserQuestion. - Do not log mnemonic, nullifier, viewing key, or the \`TSPP/derive/v1\` signature. - Language is TypeScript or Rust, not both. - Assets are SOL, SPL, and Token-2022. - Every Solana public key of the user can add a Private Wallet. One Solana address maps to one Shielded Address. - When the recipient of a private transfer does not have a Private Wallet, the Privacy API can resolve the transfer to a private-to-public withdrawal. We recommend requesting a separate user signature in the UI to ensure the user does not withdraw to a public balance by accident. ``` ## Integrieren Sie das geschützte Schlüsselpaar Eine Integration privater Wallets fügt Ihrem Schlüsselmanagement ein geschütztes Schlüsselpaar hinzu. Ein geschütztes Schlüsselpaar signiert, verschlüsselt und entschlüsselt Transaktionen. Das geschützte Schlüsselpaar ist ein Bündel aus den Signatur-, Nullifier- und Anzeigeschlüsseln. * **Signaturschlüssel:** Das Ed25519 Solana-Schlüsselpaar der Wallet zum Signieren von Transaktionen. * **Anzeigeschlüssel:** Ein P-256 Schlüsselpaar, das zum Verschlüsseln und Entschlüsseln von Transaktionen verwendet wird. * **Nullifier-Schlüssel:** Ein Schlüssel, der verwendet wird, um Nullifier abzuleiten. Eine Wallet kann das geschützte Schlüsselpaar auf zwei Arten erstellen: 1. Für seed-basierte Wallets wählen Sie **Ableiten aus Seed-Phrase**. 2. Für nicht seed-basierte Wallets wählen Sie **Ableiten aus EdDSA-Signatur**. Eine Seed-basierte Wallet leitet das geschützte Schlüsselpaar aus einem BIP-39 Mnemonic und einem Kontoindex ab (`0`, `1`, …). Jeder Kontoindex ordnet ein Solana-Schlüsselpaar einem geschützten Schlüsselpaar zu. Sie können das geschützte Schlüsselpaar auf die gleiche Weise wiederherstellen, wie Sie das Solana-Schlüsselpaar wiederherstellen. Zum Beispiel: * Konto 0: Solana-Schlüsselpaar 0 und geschütztes Schlüsselpaar 0 * Konto 1: Solana-Schlüsselpaar 1 und geschütztes Schlüsselpaar 1 | Schlüssel | Ableitungsweg | Schema | | --------- | ---------------------------------- | ------------------------- | | Signieren | `m/44'/501'/account'/0'` | SLIP-0010 Ed25519 | | Nullifier | `m/44'/1392955331'/account'/1'/0'` | SLIP-0010 Ed25519\[1..32] | | Anzeigen | `m/44'/1392955331'/account'/2'/0'` | SLIP-0010 NIST P-256 | Der geschützte Signaturschlüssel ist das Solana Ed25519-Schlüssel des Kontos. Die Nullifier- und Anzeigeschlüssel sind zusätzliche Schlüssel, die aus demselben Seed abgeleitet werden. Beispielimplementierung: [TypeScript-Beispiel](https://github.com/helius-labs/zolana/blob/cad0664e374f6a0e5c532169c5895203e366eb56/sdk-libs/ts/test/seed-based-keypair.test.ts#L60) · [Rust-Beispiel](https://github.com/helius-labs/zolana/blob/cad0664e374f6a0e5c532169c5895203e366eb56/sdk-libs/keypair/tests/seed_based_keypair.rs#L111) Ableiten des geschützten Schlüsselpaares aus einer EdDSA-Signatur über eine feste Nachricht. EdDSA-Signaturen sind deterministisch, daher erzeugt die Signatur desselben Solana-Schlüsselpaares für dieselbe Nachricht immer dasselbe geschützte Schlüsselpaar. Wir verwenden die Signatur als Seed, um ein geschütztes Schlüsselpaar abzuleiten. Die feste Nachrichten-Nutzlast ist `"TSPP/derive/v1"`, kodiert als Solana Off-Chain-Nachricht v0. Der geschützte Signaturschlüssel ist der Solana EdDSA-Schlüssel des Wallets. Die Nullifier- und Anzeigeschlüssel sind zusätzliche Schlüssel, die aus der Signatur abgeleitet werden. Die Signatur ist der Ableitungs-Seed. Wer sie besitzt, kann die Nullifier- und Anzeigeschlüssel ableiten und Benutzertransaktionen entschlüsseln. Lehnen Sie jede Signaturanfrage für die Nachricht `"TSPP/derive/v1"` von Dritten ab. Pseudocode, um ein geschütztes Schlüsselpaar aus einer Solana-Signatur abzuleiten: ```jsx theme={"system"} function deriveShieldedKeypair(solanaKeypair): solanaPubkey = solanaKeypair.publicKeyBytes() // 32 bytes payload = UTF8("TSPP/derive/v1") // Solana off-chain message v0 envelope derivationMessage = bytes("\xffsolana offchain") // 16 bytes || u8(0) // version || SHA256(payload) // application domain || u8(0) // restricted ASCII format || u8(1) // one signer || solanaPubkey || u16LE(length(payload)) || payload // Ed25519 signatures are deterministic, so the same wallet produces // the same 64-byte seed every time. derivationSeed = ED25519_SIGN( solanaKeypair.secretKey, derivationMessage ) // HKDF-Extract with no salt prk = HKDF_SHA256_EXTRACT( salt = empty, ikm = derivationSeed ) nullifierSecret = HKDF_SHA256_EXPAND( prk, info = UTF8("TSPP/nf_key/ed25519/v1"), length = 31 ) viewingKeyMaterial = HKDF_SHA256_EXPAND( prk, info = UTF8("TSPP/view_key/ed25519/v1"), length = 48 ) // RFC hash-to-field reduction into a non-zero P-256 scalar viewingSecret = P256_SCALAR_FROM_OKM(viewingKeyMaterial) return ShieldedKeypair { signingKey: solanaKeypair, nullifierKey: NullifierKey(nullifierSecret), viewingKey: P256Keypair(viewingSecret) } ``` Beispielimplementierung: [TypeScript](https://github.com/helius-labs/zolana/blob/cad0664e374f6a0e5c532169c5895203e366eb56/sdk-libs/ts/src/keypair/shielded.ts#L201) · [Rust](https://github.com/helius-labs/zolana/blob/cad0664e374f6a0e5c532169c5895203e366eb56/sdk-libs/keypair/src/shielded.rs#L126) ## Integrieren Sie die Privacy Interface und SDK Die Privacy Interface ermöglicht es Ihrem Code, das Privacy SDK zu verwenden, um private Transaktionen zu erstellen, ohne direkt auf das Schlüsselmater zuzugreifen. Ihr Schlüsselmanagement implementiert die Privacy Interface in zwei Teilen. 1. Signing Interface zum Erstellen von Transaktionen mit dem Privacy SDK. Quellansicht: [TypeScript](https://github.com/helius-labs/zolana/blob/236e6cd6cee4d07e567b316210e018f31dfa4d90/sdk-libs/ts/src/keypair/shielded.ts#L132)/ [Rust](https://github.com/helius-labs/zolana/blob/236e6cd6cee4d07e567b316210e018f31dfa4d90/sdk-libs/keypair/src/traits/shielded_keypair.rs) 2. Verschlüsselungs- & Entschlüsselungsinterface. Quellansicht: [TypeScript](https://github.com/helius-labs/zolana/blob/236e6cd6cee4d07e567b316210e018f31dfa4d90/sdk-libs/ts/src/keypair/shielded.ts#L154)/ [Rust](https://github.com/helius-labs/zolana/blob/236e6cd6cee4d07e567b316210e018f31dfa4d90/sdk-libs/keypair/src/traits/view_key.rs) Die Privacy Interface ist zustandslos und speichert daher keine Guthaben oder Transaktionshistorie. Zur Leistungssteigerung empfehlen wir, Benutzerkonten und Transaktionshistorie lokal zwischenspeichern. ### Zur Beweiserzeugung Die Erzeugung von Zero-Knowledge-Beweisen erfordert Klartext-Eingaben der vollständigen Benutzertransaktionsdaten und Nullifierschlüssel. Derzeit ist die serverseitige Beweiserzeugung über die Standard-Helius-RPC-URL verfügbar. Lokale Beweiserzeugung kommt bald. Ende-zu-Ende-verschlüsselte Server-Beweiserzeugung auf AWS Nitro ist vor dem Start des Mainnets geplant. ## Integrieren Sie Benutzerabläufe ### Erstellen Sie ein privates Wallet Ein privates Wallet wird in zwei Schritten erstellt: 1. Ableiten des geschützten Schlüsselpaares 2. Registrieren der Solana-Adresse im On-Chain-Register. Das Register verknüpft den öffentlichen Signaturschlüssel mit den Nullifier- und Anzeigeschlüsseln – zusammen bilden diese öffentlichen Schlüssel die geschützte Adresse. ```mermaid theme={"system"} %%{init: { 'theme': 'base', 'themeVariables': { 'lineColor': '#FF6B35', 'primaryTextColor': '#737373', 'primaryBorderColor': '#9CA3AF', 'actorBkg': '#FFFFFF', 'actorBorder': '#9CA3AF', 'actorTextColor': '#737373', 'signalColor': '#FF6B35', 'signalTextColor': '#737373', 'labelBoxBkgColor': '#FF6B351F', 'labelBoxBorderColor': '#FF6B35', 'noteBkgColor': '#F5F5F5', 'noteTextColor': '#737373', 'noteBorderColor': '#9CA3AF' } }}%% sequenceDiagram participant User participant Privacy SDK participant Solana User->>Privacy SDK: Create Private Wallet Privacy SDK->>Solana: Register Solana address ``` Jeder Registereintrag ist ein PDA, das vom [Registry-Programm](https://orbmarkets.io/address/regyS5rkAcw2YzDJCmTwCTHs2s246FXxbmuRZ42u2PD) verwaltet wird, das jeder einsehen kann, um zu überprüfen, ob eine Solana-Adresse private Überweisungen empfangen kann. ### Synchronisieren Sie privates Guthaben & Transaktionshistorie Die Guthabensynchronisierung ruft verschlüsselten Status vom RPC ab und entschlüsselt ihn im Wallet. Das RPC entschlüsselt nicht. Nur der Besitzer kann ein privates Guthaben mit einem Anzeigeschlüssel entschlüsseln. Eine Wallet sollte Guthaben entschlüsseln und aktualisieren, bevor private Transaktionen erfolgen und wann immer es Backfills ausführt: Beim Entsperren der Wallet, Öffnen der privaten Wallet, App-Wiederaufnahme, Netzwerk-Wiederverbindung, Stream-Lücken oder Wallet-Wiederherstellung. ### Einzahlung auf ein privates Guthaben Nutzer können auf zwei Arten auf ein privates Guthaben einzahlen: 1. Aufladen von einem Fiat-Guthaben zu einem privaten Kryptoguthaben 2. Einzahlung von einem öffentlichen SPL-Konto zu einem privaten Guthaben Aufladen und Einzahlung unterscheiden sich in ihrer Datenschutzgarantie. Wir empfehlen, für besseren Datenschutz das Aufladen über die Einzahlung zu verwenden. | Feld | Aufladen von Fiat | Einzahlung von SPL | | ----------- | ----------------- | ------------------ | | Asset | Privat | Öffentlich | | Betrag | Privat | Öffentlich | | Quelle | Nicht on-chain | Öffentlich | | Zieladresse | Öffentlich | Öffentlich | Auf-/Ab-Rampe Fiat direkt zu und von einem privaten Guthaben. Einzahlung von einem öffentlichen Kryptoguthaben. ### Private Überweisungen Benutzer können private Überweisungen an jede Solana-Wallet-Adresse senden. Für jede private Überweisung überprüft das Privacy SDK die Wallet-Adresse im On-Chain-Register, um festzustellen, ob der Empfänger ein privates Wallet hat. Das Privacy SDK kann eine private Überweisung zu einer Auszahlung von privat zu öffentlich auflösen, wenn der Empfänger kein privates Wallet hat. Wir empfehlen, die Transaktion in der Benutzeroberfläche als Auszahlung zu kennzeichnen, um sicherzustellen, dass der Benutzer nicht versehentlich auf ein öffentliches Guthaben auszahlt. | Feld | Sichtbarkeit | Warum | | ---------------------- | ------------ | ------------------------------------------------------------------- | | Asset | Privat | Das Asset ist on-chain verschlüsselt | | Betrag | Privat | Der übertragene Betrag ist on-chain verschlüsselt | | Quelle privates Wallet | Öffentlich | In einem vertraulichen Ring ist das Quell-Wallet on-chain sichtbar. | | Empfänger | Öffentlich | In einem vertraulichen Ring ist der Empfänger on-chain sichtbar. | Überweisen Sie privat auf ein privates Guthaben. ### Abheben auf ein öffentliches Guthaben Abhebungen können auf zwei Arten verwendet werden: 1. Als Rückfall für private Überweisungen an Empfänger, die kein privates Wallet haben, oder 2. Direkte Abhebung auf ein öffentliches SPL-Token-Konto. Für Abhebungen empfehlen wir, deutlich zu kennzeichnen, dass der Benutzer das private Guthaben verlässt, ähnlich wie bei einer Seed-Phrase oder dem Export eines privaten Schlüssels. | Feld | Sichtbarkeit | Warum | | ------------------------------- | ------------ | ------------------------------------------------------------------- | | Asset | Öffentlich | Das Asset ist on-chain sichtbar | | Betrag | Öffentlich | Der abgehobene Betrag ist on-chain sichtbar | | Quelle privates Wallet | Öffentlich | In einem vertraulichen Ring ist das Quell-Wallet on-chain sichtbar. | | Ziel öffentliches Wallet | Öffentlich | Die Ziel-Wallet-Adresse ist on-chain sichtbar | | Ziel öffentliches Guthaben | Öffentlich | Das resultierende öffentliche Guthaben ist on-chain sichtbar | | Verbleibendes privates Guthaben | Privat | Das verbleibende Guthaben ist on-chain verschlüsselt | Abheben auf ein öffentliches Kryptoguthaben. ## Didn't find what you were looking for? Reach out! [Telegram](https://t.me/tilo_light) | [E-Mail](mailto:sales@helius.xyz) | [Contact](https://www.helius.dev/contact)