feat: switch real pool flow to the Wallet API route, unblocking mainnet - #20
Merged
Merged
Conversation
strk20.js's create/claim/cancel were built on the SDK-direct route:
the app itself calls ProvingServiceProofProvider/IndexerDiscoveryProvider
with explicit provingUrl/discoveryUrl config. StarkWare has not
published those mainnet URLs (strk20-hackathon issue #31, still
unresolved) — this was the actual mainnet blocker.
Philoxenia (github.com/SergioSSantiago/philoxenia), the only STRK20
Private Sprint project with a working mainnet demo so far, uses a
different route entirely: WalletAccountV6 (starknet.js), where the
connected wallet (Ready) does its own proving and discovery
internally. The app never touches a proving/discovery URL or a
viewing key. Not blocked on anything StarkWare hasn't shipped.
Adds:
- ui/src/wallet-account-v6.js: Ready detection (get-starknet-discovery),
wallet-API version check (>=0.10 for STRK20), connect.
- ui/src/strk20.js rewritten: shield -> {type: "deposit"}; createPlan ->
withdraw + invoke (no open note, matches CreatePlan's empty-span
return); claim/cancel -> open note + invoke with the
${openNoteIds[0]} placeholder the wallet resolves at submission time.
Verified every action shape (deposit/withdraw/transfer/invoke field
names, the OPEN literal, the ${openNoteIds[N]} placeholder pattern)
directly against @starknet-io/starknet-types-0104's shipped .d.ts,
not just against Philoxenia's example — same starknet@10.7.0 already
installed here. `vite build` and the existing ui test suite (4/4)
both pass.
Not verified: an actual live Ready wallet in a browser — no such
environment available here. This is real production integration code;
that gap should be closed with a manual test before relying on it for
the hackathon's required mainnet transactions.
Also fixes the now-stale "waiting on StarkWare's mainnet proving and
discovery endpoints" message in App.jsx's pool-mode UI. Pool-mode
buttons still aren't wired to these functions — devnet demo mode is
unaffected and remains the only interactive path in the UI for now.
3 tasks
sainathr19
added a commit
that referenced
this pull request
Aug 19, 2026
The "act on this plan" buttons only ever called the devnet demo writer; pool mode just showed a static "not wired yet" message. Wires them to strk20.js's real create/claim/cancel via the Wallet API route from #20. - strk20.js: createPlan/claim/cancel now resolve in_token/out_token internally (one cached view call per contract address) instead of requiring the caller to already know them — matches devnet-writer.js's existing viewCall convention, and lets App.jsx's demo and pool code paths share the same params shape. - App.jsx: buttons are gated on demoMode OR an actually-detected, STRK20-capable wallet (detectPrivacyCapable from #20's wallet-account-v6.js) rather than just "not demo mode" — so the button's enabled state matches what a click would actually do, never promises something that immediately fails. Verified: vite build succeeds, ui test suite still 4/4 (unaffected — touches strk20.js/App.jsx, not iceberg.js). Not verified: an actual live Ready wallet clicking these buttons end to end — still no such environment available here. This is the last piece before the required mainnet transactions can happen through the real UI; needs a human test before relying on it for those.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This unblocks mainnet.
strk20.js's create/claim/cancel were built on the SDK-direct route — the app itself callingProvingServiceProofProvider/IndexerDiscoveryProviderwith explicitprovingUrl/discoveryUrlconfig. StarkWare hasn't published those mainnet URLs (strk20-hackathon issue #31, still open with no reply as of today) — that was the actual blocker on real mainnet transactions.Checked which sprint projects have actually gotten a working mainnet demo scored (
demo+video+mainnetall true in the hub'sprojects.json) — only one: Philoxenia. It uses a completely different integration route:WalletAccountV6(starknet.js) talking to the user's Ready wallet extension, which does its own proving and discovery internally. The app never touches a proving/discovery URL or a viewing key — not blocked on anything StarkWare hasn't shipped.What changed
ui/src/wallet-account-v6.js— Ready wallet detection (@starknet-io/get-starknet-discovery), wallet-API version check (needs ≥0.10 for STRK20), connect.ui/src/strk20.js:shield→{type: "deposit", token, amount}createPlan→withdraw(to Iceberg) +invokeCreatePlan, no open note — matches CreatePlan's empty-span return exactly, same shape as Philoxenia's zero-leftover anonymizer callclaim/cancel→ open a note +invokewith the${openNoteIds[0]}placeholder, which the wallet resolves to the just-opened note's id at submission timeApp.jsx's pool-mode UI panel.Verification
Every action shape here — field names for deposit/withdraw/transfer/invoke, the
"OPEN"literal, the${openNoteIds[N]}placeholder pattern — is checked directly against@starknet-io/starknet-types-0104's shipped.d.ts(not just Philoxenia's example code), using the samestarknet@10.7.0already installed here.vite buildsucceeds, existing ui test suite still 4/4.Not verified: an actual live Ready wallet in a browser. No such environment available in this session. This is real production integration code handling real funds — please manually test shield → create → claim/cancel against a real Ready wallet before relying on it for the hackathon's required 3 mainnet transactions. Pool-mode buttons also aren't wired to these functions yet in the UI — devnet demo mode is untouched and remains the only interactive path for now; wiring real buttons is a natural follow-up.
Test plan
vite buildsucceedsnpm test(ui) — 4/4 pass, unaffected