diff --git a/docs/builder/faq.md b/docs/builder/faq.md index 0028e47c..9cd65527 100644 --- a/docs/builder/faq.md +++ b/docs/builder/faq.md @@ -21,6 +21,8 @@ Miden's architecture separates concerns between: 3. **Proving efficiency**: Delegated provers can use optimized hardware that wouldn't be available to end-user devices, specifically designed for the mathematical operations needed in STARK proof generation. +That convenience has a privacy cost: a delegated / remote prover must receive the transaction witness (serialized transaction inputs), so it can see private account and note data that local proving would keep on the client. Choose delegated proving when you trust the prover operator; keep proving local when those inputs must stay private. + ## What is the lifecycle of a transaction? ### 1. Transaction Creation diff --git a/docs/builder/tools/clients/web-client/setup.md b/docs/builder/tools/clients/web-client/setup.md index 4f1f3364..42a7435b 100644 --- a/docs/builder/tools/clients/web-client/setup.md +++ b/docs/builder/tools/clients/web-client/setup.md @@ -118,6 +118,11 @@ See [Accounts](./accounts.md) for full examples covering wallets, contracts, and Local proving in the browser is CPU-intensive for larger transactions. Override globally via `ClientOptions.proverUrl`, or per transaction via the `prover` field: +:::caution Privacy boundary +A remote / delegated prover receives the transaction **witness** (the serialized transaction inputs), not only a digest. That payload can include account state, input notes, advice data, and other private execution context needed to build the proof. Prefer local proving (`proverUrl: "local"`) when those inputs must stay on-device; use a remote prover only when you trust that operator with the witness. +::: + + ```typescript // Globally: every transaction uses the remote prover by default const client = await MidenClient.create({ diff --git a/docs/builder/tools/clients/web-client/transactions.md b/docs/builder/tools/clients/web-client/transactions.md index bf0d0410..ad7159f5 100644 --- a/docs/builder/tools/clients/web-client/transactions.md +++ b/docs/builder/tools/clients/web-client/transactions.md @@ -316,6 +316,11 @@ await client.transactions.submit(wallet, request); Local proving is CPU-intensive. Offload globally via `ClientOptions.proverUrl`, or per-transaction via the `prover` field: +:::caution Privacy boundary +Remote proving sends witness data (serialized transaction inputs) to the prover endpoint. Treat the prover operator as trusted for those private inputs. Keep proving local when you need the witness to remain on the client. +::: + + ```typescript // Global: every transaction uses the remote prover const client = await MidenClient.create({ diff --git a/docs/builder/tools/network.md b/docs/builder/tools/network.md index 39de62f8..3808de57 100644 --- a/docs/builder/tools/network.md +++ b/docs/builder/tools/network.md @@ -38,6 +38,10 @@ The same services exist on devnet under the `devnet` subdomain — e.g., `status + +Delegated proving is a trust trade-off: the remote prover learns the transaction witness (account / note / advice inputs used to generate the proof). Use it for convenience on low-power clients; keep proving local when witness privacy matters. + + Hard-coding testnet URLs in client configs is fine for demos, but the Miden ops team moves endpoints as new nodes come online. For anything production-ish, keep your configuration loading the current URLs from [status.testnet.miden.io](https://status.testnet.miden.io/) or the client's default (which tracks the canonical testnet host).