@ducat-unit/wallet-snap 0.3.0 → 0.3.2

package/README.md

@@ -10,9 +10,9 @@ confirmation prompts.
 
 The production artifact supports exactly `mainnet` and `mutinynet`. The
 role-neutral local development artifact adds `regtest`. The Snap has no
-separate `alpha-mainnet` wallet network: its Mainnet profile currently uses the
-reviewed alpha DUCAT contract while retaining canonical Bitcoin mainnet
-address, transaction, and genesis rules.
+separate `alpha-mainnet` wallet network. Its Mainnet and Mutinynet profiles use
+the same production Mutinynet validator URL while retaining their existing Bitcoin address,
+transaction, genesis, and wallet-derivation rules.
 
 ## What are snaps?
 
@@ -43,6 +43,12 @@ MetaMask from the same Secret Recovery Phrase recovers the same managed accounts
 for this scheme. An imported key selected in Snap Home is an explicit override
 and is not derived from this scheme.
 
+The beta integration preserves all published `0.3.1` managed paths, including
+the vault's `/2/0` suffix. It does not switch existing users to the older beta
+`/0/1` vault key or migrate their vaults. Release verification checks the built
+Snap against the `0.3.1` account fixtures, including fresh recovery, on Mainnet,
+Mutinynet, and Regtest.
+
 The Snap owns one explicit deployment selection. New production installations default to
 `mutinynet`. `ducat_getNetwork()` returns that selection; `ducat_switchNetwork()`
 changes it only after a MetaMask-owned confirmation showing the requesting origin,
@@ -62,14 +68,15 @@ The production artifact allows exactly these Ducat app origins:
 
 ```
 https://app.ducatprotocol.com
-https://dev.app.ducatprotocol.com
-https://staging.app.ducatprotocol.com
+https://dev.ducatprotocol.com
+https://test.ducatprotocol.com
 ```
 
 `localhost` and preview deployments are intentionally absent from the published
 manifest. The development artifact replaces this list with exactly
-`http://localhost:3000`, `http://localhost:8075`, `http://frontend:3000`, and
-`http://ducat-admin:8075`; it does not inherit production origins. It contains
+`http://localhost:3000`, `http://localhost:8075`, `http://frontend:3000`,
+`http://ducat-admin:8075`, and `https://dev.ducatprotocol.com`; it does not
+inherit other production origins. It contains
 exactly `regtest`, `mainnet`, and `mutinynet`, defaults to `mutinynet`, and
 disables debug and unprompted signing.
 The test-only unprompted method refuses every deployment mapped to Bitcoin
@@ -81,29 +88,40 @@ while no server is running, and serves those frozen bytes only at
 `local:http://localhost:8086`. Frontend and Admin are caller workflows of this
 one local Snap; neither is an artifact-policy class. Production packaging stays
 on the isolated production policy and contains no localhost or removed wallet
-network authority. The string `alpha-mainnet` remains only as the Mainnet
-profile's expected validator response while the alpha DUCAT contract is active.
+network authority. Both production and development artifacts use the same
+shared validator URL for Mainnet and Mutinynet; Regtest stays local.
 
 From `ducat-infra`, use `make snap-down`, `make snap-install`, and
-`make snap-check` before `make snap-serve`. Starting the Alpha-configured Admin
-does not build, start, stop, or log the shared Snap. Snap install/update, key
+`make snap-check` before `make snap-serve`. Starting Admin does not build, start,
+stop, or log the shared Snap. Snap install/update, key
 import, funding, prompting, signing, and broadcast each remain separate
-operator approvals. The complete real-Bitcoin sequence and private-key
-handling rules are in
-[`../../dev/runbooks/DUCAT_ADMIN_ALPHA_MAINNET.md`](../../dev/runbooks/DUCAT_ADMIN_ALPHA_MAINNET.md).
+operator approvals. The bundled Mainnet profile requires the production
+contract identity; an Alpha-configured validator is not compatible with it.
 
 ## Network Profiles and Endpoint Overrides
 
 The Snap ships bundled network profiles in [`src/network-profiles.json`](src/network-profiles.json).
 Each profile carries a canonical Snap network, the Bitcoin network used for
 address, transaction, transport, and genesis mechanics, and the exact
-`chain_network` value expected from its validator. The Mainnet profile currently
-expects `alpha-mainnet`; that value is contract-stage evidence, not another Snap
-network. Retiring the alpha contract requires changing the profile expectation
-and validator URL, not adding or migrating a wallet network.
+`chain_network` value expected from its validator:
+
+| Snap network | Validator URL | Required `chain_network` |
+| --- | --- | --- |
+| Mainnet | `https://validator-mainnet.prod.ducatprotocol.com` | `main` |
+| Mutinynet | `https://validator-mutinynet.prod.ducatprotocol.com` | `mutiny` |
+
+`main` is Ducat Core's production chain identity; `mainnet` remains the Snap's
+wallet network name. The endpoint update does not change any `0.3.1` account
+derivation paths. A failed production request does not fall back to a dev or
+alpha validator.
+
+Each validator must report its own network identity. Mainnet rejects Mutinynet
+data, and neither profile falls back to the other network when unavailable.
 
 Users can set validator and Esplora endpoint overrides from Snap Home. Overrides are
 stored in Snap state and apply to complete wallet inventory and signing verification.
+Existing explicit overrides remain selected; clear them in Settings to use
+the bundled production defaults.
 Dapps pass only
 the target network name; they do not pass arbitrary endpoint URLs into signing or
 inventory RPC calls. Remote overrides require HTTPS and are verified against the
@@ -117,6 +135,13 @@ Home screen cannot modify a different network.
 
 ## Development
 
+For the local Flask connector, run `npm run preview:flask` and open
+`http://localhost:3000` in the browser with MetaMask Flask installed. The
+connector installs or updates `local:http://localhost:8086`. After source
+changes, stop the preview server and run the command again, then reconnect
+to load the rebuilt Snap. The server holds a verified snapshot of the bundle
+and manifest, so it never serves mismatched files during a rebuild.
+
 ```bash
 npm ci
 npm run build        # mm-snap build -> dist/bundle.js
@@ -142,6 +167,27 @@ npm run verify:harness   # MetaMask simulation harness (accounts, signing, BitVM
 Point the frontend at the local build with `NEXT_PUBLIC_DUCAT_SNAP_ID="local:http://localhost:8080"`,
 or at the published package with `NEXT_PUBLIC_DUCAT_SNAP_ID="npm:@ducat-unit/wallet-snap"`.
 
+## Home and confirmation screens
+
+Snap Home displays BTC, UNIT, and the permitted MetaMask ETH account, with
+Bitcoin, UNIT, ETH, wUNIT, and USDC balances. The Ethereum provider permission
+is used for account discovery only; opening Home can request missing account
+access, while navigation reads existing access without prompting again.
+Ethereum balances use Ethereum mainnet or Sepolia according to the selected
+Snap network. wUNIT is configured for Sepolia; its mainnet address remains
+unset until deployment. Price quotes and EVM balances are display-only and
+are not used to authorize Bitcoin signing.
+
+Settings contains the network selector, Bitcoin key override, and endpoint
+editors. Copy fields and editing controls use native Snap components.
+Vault confirmations show the action amount, destination, and verified
+before/after values. Transaction sections start collapsed; full addresses
+remain in Addresses & signing details. Raw UNIT inventory and app metadata
+sections are omitted from confirmations. Input ownership, previous-output,
+network, fee, and signing checks still run independently of these displays.
+Vault comparison metadata remains internal to the Snap; the public wallet
+inventory RPC retains its existing response shape for compatible apps.
+
 ## Security
 
 Keys, child keys, WIFs, and raw entropy never leave the snap. The manifest grants entropy access