Deep dive into decentralized applications

Decentralized, or non-custodial applications, are the type of apps where no one except the end user - owner of the wallet - can perform any actions with the blockchain assets on their wallets. Today, I want to explain 3 types of decentralized apps you can build and launch. So, let's go. 🚀🚀🚀

Three types of decentralized apps you can build

There are plenty of use cases for fully decentralized apps. I can see three main categories to which all of them belong.

1. Smart contract DeFI dApp

2. Creation of the new dApp wallet from scratch

3. Integrating existing wallet into your dApp

What kind of detailed use case you choose for your category, it's up to you. I will go and describe each one in detail.

Smart contract DeFi dApp

This type of dApp is one of the most complex ones you can think of. You must be a skilled, smart contract developer because what you are about to build is a suite of interconnected smart contracts, which is super complex to build, test and maintain.

What to build is endless. You can create a new DeFi swap platform like UniSwap, a liquidity protocol like Aave, or a complex NFT on-chain marketplace. The biggest problems here you might face are:

1. The complexity of the smart contracts - you must test, test, test, and again, test everything before your launch

2. Mitigate as many known on-chain attacks as possible. There is plenty of known vectors you can test and foresee. A nice source is this GitHub page.

3. Optimize your gas consumption. The operations you are performing on the smart contract cost your users money. Try to have them as lean as possible - less complex operations, less gas they need to pay to cover the transaction costs.

4. Once you deploy your smart contracts to the blockchain, you cant fix any bug you will find out later on. You have a couple of options for how to mitigate this scenario - deploy your contracts with a special Upgradeable Proxy pattern or just release a new version and don't use the previous one.

5. Last but not least, you must know what you are doing. Really. Don't try to deploy some forked stuff from GitHub, random code you have found somewhere, or put together pieces of generated code from ChatGPT that you don't understand. There is real money at stake here.

6. Open source your code base. Every smart contract you are deploying - open source it on GitHub, verify it on Etherscan and be as transparent as possible. It's worth it.

Building a new wallet-like functionality from scratch

If the dApp you want to build requires onboarding of the users without any blockchain wallet from the past, or you simply need to manage their wallets and operations in your dApp, you need to build the wallet logic by yourself. Key things you should focus on are:

1. Handle wallets and corresponding private keys locally on the device of the customer. Never generate private keys on the external server or via API, never send private keys over the internet, and never share them with any 3rd party.

2. All operations requiring private keys must be done on the device of the customer locally. It means exporting the wallet and signing transactions that the client wants to send.

3. Depending on the target platform, whether it is a browser, mobile, or desktop, the size of the dApp matters. Especially in the browser world, you don't want your app to load in 10 seconds because you have 20 MB of blockchain dependencies included in your code. It's much easier to leverage the unified SDK that can cover as much complexity for you as possible. More about this topic here.

4. It's a good practice to open source your code base, especially those parts which are handling wallet management. Your customers may check by themselves that you are not doing any harmful operations and you are trustworthy.

5. Expose API to your solution. Integration of others is a crucial thing in the blockchain space. If you are building a wallet, someone else would love to plug in your users from your wallet into their application.

Integrating existing 3rd party wallet

When you don't want to build your own wallet management solution as described above, your dApp should leverage some external wallets out there. You are then a consumer of the APIs of the wallet you are integrating. The architecture of your app is pretty straightforward:

1. During sign in - you need to call the API of the wallet you are integrating to verify that the user has the address and obtain it

2. Get a balance of the address or history of transactions of the address using 3rd party service or unified blockchain SDK

3. For sending the transaction, you should prepare the payload of the transaction by yourself - again, some helper functions from the SDK might be useful - and call the API of the wallet to sign it with the private key. The wallet is usually broadcasting the signed transaction to the blockchain as well - you don't have to deal with this.

The benefits of this approach are obvious - you don't need to handle the complexity of managing the private keys, securing the infrastructure around it, and keeping up to date with the protocol integrations and changes. There are obvious downsides as well - you are redirecting your customers to another application, where you might lose them.

Summary

It really depends on you and your requirements which approach you will select. I am about to prepare detailed posts about each of the categories with architecture details and some best practices from the coding perspective, so stay tuned.