Wallet Logo

Bitcan Bitcoin Wallet - USDT ETH BCH TRON

latest release: 1.3 last analysed  20th January 2021
Custodial: The provider holds the coins
4.1 ★★★★★
69 ratings


Our last analysis is based on data found in their Play Store description .
details below 

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

This wallet imitates Bitpie Wallet. It’s appId being jb.tech.bitpiewallet was the first hint but there are many more similarities. The description for example was also copied.

The provider has no website, so that’s certainly also suspicious.

Nevertheless they claim:

As a true decentralized wallet, your private key will never leave the device.

and unless we can proof that this is not the case, we will have to list it as merely “no source”? We had a look at their app for smoking guns, cause reviews like:


Awful!! I sent $800 btc to Bitcan wallet and the money NEVER showed up! I copied Receive before I sent……then, after Receive is different and btc not found!!! Scam ‼️

Fake app, you coins get deposited to someone else’s wallet. DO NOT USE!

but that might just be haters, right? After all there is many 5 star ratings, too, like this one:

Wow this is great just after sending my deposit 15Btc it appeared immediately even before confirm.

which sounds like the fake reviewers are not even trying to look serious. WTH?

We downloaded the apk and threw it at jadx and and there, we went straight for the receive screen. jb.tech.bitpiewallet.Receive should be it, right? There in onCreate, the starting point of the Activity/screen, getWallet() is called. Here it is:

public void getWallet() {
  try {
    FirebaseDatabase.getInstance().getReference("Users").child(uid).addListenerForSingleValueEvent(new ValueEventListener() {
      /* class p009jb.tech.bitpiewallet.Receive.C13267 */

      @Override // com.google.firebase.database.ValueEventListener
      public void onCancelled(DatabaseError databaseError) {

      @Override // com.google.firebase.database.ValueEventListener
      public void onDataChange(DataSnapshot dataSnapshot) {
        Receive.walletid = (String) dataSnapshot.child("WalletId").getValue(String.class);
        Receive.walletname = (String) dataSnapshot.child("WalletName").getValue(String.class);
        TextView textView = Receive.this.tv48waltname;
        textView.setText(Receive.walletname + " Receiving Addresses");
        TextView textView2 = Receive.this.tv46name;
        textView2.setText("My " + Receive.walletname + " Addresses");
        FirebaseDatabase.getInstance().getReference("Wallets").child(Receive.walletid).addListenerForSingleValueEvent(new ValueEventListener() {
          /* class p009jb.tech.bitpiewallet.Receive.C13267.C13271 */

          @Override // com.google.firebase.database.ValueEventListener
          public void onCancelled(DatabaseError databaseError) {

          @Override // com.google.firebase.database.ValueEventListener
          public void onDataChange(DataSnapshot dataSnapshot) {
            Receive.walletaddress = (String) dataSnapshot.child("Address").getValue(String.class);
            Receive.walletqr = (String) dataSnapshot.child("QrCode").getValue(String.class);
  } catch (Exception unused) {

In the third line it calls FirebaseDatabase which according to the Firebase documentation is:

Store and sync data with our NoSQL cloud database.

So if the private keys never leave the device, why would the Receive Activity have to ask a cloud database for the receive address?

Without creating a new category very obvious obvious scam we file it as custodial (The “provider” holds the coins), assuming it’s prompt removal but either way it’s certainly not verifiable.


Verdict Explained

Custodial: The provider holds the coins

As the provider of this app holds the users coins, verifiability of the app is not relevant to the security of the funds!

This verdict means that the app might or might not publish source code and maybe it is even possible to reproduce the build from the source code but as it is custodial, the provider already has exclusive control over the funds, so it is not a wallet where you would be in sole control of your funds.

Custodial wallets might not be the worst option for all users.

  • Do your own research if the provider is trust-worthy.
  • Do you know at least enough about them so you can sue them when you have to?
  • Is the provider under a jurisdiction that will allow them to release your funds when you need them?
  • Is the provider taking security measures proportional to the amount of funds secured? If they have a million users and don't use cold storage, that hot wallet is a million times more valuable for hackers to attack. A million times more effort will be taken by hackers to infiltrate their security systems. Will they detect when for some software error a hacker is spending other people's money before the losses are unrecoverable?

The app 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 app 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.