[n13]

Why

Exchanges sweeping deposit addresses need balances.transfer_all: it moves whatever the balance is at execution time, and with keep_alive: true it leaves the existential deposit behind so the address survives and its nonce keeps counting. Until now the package only offered fixed-amount transfers, so a sweep had to be hand-encoded and signed through signCall.

What changes

• signTransferAll(seed, params) and signTransferAllFromMnemonic(mnemonic, params, opts) build and sign balances.transfer_all(dest, keep_alive) (pallet 2, call 4, then a bool).
• keepAlive is required, same rule as signTransfer: no default, omitting it is a TypeScript error and a runtime TypeError, and the wasm layer rejects a missing field too. true = sweep keeping the existential deposit, false = full drain that reaps the sender.
• Rust: TransferAllParams, sign_transfer_all, sign_transfer_all_with_keypair; the balances call prefix is built by one helper shared with encode_call. lib.rs gains a small from_js helper so the three param parsers share the same error mapping.
• README (API section, intro, replay section), example, and an "Unreleased" changelog entry.

Tests

• Rust transfer_all_call_and_extrinsic: exact call bytes for both flags and envelope equality with sign_call for both schemes.
• JS: call bytes and length for both flags, envelope equality with signCall, missing or non-boolean keepAlive throws for both the seed and mnemonic entry points, and the mnemonic variant signs with the derived ML-DSA-65 key.
• cargo test 11 passed, npm run build && npm run test:js 21 passed, npm run example runs.

[n13]

Reviewer model: GPT-6.1 Sol

Verdict (advisory): Approve

Reviewed base 04174ffca2e385ca64d45ee0c9523cc1dd36707d through head f10e79ea32901f0065b31d5c0a5d16e1ad728e72. No blocking findings. The new call matches the Quantus runtime encoding, both entry points reuse the existing hedged signing/context path, and the shared-prefix refactor preserves fixed-amount balances and assets transfers.

Non-blocking documentation note: README.md:143 says keepAlive: false always empties and reaps the account. The runtime transfers only the reducible balance; locks, reserves, or other account references can prevent reaping. Describe this as allowing reaping rather than guaranteeing it, and qualify the matching API comments.

Validation passed:

• git diff --check.
• cargo test --locked: 11 tests.
• npm run build and npm run test:js: 21 tests, including npm package contents.
• npm run example.
• Additional checks: 24 signing cases across both schemes/flags, recipient formats, mnemonic indices/passphrase and scheme precedence; 38 rejection cases covering missing/non-boolean flags at both JS/WASM entry points and missing mortal block hashes. Generated TypeScript declarations reject omitted keepAlive for both APIs.
• GitHub CI passed for this exact head.

Validation was offline; no transaction was submitted to a live node.

[n13]

Reviewer model: GPT-6.1 Sol

Verdict (advisory): Approve

Reviewed base 04174ffca2e385ca64d45ee0c9523cc1dd36707d through current head 094c3893851ccb9d227aa9d422f8dd7c2a241626. No blocking findings.

Both new entry points encode balances.transfer_all(dest, keep_alive) correctly and reuse the existing hedged signing, mortality and mnemonic derivation paths. The shared-prefix refactor preserves fixed-amount balances and assets transfers. Encoding was checked against the Quantus pallet index and transfer_all implementation. The documentation correctly qualifies that allowing reaping does not guarantee it.

Validation passed in an isolated detached worktree:

• git diff --check.
• cargo test --locked: 11 tests.
• npm run build with an isolated ARM-compatible wasm-pack 0.15.0; npm run test:js: 21 tests, including package contents.
• npm run example.
• 28 additional signing cases covering both schemes/flags, recipient formats, mnemonic indices/passphrase and scheme precedence; 46 rejection cases covering omitted/non-boolean keepAlive at both JS/WASM entry points and missing mortal block hashes at the JS entry points.
• GitHub CI passed for this exact head.

Validation was offline; no transaction was submitted to a live node.