Context
The builder docs present remote proving primarily as a way to offload CPU-intensive proof generation:
docs/builder/tools/clients/web-client/setup.mddocs/builder/tools/clients/web-client/transactions.mddocs/builder/tools/network.mddocs/builder/faq.md
That is accurate, but these pages do not currently state the trust/privacy boundary created by selecting a remote prover.
In 0xMiden/rust-sdk@next, RemoteTransactionProver is documented as sending witness data to a remote gRPC server, and the request payload is the serialized TransactionInputs:
TransactionInputs may contain the partial account, input notes, transaction arguments, advice inputs, foreign account code, and foreign storage-slot names:
This does not mean those inputs are exposed to the Miden network. It means the configured proving endpoint must receive the execution inputs needed to generate the proof. Local proving keeps that boundary on the client; delegated proving moves it to the selected prover.
Existing related work
- Wallet issue #478 and merged PR #609 already describe local proving as the more private option while keeping keys on-device. This issue is about aligning the builder-facing documentation with that distinction and documenting the code-confirmed request boundary.
- Docs issue #195 tracks endpoint references, not the privacy/trust semantics of using an endpoint.
- Node PR #969 explores TEE attestation for confidential delegated proving, but it is still open and normal remote-prover configuration should not imply an attested TEE.
Scope questions
Before drafting a docs patch, could maintainers confirm the intended framing?
- Should the docs explicitly say that a remote prover receives the serialized transaction witness/inputs required for proving, while signing keys remain on-device?
- Is it accurate to recommend local proving for the strongest client-side privacy, and to describe a remote prover as a service the user or application must trust with the proving request unless an additional confidential-compute guarantee is established?
- Would a short callout in the two web-client pages, plus a concise note in the delegated-proving FAQ, be the preferred scope? I would avoid duplicating the full explanation on the network endpoint inventory page.
If this framing is correct, I am happy to prepare a small documentation-only change. It would not change prover behavior or make claims about a particular hosted endpoint beyond what the client and protocol types establish.
Context
The builder docs present remote proving primarily as a way to offload CPU-intensive proof generation:
docs/builder/tools/clients/web-client/setup.mddocs/builder/tools/clients/web-client/transactions.mddocs/builder/tools/network.mddocs/builder/faq.mdThat is accurate, but these pages do not currently state the trust/privacy boundary created by selecting a remote prover.
In
0xMiden/rust-sdk@next,RemoteTransactionProveris documented as sending witness data to a remote gRPC server, and the request payload is the serializedTransactionInputs:crates/rust-client/src/remote_prover/tx_prover.rs#L17-L18crates/rust-client/src/remote_prover/tx_prover.rs#L90-L90crates/rust-client/src/remote_prover/tx_prover.rs#L116-L121TransactionInputsmay contain the partial account, input notes, transaction arguments, advice inputs, foreign account code, and foreign storage-slot names:crates/miden-protocol/src/transaction/inputs/mod.rs#L52-L63This does not mean those inputs are exposed to the Miden network. It means the configured proving endpoint must receive the execution inputs needed to generate the proof. Local proving keeps that boundary on the client; delegated proving moves it to the selected prover.
Existing related work
Scope questions
Before drafting a docs patch, could maintainers confirm the intended framing?
If this framing is correct, I am happy to prepare a small documentation-only change. It would not change prover behavior or make claims about a particular hosted endpoint beyond what the client and protocol types establish.