Ten things you should consider when Building a Blockchain Solution

Image Credits: Pete Linforth

What to Decentralize?

When building a blockchain solution, the most important part is to figure out what part of the solution we want to decentralize and why. What part of the data or state needs to be agreed upon by different parties?

On-chain and Off-chain data

Not all the data and logic belong on the chain. Blockchains are not built to store all the data. They are there to help reach an agreement on the state of data.

Blockchain is NOT a database, it’s a verification machine.

Where does the decentralized logic live?

Depending on what you figure out in the above, you should consider whether you want to deploy smart contracts on a permission-less network, or you want to build your chain. Generally, until you find out a product-market fit, the former is better and gets you faster to market.


How does your blockchain logic evolve and who are the key stakeholders? How do you want to make sure that the voice of all participating parties is heard fairly?

Identity and Key Management

In general, in enterprise systems, users have corporate credentials for authorization. For logic and data on-chain, users have to send signed transactions. It is essential to figure out how you want to connect on-chain and off-chain identities.

Integration with Enterprise Systems

How do you want to integrate your off-chain data and logic with your on-chain data and logic? Efficiently listening to and acting on blockchain events, batching transactions, callback transactions, etc. are all part of this.


If you are using a permission-less network that does not inherently provide privacy features, and if your use-case requires on-chain data privacy, you should think even harder on the first two points in this thread. In addition, think about how you want to protect the on-chain data and only showing it to the relevant parties. Encryption, ZKPs, trusted enclaves, etc. can be considered, depending on the use case.

Gas and Transaction Fee

When using a permission-less network for your blockchain business logic, you need to consider how you should optimize and delegate the payment of transaction fees. Should the user pay for it directly or should the platform encapsulate the fees?

Iterative Development Practices

Once deployed, smart contracts cannot be changed or updated. You can deploy new ones, but that could require data migration and user account/keys migration. It is extremely critical that you plan your enterprise system’s (in-general) agile development with your smart contracts’ development and iterations.

What if something goes wrong?

Sometimes, we have to roll things back when they don’t go as intended. In multi-user and multi-process workflows and on high load, this can happen unsurprisingly. Blockchains generally do not allow the deletion of data. So, how do you handle this? Think about compensation transactions in your smart contracts. As far as all involved parties agree, we should be good.

First published as a tweet thread here — https://twitter.com/gautamdhameja/status/1406658800979951621.

Blockchain, DLT, Solution Architecture, Decentralized Systems
comments powered by Disqus