A question of building:
The other day I was speaking to an enterprising founder trying to create new insurance liquidity for an underserved market using what I would label capital market principles supported by digital assets. Not too esoteric(!), except the conversation took a turn when he asked my opinion on which blockchain his team should build this solution. I only had half-formed views on this matter and could only provide a few pointers. I decided to research this to give a clearer answer to him and the other founders who might one day ask me this question again.
Framework for L1/l2 blockchain selection:
What has resulted from the research is a framework that founders may be used to evaluate L1/L2 blockchains to develop their fintech/insurtech solutions. The framework could be converted to a decision-making framework on a spreadsheet for those inclined.
If you are building a fintech or an insurtech company on the blockchain, there are several considerations to take into account before selecting the appropriate layer one or layer 2 (L1 /L2) protocols to build on:
Whitepaper and Clarity of purpose: Read the whitepaper for the blockchain. The questions to find answers to:
- Is it clear in its aims and objectives?
- What are the foundational design elements?
- Why does it exist?
- Who are the founding team?
- Are the token economics clear and not concentrated among a few users or groups?
- Look for investor ownership of tokens and see if power is held by a few investors or founders?
Research on the team:
This can be achieved by a social media scan. Go on twitter spaces, join Telegram groups, lurk in the relevant subReddits and Discord channels where they communicate with their followers. Get a sense of their purpose and aim. Are they all about making money, or are they interested in solving big problems using their blockchain?
Scalability requirement:
The L1 / L2 protocol should be able to handle many transactions per second. Depending on your use case, you may need to process many transactions (payments are an example). Ethereum can handle around 10 to 15 transactions per second, which is not great for high throughput use cases. Key questions to ask are the time to finalize a block and block creation time. Both should be optimum for your use case. For a payments use case where you may expect thousands of transactions per second, the Bitcoin blockchain is not ideal as the block creation time is around 10mins at the time of writing (Jan 2023)
Security:
The L1 protocol should have a strong track record and resist hacks and other vulnerabilities. For security, the blockchain architecture must respect the blockchain trilemma (more on this here>>). In short, no blockchain can achieve a 100% of decentralization, scalability, and security at the same time. Compromises must be made on one dimension. Solana famously compromised in favor of being fast and scalable. Critics are that because of less decentralization has lead to hacks, price fluctuations, and fraud (SBF managed to exert a disproportionate influence on Solana).
Ecosystem:
The L1/L2 protocol should have a thriving ecosystem of developers and users, as this can make it easier to find resources and support for your startup. The easier it is to find developers, the cheaper and quicker it is to build out your Startup- easy as that. Another trick is to see if your blockchain uses standard languages such as Solidity, Viper, and Rust for creating dApps and smart contracts. There is a decently large developer base for Solidity, for example. For the front end, it is usually a Web 2 language like Javascript that will do.
Feature Roadmap:
A blockchain is not a static bit of code but can evolve and change to become better in time. The Ethereum foundation has a detailed roadmap to make the blockchain much greener and faster, and cheaper in the future. Study the roadmap and see if there is a well-defined future list of changes; how are changes picked and voted on? Will the founder team stay committed to building? Are there enough builders? Ask how the governance works.
Integration with existing systems or Defi platforms:
The L1 protocol should be able to integrate with your current systems and processes, as it may be difficult to migrate fully to a new platform. This is more relevant if you have already built out solutions that you would like to reuse or if you have access to open-source modules that you plan to use for your startup (mostly the case).
Remember, blockchains are all about composability and interoperability. If your startup needs to use Uniswap or DyDx for its operations, your target blockchain better give you access to those platforms. No point replicating an existing block (my way of saying - don't reinvent the wheel!).
Costs:
The L1 / L2 protocol should have reasonable costs associated with using it, including transaction fees and other costs. Transactions on the chain can be expensive, like on Ethereum, or cheap, like on Polygon, at the moment. While this may change as new changes and product improvements are rolled out, it is good to know how much you have to pay to operate your system. Essentially your fintech or insuretch will operate as one or a series of smart contracts which will need to "pay" for using the blockchain.
Regulation:
The L1 protocol should comply with relevant regulations and be accepted by regulatory authorities as a legitimate platform for conducting insurance business. If you are in the UK, then the FCA's and the PRA's position on the blockchain is important to understand. If in the US, the SEC has an outsized handle on all crypto. In the UAE, the VARA, FSRA, and DFSA have differing levels and depths of regulations on crypto. Read up on existing legal cases, rulings, past fines, etc.
Community quotient:
Aim for forward-looking, vibrant, and a good combination of future seekers, speculators, developers, entrepreneurs, and investors. If it is only filled with "shillers" and maximalists, then be ready for pump-and-dump schemes that will possibly discredit the blockchain. The community that follows and tweets about and lurks in their Discord channels is super important to understand. You can know more by getting into the Telegram groups and Discord channels and listening and reading. You will get a sense very quickly.
Example evaluation: Polygon
Let us quickly evaluate Polygon on this basis. Polygon (formerly known as Matic Network) is a layer 1 (L1) protocol designed for use with the Ethereum blockchain as a settlement layer. Here is how Polygon stacks up against the criteria for selecting an L1 protocol for building an insurance company on the blockchain:
Community Quotient: Polygon has a pretty decent community with a vibrant mix of users, investors and builders (BUIDLERs).
Whitepaper: The whitepaper is of a fairly high quality and lays out the use cases and aspirations in a clear and concise manner.
Scalability:
Polygon claims to have significantly higher scalability than Ethereum, with the ability to process up to 65,000 transactions per second. This makes it a strong contender for insurance companies that need to process a large volume of transactions.
Security:
Polygon has a strong track record, with no significant hacks or vulnerabilities reported. However, it is essential to note that no blockchain is completely immune to security risks. It is always essential to take appropriate precautions to protect your assets. Other authors have pointed out issues with the bridging architecture and optimistic consensus approach. Still, so far it has not resulted in issues.
Ecosystem:
Polygon has a thriving ecosystem of developers and users, with several decentralized finance (DeFi) applications and other projects built on the platform. This can make it easier to find resources and support for your project.
Integration with existing systems:
Polygon is built on the Ethereum blockchain, which is compatible with many existing Ethereum-based systems and processes. Integrating your startup's code with current systems and processes can make it easier.
Costs:
Polygon has relatively low transaction fees compared to other protocols, making it an attractive option for insurance companies that need to process large transactions.
Regulation:
Polygon is a relatively new protocol and may not be widely accepted by regulatory authorities as a legitimate platform for conducting financial services business.
Result:
Polygon is a strong contender for building a fintech or insurtech solution on the blockchain due to its high scalability, robust security track record, and relatively low costs.This is a point-in-time evaluation, which would need to be repeated periodically.
And finally, Portability:
Another criterion to consider is portability. I recommend that founders keep an approach ready to enable code migration to an alternate blockchain should the current chain fall short due to a newly discovered issue, such as a security flaw in the underlying architecture.
This article was previously published on my blog: https://www.renjitphilip.com