Different Kinds of dApps You Can Create

Another question developers are asking me all the time is, what kind of dApp should I build? What is the difference between custodial, non-custodial, or hybrid applications? What is the best for me? Will this approach win the market? I will go through these concepts one by one, and I will try to describe the upsides and pitfalls.

The main difference between the apps in the blockchain world is obvious - who is managing the wallets. Or, in other words - who owns the private keys to the assets on the blockchain and can manipulate them.

Non-custodial (fully decentralized) application

With non-custodial applications, you are the owner of the wallet. Only you own the private key and can manipulate the assets on the network. You are responsible for securing the private key in a way that you will not lose it, expose it to a 3rd party, or copy-paste it to the browser when some hacker wants to steal your funds.

When you want to build this kind of dApp, you need to take this aspect into consideration very seriously. You should build the UI in a way that users can connect their existing wallets, like MetaMask or TrustWallet, seamlessly to your app. You don't need to create any sign-up / sign-in pages - you use their wallet address as a unique identifier of them.

Once users join your dApp, in a decentralized world, you should be able to fetch the whole history of the address - you never know who is joining your system, if the user was already present and you have some data cached or not - you must always be able to get all the details of that specific address you need.

If you want to build a new decentralized wallet and not use existing ones, the main thing is to generate the private key on the client and sign transactions with the private key on the client. You can't generate the wallets on the server and send the private key via the internet - ❗❗❗they are compromised by default❗❗❗. The same applies to signing the transactions - you don't want to send a private key from the client to the server or blockchain RPC node to sign the transaction there - the key is compromised.

Finally, the onboarding of new users is pretty hard with this approach. Not all of the people out there understand the blockchain concepts, have installed a crypto wallet, or can buy some cryptocurrencies to be able to operate. This is a huge problem these days because the target audience you might reach easily is not that big so far.

Custodial (fully centralized) application

You can think about some well-known crypto exchanges like Binance or Coinbase. These are the best examples of custodial or fully centralized applications. In this setup, the provider of the application is the owner of the wallet. The provider manages the access to the funds on the blockchain address, creates the addresses for the users, and allows or forbids the withdrawals of the assets outside of their application.

The beauty of this setup is that it is a well-known architecture that is proven to work in the Web 2.0 world. You are doing sign up/in using email or social login (create a wallet). The wallet on the blockchain exists from the second the user exists in your application - you can see the whole history of all actions that the user performed from day one. You don't need to take care of the security of the private keys on the client devices or deal with cross-device compatibility issues (mobile wallet can sign some type of transactions on some blockchains due to lack of tooling and SDK for that specific language, etc.), or in terms of breaking the law. You can pause or halt the manipulation of the assets for a specific user.

On the other side, the downside of this approach is trust. You might be hacked, and the hacker will steal all the money from all your customers. Also, you might close the business and run away with money - known as rug pull -, but I believe that's not your case.😈😈😈

Hybrid (partially-centralized) application

There must be some middle ground between these 2 extremes. There always is. In a hybrid world, you are leveraging concepts of both worlds. Usually, you are starting with the custodial approach for the simplicity of onboarding your users and better control, but you are plugging external wallets into your system as well. You can effectively leverage both worlds, especially for onboarding and initial GTM. Once your users are more crypto savvy and will be able to create a wallet by themselves and take care of the private keys securely, you can step by step, migrate them to the non-custodial approach and shut down the custodial part. This is a slower, more time-consuming approach, but if you want to make your users blockchain power users, this is the way to go.

Summary

There are, of course, more ways how to split each of the categories further. You might have solutions like MPC wallets, where part of the keys holds the user, part of some external trusted party, and many more. But this overview should give you all the necessary inputs when you are considering launching your first dApp. Happy coding.