Choosing the right chain: additional functions, future development, and other factors
We have now managed to dig through the most technical stuff of blockchain selection. Let’s now, step by step move a into softer areas of blockchain evaluation.
A blockchain in essence provides a secure layer of transactions. Smart contracts are right now a necessary addition, and we don’t even think that this one could be missing.
But there is more. A chain could offer additional services such as:
- Identity solutions
- On-chain storage solutions
- Fiat on/off-board ramps
- Indexing services
- Randomness generators
- Governance solution
Many of these are chain agnostic meaning they can be provided by third parties but having a native solution at hand provides additional benefits in regard to easy implementation because it’s supported natively, better optimization and the fact that it avoids situations when a third-party service is down while the blockchain and the app is operational. Another factor to consider is cots as native solutions will usually cost less.
Some project may or may not need all or even any of these applications so decision will be highly personalized to the project.
For us an DID solution will be important, and a native solution would be preferred.
A distributed storage is always beneficial, just think about NFTs. You can not store an image or a video directly on a chain. You need a storage solution for this.
If there is native support for fiat onboarding and offloading this is a huge advantage as we will be targeting new users, not 100% familiar with blockchain. Easy entry in the crypto world is highly valued.
Every project needs real world data. It can be as simple as the current time or a price of an asset. Without oracles it is impossible for a project to know this data. The oracle to go to is of course Chainlink and that is one of the integrations that’s preferred but having a native oracle is beneficial, even if it only serves as a backup.
Indexing services like graph simplify development.
Wallets are important and each chain should have one. In the case of EVM there are many wallets available and compatible with every EVM chain and token.
Randomness generators are something only hardcore developers think of, but do you know that one of the core safety mechanisms for developing a consensus mechanism is providing true randomization of leader node selection? Not so easy.
Bridges are gateway into the multichain universe. Good bridges to other blockchains are important for tapping into liquidity and interoperability. What to look in bridges? Flexibility in flexibility or trustlessly adding new types of tokens, finality times and custody risks.
Privacy might be a deal breaker for some projects seeking regulations. On the other hand, some projects look for this specific feature as their main functionality of a chain.
Having a working governance solution would be a good feature for what we are trying to build as we do want to have decentralized governance and we do think token holders should have a saying.
Stage of development
This is a tough decision to make. On one hand one would prefer to go with a fully developed chain, evolved, proven to work, with a huge ecosystem of dApps and a big community. And on the other side there are new chains with great ideas, innovative, full of potential, but without developed ecosystem, big community, liquidity, and the security it comes with it.
It is far easier to get official support from younger chains, usually they are faster and with cheaper transactions, and they tend to make more progress in a shorter amount of time. But they will have less infrastructure like a working DEX or an NFT marketplace and less TVL (Total Value Locked).
With the pace of the current market, only a few months can make a huge difference for a young chain. In either direction. So, there is always the risk against the reward.
It is easier to stand out as a project within a smaller ecosystem and that can mean a lot for the marketing and promotion of a new project.
When selecting a younger chain, a thorough DD needs to be conducted in regard to:
- Team behind it
There needs to be an improvement in the underlaying blockchain functionalities in comparison to the more developed chains. The roadmap needs to be mapped out clearly and needs to be reasonable. Past achievements and milestones should tell the story of future developments. Also, a in depth research should be conducted on current projects already live or building on the chain.
Possibilities of collaborations and partnership in young ecosystems is far greater than in old ones.
Exit strategies should be in place in the case of catastrophic failure of a chain. We are leaned more going with a younger chain (we would not be building on Ethereum main layer right now because of the congestion) so EVM compatibility allows for an easy switch if the case it is really needed.
This can be another thing of concern. Let’s get the terminology right. The native token of a blockchain is called coin. So BTC, ETH, ADA, SOL are all coins as they are native to the blockchain. Tokens issued on one of these chains are called … tokens. So USDT, AXS, CAKE, UNI are tokens as they are representing a transactional value issued by a project.
Some say that tokens are mostly considered second-class citizens as they are just a smart contract and are handled differently than the native coin. Did you notice that transferring ETH is cheaper than any other ERC20 token? It’s not intentional but it is because of the additional processing power required to process the smart contract.
Some chains, like Cardano have built in native support for their tokens. On Cardano tokens are not based on smart contracts but have native functionalities and although some would argue that they are treated the same that is not 100% true. If you want to send any token on Cardano it needs to be accompanied by at least 1 ADA. This is not the transaction fee it is just a requirement to provide additional safety. The same goes for NFTs. They have native support but on the other hand they don’t have all the smart contract functionalities that make them programmable. So this could be something that you look for or something that you will try to avoid.
Paying for fees
Mostly blockchains require paying fees with the native coin. For instance, if you want to transfer your ERC20 token you will need to pay fees with ETH. There are not many things as annoying as finding a good deal, but your transaction failing because you don’t have the native currency to fund the transaction fee.
Some project, like Cardano, are working on providing systems that would allow paying fees in your own token. The Cardano system is called babel fees and it includes validators being willing to provide their own native currency for an additional fee paid in the token.
Currently the business world is all about the ESG narrative and it is also mixing things up in the blockchain space as we have seen with Tesla pulling out of BTC payment stating energy (in)efficiency as the reason. So, this does matter.
Without going into any political discussions, we do think we should minimize energy consumption where it is possible, and we think PoS is provably secure without the unnecessary calculations of PoW that consumes energy.