SecuX Hardware Wallet supports Polkadot transactions and staking

[rus7hex]

Project Abstract

Integrating cutting-edge SecuX hardware wallets equipped with multi-factor authentication and secure chip technology, Polkadot provides both holders of high-value assets a secure and intuitive way to protect their investments, and bolsters the total value locked (TVL) within the network. This partnership highlights Polkadot's commitment to crafting a secure and reliable investment environment, attracting high-value investors for long-term engagement.

Grant level

• Level 1: Up to $10,000, 2 approvals
• Level 2: Up to $30,000, 3 approvals
• Level 3: Unlimited, 5 approvals (for >$100k: Web3 Foundation Council approval)

Application Checklist

• The application template has been copied and aptly renamed (project_name.md).
• I have read the application guidelines.
• Payment details have been provided (Polkadot AssetHub (DOT, USDC & USDT) address in the application and bank details via email, if applicable).
• I understand that 30% of each milestone will be paid in vested DOT, to the Polkadot address listed in the application.
• I am aware that, in order to receive a grant, I (and the entity I represent) have to successfully complete a KYC/KYB check.
• The software delivered for this grant will be released under an open-source license specified in the application.
• The initial PR contains only one commit (squash and force-push if needed).
• The grant will only be announced once the first milestone has been accepted (see the announcement guidelines).
• I prefer the discussion of this application to take place in a private Element/Matrix channel. My username is: @_______:matrix.org (change the homeserver if you use a different one)

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[rus7hex]

I have read and hereby sign the Contributor License Agreement.

[keeganquigley]

Hi @rus7hex thanks for the application. Currently, the milestone table is missing the default deliverables 0a. - 0e. as listed in our application template. Could you add these in? Docker might not be necessary in your case, so you can omit this, but the other sections should still apply. Thanks!

[PieWol]

Hey @rus7hex ,
please combine both tables into one and keep the default column headers as given in the template.
Thanks.

[PieWol]

Regarding Hardware wallets, historically speaking Ledger had a lot of trouble to offer a user friendly convenient solution for the whole substrate ecosystem as each chain required a different app. I'm not sure right now what the reason for this choice was. Possibly the need for different metadata for different chains. Even worse was the problem that the addresses of accounts that are associated with a single ledger app for a substrate chain could be converted with tools like subscan which led to the issue that people sent funds to this converted address on other chains assuming that their ledger will have exactly this converted address in the app for the other chain. Yet ledger apps for different chains are not sharing one underlying account so addresses varied. How are you solving this problem which led ledger to this decision? Preferrably you can come up with a concept that drastically improves this UX mess for users. Looking forward to your answers.

[PieWol]

More in scope of this very Polkadot only specific application I have a question regarding "Seed phrase generation and management, signing a transaction and staking." which you listed as key-deliverable.

"Signing a transaction" is a somewhat very vaguely specified deliverable. As you probably know Polkadot and other Substrate based chains use multiple pallets each with different extrinsics. So does this key-deliverable now mean that you will support ALL extrinsics that Polkadot offers or are you just describing the process of transacting tokens? E.g. sending Tokens from one account to another? I'm asking because if you were to support all extrinsics there wouldn't be the need to specify functionality for staking as an additional deliverable.

TLDR: What exactly means "signing a transaction" as a deliverable? Does the deliverable about staking compatibility mean that you are supporting ALL staking related extrinsics?

Thank you for your clarification.

[rus7hex]

Regarding Hardware wallets, historically speaking Ledger had a lot of trouble to offer a user friendly convenient solution for the whole substrate ecosystem as each chain required a different app. I'm not sure right now what the reason for this choice was. Possibly the need for different metadata for different chains. Even worse was the problem that the addresses of accounts that are associated with a single ledger app for a substrate chain could be converted with tools like subscan which led to the issue that people sent funds to this converted address on other chains assuming that their ledger will have exactly this converted address in the app for the other chain. Yet ledger apps for different chains are not sharing one underlying account so addresses varied. How are you solving this problem which led ledger to this decision? Preferrably you can come up with a concept that drastically improves this UX mess for users. Looking forward to your answers.

The SecuX wallet notably facilitates the creation of up to 500 distinct addresses from a singular seed phrase, offering Polkadot users a streamlined and secure method to manage various cryptocurrency assets across multiple blockchains. This capability underscores the wallet's utility in enhancing the operational efficiency and safety for individuals engaging with diverse digital currencies.

More in scope of this very Polkadot only specific application I have a question regarding "Seed phrase generation and management, signing a transaction and staking." which you listed as key-deliverable.

"Signing a transaction" is a somewhat very vaguely specified deliverable. As you probably know Polkadot and other Substrate based chains use multiple pallets each with different extrinsics. So does this key-deliverable now mean that you will support ALL extrinsics that Polkadot offers or are you just describing the process of transacting tokens? E.g. sending Tokens from one account to another? I'm asking because if you were to support all extrinsics there wouldn't be the need to specify functionality for staking as an additional deliverable.

TLDR: What exactly means "signing a transaction" as a deliverable? Does the deliverable about staking compatibility mean that you are supporting ALL staking related extrinsics?

Thank you for your clarification.

SecuX is dedicated to providing support for both transaction signing and staking on the Polkadot and Kusama networks. This commitment equips our users with comprehensive tools that are vital for efficiently managing and enhancing their digital assets within these ecosystems. Additionally, we are keen and open to exploring collaboration opportunities with other parachains in various proposals. We believe that such cooperative efforts can yield mutually beneficial outcomes and drive further innovation within the community.

[rus7hex]

@PieWol please let us know if a meeting is needed for the review, thank you.

[keeganquigley]

Thanks @rus7hex most of the team is traveling for a team retreat this week so will probably be early next week before more feedback is given. Thanks for your patience!

[semuelle]

Hi @rus7hex. Thanks for the application and the effort you put into it. Correct me if I'm wrong, but it looks to me as if the software you are building is based around proprietary hardware, which is something we usually try to avoid. Also, large parts of this project are dependent on successfully merging changes into the staking dashboard and polkadot.js apps repos, which we have had mixed success with, so I'm wondering if there was a better way to integrate, like working with Talisman or other wallets.

[semuelle]

Why are these called version number?

[rus7hex]

We will have specific SE firmware version and MCU firmware version supporting Polkadot.

[semuelle]

I understand, I'm just a bit confused why that's the name of the deliverable when the actual work being done for it is software development. Could you expand a bit on what exactly needs to be implemented for these deliverables that's specific to Polkadot? Account generation?

[dannyhuang213]

1. To implement and verify compatibility with BIP32-ED25519 seed phrase recovery, ensuring that accounts generated by Ledger are compatible with SecuX and vice versa. Users can switch between Ledger and SecuX devices without worrying about compatibility issues.

2. Display the Polkadot (DOT) cryptocurrency icon on the front end of the SecuX Web Wallet app.

3. Support Polkadot (DOT) cryptocurrency send/receive functions, including transaction history, via the SecuX Web Wallet and SecuX Hardware Wallet through WebUSB or Bluetooth.

4. Prompt the user to confirm the transaction amount and receiver address on the SecuX Hardware Wallet.

[semuelle]

How do you distribute the firmware? Please note that all deliverables should ideally be reusable, so please specify or remove. See also our FAQ.

[rus7hex]

Updates will be done through our SecuX web wallet.

[semuelle]

Can you elaborate what is being delivered here? To reiterate, all deliverables should be reusable and verifiable.

[dannyhuang213]

revising

[semuelle]

Are you still working on this, @dannyhuang213?

[dannyhuang213]

@rus7hex is helping to update it now, thank you for your patience.

[semuelle]

Who is meeting here? See my note below on reusability of deliverables.

[rus7hex]

The purpose of the periodic meeting is to gain a comprehensive understanding of Polkadot's JavaScript user interface and its staking dashboard.

[dannyhuang213]

Hi Sebastian @semuelle please feel free to let us know if you have any questions, we will be happy to clarify things

[semuelle]

The purpose of the periodic meeting is to gain a comprehensive understanding of Polkadot's JavaScript user interface and its staking dashboard.

That doesn't answer my question. Please keep in mind that deliverables in the grants program should be reusable and verifiable, which meetings usually aren't (unless the deliverable is a result of these meetings).

[dannyhuang213]

revising

[rus7hex]

Hi @rus7hex. Thanks for the application and the effort you put into it. Correct me if I'm wrong, but it looks to me as if the software you are building is based around proprietary hardware, which is something we usually try to avoid. Also, large parts of this project are dependent on successfully merging changes into the staking dashboard and polkadot.js apps repos, which we have had mixed success with, so I'm wondering if there was a better way to integrate, like working with Talisman or other wallets.

The primary purpose is to support Polkadot, our hardware wallet is built using industry-standard architecture like an MCU and a Secure Element.

[PieWol]

Hey @rus7hex ,
thank you for the time and effort you put into this application. I sadly will not approve it but maybe my colleagues will. I deem this application as the start of sunk cost fallacy relationship between your company and the foundation. Constantly threatening to no longer maintain the apps as Polkadot is a fast paced ecosystem. An eventual halting of maintenance on your end, in case the foundation no longer funds the development, would hurt the reputation of the ecosystem. Presumably far further than the bounds of your userbase. Trying to get the funds to even start this endeavour are sadly not convincing to me.

I'm wishing you all the best going forward.

[dannyhuang213]

@PieWol

Hey @rus7hex , thank you for the time and effort you put into this application. I sadly will not approve it but maybe my colleagues will. I deem this application as the start of sunk cost fallacy relationship between your company and the foundation. Constantly threatening to no longer maintain the apps as Polkadot is a fast paced ecosystem. An eventual halting of maintenance on your end, in case the foundation no longer funds the development, would hurt the reputation of the ecosystem. Presumably far further than the bounds of your userbase. Trying to get the funds to even start this endeavour are sadly not convincing to me.

I'm wishing you all the best going forward.

We will continue to support Polkadot and list it as one of our standard offerings. Not only do we care about our reputation, but also our customers' experience and success.

[takahser]

@dannyhuang213 thanks for your interest in our grants program and the work you put into this thus far. Unfortunately, I've decided to not add my approval, since I agree with my colleagues on their reasonings

I also want to mention that our funding guidelines require all produced code to be open-sourced and independent of closed-source software:

All code produced as part of a grant must be open-sourced, and it must also not rely on closed-source software for full functionality. We prefer Apache 2.0, but GPLv3, MIT, or Unlicense are also acceptable.

I know, in your case it's technically hardware (though one could argue that the hardware is programmed with proprietary software as well), but I think the dependency is comparable.

I appreciate your understanding and hope you'll continue to support Polkadot with your innovative hardware. Thanks again!

[semuelle]

Hi @rus7hex & @dannyhuang213, thanks again for the application, but the committee has decided not to support it, the main reason being the use of proprietary hardware. We still hope that you will continue working on the project and I hope we will be able to work together sometime, somewhere in the future.