Adding a data point to the mainnet proving thread (#121, #124, #135, #147, #158) rather than a sixth "me too", because the documented workaround does not cover one class of design and it is cheap to say why.
The Wallet API route cannot express compute_and_invoke
docs/MAINNET-DAY-0.md offers the Wallet API as the route that needs no proving service URL of your own. For shielding and note-to-note transfers that holds. It does not hold for a dapp whose private transaction hands off to its own Cairo contract, because the action type that does the handoff is not in the wallet API:
LOCAL SHIM — remove when @starknet-io/starknet-types ships it. The compute-and-invoke sibling of STRK20_INVOKE_ACTION ... Modeled here so Strk20Action can express core's computeAndInvoke uniformly; a real strk20 wallet gains it upstream.
— client/src/interfaces.ts:14-26
So ComputeAndInvoke is expressible only on the SDK route, which is the route that needs the URL. A wallet that implements every published STRK20 method today still could not submit this transaction. That is separate from the wallet-support gap PugarHuda reported in #121 — it would remain true after that gap closes.
Concretely, the transaction is UseNote → CreateEncNote → ComputeAndInvoke(our contract): no deposit, no open notes, no value leaving the pool, so no screening subject. It only needs a proof.
The question
- Is there a mainnet proving service URL for the sprint, or is there deliberately none? A "no" is genuinely useful — it is a design input, and right now teams are holding on an unanswered maybe.
- If the answer is self-host, is the published
transaction-prover:PRIVACY-0.14.3-RC.2 image the intended path for the sprint? The compatibility matrix pairs it with Pathfinder at PATHFINDER_STORAGE_STATE_TRIES=10000, which reads as a full node rather than a public RPC endpoint. Confirming that one way or the other decides whether self-hosting is a day of work or a week of it, and nobody can answer it from outside.
Happy to self-host if that is the intent — the ask is only to know which of the two it is before spending the days.
Adding a data point to the mainnet proving thread (#121, #124, #135, #147, #158) rather than a sixth "me too", because the documented workaround does not cover one class of design and it is cheap to say why.
The Wallet API route cannot express
compute_and_invokedocs/MAINNET-DAY-0.mdoffers the Wallet API as the route that needs no proving service URL of your own. For shielding and note-to-note transfers that holds. It does not hold for a dapp whose private transaction hands off to its own Cairo contract, because the action type that does the handoff is not in the wallet API:So
ComputeAndInvokeis expressible only on the SDK route, which is the route that needs the URL. A wallet that implements every published STRK20 method today still could not submit this transaction. That is separate from the wallet-support gap PugarHuda reported in #121 — it would remain true after that gap closes.Concretely, the transaction is
UseNote→CreateEncNote→ComputeAndInvoke(our contract): no deposit, no open notes, no value leaving the pool, so no screening subject. It only needs a proof.The question
transaction-prover:PRIVACY-0.14.3-RC.2image the intended path for the sprint? The compatibility matrix pairs it with Pathfinder atPATHFINDER_STORAGE_STATE_TRIES=10000, which reads as a full node rather than a public RPC endpoint. Confirming that one way or the other decides whether self-hosting is a day of work or a week of it, and nobody can answer it from outside.Happy to self-host if that is the intent — the ask is only to know which of the two it is before spending the days.