Add OneKey Pro and OneKey Classic 1S wallet to the wallet list

[yikZero]

Looking forward to your review and approval.

[crwatkins]

Thank you for your submission.

Have you carefully reviewed the criteria for listing and verified that OneKey devices meet those criteria?

Note that the above document specifies for the wallet description text:

Do not use superlatives or exclusive phrases. For example, you might want to comment on ease of use. Don't write "This wallet is the easiest to use" or "This wallet is extremely easy to use"; write "This wallet is easy to use."

You may want to update your descriptions to meet these guidelines.

[yikZero]

Thanks for the feedback.

I've reviewed the criteria again and updated the description to remove the superlatives as requested.

Could you please check it again?

Thanks.

[crwatkins]

Looks much better. Thanks.

[crwatkins]

The transparency score on both submissions is checkgoodtransparencydeterministic yet all I have been able to find is failures by a third party attempting a reproducible build. Can you point to any successful third party deterministic builds?

[yikZero]

Hi @crwatkins ,

Thank you for your patience and for pointing this out.

We have worked with our third-party security partner, SlowMist, to update the audit report. This report now includes a detailed section on our reproducible build process, which should address your concerns.

You can view the updated audit report here:
https://github.com/slowmist/Knowledge-Base/blob/master/open-report-V2/blockchain-application/SlowMist%20Audit%20Report%20-%20OneKey%20Pro_en-us.pdf

As noted in the report, we utilize GitHub Actions for our firmware releases. This ensures the consistency and verifiability between the committed source code and the final signed firmware binaries. This verifiable build process is a standard procedure for our hardware wallet line to ensure transparency and security.

We believe this addresses the checkgoodtransparencydeterministic criteria. Please let us know if you require any further information.

Thank you again for your guidance.

[crwatkins]

We have worked with our third-party security partner, SlowMist, to update the audit report. This report now includes a detailed section on our reproducible build process, which should address your concerns.

Could you provide a reference to that detailed section? I wasn't able to find it in the referenced audit report.

[yikZero]

Hi @crwatkins ,

My apologies for the oversight. I should have pointed you directly to the relevant section in my previous message.

You can find the details on our reproducible build process on page 6 of the report, at the very end of section 3.1 Project Introduction.

Thank you for your patience, and please let us know if there is anything else we can provide.

[crwatkins]

We have worked with our third-party security partner, SlowMist, to update the audit report. This report now includes a detailed section on our reproducible build process, which should address your concerns.

I'm sorry, I'm still having trouble finding a "detailed section on our reproducable build process". All I see are two sentences in a note. Is that what you are referring to?

What is looked for here are detailed instructions that anyone in the community can follow to produce the released build anytime, and for any releases. The good folks at Wallet Scrutiny such as @Giszmo often perform such builds for the community and do a great job recording the results. There seems to be an open issue that you might want to help them with. They seem to be pretty close, so hopefully there will be an easy solution.

[yikZero]

Hi @crwatkins ,

Thank you again for your patience and valuable guidance.

Following your suggestion, we have been in touch with the team at Wallet Scrutiny. We provided them with the necessary information, and we're happy to report that they have now successfully verified our build.

You can view the verification results directly on their website:
https://walletscrutiny.com/hardware/onekey.pro/#verificationId=0b63f9f88dd497a09d1784f5a1c86a0fdafd7735ab7a12a323b8d9154a85a677

We believe this provides the clear, community-verifiable proof of our reproducible build process that you were looking for. We appreciate your help in pushing us to improve our transparency.

Please let us know if you have any other questions.

[crwatkins]

That looks great. Thanks!

Was the OneKey Classic also verified?

[yikZero]

@crwatkins Yeah, OneKey Classic also verified.

You can view the verification results on their website:
https://walletscrutiny.com/hardware/onekey.classic.1s/#verificationId=76252345ad4278aa8d51fc6e94f67db75c74d179797df6ca5ea923b3ae9c9dba

[crwatkins]

I'm glad you were able to verify those builds!

The OneKey app appears to reuse Bitcoin addresses. Is that correct?

[yikZero]

@crwatkins

Thank you for your feedback.

You are correct, our app does currently reuse Bitcoin addresses. This approach was implemented for several reasons: to ensure compatibility for users of our previous versions, to accommodate those familiar with an account-based model, and to prevent users from mistakenly thinking funds are lost when sent to a new change address.

To enhance user privacy and security, we are developing a new feature. In a future update, we will add a switch in the "Settings" that will allow users to choose whether to use a new address for each transaction.

[Giszmo]

Address reuse is a severe anti-pattern I wish more people would understand for what it is. It threatens directly Bitcoin's fungibility for everybody even if a user is fine with all his past and future spendings being linked for all his trading partners to see. That's not a minor one.

[crwatkins]

The listing criteria include

• Avoid address reuse by displaying a new receiving address for each transaction in the wallet UI
• Avoid address reuse by using a new change address for each transaction

While technically, hardware wallets don't control the selection of receiving addresses (the companion app does) and historically these criteria have not been applied to hardware wallets (since hardware wallets are reviewed independent of the companion app), all of the hardware wallets that are currently listed either do not have a companion app (and primarily work with apps that do not reuse addresses, e.g. Coldcard) or have a companion app which does not reuse addresses. Since the OneKey companion app reuses addresses, recommending OneKey hardware would be somewhat similar to recommending address reuse.

You may want to review Bitcoin wiki address reuse. OneKey address reuse not only damages the security and the privacy of its users, but it also damages the privacy of the entire community. It is concerning that any wallet would be doing this in 2025 as there have been no wallets listed that reuse address for about ten years. Advances in quantum computing have caused recent increased interest in development of quantum resistant algorithms for Bitcoin. Reused addresses create some of the most vulnerable funds to quantum attacks and this is reasonably easy to avoid.

For these reasons, I highly recommend proceeding quickly with a mandatory feature to provide new addresses for each transaction.

[yikZero]

Hi @crwatkins,

Thank you for the valuable feedback. We acknowledge the seriousness of the address reuse issue you and @Giszmo have pointed out.

We are pleased to inform you that we have prioritized this and plan to release a fix in Q4. This update will add a new setting, allowing users to enable fresh addresses for each transaction.

To avoid disrupting the experience for our long-time users, this feature will be an opt-in toggle initially. We understand the ideal is for this to be the default, and we will consider making that change in the future once our user base has adapted to the new option.

We appreciate your patience and guidance. We believe this plan is a solid step in the right direction. Let us know what you think.

[crwatkins]

I appreciate your understanding. Note that wallets are evaluated and scored based on default behavior. New addresses should be available automatically.

You might also want to consider a suggestion to your existing users to perform a onetime transaction to move their existing funds off of reused addresses.

[yikZero]

Hi @crwatkins,

Following up on our discussion regarding the BTC address reuse issue.

We are pleased to inform you that we have added support for fresh BTC addresses in our latest release, v5.16.0.

Critically, based on your feedback that this needed to be the default behavior, this new feature is enabled by default.

As noted in the official release notes:

Change and receiving addresses in BTC now use fresh addresses by default for enhanced security.

You can find the full release notes here: https://github.com/OneKeyHQ/app-monorepo/releases/tag/v5.16.0

Thank you again for your valuable feedback and guidance on this. Please let us know if there is anything else we can assist you with.

[crwatkins]

That's great news for your users! Thanks for the new release.

[yikZero]

Hi @crwatkins,

Just gently checking in. Please let us know if there's anything else you need from our side for the merge.

Thanks!

[Cobra-Bitcoin]

There was an issue with our build server. If you push another commit it will trigger a build and then the tests can run which will speed up a merge.