A WASM wallet brings Z00Z wallet concepts into the browser environment. That is useful for accessibility and integration, but it changes the trust boundary. Browser storage, script loading, service workers, extension interference, timing behavior, device recovery, user prompts, and network publication all affect safety. A builder should treat a browser wallet as a constrained wallet environment, not as a transparent copy of a native wallet.
The current website repository does not ship a WASM wallet implementation. It ships a Next.js documentation site, content loaders, configuration, and local verification scripts. This page describes target architecture constraints for a future browser wallet and marks unsupported claims explicitly. If a future implementation adds WASM modules, key-management code, or wallet tests, this page should be updated to cite those concrete files.
Browser Trust Boundary
The browser wallet boundary includes code delivery and execution context. A native wallet can control its process and storage model more tightly. A browser wallet depends on the browser, origin security, content security policy, dependency integrity, user device posture, and update process. That does not make a browser wallet impossible, but it does require narrower claims.
Local Possession in a Web Environment
The Main Whitepaper’s wallet-local possession idea means the wallet holds private context needed to interpret commitments and authorize user actions. In a browser, local possession must be designed around weaker and more variable storage primitives. IndexedDB, local storage, Cache Storage, OPFS, encrypted files, extension storage, and platform credential APIs all have different tradeoffs. A future implementation should document which storage it uses and what threat model that choice assumes.
Private wallet context should not be treated as ordinary app state. It should not be logged, serialized into analytics, embedded in URL parameters, stored in plain Redux-like debug state, or exposed through generic support exports. If the wallet needs to keep private policy text, receiver material, recovery metadata, or selective disclosure hints, those records should be encrypted or otherwise protected according to the eventual wallet threat model.
The website docs pipeline can render wallet documentation, but it cannot prove browser storage safety. That proof requires wallet-specific implementation tests and security review.
Key Safety
Key safety starts with minimizing key exposure. A future WASM wallet should avoid exporting raw private keys into JavaScript when a safer boundary is available. If JavaScript must orchestrate signing, the interface should be narrow and typed. Memory handling, zeroization behavior, deterministic serialization, random number generation, and domain separation all need protocol-level review.
User prompts are part of key safety. The browser wallet should explain what is being authorized: publish a package, create a payment request, reveal a fact, recover a wallet, rotate a suite, export backup material, or connect to a service. Prompts should be specific enough that a user can detect an unexpected action. “Continue” is not enough for disclosure or spend-like operations.
The Post-Quantum Migration paper is relevant because wallets may need to understand suite generation, receiver material, recovery paths, rewrap state, and migration metrics. A browser wallet should not silently restore deprecated lanes or hide migration risk behind a generic recovery button. It should show which cryptographic suite or migration state applies when that becomes part of the implementation.
Offline and Service Worker Behavior
Browser wallets often promise offline support. Builders should define what “offline” means. A wallet may prepare a package offline, view local history offline, or queue a publication request offline. It cannot obtain new network state, verify fresh data availability, or claim settlement finality while offline unless the necessary evidence was already present and valid.
Service workers and caches can improve resilience but also add stale-state risk. A wallet UI served from cache may display old maturity labels. A queued publication may retry after network return. A recovery flow may use cached scripts. Each behavior needs clear state labels and user prompts. Offline capability should never be described as a guarantee that settlement has occurred.
Network Publication and Timing Leakage
Publishing from a browser leaks timing and network metadata unless mitigated. The Privacy Threat Model warns about telemetry, timing, and user-behavior signals. A browser wallet should avoid unnecessary beaconing, stable cross-context identifiers, raw wallet IDs, and verbose analytics. If a publication service is used, the wallet should separate service receipt from settlement maturity.
Timing leakage also affects receiver flows. If a browser wallet checks a payment request, fetches receiver material, or polls status in a distinctive pattern, observers may infer user interest. Future implementations should test polling, retry, notification, and support flows under privacy scenarios.
Recovery
Recovery is a high-risk browser-wallet feature. The wallet may need encrypted backup, mnemonic or secret material, device transfer, cloud storage, local file export, social recovery, or post-quantum rewrap information. Each option has a different failure mode. Documentation should identify what the repository actually implements before giving recovery instructions.
This page does not provide recovery steps because no WASM wallet implementation exists here. Future recovery docs should specify supported browsers, storage locations, encryption assumptions, backup format, migration behavior, unsupported paths, and tests. They should also state what happens when a user restores old material after a suite migration.
Unsupported Claims
Until implementation evidence exists, do not claim that this repo provides:
- A production browser wallet.
- A WASM signing module.
- Secure browser key isolation.
- Offline settlement.
- Wallet recovery tooling.
- Post-quantum wallet migration.
- Live publication from the browser.
- Browser privacy guarantees beyond the docs site’s general web behavior.
The docs may explain the target design, but maturity language must remain explicit.
Implementation Review Questions
When a future WASM wallet appears, reviewers should start with delivery and key boundaries. How is the WASM loaded? Which origin is trusted? Which dependencies can affect signing or disclosure? Where are private payloads stored? What happens if browser storage is cleared, partially restored, or synced by the browser vendor? Which actions require an explicit prompt? Which prompts show the exact object, amount, right, voucher, disclosure, or network context?
Reviewers should also check whether offline behavior is overstated. Preparing a package offline is different from verifying current settlement state. Viewing cached wallet history is different from proving current root membership. Retrying a publication after reconnect is different from obtaining finality. The UI should preserve those distinctions even when it tries to be friendly.
Test Requirements
Future browser-wallet tests should cover storage loss, stale cache, wrong origin, unsupported browser, declined prompts, duplicate publication, timing polling, disclosure redaction, recovery from old material, and cryptographic suite migration. Tests should use real wallet primitives after they exist. Until then, docs examples should remain conceptual and should not include fake commands that imply a WASM module is present.
Documentation Maintenance
Browser capability changes quickly. A future WASM wallet page should record supported browsers, tested storage backends, known unsupported environments, and feature flags. It should also identify which claims depend on browser security behavior and which depend on Z00Z protocol behavior. If the browser environment changes, the docs should be reviewed even when protocol code has not changed.
The safest public wording is specific. Say “the target wallet should prompt before selective disclosure” until prompt code and tests exist. Say “the implementation stores encrypted payloads in X” only after the implementation does so and tests cover recovery and failure behavior. Specific evidence should always replace broad assurance.
Read Next
- Wallet for conceptual wallet roles.
- Runtime Services for publication, support, and disclosure service boundaries.
- Verification And Tests for what tests a future browser wallet must add.
Evidence and Further Reading
Use the source bullets below as an audit checklist, not decoration: when reusing this page, preserve the named section scope, the responsible actor, and the split between live repository evidence, target architecture, and open design work.
- Main Whitepaper sections 3 and 5 for canonical object vocabulary and wallet-local possession framing.
- Privacy Threat Model And Metrics sections 7 and 10 for wallet UX, telemetry, timing, and privacy validation expectations.
- Post-Quantum Migration Whitepaper section 11 for wallet suite generation, receiver material, recovery, and migration metrics.
src/lib/content/andscripts/verify.shfor current repository surfaces that are not wallet implementation code.