docs(sdk): keep v1 documentation free of chain flavor in go, python and js

Author: kvinwang

sdk/go/README.md

@@ -21,11 +21,11 @@ dstack applications consist of:
 
 ### SDK Capabilities
 
-- **Key Derivation**: Deterministic key derivation for wallets, signing, encryption, and other application-specific secrets
+- **Key Derivation**: Deterministic key derivation for signing, encryption, and other application-specific secrets
 - **Remote Attestation**: Versioned attestations providing cryptographic proof of execution environment, including GPU evidence
 - **TLS Certificate Management**: Fresh certificate issuance with optional RA-TLS support for secure connections
 - **Deployment Security**: Client-side encryption of sensitive environment variables ensuring secrets are only accessible to target TEE applications
-- **Blockchain Integration**: v0-era adapters for Ethereum and Solana, see [Blockchain adapters](#blockchain-adapters)
+- **Blockchain Integration (legacy)**: v0-era adapters for Ethereum and Solana, not part of v1 — see [Blockchain adapters](#blockchain-adapters)
 
 ### Two API versions
 
@@ -54,13 +54,13 @@ What v1 changes:
 - `Attest` subsumes `GetQuote`; `Info` is flat, with no `tcb_info` blob and no `app_cert`.
 - `Sign`, `Verify` and `EmitEvent` are gone. Sign and verify locally with a standard library, using the key `GetKey` returns; `EmitEvent` is gone because runtime RTMR3 events became system-owned.
 
-> **⚠️ v1 derives different key material than v0.** `client.GetKey(ctx, "wallet", "secp256k1")`
-> and `v0.GetKey(ctx, "wallet", "", "secp256k1")` return **unrelated** keys. v1 derives
+> **⚠️ v1 derives different key material than v0.** `client.GetKey(ctx, "storage-encryption", "secp256k1")`
+> and `v0.GetKey(ctx, "storage-encryption", "", "secp256k1")` return **unrelated** keys. v1 derives
 > under its own HKDF salt and binds the algorithm and a versioned context tag alongside
 > the domain, so secp256k1 and ed25519 no longer share one 32-byte secret either. There is
 > no compatibility mode and no way to reach a v0 key through v1. An application holding
-> funds or data under a v0 key must migrate them deliberately: derive the v1 key, then
-> move the assets. See `docs/guest-api-v1.md` for the byte-level construction.
+> anything under a v0 key must migrate it deliberately: derive the v1 key, then re-key
+> whatever the old one protected. See `docs/guest-api-v1.md` for the byte-level construction.
 >
 > Code that used the unsuffixed client for v0 calls fails **loudly** on upgrade rather
 > than silently deriving different keys, because the v1 method signatures differ and
@@ -140,14 +140,14 @@ func main() {
 	fmt.Println("App Compose:", info.AppCompose)
 
 	// Derive deterministic keys for application-specific secrets
-	walletKey, err := client.GetKey(ctx, "wallet/ethereum", "secp256k1")
+	storageKey, err := client.GetKey(ctx, "storage-encryption", "secp256k1")
 	if err != nil {
 		log.Fatal(err)
 	}
 
-	fmt.Println("Derived key (32 bytes):", hex.EncodeToString(walletKey.Key)) // secp256k1 private key
-	fmt.Println("Public key:", hex.EncodeToString(walletKey.PublicKey))
-	fmt.Println("Signature chain links:", len(walletKey.SignatureChain)) // Authenticity proof
+	fmt.Println("Derived key (32 bytes):", hex.EncodeToString(storageKey.Key)) // secp256k1 private key
+	fmt.Println("Public key:", hex.EncodeToString(storageKey.PublicKey))
+	fmt.Println("Signature chain links:", len(storageKey.SignatureChain)) // Authenticity proof
 
 	// Generate a remote attestation, bound to your own data
 	applicationData := map[string]interface{}{
@@ -256,7 +256,7 @@ envVars := []dstack.EnvVar{
 	{Key: "DATABASE_URL", Value: "postgresql://user:pass@host:5432/db"},
 	{Key: "API_SECRET_KEY", Value: "your-secret-key"},
 	{Key: "JWT_PRIVATE_KEY", Value: "-----BEGIN PRIVATE KEY-----\n..."},
-	{Key: "WALLET_MNEMONIC", Value: "abandon abandon abandon..."},
+	{Key: "BACKUP_SIGNING_SEED", Value: "hex-encoded seed..."},
 }
 
 // 2. Obtain encryption public key from KMS API (dstack-vmm or Phala Cloud).
@@ -320,16 +320,16 @@ The SDK implements secure key derivation using:
 
 ```go
 // Each domain generates a unique, deterministic key
-wallet1, _ := client.GetKey(ctx, "app1/wallet", "secp256k1")
-wallet2, _ := client.GetKey(ctx, "app2/wallet", "secp256k1")
-// wallet1.Key != wallet2.Key (guaranteed different)
+storageKey, _ := client.GetKey(ctx, "storage-encryption", "secp256k1")
+authKey, _ := client.GetKey(ctx, "api-auth", "secp256k1")
+// storageKey.Key != authKey.Key (guaranteed different)
 
-sameWallet, _ := client.GetKey(ctx, "app1/wallet", "secp256k1")
-// wallet1.Key == sameWallet.Key (guaranteed identical)
+sameStorageKey, _ := client.GetKey(ctx, "storage-encryption", "secp256k1")
+// storageKey.Key == sameStorageKey.Key (guaranteed identical)
 
 // The algorithm is bound into the derivation, so the two curves never share a
 // secret — this is a second, unrelated key, not a reinterpretation of the first.
-solWallet, _ := client.GetKey(ctx, "app1/wallet", "ed25519")
+storageKeyEd25519, _ := client.GetKey(ctx, "storage-encryption", "ed25519")
 ```
 
 Derivation is **flat**: `a/b` is not a child of `a`. The `/` is a naming convention, nothing more, and two domains that share a prefix yield unrelated keys.
@@ -473,14 +473,13 @@ Derives an application key from `(domain, algorithm)`.
 secp256k1, 32 raw bytes for ed25519), and a two-element `SignatureChain`.
 
 ```go
-key, err := client.GetKey(ctx, "wallet/ethereum", "secp256k1")
+key, err := client.GetKey(ctx, "backup-signing", "secp256k1")
 ```
 
 **Use Cases:**
 - Stable service identity keys
 - Application signing keys
 - Encryption key seeds
-- Cryptocurrency wallets and transaction signing
 - Any scenario requiring consistent, reproducible keys
 
 #### `Attest(ctx context.Context, reportData []byte, includeBoottimeGpuEvidence bool) (*AttestV1Response, error)`

sdk/js/README.md

@@ -8,7 +8,7 @@ JavaScript / TypeScript client for the dstack guest agent. Derive deterministic
 npm install @phala/dstack-sdk
 ```
 
-`@noble/hashes` and `@noble/curves` ship as regular dependencies — the core needs them for hashing and for verifying the KMS env-encryption key. Install the matching peer when you import a blockchain submodule:
+`@noble/hashes` and `@noble/curves` ship as regular dependencies — the core needs them for hashing and for verifying the KMS env-encryption key. Install the matching peer when you import one of the v0-era chain submodules:
 
 | Import path | Extra peer dependency |
 | --- | --- |
@@ -26,7 +26,7 @@ import { DstackClient } from '@phala/dstack-sdk'
 
 const client = new DstackClient()
 
-const key = await client.getKey('wallet/eth', 'secp256k1')
+const key = await client.getKey('storage-encryption', 'secp256k1')
 console.log(Buffer.from(key.key).toString('hex'))
 
 const { attestation } = await client.attest('app-state-snapshot')
@@ -55,7 +55,7 @@ dstack 0.6.0 splits the guest agent API into two surfaces on the same socket, se
 
 The unsuffixed `DstackClient` names v1. `DstackClientV1` is the same class under an explicit name — use whichever reads better; new code should not need `DstackClientV0` at all.
 
-> **v1 keys are not v0 keys.** `getKey` on v1 derives under its own HKDF salt and binds the algorithm and a versioned context tag into the derivation. The same name yields **different key material** on the two surfaces, and under v1 secp256k1 and ed25519 no longer share one 32-byte secret. There is no compatibility mode and no migration path back — an app that has published a v0-derived address must keep deriving it with `DstackClientV0`. `docs/guest-api-v1.md` pins the byte-level construction.
+> **v1 keys are not v0 keys.** `getKey` on v1 derives under its own HKDF salt and binds the algorithm and a versioned context tag into the derivation. The same name yields **different key material** on the two surfaces, and under v1 secp256k1 and ed25519 no longer share one 32-byte secret. There is no compatibility mode and no migration path back — an app that has published v0-derived material must keep deriving it with `DstackClientV0`. `docs/guest-api-v1.md` pins the byte-level construction.
 
 Code that used the unsuffixed client for v0 calls fails **loudly** on upgrade rather than silently deriving different keys, because the v1 method signatures differ and `getKey` requires `algorithm` explicitly. To stay on the frozen surface, switch to `DstackClientV0`.
 
@@ -87,12 +87,12 @@ The key is freshly generated on every call and is not derived from the app ident
 Derive a deterministic application key.
 
 ```typescript
-const eth = await client.getKey('wallet/ethereum', 'secp256k1')
-const sol = await client.getKey('wallet/solana', 'ed25519')
+const enc = await client.getKey('storage-encryption', 'secp256k1')
+const sig = await client.getKey('backup-signing', 'ed25519')   // unrelated key material
 
-eth.key             // Uint8Array, 32 bytes
-eth.public_key      // Uint8Array — SEC1 compressed (33) for secp256k1, raw (32) for ed25519
-eth.signature_chain // Uint8Array[], exactly 2 links
+enc.key             // Uint8Array, 32 bytes
+enc.public_key      // Uint8Array — SEC1 compressed (33) for secp256k1, raw (32) for ed25519
+enc.signature_chain // Uint8Array[], exactly 2 links
 ```
 
 Both arguments are required. `algorithm` is exactly `'secp256k1'` or `'ed25519'` — there is no default and no `k256` alias, because v0's defaulting meant a typo silently produced a key of the wrong type under a name the caller thought meant something else.

sdk/js/src/index.ts

@@ -720,7 +720,7 @@ export interface VersionResponseV1 {
  * `emitEvent` are absent by design, not by oversight; see `docs/guest-api-v1.md`.
  *
  * A v1 key is NOT the v0 key of the same name. v1 derives under its own HKDF
- * salt and binds the algorithm into the derivation, so `getKey('wallet',
+ * salt and binds the algorithm into the derivation, so `getKey('storage-encryption',
  * 'secp256k1')` here returns different material than `DstackClientV0.getKey`
  * ever did, and secp256k1 and ed25519 no longer share one secret. There is no
  * compatibility mode.

sdk/python/README.md

@@ -22,9 +22,9 @@ out for code that wants the surface visible at a glance.
 > the algorithm and its own context tag alongside the domain, which is the point of
 > the new derivation, not a defect: v0 ignored the algorithm, so one secret served
 > two curves. There is no compatibility mode and no flag that brings the old bytes
-> back. An application holding assets under a v0 key must migrate them deliberately —
-> derive the v1 key, move the asset with a transaction signed by the v0 key, and only
-> then cut over.
+> back. An application that has published or committed to material derived from a v0
+> key must migrate deliberately — derive the v1 key, re-establish whatever depends on
+> the old one under it, and only then cut over.
 >
 > Code that used the unsuffixed client for v0 calls fails **loudly** on upgrade
 > rather than silently deriving different keys, because the v1 method signatures
@@ -60,7 +60,7 @@ from dstack_sdk import DstackClient
 
 client = DstackClient()
 
-key = client.get_key('wallet/eth', 'secp256k1')   # algorithm is required
+key = client.get_key('storage-encryption', 'secp256k1')   # algorithm is required
 attestation = client.attest(b'my-app-state')
 info = client.info()
 ```
@@ -89,7 +89,7 @@ same domain always produces the same key for your app, and different apps get
 different keys for the same domain.
 
 ```python
-key = client.get_key('wallet/eth', 'secp256k1')
+key = client.get_key('storage-encryption', 'secp256k1')
 print(key.decode_key())             # 32 raw bytes
 print(key.decode_public_key())      # SEC1 compressed (33 B), or 32 B for ed25519
 print(key.decode_signature_chain()) # two links: app root, then KMS root
@@ -212,7 +212,7 @@ async def main():
     client = AsyncDstackClient()
 
     info = await client.info()
-    key = await client.get_key('wallet/eth', 'ed25519')
+    key = await client.get_key('backup-signing', 'ed25519')
 
     # Run requests concurrently
     keys = await asyncio.gather(