Substrate Ledger app and contract with Zondax

Ecosystem
1

Hello everyone. I wanted to open up a conversation regarding Zondax and their Ledger app integration with parachains in the ecosystem.

Background and Motivation

As many parachains are aware by now, around May of this year, Zondax and Web3 Foundation struck a deal to provide parachain projects with free Ledger app support for basic pallets (source).
However, the article and announcement neglect to mention that this package will only support the balance pallet, which is insufficient for most parachains as we need at least the standard plan to make the app usable with most dApps. Custom solutions for adding more frame pallets or custom pallets.

Screenshot from 2022-08-25 18-58-46
Screenshot from 2022-08-25 18-58-461407Ă—730 135 KB

Furthermore, they will only offer 3 months of free support (which covers app update when the extrinsic interface changes) in a ecosystem that is growing and changing everyday.

I am not saying that their plans are completely unreasonable and we shouldn’t use them because they are a very capable team who deserves the attention. But when we consider that most parachain projects are relatively small companies or small networks (and in case of Astar Fondation, a team of builders without any other source of income outside of our network), I feel like the announcement of the partnership with the Web3 Foundation did not result in anything practical outside of transferring balance (and God know what would happen after three months).

What is the problem?

I believe that for most parachains, the standard plan is not enough (in the case of Astar, we don’t use the proxy pallet and the staking pallet) to create something usable and representative of the parachain’s value proposition. And considering that most Substrate-based chains are using a shared pallet in the Substrate frame, having the parachains pay separately to support the same pallet to the same organization seems wrong. I am also unhappy with having the parachain responsible for paying the full support fee for commonly used pallets when upgrades are inevitable, and the chain is always evolving. Another issue is when we have to add the contract pallet support for the Ledger app as the Ledger app UI rendering is done on an interface basis (similar to how EVM signatures work on Ledger for ERC20 transfers).
Of course, it doesn’t make sense for the parachain not to pay anything to Zondax, but having the parachains for everything separately for the same feature doesn’t seem right to me. Especially when the burden of UX (Ledger support to the dApp front-end and gracefully fail unsupported pallets) and mass adoption for Polkadot ecosystem projects rely on the hands of the parachains.

I am not a fan of businesses treating small sovereign layer 1 blockchains like parachains as business clients to perform a service instead of an open platform that any projects can build on or use. This is not the Web3 way.

Proposal

I feel that it’s not far-fetched to have the Polkadot’s (or Kusama’s) treasury to pay the development fee for common standard pallets (frame) or the maintenance fee to Zondax. This would encourage more projects to add Ledger support, leading to more adoption from new users, not to mention the added security for key management.

Discussion

We were presented with a hefty amount per year for the full integration with a couple of custom pallets and the contract pallet support. This is impossible for us to support in the long run as a small team, and I don’t know how we can continue to support once we become a DAO.
I want to start the discussion by asking parachain projects who are working with Zondax for their Ledger app and what your thoughts are.

I will not claim that my proposal is the only way to solve this issue, or even if the problem I raised is an actual problem for others. But I think it’s worth talking about it.

6 Likes
2

We have been working for over a year with Zondax on our side. All the points mentioned by @hoonkim generally apply to us as well. However, I’d like to suggest a different path forward.

Indeed, Zondax currently has the monopoly of Ledger development for Substrate and thus can charge hefty fees to each Parachains. Not only that, but the work done should generalize among Parachains that use similar pallets, right now, we all pay the same fees for the same piece of code which is duplicated across codebases. This sounds like a waste of resources. Not only that, but we also end up having to support one Ledger app for every single Parachain, while the underlying primitives are almost the same.

I am wondering whether there would be a path towards a single general application, potentially with some extensions for each parachain. This would be similar to the ETH Ledger app for which extensions are then developed (for example, that’s how the LIDO works from what I know). Are there any technical blockers behind this structure? If not, is this something we could push for and sponsor via some grants from all of us?

2 Likes
3

I think the major technical blocker for that approach would be handling different pallet versions, embedding chain metadata, and handling custom pallet interfaces. Especially with common basic pallets, we could probably just make a unified codebase that allows us to add something like GitHub - paritytech/ss58-registry: Registry for SS58 account types for our chain.
But the biggest challenge is handling custom pallets and smart contracts. The codebase is a bit challenging for us to make scalable for different solutions since it’s not easy as adding a JSON file with the custom interfaces.

1 Like
4

My gut feeling is that the custom pallets / smart contracts could be supported via a second app/shim that serves as an extension. This is how ETH-based and BTC derivatives apps are implemented on Ledger, they all piggyback on the main ETH/BTC app. (Correct me if I am wrong obviously)

5

Thanks @hoonkim and @eliott for bringing this forward! I do think there are synergies across parachains that can be useful for this, and that potentially the Polkadot/Kusama Treasury, even combined with the different chains Treasuries can provide the needed funding for this development.

I think it would be interesting to discuss some particular case. I’ve put together this list some time ago with the pallets being used on each parachain’s runtime on both Polkadot and Kusama. These are ranked by which one is present in the most amount of runtimes (note that these are counted by name; if any team is using the same pallet name but there is something different inside, this analysis wouldn’t notice it).

From this particular list: which pallet(s) could be a good target for the idea being discussed here? Personally I think it should be a combination of pallet(s) that users will use, and that are extensively being used in the different runtimes.

1 Like
6

Thank you for the list! Yes, I think pallets listed here with at least 30% usage expected for the end users to directly interact with (ex: pallets that you would put in your custom UI) are a good starting point in my opinion.

2 Likes
7

This sounds similar to the discussion around which pallets we need to move to the independent FRAME organization. Maybe a good approach could be to say that if a pallet is in the FRAME org + exposes external extrinsic, then it could be a good candidate for a generalized integration.

2 Likes
8

This topic is quite essential and has been brought up by a few individuals and institutions of ours about not having hardware wallet support for the tokens on the Kusama Parachain.

I would like to ask for general Substrate-based Blockchain support on the Ledger, as it was already previously mentioned for the basic transfers and signing process.

Instead of Kusama Parachains paying for individual integration, it would make more sense to pay once as a collective for a general implementation usable for the basic functionalities.

If that is technically not possible, it would be interesting to know what the blocking matter is and if we could overcome it, at least for the Parachains.

1 Like
9

I agree with your point. The problem is, I’m not sure who would be the right person to contact regarding this issue

10

I would like to bring up the thread I wrote here: XCM as a Standard for Reading And Interacting with Parachains

I think that it totally made sense at the time of original Ledger Application development, to think of interfacing with Polkadot and Parachains via Pallets, since this was the only APIs exposed from the runtime.

However, as noted in my thread, the real long term, and scalable solution you all are looking for is an interface from ledger to parachain via XCM.

Then it would not matter which pallet is in the background being used for multisig, balance transfers, voting, or anything else. Also it will not matter when and how often these apps are updated. As long as a ledger device can produce an up to date XCM message, then any runtime should be able to interpret and execute that message as intended.

In this case, the ledger app developer just needs to stay up to date with XCM, which is a whole ecosystem need, and which costs can easily and fairly be split between teams.

9 Likes
11

Hello! Here’s the proof of concept for unified ledger APP for substrate-based parachains, I’ve covered the Idea here and here.

3 Likes
12

To me the per-chain substrate Ledger app makes no sense. It brings no benefit, and makes great harm to the ecosystem.

First, the money cost. Most of the parachain teams work with 3rd party companies to build their own Ledger app with significant costs that’s hard to be justified. The underlying work doesn’t actually involve real development, but literally dump the latest chain metadata, replace it, bump the version number, and create a new release. This process can be perfectly done by CI/CD pipelines to make it fully automated. So it’s really hard to justify the price of this kind of service.

Second, the time cost. Ledger has an official app store. To launch a new app or to upgrade an app, a review process is required, and it usually takes a very long time (months). For a lot of minor update which may just involve some simple metadata change, or even a tiny transaction version change, the team must submit a new version app and wait for months just for that tny update. It means that during this period, the Ledger users have no access to their substrate chain assets, unless they switch to the developer mode and compile their own app firmware. It’s the opposite of any user friendly blockchain.

I’d say the bad hardware wallet experience is one of the top reason to form the public opinion “Polkadot is not user friendly”. Now we know why.

4 Likes