Grin ledger hardware wallet progress thread by @markhollis


Here I will post my updates about the work I’m doing for implementing Ledger hardware support. See this thread: [LOCKED] Support Ledger Wallet

The past two weeks I started working on the connection between Grin++ and Ledger.

There are two projects I am now working on: the Grin++ hardware wallet support and the Ledger device app.

Now I’m working on the USB communication code on the Grin++ side.

After this goes well, here are some tasks I can already anticipate:

I plan to look at how to implement other setup functions like key derivation, setting PIN and passphrase.

I will also look at integrating some of the C embedded code that Vlad posted previously. Notably the cryptographic primitives, such as rangeproofs. These are things that will be reused.

After this, I will start working on the transactions: defining the UI screens, the different commands that must happen during the different types of transactions.


Great news. Good luck!


You’re making efficient progress, cheers!


great , was waiting for ledger support.


The last weeks I worked on grin-wallet. I’ve been looking how I can integrate the hardware wallet interfacing code in this existing codebase.

I have been stuck for some days on getting the communication between the Ledger device and my test program working.

But I can now send ‘simple’ commands between the terminal and receive feedback. It turned out to be some USB timing issue.

I think I am also going to start looking into the Ledger Live component. I think it helps when I can switch between different parts of the project, whenever I feel I am ‘stuck’ on one part.

I hope I can get more progress the following weeks.


Update for the weeks 13/04 to 27/04:

  • I have been looking about how to open an existing hardware wallet on the desktop side. I have looked at how the Monero project approached this issue. The way they do this, is that when the wallet is created, an view key is generated on the device, sent to the host and serialized in a file.
  • I have learned more about the MW/Grin cryptography in depth, as I felt I was lacking in this area. I started looking in detail at the Beam
  • I started integrating code in the grin-wallet and created a pull-request for some files.
  • Added the secp256k1-zkp library to the app firmware.

Next will be further integration, and looking more into cryptography specific components.


But there aren’t any view keys in Grin, right? So I wonder how a wallet that cannot access the private key could show an up-to-date Grin balance without being actively “authorized” by the user through the HW wallet every time. As I understand, showing the current balance can only be interactive with Grin, because it requires the private key.

1 Like

Yes, Grin does have view keys, just like Monero; see


Is that documented for grin-wallet somewhere? I can remember having that searched before and I could not find any hints. Maybe it has different naming?

Edit: I assume it has not been implemented for wallets yet.

1 Like

Update for weeks 27/04 to 11/05.

  • I have integrated my existing code now into libwallet.
  • The approach now is to add a ‘–hardware’ flag to commands, to test during during development. This can change later. This is mostly done now.
  • I focused mostly on the receiver function these weeks. In particular on the offset adjusting and the payment proof. On the firmware side, I worked on the nonce generation using the secp256k1-zkp library. I was also looking into the payment proof signature.
  • Last week I was sick, I couldn’t really work as much as I wanted to do.

The first thing I will do now is to work further on the initialization of the hardware wallet, on the grin-wallet and the firmware side. After that, I will work further on the different items in the SRS workflow, starting with the sender.

Some things to keep in mind:

  • To communicate between grin-wallet and the firmware, APDU packets are needed. Items like payment proofs need to be serialized in a fixed format. This can sound obvious, but the grin-wallet has to be able to decode the data from the APDU packets.

Looks like there is a bunch of APDU related crates available:


@mably I use the Ledger library from Zondax.
My last comment was about the thought that the library provides functionality for sending commands and getting data answers back in bytes. But it is up to the developer to decide how the data answers are formatted, which data to send and in which order the bytes appear.


Update for weeks 11/05 to 25/05.

  • Researched initialization and sender/receiver wallet functions further + implementation.
  • Made an interface that encapsulates the logic for dealing with the device and keys, similar to how Beam uses a KeyKeeper interface.
  • I researched rangeproofs somewhat these weeks, but it isn’t yet clear to me how I should approach this further. I’ve been reading through GitHub - AdamISZ/from0k2bp: From Zero (Knowledge) to Bulletproofs - writeup and through how BP’s are used in grin. Here (grin/ at 1b8acee72e7a4236cdf8561a7af5f894bfe11985 · mimblewimble/grin · GitHub) it seems like BP’s should be created at the device. Creating BP’s is however computationally expensive for the HW. Maybe the HW should do only the part before the call to secp.bullet_proof()?
    *One thing I’m thinking of as I write this, in grin-wallet, an input is a Vec<(Identifier, Option, u64). The Option<64> is an mmr_index. See: grin-wallet/ at bdc5bd748a4e399e6febc5e3c4974e569ee39638 · mimblewimble/grin-wallet · GitHub. I should look into how this MMR index is generated.
  • I did some work again on the Grin++ side. I found a C++ library to work with Ledger, which I can communicate with the device. The plan here is to implement the same ideas as I already did in the grin-wallet. Furthermore, it is informing to see two implementations of the protocol; it makes somehow the protocol more clear to me at certains points.
  • I made a document for grin-wallet and Grin++, for listing parts in the source code that should be delegated to the HW wallet. (The documents cointain permalinks and some comments about the code structure.) However, these are not ready to share yet.

You might be able to split the bulletproof up into pieces that require the user’s secret keys, do those operations on the HW, and do the rest of the proof on the machine. Not sure how intensive of an implementation challenge that would be, or how much work it will involve.


Is it possible to embed Grin into Trezor in future?


This would require a separate application for Trezor. But with Ledger wallet I should to make sure that the interfaces are defined in such a way that future hardware wallet can be supported.


Update for weeks 25/05 to 8/06:

  • I was sick for the greater part of the last two weeks. I couldn’t make much progress.
  • I am writing an RFC that standardizes the serialization of a packet necessary to send to a hardware wallet.

Hi. any update?
Hope you healed man.Take care.

1 Like


I’m still somewhat sick at the moment.

  • I received the Beam Ledger app code, thanks to Vladislav.
  • I worked further on said RFC and the reference implementations. I try to publish this as soon as possible.
  • It is best to keep in mind that a Trezor wallet may come. So the code should be separated between which is platform specific and what is not, so that code can be reused in a future Trezor wallet implementation.
  • There are some C libraries for working with PSBTs (BIP174), which can be useful on the firmware side.

This is FANTASTIC news - greatly appreciate all your efforts!