Three things to consider when choosing a blockchain for your project — or why Veris chose NEO.

Last spring we began evaluating the feasibility of placing the American healthcare claims process on a blockchain. The only thing we were certain after determining that the process would benefit from blockchain was that it did not make sense for us to build a new chain when at least a dozen public blockchains were available. The question we did have was ‘What chain best fits this our use case?’

We considered five of the most prominent blockchains as part of our process :

We then determined three key criteria to use in evaluating the fit of these existing chains to our use case. Many current crypto projects are based around creating new ‘trust-less’ ecosystems separate from their traditional equivalents. This is unlike our application which is a specific use case of blockchain technology inserted into an existing ecosystem. Your needs may change based on your specific use case, but in our case we felt the three criteria most important to the creation of a successful blockchain application were:

• Technical Capability
• Governance
• Community

Technical Capability

We were quickly able to eliminate the chains (IOTA and Cryptonote) which did not currently include smart contract functionality. Though Bitcoin does offer smart contract functionality with the RootStock add-on, we determined that the risk attached to a second party developing smart contract functionality for a chain that did not have this capability as core functionality was too high. Thus we eliminated Bitcoin.

This left us Ethereum and NEO. To be frank, we expected to land on Ethereum as our choice in this category. Ethereum’s value proposition is based on smart contracts, the chain is the most functional chain ever created in terms of efficiency and transactions per day, and Solidity attempts to simplify the language of smart contracts. At the time NEO had the label as a ‘Chinese Ethereum’ and we did not see the need for a clone. While they are both blockchains that support smart contracts, there are two fundamental technical differences between Ethereum and NEO that led us to prefer NEO.

• Bookkeeping Nodes — NEO allows the use of bookkeeping nodes for authority and consensus on the network. While one can argue that the centralization of these functions is counter to the purpose of blockchain, we feel it is critical to the success of our product. These nodes become the gatekeeper between those who are holding our coins, and those who are creating insurance contracts on the chain. For the latter, being able to validate that they are in fact who they say they are is critical. We can not have John Smith impersonating Aetna on our platform.
• Splitting Network Fees from Coins — It is important that users of our platform hold a number of coins relatively commensurate with their use of the platform. NEO’s use of GAS to pay for network fees enables this for us. Additionally, if we were to deploy our platform using Ethereum, usage of the network could degrade stake in the network at points in time. For example, if a stakeholder has 100 ETH, and needs to execute many smart contracts, they may reduce their holdings to 50 ETH at a point in time after all transactions have bee executed. This essentially creates scenarios from a governance perspective where use of the chain dilutes the weight of a stakeholders vote on the chain. NEO resolves this problem.

Governance

Our solution fits into the existing American healthcare system. A system which is fragmented, and has the possibility of undergoing significant regulatory changes in short periods of time. Look no further than the discussion around the Affordable Care Act to see that building a decentralized solution to this problem requires a strong governance mechanism. We need to be able to develop a platform that allows for software changes in a timely, and orderly fashion. We also need these changes to be voted upon by the stakeholders of the chain — as the stakeholders in this process have conflicting needs at times.

Bitcoin handles this through a UACOMMENT function on the client miners are using to signal support for software updates. As demonstrated by the speculation around prospective Bitcoin forks over the past year, this method is not particularly effective.

Ethereum utilizes the Ethereum Foundation to manage this process — though it is important to note that there is no signalling/voting mechanism in place similar to Bitcoin.

Ultimately, we determined that none of the existing solutions adequately meet our governance needs. What we do feel is that the NEO design of splitting coins from network fees is a foundation on which we can develop a voting system to handle governance. Interestingly enough, one of the chains developed to specifically address blockchain governance, Tezos, has experienced some of the worst governance problems in the blockchain space.

Community

When we use the term community we are essentially evaluating what traction the chain has in the mind-share of developers — which should thus increase the availability of developers. Bitcoin is the oldest and has arguably the strongest, most entrenched community, whereas the Ethereum community may be the largest and is growing the quickest. Cryptonote, IOTA, and NEO all had much smaller communities in the spring of 2017. Since then, both IOTA and NEO have had exceptional community growth. Particularly NEO with their City of Zion group of independent developers.

With these three criteria in mind we chose NEO. Note that this write up is certainly not exhaustive, and I’m certain we are missing chains as well as capabilities of the chains listed in this article that supporters feel better support our use case. The purpose of this was to walk through how one firm worked through the evaluation process. Ultimately, different chains are better fits for different use cases — for ours, NEO is the best fit.