Is there a fully open-source hardware wallet DRep voting solution?

Terminada · 30 June 2026 06:11

I have found only a few hardware wallets usable with Cardano:

Ledger (not fully open-source.)
Trezor (open-source but can only delegate to a DRep. Cannot do governance votes.)
Keystone (fully open-source and can do governance votes.)

So I could only find one open-source hardware wallet option for DRep voting on Cardano and that is Keystone.

My Keystone device works with Eternl software wallet and I can submit governance votes, but Eternl is not open-source.

So what about voting manually using cardano-hw-cli? It purports to have Keystone support. But I can’t get it to output the correct address details. See this bug report I submitted nearly 1 year ago with no response: Keystone address key-gen produces incorrect key · Issue #197 · vacuumlabs/cardano-hw-cli · GitHub

I have emailed Keystone and submitted a support request via their website. I did both these things nearly 1 year ago too.

I have been trying again recently with the latest software versions. Keystone firmware version 2.5.0 (29 June 2026), cardano-hw-cli version Cardano HW CLI Tool version 1.19.1
(Commit hash: 97047f09baf7165a8eda1058980f53b38ff7dcbb)

I am not aware of a single Cardano user who has successfully used cardano-hw-cli with a Keystone device to output correct public keys and address details. Not even one person! Has anyone else even tried?

If anyone reading this has a keystone device, would they please try using it with cardano-hw-cli which is open-source and available from Vacuum Labs github page: GitHub - vacuumlabs/cardano-hw-cli: Cardano CLI tool for hardware wallets · GitHub

Please try exporting your public payment and staking keys and then generate the address using cardano-cli. Does the address generated agree with what your Keystone device displays and what other wallets like Eternl display?

Is there any fully open-source way to submit a Cardano DRep governance vote using the protection of a hardware wallet?

COSDpool · 30 June 2026 16:31

At some point this was believed to work, and I’ve posted here to try to find out more about why that claim was made & what happened to prompt its retraction:

github.com/cardano-foundation/CIPs

Comment by rphair - CIP-0021 | Add Keystone wallet support

master ← Ryun1:cip-21-add-keystone

@Ryun1 I would be interested in any Intersect or community experiences that migh…t have made you want to close this PR today. I have heard over the last month that Keystone is definitely not supported for the governance primitives that were claimed... but also that there is no workaround to use a Keystone derived address for voting with `cardano-hw-cli` itself ([general details here](https://forum.cardano.org/t/is-there-a-fully-open-source-hardware-wallet-drep-voting-solution/155403)). Especially with the significance of the on-chain budget voting cycle coming up, I feel underinformed about what to tell people. Can you and/or some other community experts please dump what is known here about Keystone compatibility as it stands now, or even what's been promised? Any workaround for voting would be welcome (including `cardano-signer` if possible) 🙏 cc @gitmachtl @Crypto2099 @gufmar @TerminadaDrep

Hopefully that will provide some insight about whatever workarounds there might be for this — at least enough to get Keystone ada holders voting on the current proposals. cc @ATADA @HeptaSean @ryun1

HeptaSean · 30 June 2026 16:44

Seem to be two completely separate topics to me.

What Keystone has implemented: I know that delegation and voting works with Keystone and Eternl without problem. Haven’t created a proposal and don’t have a stake pool, though. I don’t know if it makes sense to document the limitations of specific products in a CIP.
That @Terminada does not want to use a non-open-source wallet app and, hence, Keystone and Eternl is not good enough.

COSDpool · 30 June 2026 16:57

The purpose of that CIP is to document the capabilities of the hardware wallet interfaces. I guess the fact that support for governance certificates was documented & then withdrawn (see the contents of the closed PR if you wish) indicates that Eternl wallets obtain them some other way: and then the voting process works as you report.
That is an incidental observation and not the point of the post: which is to determine to what extent voting is possible from an entirely open-source platform.

I tagged a few more people here since I personally have little means of learning about cardano-hw-cli without a hardware wallet (I have my own reasons for believing, very subjectively, that they are “not good enough” — again, not the point of the discussion).

If it’s true that the open source wallet is only fully featured with a closed source piece of software, then we have a divergence between reality & the ultimate goals of standardisation on Cardano. We’re not obligated to fix all those divergences: but some of us are required to document them.

HeptaSean · 30 June 2026 17:24

Why should it “indicate” that?

The code for handling governance definitely is in Keystone (and has been for many months):

github.com/KeystoneHQ/keystone3-firmware

rust/apps/cardano/src/governance.rs

master

use crate::address;
use crate::errors::{CardanoError, Result};
use crate::structs::SignVotingRegistrationResult;
use alloc::string::{String, ToString};
use alloc::vec::Vec;
use cardano_serialization_lib::protocol_types::Address;
use cryptoxide::hashing::blake2b_256;
use ed25519_bip32_core::XPrv;
use hex;
use ur_registry::cardano::cardano_delegation::CardanoDelegation;
use ur_registry::cardano::governance::CardanoVotingRegistration;

pub fn build_metadata_cbor(
    delegations: Vec<CardanoDelegation>,
    stake_pub: &[u8],
    payment_address: &[u8],
    nonce: u64,
    voting_purpose: u8,
) -> Result<Vec<u8>> {
    match build_delegations(delegations) {

This file has been truncated. show original

No, Eternl does not use “some other way”.

Still don’t think that the capabilities and limitations of commercial products with a plethora of hardware and software versions should be “documented” in a CIP. It’s the job of the vendors to document what they can do. A CIP will always be hopelessly outdated.

COSDpool · 30 June 2026 18:04

@HeptaSean I’m just trying to expose the reason for @Terminada’s problem report above. Your confirmation definitely helps to indicate that it should also be working for him… which would then indicate that there’s nothing special that Eternl is doing and no reason why this or any other software wallet intermediary was needed.

@Terminada please post all the detail about the problem you are having on the Keystone (regardless of the apparent support): including the scripts of cardano-hw-cli showing how the derived keys are different. I’ve done all I can to help introduce the problem and now it’s time to post every bit of relevant detail: even if it means with putting up with more sarcasm.

HeptaSean · 30 June 2026 20:24

So, now I tried.

Yes, the address that I get is not the correct one:

It is the address for the Ledger/BitBox02 derivation, not the Cardano Native derivation.

Keystone can do both and you can switch between both in the three-dot menu if the ADA/Cardano view is open (the one showing you an address and a QR code for that address):

But switching does not seem to have any effect on what cardano-hw-cli gets. It’s always the public keys for the Ledger derivation.

Vacuum Labs quite prominently states: “NOTE: support for Keystone is developed and maintained by the Keystone team”

There seems to be a pull request for repairing all that now:

Terminada · 30 June 2026 21:46

Thank you @HeptaSean .
Clearly nobody in Cardano land is using open-source cardano-hw-cli with their Keystone. Anyone else attempting would have failed. I originally submitted the bug report in August last year.

adatainment · 1 July 2026 05:59

Does it have to be Keystone, or can it also be Ledger or Trezor? What’s the problem with sites that connect via CIP30/CIP95?

COSDpool · 6 July 2026 18:15

Finally some perspective about Keystone support in cardano-hw-cli: “I believe it never worked, I don’t think we’ve ever tested it in-house” https://github.com/vacuumlabs/cardano-hw-cli/pull/210#discussion_r3531088566

COSDpool · 8 July 2026 17:11

… and now an announcement that it’s been fixed (though I won’t be really happy until seeing confirmation from @Terminada here):

github.com/vacuumlabs/cardano-hw-cli

Keystone address key-gen produces incorrect key

opened 05:50AM - 28 Aug 25 UTC

closed 10:44AM - 08 Jul 26 UTC

TerminadaPool

Running the following commands should generate Address-0 displayed by the Keysto…ne device: ``` sudo cardano-hw-cli address key-gen \ --path 1852H/1815H/0H/0/0 \ --verification-key-file payment.vkey \ --hw-signing-file payment.hwsfile sudo cardano-hw-cli address key-gen \ --path 1852H/1815H/0H/2/0 \ --verification-key-file stake.vkey \ --hw-signing-file stake.hwsfile cardano-cli address build \ --payment-verification-key-file payment.vkey \ --stake-verification-key-file stake.vkey \ --mainnet \ --out-file payment.addr ``` However the output of ```cat payment.addr``` is not Address-0 or in fact any receive address displayed by the Kestone device in the first 50 or so addresses. (I gave up after checking the first 50.)

adatainment · 9 July 2026 07:10

So they listen or read along (both is great)

HeptaSean · 9 July 2026 07:11

Reading the issues in their own GitHub is kind of the bare minimum, though.

Topic		Replies	Views
Is it possible to register as a DRep using a Trezor safe 5 hardware wallet? Community Technical Support	18	616	7 December 2024
Registering several wallets/accounts to the same Catalyst voting key Project Catalyst	16	1743	14 January 2024
🗳️ Cardano ra mắt công cụ bỏ phiếu quản trị mới dành cho cộng đồng! TIN TỨC	0	57	22 June 2025
Voting for Fund3 Project Catalyst cardano	7	1347	25 March 2021
Unable to select/add Ledger HW as pool owner Staking & Delegation wallet , ledger , hardware	87	3624	10 April 2021

Is there a fully open-source hardware wallet DRep voting solution?

Related topics