Resources

Change Logs

Learn about the changes and updates in each version of the Hydra SDK

August 2026 — `core` v1.5.0 (Latest)

KeysUtils.mnemonicToCliKey() returned a key that had nothing to do with the mnemonic it was derived from. This release fixes that and teaches CardanoCliWallet to read extended keys.

🐛 The derived key did not match the wallet

Payment keys derived from a mnemonic are BIP32-Ed25519 extended keys: 64 bytes, kL | kR. mnemonicToCliKey() cut a 32-byte slice out of one and passed it to genVkey(), which read it back with PrivateKey.from_normal_bytes(). Two separate faults:

The slice was taken at hex offset 4 — a leftover from stripping a 5820 CBOR prefix that to_raw_key().to_hex() never emits — so it was misaligned by two bytes.
Even a correctly aligned kL cannot be read as a plain key. In BIP32-Ed25519, kL is the scalar; a plain ed25519 key is a seed that gets hashed into a scalar. The two derive different public keys.

The output was a perfectly valid keypair — just an arbitrary one. Its address did not match the wallet the mnemonic builds, so funds sent to one were unspendable by the other:

const account = wallet.getAccount(0, 0)
account.enterpriseAddressBech32 // addr_test1vqp8nzt7zvl8chcj6hmhluhesyfqa56kyl573udka4qw82gsk9hnm
cliWallet.getAddressBech32() // addr_test1vz36gll4gnlfmwg5wgdxmr8apvgu0dxq3ye06c4mwre76jq336zfs ✗

💥 Breaking — `mnemonicToCliKey()` now returns an extended pair

An extended key cannot be narrowed to a plain one, so the fix is to stop trying. mnemonicToCliKey() returns the same envelope cardano-cli writes for HD-derived keys, and both cborHex values change:

	before	now
`sk.type`	`PaymentSigningKeyShelley_ed25519`	`PaymentExtendedSigningKeyShelley_ed25519_bip32`
`sk.cborHex`	`5820…` (32 bytes)	`5880…` (128-byte xprv, `prv \| pub \| chaincode`)
`vk.type`	`PaymentVerificationKeyShelley_ed25519`	`PaymentExtendedVerificationKeyShelley_ed25519_bip32`
`vk.cborHex`	`5820…` (32 bytes)	`5840…` (64-byte xpub, `pub \| chaincode`)

If you persisted keys produced by an earlier version, re-derive them and move any funds across. The old address is not recoverable from the new key.

The pair now resolves to the same payment credential as the wallet it came from, and signs byte-identically:

import { AppWallet, CardanoCliWallet, KeysUtils, NETWORK_ID } from '@hydra-sdk/core'

const mnemonic = AppWallet.brew()
const wallet = new AppWallet({ key: { type: 'mnemonic', words: mnemonic }, networkId: NETWORK_ID.PREPROD })
const { sk, vk } = KeysUtils.mnemonicToCliKey(mnemonic, 0, 0)

const cliWallet = new CardanoCliWallet({ skey: sk.cborHex, vkey: vk.cborHex, networkId: NETWORK_ID.PREPROD })

cliWallet.getAddressBech32() === wallet.getAccount(0, 0).enterpriseAddressBech32 // true

✨ Extended keys accepted throughout

CardanoCliWallet takes skey as 5820… (32-byte plain), 5840… (64-byte raw extended), 5860… (96-byte xprv) or 5880… (128-byte xprv), and vkey as 5820… or 5840… (xpub). Plain keys behave exactly as before.
KeysUtils.genVkey() accepts every signing-key shape above. A BIP32-Ed25519 key carries a chain code, so it yields an extended verification key; every other shape yields a plain one, unchanged.
New envelope helpers: KeysUtils.encodeCliKeyEnvelope(), decodeCliKeyEnvelope(), cliSkeyToPrivateKey() and cliVkeyToPublicKey() read and write cardano-cli key envelopes directly.

Package	Current Version	Description
`@hydra-sdk/core`	1.4.1	Core library for building decentralized applications
`@hydra-sdk/transaction`	1.2.0	Transaction building and management utilities
`@hydra-sdk/bridge`	1.3.2	Bridge functionality for wallet connections
`@hydra-sdk/cardano-wasm`	1.0.0	Cardano WASM bindings and utilities
`@hydra-sdk/tsconfig`	0.0.4	Shared TypeScript configuration
`@hydra-sdk/eslint-config`	0.0.4	Shared ESLint configuration