wative-core 2.4.2 → 2.4.4

package/CHANGELOG.md

@@ -2,44 +2,36 @@
 
 All notable changes to `wative-core` are documented here. The format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/) and the project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
-## [2.4.2] — 2026-08-11
+## [2.4.4] — 2026-08-12
+
+Correctness fixes across signing, storage and the network layer.
+
+### Fixed
+- Signing twice, or signing after sending, no longer double-signs a transaction or erases its recorded on-chain outcome.
+- A Solana transaction reports the id the network knows it by, not the wallet's own signature — including after a failed broadcast.
+- Requests to a node now have a deadline, so an unresponsive endpoint no longer leaves a transaction hanging indefinitely.
+- A failed unlock leaves no open session and no stray directories behind, and a workspace root that is a symlink is refused.
+- `signTransaction(tx)` returns the type it was given. Type-only: a non-generic value assigned to it now needs the same shape.
 
-Importing a private key gets easier and does more: you no longer have to say
-which chain a key is for, more of the formats you actually hold are accepted,
-and one import now gives you an address on both chains.
+## [2.4.3] — 2026-08-11
+
+Documentation only. No API or behaviour changes from 2.4.2.
 
 ### Changed
-- **BREAKING. A PK wallet now holds two addresses instead of one.** Importing a
-  key gives you an address on the chain that key is for, plus one on the other
-  chain seeded by the same 32 secret bytes. The chain you imported for stays at
-  `addresses[0]`, so code reading that position is unaffected — but
-  `addresses.length` is now 2, and totals derived from it will differ.
+- The README now leads with what a `Record` is and where records can live, and states plainly that one imported key controls both addresses in a PK wallet.
+
+## [2.4.2] — 2026-08-11
 
-  ⚠️ **One secret controls both addresses.** There is only one key to import,
-  so both addresses come from it, and whoever learns that key holds both
-  chains. This is not how an HD account behaves: there a slot's two addresses
-  come from two derivation paths and are independent keys. Use an HD account,
-  or import a separate key per chain, if you need that separation.
+Importing a private key is easier, and one import now reaches both chains.
 
-  Wallets already stored keep the single address they were written with. Only
-  new imports are paired.
+### Changed
+- **BREAKING.** A PK wallet now holds two addresses — the chain you imported for, plus one on the other chain derived from the same secret, so one key controls both. `addresses[0]` is unchanged; `addresses.length` is now 2. Existing stored wallets keep their single address.
 
 ### Added
-- **`importPrivateKey(pk)` no longer needs a `vm`.** The accepted formats do not
-  overlap — 64 hex characters for EVM, 80–96 base58 for Solana — so the chain is
-  read off the key. Passing `vm` explicitly still works and still wins.
-- **`solana-keygen` JSON byte arrays are accepted.** The contents of
-  `~/.config/solana/id.json` can be handed to `importPrivateKey` as-is, instead
-  of being converted to base58 by hand first.
+- `importPrivateKey(pk)` no longer needs a `vm` — the chain is read from the key — and accepts the JSON byte array `solana-keygen` writes.
 
 ### Fixed
-- **An out-of-range EVM private key is now `INVALID_PRIVATE_KEY`.** 32 bytes of
-  hex is not necessarily a key: zero, and anything at or above the secp256k1
-  group order, previously reached the curve library and surfaced as a bare
-  `Error` with no `code`, thrown from inside a queued mutation. It is refused at
-  the boundary now, like every other malformed key.
-- Corrected the README's account diagrams, which described a PK wallet as
-  carrying exactly one address as though it were a structural rule.
+- An EVM private key outside the valid range is refused as `INVALID_PRIVATE_KEY` instead of surfacing as an untyped error.
 
 ## [2.4.1] — 2026-08-11
 

package/README.md

@@ -7,8 +7,9 @@
 
 Hyperscale crypto wallet management library — multi-workspace, multi-chain, originally designed for on-chain market makers.
 
-Runs in Node and in the browser. Wallets live in one encrypted container: on disk
-under Node, in IndexedDB in a browser, or in any storage you plug in yourself.
+Runs in Node and in the browser environments. Everything a workspace persists — wallets, accounts, networks, assets — is encrypted `Record` layer, sealed by the library exclusively seen by creators.
+
+Where those records live is yours to choose: files, IndexedDB, Docker, NSA, databases, CDN, RAM, etc. Any encryption algorithm, any format, any storage media.
 
 ## How it fits together
 
@@ -65,15 +66,6 @@ Account "Cold Storage"   (PK)          no mnemonic
 A PK account can hold as many keys as you like, on any mix of chains — but it
 refuses the same identity twice, on either chain.
 
-> ⚠️ **One secret controls both addresses in a PK wallet.** There is only one
-> key to import, so both addresses come from it. Whoever learns that key holds
-> both chains.
->
-> This is not how an HD account works. There, a slot's two addresses come from
-> two different derivation paths — the mnemonic is shared, the private keys are
-> independent. If you want independent keys per chain, use an HD account, or
-> import a separate key for each and read `addresses[0]` of each wallet.
-
 > **`wallet.addresses` is a list.** It holds one address per `(vm, network)`
 > pair and is free to carry several. Read it rather than assuming a position:
 >
@@ -113,10 +105,10 @@ await hd.deriveWallets(5);                       // slots 1..5, alongside slot 0
 hd.wallets[0].addresses.find((a) => a.vm === "evm");
 hd.wallets[0].addresses.find((a) => a.vm === "svm");
 
-// PK — each import is its own wallet, on one chain
+// PK — each import is its own wallet, with an address on both chains
 const pk = await ws.accounts.create("Cold Storage", password, privateKey);
-await pk.importPrivateKey(anotherEvmKey, "evm"); // -> a new Wallet
-await pk.importPrivateKey(aSolanaKey, "svm");    // -> another new Wallet
+await pk.importPrivateKey(anotherEvmKey);        // -> a new Wallet, vm inferred
+await pk.importPrivateKey(aSolanaKey);           // -> another new Wallet
 ```
 
 ## Install
@@ -292,9 +284,7 @@ to be sure you get it rather than the fallback.
 import { argon2BackendInfo } from "wative-core";
 
 argon2BackendInfo();
-// { backend: "wasm", wasm: true, overrides: [] }
-// { backend: "noble", wasm: false, reason: "...", overrides: [] }  ← degraded
-// { backend: "unresolved", wasm: false, ..., overrides: ["node-rs"] }
+// -> { backend: "wasm" | "noble" | "unresolved", wasm, reason?, overrides }
 ```
 
 `backend` is the process-wide default. A provider may carry its own — a
@@ -403,13 +393,10 @@ So a typical lifecycle looks like:
 // First run on a fresh machine — env unset, no <cwd>/.wative2 → creates ~/.wative2
 await Workspace.open({ password: "wsp-pwd" });
 
-// Later, opt the project into a local workspace
-// $ mkdir .wative2
-// Now <cwd>/.wative2 exists → tier 2 wins
+// After `mkdir .wative2`, <cwd>/.wative2 exists and tier 2 wins
 await Workspace.open({ password: "wsp-pwd" });
 
-// Or override via env in CI/staging
-// $ WATIVE_WORKSPACE_PATH=/srv/wative-staging node app.js
+// Or set WATIVE_WORKSPACE_PATH=/srv/wative-staging to override
 await Workspace.open({ password: "wsp-pwd" });
 ```
 
@@ -469,6 +456,15 @@ await hd.wallets.drop(hd.wallets[10]);
 
 ### Address — sign messages, build transactions
 
+> ⚠️ **One secret controls both addresses in a PK wallet.** There is only one
+> key to import, so both addresses come from it. Whoever learns that key holds
+> both chains.
+>
+> This is not how an HD account works. There, a slot's two addresses come from
+> two different derivation paths — the mnemonic is shared, the private keys are
+> independent. If you want independent keys per chain, use an HD account, or
+> import a separate key for each and read `addresses[0]` of each wallet.
+
 ```ts
 const evmAddr = hd.wallets[0].addresses.find((a) => a.vm === "evm")!;
 const svmAddr = hd.wallets[0].addresses.find((a) => a.vm === "svm")!;
@@ -562,11 +558,7 @@ const evmTx = new EvmTransaction({
   from: evmAddr.publicKey as EvmAddress,
   to: "0x1234567890123456789012345678901234567890" as EvmAddress,
   value: 10_000_000n,
-  // The chain is set HERE, by id. `chainId` is required and has no default,
-  // and there is no `network` field on a transaction — both are refused
-  // rather than guessed, because a signed transaction for the wrong chain is
-  // still a valid transaction on that chain.
-  chainId: 8453 as ChainId,   // Base
+  chainId: 8453 as ChainId,   // required, no default; there is no `network` field
   gasLimit: 21000n,
   maxFeePerGas: 50_000_000_000n,
   maxPriorityFeePerGas: 1_000_000_000n,
@@ -591,8 +583,7 @@ const evmTx = evmAddr.buildTransaction({
   gasLimit: 21000n,
 });
 const rawEvm = evmTx.toRawTx();
-// { from, to, value, data, type, chainId, gasLimit, ... }
-// pass `rawEvm` to web3.eth.sendTransaction, ethers Signer, viem walletClient, etc.
+// { from, to, value, data, type, chainId, gasLimit, ... } — hand to web3/ethers/viem
 ```
 
 ```ts
@@ -602,9 +593,7 @@ const svmTx = svmAddr.buildTransaction({
   amount: 1_000_000n,
 });
 const rawSvm = await svmTx.toRawTx();
-// rawSvm.add(extraIx);
-// rawSvm.sign(theirKeypair);
-// connection.sendRawTransaction(rawSvm.serialize());
+// then rawSvm.add(...) / .sign(...) / connection.sendRawTransaction(rawSvm.serialize())
 ```
 
 For SVM, if you supply `recentBlockhash` at construction time, `toRawTx()` builds entirely offline — no Address binding required.