[Paused] Incognito Ledger Integration


As the Incognito network grows so does the value of the chain and the possibility of a hack such as attempting to steal someone’s private key or malicious software such as a wallet app pretending to be trusted increase. The Incognito team not only wants to develop the world’s best privacy chain but also protect user’s assets therefore we are planning on bringing Incognito to the hardware wallet developed by Ledger(https://www.ledger.com/). This will provide our users with a more secure place to store their private keys and make transactions.

The problems:

  • Software and online wallets are not well protected as against platforms and servers hacking/breaching.
  • There’re so many malicious “trusted” software and online wallets out in the wild.
  • Having to import your private key every time you change to a new wallet isn’t a great user experience and a security risk.

The Solution:

With hardware wallet, we have:

  • The private keys always-on device.
  • Pin-locked action. (have to unlock wallet to be able to transact)
  • Offline
  • Don’t need to import keys when moving to a new wallet/platform.

In case you don’t know what a hardware wallet is, our friends at Binance Academy had written a great article explaining it here (https://academy.binance.com/en/articles/what-is-a-hardware-wallet)


Research & Features planning: 2 weeks

  • Read sample code & try samples on HW (1 week)
  • Features research (1 week)

Implementation: 6 weeks

  • Hardware: (4 weeks)

  • Generate Keys (1 week)

    • Generate a new Incognito key set
    • Recover wallet from seed words
    • Import from a private key
  • Sign transactions (3 weeks)

    • Generate coin commitment
    • Generate key image
    • Generate asset tag
    • Generate OTA
    • Encrypt/Decrypt coin value
    • Generate ring signature
    • Generate bulletproof
  • App Integration: (2 weeks)

    • Building on top of Incognito Devframework
    • A tool for testing and interacting with the Incognito ledger app

Integration & Test: (4 weeks)

  • Integration & test with application wallets (mobile app, web app, extension)

Total length: 12 weeks

Resources: @lam @hieutran @daniel


Great news!


Awesome! Will incognito first switch to a seed phrase before this integration starts? I think that process is nearing completion so the timing seems right.

Just to clarify: I just want to make sure that the seed phrase held by Ledger also backs up the incognito chain. (As of now, one Ledger seed phrase backs up all the coins it supports.)


Hi @marko,

Yes, after we finish the integration with Ledger, you can control your assets on Incognito chain in the most secure manner by the seed phrase held by Ledger.

However, security and ease of use cannot achieve at the same time. You can keep your asset on the mobile app wallet to easily trade, transfer, shield, unshield; or you can keep your asset securely on the Ledger.

We will try to make the balance of security and ease of use to bring the best UX and security for Incognito’s community :slight_smile:


That’s gonna be a game changer…good luck to us all.


Hi everyone, I would like to update you on our progress, we are really on schedule:

  • We are able to generate, import and export Incognito keyset.
  • Currently researching/implementing coin related functions.

And Happy New Year everyone :tada: hoping next year will be a better year for the world and greater for Incognito.


Wow…too cool and ty for update @lam for I have a ledger hard wallet and look forward to its integration/implementation with the Incognito app… :sunglasses:


Love this!

One thing worth thinking about. Because there won’t be a way to import existing Incognito keys onto the Ledger, any keys currently bound to a vaiidator will have to be swapped out to one generated using Ledger seed. I know that at least in my case, unstaking my validators one-by-one is going to be a long and painful process. I’m using JServers for my nodes, and I anticipate it’s going to be a lot of overhead for them all at once. It may also show up on the network as a lot of nodes unstaking all at once, which may affect the supply and price.

This swap could probably be solved using a smart contract and some instruction to swap keys on a validator already staked, requiring the instruction to be signed using the existing key. But that’s a bit of work. Maybe something to consider.

I don’t know if this will cause serious instability, but it might be worth warning validators to unstake over time? In most cases, I suspect validator keys protect the largest amount of PRV someone has in one place, so the priority to move over to hardware storage will be the highest.


Thinking about this more, I’m not sure how Ledger support will work with Validators at all, since generating a validator key will be required and I’m not sure how that will work? Are these keys generated from the public key? Or the private? With many other networks, it’s either derived from the private key, or it is the private key. This work well for industrial uses since we can use TPMs/HSMs for signing operations.

Is there a plan to support validators with offline storage? Worst case scenario, the ability to remove the private key from the app would be nice. I don’t know offhand if it’s required to unstake/stake or remove rewards (I don’t think so), but it’d be great if I could provide it only when needed. The app storing some private keys and not others would be very confusing, I think.


This would be a great addition for a builder reward, I think. If you or anyone here sees value in coding this, I think that many would love it.


I agree! Though, it’s security sensitive. If there’s a bug, this could allow someone to steal the PRV staked to a node as replacing the validation key would also mean changing the account the staked PRV would return to. The attacker would still need to wait through the unstaking process, in which case the stake could be slashed. Harder once the network is truly decentralized.

Whomever builds it would have to do some threat-modeling and validation, like all contracts :grin: I’d love to build if no one else wants to.


Hi @heavypackets,

Thanks for your interesting discussion. These are also our concerns during this time.

Roughly speaking, we don’t need to introduce something like Instructions or Smart contracts to swap user’s validator keys. The easiest way is that you can un-stake and stake again with a new validator key generated by Ledger (note that the validator private key is generated from the private key).

However, as you said, this may be a cause for network instability. Fortunately, we currently have fixed nodes and pNode that can help in this case. In addition, we will release the new staking flow in Feb, which will make the un-staking process faster.


Ah, I didn’t know about the new staking flow. I will hold for that before moving over to Ledger derived keys. I know there are a few Ledger apps that expose keys, so I imagine this app can do that for the validator key after deriving it on the device. I like the fact that the Bitcoin app has a privacy warning around the key. It’d be nice to have something like that too.


Looking forward to testing this flow out. Thankful for having a separate validator key, this would be far more difficult without it.


Hi everyone, I would like to update you on our progress this month, a lots had been done since the last update post:
:heavy_check_mark: Generate coin commitment
:heavy_check_mark: Generate key image
:heavy_check_mark: Generate asset tag
:heavy_check_mark: Generate OTA
:heavy_check_mark: Encrypt/Decrypt coin value
:heavy_check_mark: Generate bulletproof
:heavy_check_mark: Get account balance via ledger

Upcoming focus items are:
:white_medium_small_square: Generate ring signature
:white_medium_small_square: Successfully create & sign tx via ledger
:white_medium_small_square: Host-side CLI and service
:white_medium_small_square: Refining API flows
:white_medium_small_square: Testing


Great news! Tks a bunch!

1 Like

Hello, here is the monthly update of the proposal, we nearly there:
:heavy_check_mark: Generate ring signature
:heavy_check_mark: Successfully create & sign tx via ledger
:heavy_check_mark: Refining API flows
Upcoming focus items are:
:white_medium_small_square: Get ledger app reviewed by Ledger
:white_medium_small_square: Host-side CLI and service
:white_medium_small_square: Testing

Enjoy the weekend everyone!


Are the Master keychains using a hardened derivation path? BIP32 allows for both hardened and non-hardened derivation paths. I’m having trouble finding anything definitive regarding Incognito’s implementation.

1 Like

Yes, the Master keychains are using hardened derivation path. Both mobile app and ledger app are following BIP32, BIP39 and BIP44. Our hardened path is m / 44’ / 587’ / 0’ as implemented in incognito-chain-web-js.


Haven’t had an update in a couple months. Any updates to share?


Checking in here too! I cloned the most up to date code for the ledger app. It looks basically complete, though I’m not sure if there have been breaking changes since.

I’m curious what is left at the moment. The Ledger app would still need approval and that’d require a bit of non-dev effort. Still, this would be a good step in security for users.