There are several comparisons of the trezor and Ledger HW and their corresponding SW wallets. These mainly focus on the end user usability and number of coins supported.
However, when it comes to business, who want to support many customers, and for developers who want to integrate the HW wallets into existing commerce or financial systems, the picture is very different.
The conclusion is that Trezor is far better suited to business than the Ledger, but neither are perfect.
Note, here we don’t make the distinction between Ledger Nano S and Ledger Blue, and likewise between Trezor one and Trezor T, because the later models are basically the same as the former just with larger screen and a few extras.
Trezor has everything built into the firmware. The 500 or so coins it supports are always there and always avialble. No installation or configuration is required. When Trezor add more coin support, you just upgrade the firmware (which takes less than one minute) and you are done.
Out of the box, the ledger has literally nothing on it, it cant do anything. You need to install apps using their SW wallet. Each coin is an app. So there is an app for BTC, one for ETH etc. You can only install a small number of apps at the same time (something like 4 on the nano and 18 on the blue depending on app size). If you want to do transactions in more than the allowed number of apps, you have to uninstall and reinstall.
When you upgrade the Ledger, you have to remove all the apps, then reinstall them.
Trezor has a single unified API which is coin agnostic – e.g. you can generate addresses for any coin with one call, and you can sign transactions for any coin. The coin (e.g. Bitcoin or Ethereum) is just a parameter.
There are several ways to access the Trezor API. there is a python based command line tool, which allows you to do pretty much anything with a bash script or command line (such as generating 1000 addresses for a given path). There is also the bridge, which allows web apps to access the Hw through the browser. This then requires no SW to be installed on the users machine to
Ledger doesn’t have an API as such. In theory, each app can provide its own API. There is apparently a beta API for the BTC app. But there is nothing to say that other apps (aka coins) will get APIs, or if they will be unified in any way.
Interestingly, you can restore your 24 word seed on either device. So they are largely compatible in this regard. The only issue is that the Ledger uses a different Path for Ethereum than the Trezor by default, so you will need to use a wallet which allows the path to be configured (such as Electrum).
Labelling accounts and addresses is important for avoiding mistakes and for reconciliation/accounting. e.g. if you have 10 addresses, you might label them with the 10 customer names you have given them to. Or you might label them for different invoices.
Trezor has an interestingly solution for labels. They dont want to store them on the device, as they will be lost if you lose the Trezor and need to restore it from the Seed. So instead the store the labels in an encrypted file in dropbox. The nice part of this is that other users (in a company) can use their dropbox to securely share the labels between administrators.
Ledger supports labels for accounts, but doesn’t support addresses for accounts so these cannot be labeled.
Trezor can label individual addresses.
Discovery gap limit, accounting, and client funds segregation.
If you have say 20 customers, and you want to invoice each, you would want to give each customer their own account in the form of an address. This allows proper client fund segregation, easier audit and accounting. Even better, an account per invoice. Additionally, you would want to label each account with its function. At a glance, you can see the balance and transactions on any account.
This should be trivial to do with the HD wallet, as it supports unlimited addresses for a given account path. However, due to the limited SW implementations of the discovery gap, it is not.
Ledger only allow one address to be generated at a time, and only for one account. It ignores one of the main features of the HD wallet – the ability to generate many addresses, with increasing indexes, for a given account. It is difficult to compare the ledger wallet to any other wallet, as its feature set is so limited.
Above we see an “account” called trstbtc1. It has one address, which corresponds to index zero. You cannot see this address.
You cannot add a second address until there is a transaction on the first. If you have two customers, and want to give each a separate address for payment, you cant. You would have to give the first customer an address, wait for them to pay, then the SW will allow you generate the second address. This goes for their “accounts” also. The work around I see clients doing every day is the “loading hack“. They generate an addresss, transfer 1 satoshi (or equivalent coin) in to it, wait till it is confirmed (1 hour in the case of BTC), then they can generate a second address. Next they remove the 1 satoshi, so the customer who gets that address given to him doesn’t get worked that it has a balance (so is a “used” account), and do the same process for the next a account. This is a manual, time-consuming, costly and needless task.
So what is the problem?
Hierarchical Deterministic (HD) wallets have some interesting properties. Firstly, you only need to backup the master key (e.g. as a 24 word mnewmonic). From this all child keys can be derived again at any time. Each coin/token has a well defined sub tree, as defined by the derivation path. So Bitcoin has one standard path, and Ethereum another. Well, this is not strictly true, bitcoin has at least 2 standard paths, one for “legacy” and one for “segwit”, but that is another post. Within a specific path, any number of child keys can be derived deterministically (i.e. if you start from the same master key, you will always get the same child keys). Child keys have an index. so 0 is the first, 1 is the second etc. key 0 and key 1 are siblings.
The missing piece in HD wallets is knowing how many child keys were generated, i.e. what index you are on. As you are only backing up the master key, not the master key + indexes of children for each path.
One solution is the “discover gap limit”. This setting tells the SW wallet how many addresses for each parent to “load up” (i.e. show the balances for and allow transfers from). For example a discovery gap limit of 20 means generate the first 20 addresses for the given parent (i.e. index 0 to index 19). For each of these check the blockchain to see if there were any transactions. If any transactions are round, show the first 20 (with their addresses and balances), and look at the next 20 (index 20 to 39) and so on until no transactions are found for the given block.
The Trezor wallet has a discovery gap limit of 20, allowing 20 new (empty) addresses to be generated without the “loading hack“.
Ledger has a discovery gap limit of 1, alowing only a single new address tone generated (for a given token).
Electrum allows the discovery gap limit to be configured, so you could have 100 or 1000 new accounts to give to your customers in parallel.
The downside to this method is that if you are using a wallet with a high discovery gap limit, then you decide to move to a different wallet with a low discovery gap limit, AND restore your master seed to that new wallet, you wont “see” your accounts. They are there, no money is lost, but the wallet just wont let you view them or use them.
For this reason, all wallets should have a configurable discovery gap limit in the advanced settings. This is, at most, a few days of development effort for the wallet providers. There is no excuse not to implement this, even as a paid for “pro” feature.
Trezor is far superior to Ledger in this regard (20 vs 1)