Choosing a blockchain platform for Finprint

Note: Finprint isn’t under active development, but we think the lessons we learned are still valuable for other developers evaluating blockchain platforms.

We recently open-sourced Finprint, a data sharing protocol that aims to empower consumers with the ability to own and securely share their financial data. Finprint’s goal of bringing control and transparency to consumers was a natural fit for the decentralized nature of blockchain platforms. We built our first implementation of the protocol on Ethereum in the Solidity smart contract language. However, we soon encountered limitations in Ethereum that made it difficult to build our protocol without sacrificing scale or security.

Some of the key needs of the protocol are:

Payments and token staking were straightforward to implement on Ethereum, but the latter two needs were not well-supported. We were able to implement a proof-of-concept version of RSA decryption in Solidity, but we quickly ran into gas limits when increasing the key size past 1024 bits. While Solidity could support this unsophisticated RSA decryption, we felt that an elliptic curve encryption scheme such as X25519 should be used in a production application for better security with smaller key sizes. As an added benefit, the operations with smaller key sizes would also reduce gas costs. We did not believe it was viable to safely implement this on Ethereum in the short term.

Many developers and researchers have examined Ethereum’s current scalability problem, leading to projects working on a wide range of possible solutions. However, the timeframe for a production-ready “Ethereum 2.0” is still up in the air, and given that our aim was to support useful consumer applications in the short term, we decided to explore the viability of other platforms.

We explored many of the nascent next-gen blockchain platforms aiming to compete against Ethereum. Kadena stood out as the most viable option given our project’s needs, while offering a scalable mainnet in 2019. In addition to scalability, other priorities included smart contract security and developer productivity, two areas in which we found Kadena’s platform to excel.

Key features of Kadena

Kadena offers a hybrid (public and permissioned) blockchain that is designed to address the scale, security, and speed needs of industrial infrastructure. These features provided a natural rollout strategy that allowed our partners to assess our protocol with minimal security risk. We could launch our protocol on a permissioned blockchain, then transition to a fully public chain as the financial industry’s appetite for the public blockchain grew. Furthermore, the hybrid blockchain offered us an avenue to transition a centralized entry check for members into a decentralized one by guarding access to the chain via a smart contract.

Pact, their unique smart contract language built on Haskell, addressed the shortcomings we ran into with Solidity and the EVM. Pact had more native support for cryptographic functions, built entirely using widely vetted open-source Haskell libraries. While it didn’t support X25519 at the time, the Kadena team assured us that it could be added to the language quickly and would directly call the cryptonite library with a low gas cost. We co-designed the decryption primitive with their team, and they were able to release a new version of the interpreter that included it in just a couple of days.

Pact’s concept of guards and capabilities also helped us simplify permissioning. Guards provided a primitive to gate access to functions based on the caller’s keyset, while capabilities let us define reusable custom permissions for our contracts. The built-in unit testing via the Pact interpreter made it easy to set up different users to test our more complex permission checks easily, leaving less room for developer error.

Rewriting our smart contracts

Pact was a young language without the large community and usage of Ethereum, so we naturally ran into some unintuitive behavior and tooling gaps in the language. As we rewrote our contracts, we noted areas of improvement for Pact, and reported our suggestions to the Kadena team.

They were very quick to respond to our requests and eager to collaborate. In particular, we worked with them on adding a try function and designing a decrypt function. The try function allowed developers to run a function that could cause a transaction revert, and act upon knowledge of the function’s failure. The decrypt function leveraged Curve25519, Salsa20, and Poly1305, since NaCl box encryption was not supported by Haskell’s cryptonite library at the time. As part of this, the Kadena team also encouraged cryptonite to add NaCl box encryption. They were able to add all requested functionality to Pact on the order of days to weeks, enabled by Pact being an interpreted language.

One advantage of developing on Ethereum that we missed on Kadena was the developer ecosystem and tooling. For this reason, we created the ts-pact library, which contains tooling to help with testing and deploying contracts, similar to what Truffle provides for Ethereum. It also contains JavaScript-based clients for calling smart contract functions, similar to web3.js for Ethereum, albeit with much less functionality. We hope that this tooling serves as a starting point for other developers to contribute to the Pact ecosystem.


While we won’t see the full implications of our choice of blockchain, there were some valuable signals we learned to look for while evaluating nascent technologies.

You can take a look at the code of the Ethereum implementation of Finprint, Pact implementation of Finprint, and the Kadena platform.