build(deps-dev): bump @midnightntwrk/wallet-sdk-address-format from 4.0.0-beta.2 to 4.0.0-canary.20260904230148-3a8f1ea

[dependabot]

Bumps @midnightntwrk/wallet-sdk-address-format from 4.0.0-beta.2 to 4.0.0-canary.20260904230148-3a8f1ea.

Release notes

Sourced from @​midnightntwrk/wallet-sdk-address-format's releases.

@​midnightntwrk/wallet-sdk-address-format@​4.0.0-beta.3

Minor Changes

• b9c1150: Hard-fork support. A wallet runs @midnight-ntwrk/ledger-v8 below the chain's fork version and @midnightntwrk/ledger-v9 from it, and follows a live chain across that boundary: balances, coins and transaction history survive the crossing, and a wallet restored from a snapshot crosses too. Applications no longer import a ledger package directly.

  Breaking: configuration

  • forks: { v9 } is the protocol version from which ledger-v9 reads the chain. ProtocolVersion.V9NativeForkVersion (2000000) is the value a 2.x node reports, and ProtocolVersion.V9NativeForkSchedule is { v9: V9NativeForkVersion }. The facade presets it as DefaultForkSchedule when forks is left out of the configuration and hands the completed configuration to every factory in InitParams; WalletFacade.resolveConfiguration(configuration) returns the same for code outside a factory. ShieldedWallet, UnshieldedWallet and DustWallet require forks.
  • provers: { v8?, v9 } names a proving backend per ledger version, each { kind: 'server', url } or { kind: 'wasm' }. provingServerUrl remains the shorthand for one proof server under both keys; provers wins when both are given, and naming neither fails with ProvingConfigurationError. A transaction whose version has no backend fails with UnsupportedProvingVersionError. No published proof-server image serves both ledger versions, so a chain with ledger-v8 history wants a server per key; the in-process prover serves both.
  • chainVersionProbe (optional, all three wallets) asks on every start which protocol version the chain's first block was produced under, so the wallet starts on the matching ledger version; the default asks the indexer. A failed probe never fails a start: the wallet starts on ledger-v8 and crosses on its first synced update.

  Breaking: starting a wallet

  • Wallets start from seeds. WalletSeeds.fromMasterSeed(masterSeed, { account?, addressIndex?, unshieldedRole? }) derives the shielded, dust and unshielded seeds and throws SeedDerivationError for a seed it cannot read. ShieldedWallet(...) and DustWallet(...) gain startWithSeed(seed) and startWithKeys({ v8, v9 }), both returning a Promise; startWithSecretKeys and startWithSecretKey are removed. The unshielded startWithPublicKey also returns a Promise. The single-ledger CustomShieldedWallet and CustomDustWallet keep their synchronous starts and cannot cross a fork.
  • WalletFacade.start takes WalletSeeds or FacadeKeysByEpoch ({ v8: { shielded, dust }, v9: { shielded, dust } }), and its third argument is now { manualSync?: boolean }; doSync takes the same start material.
  • The secretKeys parameter is gone from every transaction-building method. A stopped wallet drops its key material, so transacting after stop() fails with MissingStartAuxError.
  • DustWallet(...).startWithSeed(seed, dustParameters?) and DefaultDustConfiguration.dustParameters take a plain DustGenerationRates object and default to the ledger's initial parameters.
  • Snapshots restore on whichever ledger version wrote them. tryRestore returns the reason a snapshot cannot be read instead of throwing; the dust wallet adds peekProtocolVersion and UnsupportedSnapshotVersionError; the shielded Restore and unshielded UnshieldedRestore namespaces inspect a snapshot.

  Breaking: transactions carry the version that built them

  • Every facade and wallet method that took or returned a ledger transaction now uses WalletTransaction, a handle that records the protocol version the transaction was built for. A handle for the other ledger version is refused with ProtocolVersionMismatchError. Applications that build their own transactions import @midnightntwrk/wallet-sdk/ledger/v8 or /ledger/v9 and seal the result with WalletTransaction.adopt('Unproven', tx, protocolVersion); handles serialize with toWire and fromWire.
  • finalizeTransaction and finalizeRecipe stamp the version the transaction was authored at, not the version reached while it was being proved. If the chain moved to the other ledger version during proving, they fail with

... (truncated)

Commits

• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[dependabot]

OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting @dependabot ignore this major version or @dependabot ignore this minor version. You can also ignore all major, minor, or patch releases for a dependency by adding an ignore condition with the desired update_types to your config file.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.