OpenZeppelin / OpenZeppelin/guardian
miden-multisig-client: drop the reconstructed WasmWebClient and use the MidenClient surface
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 10
- Forks
- 20
- Avg merge
- 2d 11h
- Merged PRs (30d)
- 43
Description
Every version number in this issue is a Miden protocol version, not a guardian one. Guardian's own release numbering is separate and currently looks similar, so read "0.17" here as Miden protocol 0.17 throughout.
This needs a @miden-sdk/miden-sdk release that tracks Miden protocol 0.17. The API it depends on lands there; none of it is on the Miden 0.16.x line and none of it can be backported.
packages/miden-multisig-client builds a second WasmWebClient over the store a caller's MidenClient already owns, because the SDK used to lack the surface it needed. That surface now exists, so the reconstruction can go.
Where it is
getRawMidenClient (src/raw-client.ts) calls WasmWebClient.createClient(endpoint, undefined, undefined, await client.storeIdentifier()) and caches it per MidenClient. Everything reached through it (multisig.ts, transaction/summary.ts, transaction/consumeNotes.ts, transaction/noteAuthentication.ts, recovery/proposalNoteImport.ts, recovery/publicNoteBackfill.ts) then talks to that second client.
Why it should go
Two live clients over one store are uncoordinated. Without an explicit storeName the owner syncs under a different Web Lock name for the same IndexedDB database, so two syncs can run at once. On Node it is worse: storeIdentifier() returns a SQLite file path that createClient treats as a store name, so the second client opens a different database. (This was filed upstream as 0xMiden/web-sdk#169; the original "two clients do not share in-memory state" explanation there was wrong and has been corrected.)
The mapping, once the Miden protocol 0.17 SDK release (carrying 0xMiden/web-sdk#170) is out
| raw call | MidenClient |
|---|---|
getAccount / newAccount(acc, true) |
accounts.get / accounts.insert({ account, overwrite: true }) |
getInputNote(s) / getOutputNote |
notes.get / notes.list / notes.listSent |
importNoteFile / exportNoteFile |
notes.import / notes.export |
syncState |
sync |
chainAnchorForRequest + executeForSummaryAt |
transactions.captureAnchor + transactions.preview({ operation: "custom", anchor }) |
createCodeBuilder().linkModule() |
compile.component({ libraries }) |
getConsumableNotes + the local consumable-now filter |
notes.listAvailable |
preview with an anchor forwards straight to executeForSummaryAt, so the summary path is unchanged.
Note on consumability
The SDK now treats a block-locked note as not consumable, and exports isConsumableNow(record, accountIdHex?) for code that still reads the low-level client. multisig.ts's own consumable-now filter can use it instead of re-deriving the rule.
Blocks
Blocked by: a @miden-sdk/miden-sdk release on the Miden protocol 0.17 line (again: Miden's 0.17, not guardian's). Blocking: 0xMiden/web-sdk#387, a guard against opening a store that already has a live client, cannot land while any consumer still does this.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in packages/miden-multisig-client/src/raw-client.ts and trace getRawMidenClient into multisig.ts, transaction/summary.ts, transaction/consumeNotes.ts, transaction/noteAuthentication.ts, recovery/proposalNoteImport.ts, and recovery/publicNoteBackfill.ts. Confirm the Miden protocol 0.17 SDK release is available, then compare each raw call with the mapping in this issue. Done means the reconstructed WasmWebClient and its cache are removed, the listed paths use MidenClient, and the local consumability check uses the SDK helper.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- backend-api-design
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 45/100