Wallet Logo

HyperMate G

Latest release: 4.1.7 ( 22nd September 2021 ) 🔍 Last analysed 12th December 2021 . No source for current release found
13th April 2020

Jump to verdict 

Help spread awareness for build reproducibility

Please help us spread the word discussing transparency with HyperMate G  via their Twitter!

Do your own research!

Try out searching for "lost bitcoins", "stole my money" or "scammers" together with the wallet's name, even if you think the wallet is generally trustworthy. For all the bigger wallets you will find accusations. Make sure you understand why they were made and if you are comfortable with the provider's reaction.

If you find something we should include, you can create an issue or edit this analysis yourself and create a merge request for your changes.

The Analysis 

HyperMate G is about the size of a credit card and has buttons and a screen. These help the user to verify and confirm transactions. The wallet can connect via Bluetooth.

(Unboxing video featuring the product.)

Private keys can be created offline and are not shared

HyperMate wallet will NOT enable Bluetooth or USB connection before the wallet initialization process is completed in order to guarantee that the initialization process is completely conducted in an offline environment.

After setting up the hardware wallet, you can create a wallet and set a PIN. Afterwards, you are provided with the 12/24-word mnemonic.

Device displays receive address for confirmation

The official help center states that this is possible.

Receiving payments can be done offline without connecting your HyperMate mobile application. Press “up” and “OK” together to enter the menu and select “My Address” and mainnet to find your receive address, and you can press “down” to display the QR code of your address.

It also shows a picture of the receive address on this wallet’s screen.

## Code and Reproducibility

On their website they link to a GitHub account that also features a repository called hardwallet but it’s not clear what to make of this. There are no clear build instructions and neither is there any version tagged. According to their official Twitter the latest version is 4.1.7 from 2021-09-22 but their repository has no such tag. In fact it has no tags at all.

The commit history is also rather curious. 14 commits with the last commit half a year before the latest release 4.1.7. That last commit adds the folder HardWalletSDK to the project. GitHub describes the commit:

773 changed files with 116,778 additions and 0 deletions

The content of that folder is actually the “SDK” of JuBiter Blade No Source! : JubiterWallet/JubiterSDK_C

With the missing build instructions but above all missing commits leading up to the latest release, we find this product to be not verifiable.

(ml, dg, lw)

Verdict Explained

Without public source of the reviewed release available, this product cannot be verified!

As part of our Methodology, we ask:

No Source!

Is the source code publicly available?

If the answer is "no", we mark it as "No source for current release found".

A wallet that claims to not give the provider the means to steal the users’ funds might actually be lying. In the spirit of “Don’t trust - verify!” you don’t want to take the provider at his word, but trust that people hunting for fame and bug bounties could actually find flaws and back-doors in the wallet so the provider doesn’t dare to put these in.

Back-doors and flaws are frequently found in closed source products but some remain hidden for years. And even in open source security software there might be catastrophic flaws undiscovered for years.

An evil wallet provider would certainly prefer not to publish the code, as hiding it makes audits orders of magnitude harder.

For your security, you thus want the code to be available for review.

If the wallet provider doesn’t share up to date code, our analysis stops there as the wallet could steal your funds at any time, and there is no protection except the provider’s word.

“Up to date” strictly means that any instance of the product being updated without the source code being updated counts as closed source. This puts the burden on the provider to always first release the source code before releasing the product’s update. This paragraph is a clarification to our rules following a little poll.

We are not concerned about the license as long as it allows us to perform our analysis. For a security audit, it is not necessary that the provider allows others to use their code for a competing wallet. You should still prefer actual open source licenses as a competing wallet won’t use the code without giving it careful scrutiny.

The product cannot be independently verified. If the provider puts your funds at risk on purpose or by accident, you will probably not know about the issue before people start losing money. If the provider is more criminally inclined he might have collected all the backups of all the wallets, ready to be emptied at the press of a button. The product might have a formidable track record but out of distress or change in management turns out to be evil from some point on, with nobody outside ever knowing before it is too late.