Open source eKYC blockchain built on Hyperledger Sawtooth

By | Blog

Guest post: Rohas Nagpal, Primechain Technologies

1. Introduction

Financial and capital markets use the KYC (Know Your Customer) system to identify “bad” customers and minimize money laundering, tax evasion, and terrorism financing. Efforts to prevent money laundering and the financing of terrorism are costing the financial sector billions of dollars. Banks are also exposed to huge penalties for failure to follow KYC guidelines. Costs aside, KYC can delay transactions and lead to duplication of effort between banks.

Blockchain-eKYC is a permissioned Hyperledger Sawtooth blockchain for sharing corporate KYC records amongst banks and other financial institutions.

The records are stored in the blockchain in an encrypted form and can only be viewed by entities that have been “whitelisted” by the issuer entity. This ensures data privacy and confidentiality while at the same time ensuring that records are shared only between entities that trust each other.

Blockchain-eKYC is maintained by Rahul Tiwari, Blockchain Developer, Primechain Technologies Pvt. Ltd.

The source code of Blockchain-eKYC is available on GitHub at:

Primary benefits

  1. Removes duplication of effort, automates processes and reduces compliance errors.
  2. Enables the distribution of encrypted updates to client information in real time.
  3. Provides the historical record of all compliance activities undertaken for each customer.
  4. Provides the historical record of all documents pertaining to each customer.
  5. Establishes records that can be used as evidence to prove to regulators that the bank has complied with all relevant regulations.
  6. Enables identification of entities attempting to create fraudulent histories.
  7. Enables data and records to be analyzed to spot criminal activities.

2. Uploading records

Records can be uploaded in any format (doc, pdf, jpg etc.) up to a maximum of 10 MB per record. These records are automatically encrypted using AES symmetric encryption algorithm and the decryption keys are automatically stored in the exclusive web application of the uploading entity.

When a new record is uploaded to the blockchain, the following information must be provided:

  1. Corporate Identity Number (CIN) of the entity to which this document relates – this information is stored in the blockchain in plain text / un-encrypted form and cannot be changed.
  2. Document category – this information is stored in the blockchain in plain text / un-encrypted form and cannot be changed.
  3. Document type – this information is stored in the blockchain in plain text / un-encrypted form and cannot be changed.
  4. A brief description of the document – this information is stored in the blockchain in plain text / un-encrypted form and cannot be changed.
  5. The document – this can be in pdf, word, excel, image or other format and is stored in the blockchain in AES-encrypted form and cannot be changed. The decryption key is stored in the relevant bank’s dedicated database and does NOT go into the blockchain.

When the above information is provided, this is what happens:

  1. Hash of the uploaded file is calculated.
  2. The file is digitally signed using the private key of the uploader bank.
  3. The file is encrypted using AES symmetric encryption.
  4. The encrypted data is converted into hexadecimal.
  5. The non-encrypted data is converted into hexadecimal.
  6. Hexadecimal content is uploaded to the blockchain.

Sample output:

  {file_hash: 84a9ceb1ee3a8b0dc509dded516483d1c4d976c13260ffcedf508cfc32b52fbe
     file_txid: 2e770002051216052b3fdb94bf78d43a8420878063f9c3411b223b38a60da81d
     data_txid: 85fc7ff1320dd43d28d459520fe5b06ebe7ad89346a819b31a5a61b01e7aac74
     signature: IBJNCjmclS2d3jd/jfepfJHFeevLdfYiN22V0T2VuetiBDMH05vziUWhUUH/tgn5HXdpSXjMFISOqFl7JPU8Tt8=
     secrect_key: ZOwWyWHiOvLGgEr4sTssiir6qUX0g3u0
     initialisation_vector: FAaZB6MuHIuX}


3. Transaction Processor and State

This section uses the following terminology:

  • Transaction Processor – this is the business logic / smart contracts layer.
  • Validator Process – this is the Global State Store layer.
  • Client Application (User) – this implies a user of the solution; the user’s public key executes the transactions.

The Transaction Processor of the eKYC application is written in Java. It contains all the business logic of the application. Hyperledger Sawtooth stores data within a Merkle Tree. Data is stored in leaf nodes and each node is accessed using an addressing scheme that is composed of 35 bytes, represented as 70 hex characters.

Using the Corporate Identity Number, or CIN, provided by the user while uploading, a 70 characters (35 bytes) address is created for uploading a record to the blockchain. To understand the address creation and namespace design process, see the documentation regarding Address and Namespace Design.

Below is the address creation logic in the application:


  • uniqueValue is the type of data (can be any value)
  • kycAddress is the CIN of the uploaded document.

The User can upload multiple files using the same CIN. However, state will return only the latest uploaded document. To get all the uploaded documents on the same address, business logic is written in Transaction Processor.

The else { part will do the uploading of multiple documents on the same address and fetching every uploaded document from the state.

4. Client Application

The client application uses REST API endpoints to upload (POST) and get (GET) documents on the Sawtooth blockchain platform. It is written in Nodejs. In case of uploading, few steps to be considered:

  • Creating and encoding transactions having header, header signature, and payload.(Transaction payloads are composed of binary-encoded data that is opaque to the validator.)

  • Creating BatchHeader, Batch, and encoding Batches.

  • Submitting batches to the validator.

When getting uploaded data from blockchain, the following steps needs to be considered:

  1. Creating the same address from the CIN given by User, using GET method to fetch the data stored on the particular address. As shown in  the following code snippet, updatedAddress is created by getting user input either from User (search using CIN in the network) or from the private database of the user (Records uploaded by the user). Similarly, splitStringArray splits the data returned from a particular address because of the transaction logic written in the Transaction Processor to upload multiple documents on the same address while updating state with the list of all the uploaded data (not only the current payload).

2. The client side logic is then written to convert the splitStringArray by decoding it to the required format and giving User an option to download the same in the form of a file.

5. Installation and setup

Please refer to the guide here:

6. Third party software and components

Third party software and components: bcryptjs, body-parser, connect-flash, cookie-parser, express, express-fileupload, express-handlebars, express-session, express-validator, mongodb, mongoose, multichain, passport, passport-local, sendgrid/mail.

7. License

Blockchain-eKYC is available under Apache License 2.0. This license does not extend to third party software and components.

Debunking Myths Surrounding Hyperledger

By | Blog

Since its inception at the end of 2015, Hyperledger has grown from two projects to ten, and the adoption of the Hyperledger platforms and tools has spread across a wide range of industries. Even as Hyperledger has become a trusted name when it comes to using blockchain for the enterprise, there are still some misperceptions that we’d like to debunk once and for all.

Myth #1: Hyperledger is a vendor.

Reality: Hyperledger is not a vendor. It is a non-profit industry consortium with a membership-based model. Anyone can use the code, contribute, and even become a core maintainer on any of the projects, whether or not they work at member companies. We do have a growing subset of our member community that offer business blockchain products and services based on Hyperledger projects; you can check the 80+ organizations and offerings in the vendor directory.

Myth #2: Hyperledger is an IBM- and Intel-run shop.

Reality: Though a number of Hyperledger projects were originally contributed by IBM (Hyperledger Fabric, Hyperledger Composer, Hyperledger Cello, Hyperledger Explorer) and Intel (Hyperledger Sawtooth, Hyperledger Explorer), the diversity of the developers working on the projects grows every day. Over the lifetime of all 10 Hyperledger projects, there have been 729 unique code contributors, representing more than 150 organizations. The recent 1.2 release of Hyperledger Fabric featured contributions from 15 companies, including Accenture, BBVA, Oracle, and Blocledger; 22% of the commits came from non-IBM sources. In the Hyperledger Sawtooth project, Bitwise has eclipsed Intel in the maintainer count. We are grateful for the continued resources and support that IBM and Intel provide, and encourage other companies to follow their lead, so that Hyperledger remains a healthy, multi-stakeholder community.

Myth #3: Hyperledger doesn’t support interoperability.

Reality: Hyperledger Quilt, one of the five tools in the Hyperledger greenhouse, offers a way of guaranteeing transactional coherence across two ledgers. And that’s just the start of what Hyperledger can do for interoperability.

An early example of this was the integration between the Hyperledger Sawtooth and Hyperledger Burrow projects last year. As a result of that integration, simple EVM smart contracts can be deployed to Hyperledger Sawtooth using the “Seth” (Sawtooth Ethereum) Transaction Family.

More recently, the  Hyperledger Fabric community began working to create a bridge to the Ethereum community so that developers can write EVM smart contracts on Fabric. The hope is that our community will continue to tighten integration and interoperability across Hyperledger projects and beyond, creating a greater number of options for developers. We hope that even more developers can start to think out of the box, connecting blockchains, and doing it securely. The problem of working with more than one technology stack is no longer a technical one.

Our philosophy has always been that you can write one blockchain that talks to multiple other blockchains at the same time. They’re not hermetically sealed.

Myth #4: Hyperledger isn’t focused on scalability and privacy.

Reality: Hyperledger is working on multiple fronts to improve scalability and privacy. The Performance and Scale Working Group is collaborating on defining key metrics for scalability in blockchain technology. Hyperledger Fabric already has a scalability feature called ordering nodes, which lets you focus a subset of your network on the performance-critical part of it in order to improve performance.

When it comes to personal data, Hyperledger Indy upholds the standards mandated by GDPR. Hyperledger Fabric has support for private channels, which is one of the techniques for providing confidentiality between parties with their transactions on the blockchain.

At the same time, our Hyperledger Architecture Working Group has a working draft of an evaluation of the different Hyperledger projects’ approaches to privacy and confidentiality.

Myth #5: Hyperledger blockchains are one network per application.

Reality: Our vision is that there can be multiple, different applications for each network. The food trust network that is being developed with Walmart, for example, could be applied to trace fish, packaged greens, and consumer products, all at the same time. Plus, we are eager to see the interesting applications that can be built on top of that traceability.

The Hyperledger community keeps growing: We’re up to 277 member organizations, including new members FedEx and Honeywell. While that should mean greater awareness of who we are and what we do, we also want to continue to answer your questions. Are there other myths you have heard or seen? Not sure if something is true or not about Hyperledger and blockchain in general? Feel free to share with us on Twitter @Hyperledger.

We hope you join us in the effort by contributing to Hyperledger projects. You can plug into the Hyperledger community at github, Rocket.Chat the wiki or our mailing list. As always, you can or email us with any questions:

Developer Showcase Series: Jonas Snellinckx, TheLedger

By | Blog

This blog series serves to highlight the work and motivations of developers, users and researchers collaborating on Hyperledger’s projects. Next up is Jonas Snellinckx from TheLedger. Let’s see what he has to say!

What advice would you offer other technologists or developers interested in getting started working on blockchain? 

Blockchain isn’t like any other technology, it isn’t well researched, and it sure isn’t well documented. But let this not scare you. You are a pioneer in the era of a new internet.

Whether you have a computer science background or not, blockchain is a technology you want to get started with. I would not recommend focusing all your resources on one technology. Everything is still early, and there are so many good concepts and technologies out there. Just wait and follow the market. New technologies will arise, so there’s no reason to get tunnel vision and use one technology for all. This is not Java.

What project in Hyperledger are you working on? Any new developments to share? Can you sum up your experience with Hyperledger?

I’m currently working at TheLedger developing prototypes on mostly Hyperledger Fabric, but also BigchainDB. We are a consultancy firm, mostly doing prototypes, which means I’m fortunate enough to cycle through projects and learn new things at a quick pace. I have worked on numerous prototypes from KYC to competencies on the blockchain to a hackathon solution for diamond invoice financing to even a self-conscious house. You can learn all about our adventures and other Hyperledger Fabric related posts here:

I’m also maintainer of some boilerplates and tools for the Hyperledger Fabric network. You can find all our tools on , we have a bunch. We created a network boilerplate, backend boilerplate using nestjs and typescript, node utils to write nodejs chaincode at lightning speed and a mockstub to test nodejs chaincode. We vastly improved our workflow by using these tools, so I highly recommend looking at these.

What do you think is most important for Hyperledger to focus on in the next year?

I think Hyperledger Indy is a big one, I think self-sovereign identity will be more important in the future. Just overall making the projects more mature and listening to the needs of the community. I think Fabric is doing this pretty well already.

As Hyperledger’s incubated projects start maturing and hit 1.0s and beyond, what are the most interesting technologies, apps, or use cases coming out as a result from your perspective?

We recently talked about this at the office. Hyperledger Indy and Self-Sovereign Identity will be a big part once we get to integrate this with Hyperledger Fabric. There’s still some work to this, but this has so much potential. Blockchain is one thing, but SSI will have a whole other meaning to the ecosystem. This will also help some GDPR related issues.

What’s the one issue or problem you hope blockchain can solve?

I think I’m not the only developer who’s lazy. At school they told us a developer should be like this. This is why it frustrates me one has to do so much duplicate work to submit forms to difference instances for example. I just hope we get rid of this all this duplicate paperwork and do something useful with this saved time.

Where do you hope to see Hyperledger and/or blockchain in 5 years?

I don’t think we can even imagine the impact of blockchain in 5 years. There’s so many awesome ideas, and most of them are currently only in their concept phase. We’ll have to wait until things mature.


Growing the Enterprise Blockchain Ecosystem Through Open Standards and Open Source Code

By | Blog

By Brian Behlendorf, Executive Director of Hyperledger at the Linux Foundation

and Ron Resnick, Executive Director of the Enterprise Ethereum Alliance

The Enterprise Ethereum Alliance and Hyperledger today announce that we are formally joining each other’s organizations as Associate Members. This will enable more active and mutual cross-community collaboration through event participation, connecting with other members, and finding ways for our respective efforts to be complementary and compatible. The collaboration between our organizations will further accelerate adoption of blockchain technologies for business.

The Enterprise Ethereum Alliance sponsors the development of specifications and standards for enterprise blockchain networks, with a focus on those aligned with the broader Ethereum ecosystem. Hyperledger fosters the development of open source software for establishing, managing, and connecting enterprise blockchain networks. Thus, our two organizations have similar objectives, with highly complementary approaches to achieving them.

Our two organizations have similar objectives, such as broadening and strengthening the community around and the adoption of enterprise blockchain technologies. What we hope to get across to the public is that anyone who ever put a “versus” between EEA and Hyperledger got it wrong; it’s now conclusively “EEA AND Hyperledger.”

This relationship will enable Hyperledger developers to write code that conforms to the EEA specification and certify them through EEA certification testing programs expected to launch in the second half of 2019. As members of each other’s organizations, both communities will be able to collaborate across tens of Special Interest Groups, Working Groups, meetups and conferences globally, across hundreds of thousands of developers in both communities.

EEA community members working on specifications and standards can turn to Hyperledger to collaborate on software implementations of those standards. Those could be done as lightweight efforts in Hyperledger Labs, or proposed as top-level projects to the Technical Steering Committee for approval to join the other 10 Hyperledger projects. Our cross-cutting working groups on identity, architecture, performance/scalability could also be leveraged. Both organizations host Meetups and events around the globe, adding to the opportunities for collaboration.

There is already work underway that shows our alignment. In 2017, Hyperledger launched the Hyperledger Burrow project, an Apache-licensed implementation of the Ethereum Virtual Machine (EVM) bytecode interpreter. Earlier this year, Hyperledger Sawtooth added support for the EVM as a transaction processor, bringing smart contracts developed for the Ethereum mainnet over to Sawtooth-based networks. That effort, dubbed “Seth,” is now in active use, and the developers anticipate submitting it for conformance testing to the EEA Spec 1.0 as soon as possible. Likewise, support for the EVM is now available in Hyperledger Fabric.

As a further example, there is currently a working group on Trusted Execution Environments in EEA, and a prototype implementation of those proposed standards, called “Private Data Objects,” being built as a lab at Hyperledger. Hyperledger Labs provide a channel for innovation and testing of ideas to experiment with new frameworks and modules before achieving MVP or stable code.

This concept of simultaneously developing community-driven open standards and production-quality open source reference implementations is a best practice of Internet-scale software development work. Previous examples include the IETF and Apache working on HTTP, and ECMA and Mozilla working on JavaScript.

Down the road, we hope this mutually beneficial relationship will encourage Ethereum developers to consider submitting their enterprise projects to Hyperledger and Hyperledger project maintainers to consider taking de-facto interfaces appropriate for standardization to the appropriate EEA working groups. This relationship will also enable Hyperledger developers to write code that conforms to the EEA specification and certify them through EEA certification testing programs expected to launch in the second half of 2019.

Both organizations will continue to work with other standards bodies, and other open source communities. By working together, the Enterprise Ethereum Alliance and Hyperledger will bring substantial benefits to developers and enterprises, and accelerate the adoption of enterprise blockchain technologies.



Brian & Ron


Developer Showcase Series: Joshua Smith, MonetaGo

By | Blog, Hyperledger Fabric

We return back to our Developer Showcase blog. This series serves to highlight the work and motivations of developers, users and researchers collaborating on Hyperledger’s projects. Next up is Joshua Smith from MonetaGo. Let’s see what he has to say!

What advice would you offer other technologists or developers interested in getting started working on blockchain?

Be willing to ask questions, keep an open mind, and stay humble.  Blockchain is bleeding edge technology, there are difficult problems that many people are trying to solve in different ways. There is no gold standard or best practice guide to follow, the whole community is figuring it out as we go along. There are so many different blockchain implementations; do some research, pick one, and dive in.

Give a bit of background on what you’re working on, and let us know what was it that made you want to get into blockchain

Before becoming a software engineer I was a physicist. After leaving academia, I was focused on finding another career path that would allow me to be a part of a community dedicated to solving complex problems. I was familiar with public, permissionless blockchain implementations before formally entering the field and learned a lot about Hyperledger and its projects while preparing for my interview with MonetaGo. I felt pretty confident that getting into blockchain would be fun. A year and a half later and I’m still having a really great time solving tough problems with my team and the broader Hyperledger community.

What project in Hyperledger are you working on? Any new developments to share? Can you sum up your experience with Hyperledger?

For the past year we’ve worked towards launching a production blockchain network for a group of exchanges in India seeking to mitigate fraud in the process of invoice factoring. I spent a long time writing chaincode, working with the node sdk, and customizing channel settings to make sure our solution met the necessary standards to go into production. We hit our go live milestone at the end of March 2018, making us the first production enterprise blockchain solution in India. Now most of my focus is on scaling our architecture to support our growing user base.

I’ve worked with Hyperledger Fabric since version 0.6.5 and I’m really happy with how the project has evolved. I really appreciate the transparency maintainers have with regards to project direction and priorities. As the community has grown over time I’ve found members to be consistently helpful and friendly in both hackfests and rocket chat. There’s a great wealth of knowledge available if you know the right questions to ask.

What do you think is most important for Hyperledger to focus on in the next year?

The passing of GDPR and some US states looking to adopt similar privacy rules is going to make data privacy of huge importance. Although it’s currently possible to implement your own privacy solutions, I think Hyperledger projects will need to include guarantees out of the box for widespread adoption as production solutions.

What is the best piece of developer advice you’ve ever received?

The biggest difference between expert and novice problem solvers is the time it takes to begin. Experts take a much longer time to ensure they understand the bounds of a problem before starting to implement a solution and end up saving time by doing it right the first time.

What technology could you not live without?

Definitely my phone, I use it for so many different things throughout the day it may as well be a part of me.

Hyperledger Bug Bounty Update

By | Blog

By Dave Huseby — Hyperledger Security Maven

In October of 2017, the Hyperledger community launched our first bug bounty program through a partnership with HackerOne. This is in addition to the independent security audits we have initiated to vet our software. Now that the first year of the program is coming to a close, it is time for an update on the impact it has made so far.

We’ve found that increasing our bug bounty payouts has attracted more interest among analysts, and we’ll make even more changes in 2019 to boost bug reporting.

At the launch of the program, only Hyperledger Fabric was in a position to be included. Initially, the bug bounty program was kept private and only open to people in HackerOne’s pool of vetted security analysts because of the relatively new nature of the Fabric code base. By limiting the pool of analysts, we were hoping to better control the number of security bugs coming in.

HackerOne sent invitations to 174 analysts in their pool. Of those 174, only 72 accepted the invitation and joined our program. We were excited to finally have outside people trying to break our software. Unfortunately, at the end of the first six months of the program, we were not where we wanted to be.

To better understand why we are seeing a general lack of interest, HackerOne surveyed the analysts invited to the program to ask why they were not participating in the bug bounty. The results are listed in Table 1.

Specialization 26
Uninteresting 17
Competitiveness 11
Small Scope 10
Onerous Setup 9
Skills Mismatch 7
Clarity 6
Unresponsive 6
Hardened 5
Objection 5
Unattractive 4
Access Criteria 2
Aggressive Policy 2
Low Payouts 2
Small Scope 2
Unclear Payout Structure 1
Total 115

Table 1 — HackerOne Survey Results

We know that blockchain platforms are novel and different from what the HackerOne analysts are used to working with, but we had hoped that it wouldn’t matter. From the survey results, it appears that most analysts weren’t interested because of the high degree of specialization needed to mount effective attacks against the software. To offset the specialization required, we decided to increase our bounty payouts to move out of the “uninteresting” category.

The bug bounty program opened to the public this past April with increased bounty amounts. Immediately we had more interest, however we received a flood of bug reports from people who didn’t take the time to read our program rules and weren’t aware that we are an open source organization. However, we did receive three bugs worth paying attention to. Two were configuration issues with our infrastructure and one was a bug in Fabric. All were fixed and small bounties were paid.

Our bounty award levels are right near the industry median, but based on the required levels of specialization needed to effectively attack our networks, we may need to raise our bounty payouts even further  to increase the level of interest. Table 2 lists our current payouts.

Critical $2000
High $1500
Medium $500
Low $200

Table 2 — Current Bounty Payment Schedule

Moving into 2019, we will reassess the efficacy of our bug bounty program and change our direction. One obvious thing is that we’re not getting the level of interest we had hoped for. Either Hyperledger Fabric has airtight security or we’re not doing enough to interest analysts and hackers. If I had to bet, my money would be on the latter. We’re exploring a number of ideas, from more marketing, using the available bounty budget better through limited time bonuses and offering other incentives like all-expenses-paid trips to Hyperledger events for anybody who reports a critical bug. The discussion is taking place on our Technical Security Mailing list right now: here and here.

Overall, we need to have a well-rounded security process that follows all of the best practices. We have a robust and public bug tracking system and development discussions. All of the teams have rules around code reviews, and they do a good job of managing risk when carving new releases. Over the past year, we have conducted outside security audits of Hyperledger Fabric, Sawtooth, Iroha, Composer, and Indy is underway. The bug bounty is underway and we’re discussing expanding it to include Hyperledger Sawtooth, Iroha and Indy. The idea of running test nets is also being considered.

You can stay connected and participate in that discussion to help us make even more effective use of our security resources in 2019. And as always, you can keep up with what’s new with Hyperledger on Twitter or email us with any questions:

Bitagora: A Decentralized Voting Platform Built on Hyperledger Sawtooth

By | Blog, Hyperledger Sawtooth

Guest post: Ignasi Ribó (@seliestel)

On October 1 2017, Catalan citizens were called to the polls to decide whether they wanted to become an independent Republic or remain a region of Spain. This self-determination referendum had been promoted by the Catalan regional government with the support of civic organizations and a large part of the Catalan population. But there was one problem: the Spanish government was staunchly opposed to its celebration. As the day of the referendum approached, Spanish police and public prosecutors increased their repressive actions against Catalan citizens and institutions, including the seizure of websites, print houses, postal mail, and any other means by which the referendum could be carried out.

In spite of the repression, citizens occupied the polling stations days before the referendum in order to prevent the police from shutting them down. During October 1st, in an exemplary show of self-organization and resilience, thousands of people kept the polling stations open, defending ballot boxes with their bodies as policemen armed with riot gear tried to seize them by force. Hundreds were injured by the batons and rubber balls indiscriminately used by the police against peaceful voters. In spite of coordinated DDoS attacks throughout the day, anonymous citizens managed to sustain the computer systems used for voter registration. At the end, more than 2 million people were able to cast their ballot. But police brutality and the repressive actions of the Spanish state seriously disrupted the polling and managed to put into question the final results.

Inspired by these dramatic events, I began at the end of November 2017 to develop a blockchain application that would allow any concerned group of citizens to organize a referendum and deliver accurate and auditable results without having to rely on a central authority. The project aimed to strengthen grassroots democracy around the world and give people the ability to exercise their right to vote on any question they deemed relevant, whether central institutions and authorities approved the vote or not.

My interest in decentralized, direct democracy was not new. In my book Habitat: The Ecopolitical Nation I had already argued for the need to extend it as much as possible in order to achieve more sustainable and resilient commonwealths. But now I felt it was the time to work on a practical tool that could help to bring this ideal closer to reality.

Developing Bitagora

The first thing I needed to do was to devise a system for voter registration that would guarantee the anonymity of voters while ensuring that everyone casting a ballot was authorized to do so and that no one would be able to vote more than once in the same election. Centralized voting systems solve this problem by using official censuses and polling stations. For obvious reasons, a decentralized system could not rely on this machinery.

Fortunately, modern public-key cryptography offers the necessary tools to build systems that provide both anonymity and verifiability without relying on a central authority. In the Bitagora implementation, voters submit their identification to a fully automatic Certifier script that checks the validity of the information according to the requirements set by the promoters of the poll. If the identification is valid, the Certifier script generates a private key that is deterministically derived from the voter identification using a hashing function that would prevent an attacker from recovering the identification information of the voter even if he got hold of the private key. The Certifier also generates a token that includes the public key derived from the voter private key using the elliptic curve secp256k1 protocol, the same cryptographic cypher underlying Bitcoin. The Certifier signs this token with its own private key and sends the signature and the voter key back to the voter. With this key, the voter can then cast a ballot in the poll.

Enter Hyperledger Sawtooth

Once I had set up the registration system and a user interface (both mobile and web) that voters could use to register and cast their ballots, I still needed to develop the core functionality of the decentralized network of validators that had to sustain the trustless voting system (i.e., a blockchain).

One very attractive possibility was to build the voting system as a DApp running on the Ethereum Virtual Machine. But that would have required voters to interact with the network using a cryptocurrency. Without owning some amount of Ether, or some other fungible token, voters would not be able to pay for the transaction costs involved in executing the Bitagora smart contract. This didn’t look like a scalable, or even fair way of setting up a voting system that could be used by a large number of voters in a real election.

So I quickly discarded relying on any existing blockchain and opted instead for building my system using a private blockchain that would be sustained by volunteers and be completely free for voters. After reviewing several of the frameworks currently available to build such a system, I chose Hyperledger Sawtooth.

Unlike other frameworks, Hyperledger Sawtooth was meticulously documented, with exhaustive explanations and a wide range of examples and applications that worked right away without a flaw. It also provided a complete SDK in Javascript, the language I was already using to code my system. Moreover, the different modules were packaged in Docker containers, which greatly facilitated the installation and fit perfectly well in my strategy to make the Bitagora validator software easily deployable by a large number of nodes in various operating systems without having to go through messy installations.

As I started to work on developing the validator software using the Hyperledger Sawtooth framework, I also found that there was a very active community of engineers and developers exchanging information, ideas and support on the Hyperledger chat. Whenever I had a question I could not solve on my own, I would post it there and quickly receive valuable suggestions and advice from the Sawtooth team or from developers working on other projects. On some occasions, this chat was a lifesaver!

An open project

At the beginning of August, after months of development, I finally distributed the code of the different Bitagora modules through Github under an Apache 2 license. With the help of the Catalan Pirate Party, I had previously conducted several tests and the system performed really well, thanks in particular to the robust consensus mechanism employed by the Hyperledger Sawtooth network layer. The platform is now ready for anyone to set up and use in all sorts of elections.

Since I am not a professional developer, I don’t have the time or resources to sustain this project on my own beyond its current state. But I would be happy to work with other people interested in expanding and improving Bitagora in order to turn it into a fully functional and open-source tool that can enhance direct democracy and empower voters around the world.

If you’re interested in learning more about the project, you can do so at You can also help contribute code by visiting:

Hyperledger 2018 Summer Mentors Recap

By | Blog, Hyperledger Cello, Hyperledger Fabric, Hyperledger Iroha

Our interns did some great work on some very meaningful projects this summer. We’ve shared details of their work here. Of course, the program wouldn’t work without the time, effort and input our mentors provided. Many of them went the extra mile and provided their take on lessons learned, what they gained by being a mentor and advice for future interns as well. Here is some of the wisdom they shared:

Baohua Yang, Principal Architect, Oracle Blockchain (Project: Design Effective Operational Platform for Blockchain Management)

Lessons learned:

The intern’s self-motivation is important as is his/her interests with open-source projects.

What you got out of being a mentor:

I was very glad to help new person to get involved into the open-source world.

Advice for those interested in interning in the future:

Knowledge or skill is not the most important thing to learn as an intern. The Hyperledger internship is a great opportunity to help you learn open culture and principles to participant a teamwork.

Dave Huseby, Security Maven, Hyperledger, The Linux Foundation (Project: Simulating Hyperledger Networks with Shadow)

Lessons learned:

The primary lesson I learned is to choose the right size for an intern project. I was ambitious in what I asked my intern to do. It turns out that blockchains are complicated pieces of software and getting them to run under a simulator is difficult. That said, the reduced scope we agreed upon mid-summer was met and we did advance this effort.  I’m hoping that an intern next summer will pick up where my intern left off.

What you got out of being a mentor:

It was interesting to see our community through the eyes of a newcomer.  I got involved with open source communities so long ago that I forgot what it was like to be new.  I had forgotten all of the mental shifts (e.g., don’t ask for permission, just do) and leaps of faith (e.g., here’s my code, please be nice) that a developer has to make to be a successful contributor to an open source project. It takes real courage to contribute code and fully participate in a community where you know nobody. I really enjoyed encouraging Martin when things got tough. More importantly, the best thing I got from being a mentor was a new friend.  Martin is a really good person.

Advice for those interested in interning in the future

Be prepared to work hard. Working remotely is difficult and not a normal way of working. It takes a great deal of self-discipline, and as I said above, it takes real courage to submit code to people you don’t know and be judged by your contribution.  Be prepared to learn. With the right attitude, an intern can get some real rubber-meets-the-road experience. There’s a big difference between a recent computer science graduate and a work-a-day programmer. An internship working on open source software can go along way towards making you a work-a-day programmer.

Jay Guo Software Engineer, IBM (Project: Extended Support for EVM and and Tooling in Hyperledger Fabric)

Lessons learned:

We should set realistic goals for interns, and we should give them enough time to climb the learning curve.

What you got out of being a mentor:

Mentoring requires more than technical skills. I learned a great deal of project management, communication and presentation skills

Advice for those interested in interning in the future:

  • Remote internship is hard and timezone difference makes it even harder. Both mentors and applicants should take this into consideration. Being located in the same city would make life much easier.
  • Communication is a key part of internship. Interns should proactively seek help from mentors, and this is a quality that mentors should pay attention to when interviewing candidates.

Swetha Repakula, Open Source Developer, IBM Digital Business Group (Project: Extended Support for EVM and and Tooling in Hyperledger Fabric)

Lessons learned:

  • Most of my lessons comes from the fact that this was a remote internship. I underestimated the difficulty that comes from both not being able to work together in person as well as being able to finding a reasonable time for everyone involved to be able to speak. Because of this, I think projects that are suggested for this program either have to be very structured and scoped or the project needs to be isolated enough that the intern is able to make progress without other people. The solution to this we found was scheduling regular calls and asking for daily reports on progress to make she was on track.
  • Another thing I learned was making sure our intern felt comfortable asking questions and not feeling like she was alone. Creating that environment was our number one goal because interns shouldn’t feel like they are expected to do everything by themselves. We found that explaining our expectations to her and constantly encouraging her to ask us questions was the best solution to this.
  • My final takeaway was setting realistic goals for the internship. Goals can refer to the actual progress of the project, but I viewed the internship successful if our intern was able to end the program with a skill set she could apply to whatever she planned to do next. Of course our intern produced results, but what I was most proud of was when she understood concepts such as test-driven development or breaking down a project into smaller achievable tasks. Those are the skills that will make her a good developer and, in the end, the goal of this program is to enrich our interns, not necessarily just got some work done for our projects.

What you got out of being a mentor:

  • I have always enjoyed sharing knowledge, and this program gave me the opportunity to do that. My proudest moment easily was when my intern spoke about how the things we taught her during the internship directly applied to her current classes. As I mentioned above, our first goal was to make sure our intern learned enough that she could apply it to the rest of her career.
  • I found though that mentoring someone was not just about teaching but required some managerial skills. That would involve making sure my schedule allowed enough time for me to be available to guide my intern, ensuring she was making enough progress at the correct pace and helping her get the resources she needed to complete her work. This is was a very new experience from me.

Advice for those interested in interning in the future:

  • I recommend that those who wish to intern in the future be honest, whether that is about their skill set, their availability, or their professional interests. Our intern was clear about what she understood or didn’t understand and that really helped make sure the limited time we had was focused on what she was stuck on.
  • Be proud of your current accomplishments. As mentors we aren’t expecting you to necessarily have experience in the topics we are working on. What I look for is someone who is driven and passionate about the work they do. So be able to talk about those accomplishments, regardless of whether it is a class assignment or a huge project you have worked on.
  • Communication is key for anything you work on. Focus on being to explain your ideas clearly as well as relaying what you have done in the past. And, lastly, come with your ideas and questions.

Sheehan Anderson, Vice President/Director of Architecture, State Street (Project: Hyperledger Fabric Chrome Extension)

Lessons learned:

Working remotely brings unique challenges, especially when starting a new project. There were several of steps we took that worked really well throughout the internship.

  1. Have a plan laid out on day one that covers the length of the internship. Understand what parts of the project should be functioning by the end of each week as 12 weeks will go by really quickly. You don’t want to be spending time deciding what to do at the start of each week.
  2. Communication is important. Have regular video conference calls to demo what has been built, discuss any blockers, make sure that next steps are understood, and just to get to know each other. Be available on Rocket.Chat ( so you can answer questions. Also, encourage your intern to reach out in the various channels when they have a question. It’s a great way to meet other Hyperledger developers.
  3. Be flexible. Chances are that your 12 week plan will encounter at least some roadblocks. Be quick to remove or alter features if they are taking longer than expected to build.

What you got out of being a mentor:

Hyperledger Fabric is no longer a new project. I started as one of the original developers and now spend most of my time writing applications that run on the Hyperledger Fabric platform. I’m surrounded by people with similar experience. Having a chance to work with someone who is both new to Hyperledger and early in their software engineering career brings new perspectives that are important. A risk of working on the same thing for too long is that you get used to the way things are and don’t stop and question why something is done in a particular way and if there may be a new or better alternative. Being a mentor requires you to both be able to explain the existing architecture and answer those “why” questions that you may have ignored otherwise.

Advice for those interested in interning in the future:

The interns that really stood out during the interview process had built projects utilizing existing open source projects. This showed that they had curiosity, determination, and the ability to self-learn and get unstuck when faced with an obstacle. Sometimes contributing to existing open source projects can seem daunting or have a very steep learning curve. Creating your own small project that makes use of an existing open source project can be a great introduction to various open source communities and will also show that you have the skills needed to succeed in a program like the Hyperledger internship.

Salman A. Baset, IBM (Project – Running Solidity Smart Contracts on Hyperledger Fabric or Vice Versa)

1) Lessons learned:

To have a successful internship outcome, a project needs to be crisply defined, have an intern who possesses the necessary background and is excited to learn, and have periodic sync ups with the intern. I was fortunate to have an intern who had background in compilers and was excited to learn both Ethereum and Hyperledger Fabric in order to translate Solidity smart contracts into Javascript for Fabric. We leveraged Zoom and Hyperledger Rocket chat for communication.

The key takeaway from the project is that it is possible to write smart contracts for one platform that run in another without making changes to the core platform. Perhaps, a bigger lesson is that there is a need to write smart contracts in a language that can be run on any target platform (similar to Java). Hopefully, next year, we can have a project to develop a smart language that targets multiple blockchain platforms within Hyperledger.

The project is available as open source with Apache 2.0 license and will soon be converted to a Hyperledger Lab. The source code is available here:

What you got out of being a mentor:

I had the satisfaction of supervising a hardworking intern who was able to create running code for the seemingly difficult idea of running Solidity contracts on Fabric. My hope is that the project does not end with the culmination of the internship and sparks interest among other members of the community.

Advice for those interested in interning in the future:

Asking questions to your mentor and seeking solutions on your own from members of community is very important.

We would also like to recognize the mentors for all the time, effort and input they provided! As always, you can keep up with what’s new with Hyperledger on Twitter or email us with any questions:

Hyperledger 2018 Summer Interns Recap

By | Blog, Hyperledger Burrow, Hyperledger Cello, Hyperledger Fabric, Hyperledger Iroha

It’s suddenly September and so it’s time to check in on our Hyperledger summer interns and mentors. Read on for more about five of the projects our interns tackled. We asked the interns about their summer with Hyperledger.

Here, their own words, are the goals, successes and lessons learned from each intern:

Ahmad Zafar (Project: Running Solidity Smart Contracts on Hyperledger Fabric or Vice Versa)

Project goals:

I was working on Running Solidity Smart Contracts on Hyperledger Fabric Project. The Solidity smart contracts are easy to write and are widely used by developers. The aim of this project was to help the developers to translate the publicly available Solidity smart contracts into readable and, hopefully, functionally equivalent Hyperledger Fabric contracts without writing the contracts from scratch. For Hyperledger Fabric, we chose Javascript language. Our goal was to translate 70-80% of the Solidity grammar/programs correctly into fabric smart contracts that are also human readable to make them easy to understand and change.


I have successfully translated approximately 65-70% of solidity code to javascript code for Fabric smart contracts. Examples of language features include types, expressions, functions, events, function modifiers, structs, and single inheritance. Since Ethereum is a public blockchain with notions of Ether (Cryptocurrency) and Ether transfer, I had to provide functional equivalence in terms of Ether transfer on Fabric – (we ignore gas for now).

I have also translated 15 Solidity smart contracts examples to javascript code. These contract have been taken from different places. Some are from solidity documentation, and some are from github repositories, including the ERC20 token format which is used to create ICOs. These contracts were chosen with my mentor to cover a large number of Solidity features.

My translator will work on other contracts as well if the contract has 65-70% of the common components. My translated code and all examples that I have tested are placed on my github repository along with all the other content related to my project, including which components we have covered, how you can run this tool and results of my translated code.

Lessons learned:

For developing a translator from Solidity to Fabric, one has to have knowledge of compilers and has to learn both Solidity and chain code and both frameworks for testing code. Before starting this internship, I worked on compiler construction in my university project. The scope of that project was not big but making a translator for complete language was a massive task for me. Successfully completing that project boosted my skills in writing translator tools for different things. However, before starting this project, I had little knowledge about Ethereum and Hyperledger Fabric smart contracts. After this project, I have become skillful enough in writing both Ethereum and Fabric smart contracts. Other than languages, I have learned how to run contracts on both frameworks and their architecture. In short, I learned many things related to Ethereum and Hyperledger Fabric. This project will help me a lot to start development in blockchain, especially in Fabric and hopefully other Hyperledger frameworks.

A V Lakshmy (Project: Extended Support for EVM and and Tooling in Hyperledger Fabric)

Project goals:

My project involved the integration of Ethereum events into Hyperledger Fabric. The two key goals of the project were:

  • Implementation of event-related interfaces from Hyperledger Burrow to work with the event framework in Hyperledger Fabric
  • Modification of the JSON-RPC API functions in the fabproxy module to deal with events


  • In the initial few weeks of my internship, I wrote some simple test cases for the chaincode evmscc.go. When my patch passed through the review process and finally got merged into the repository, I was elated
  • I also wrote code for an event manager module and modified the API functions in the fabproxy module. These pieces are still under review and will hopefully be merged before the September release.
  • This was my first experience with open-source development and in the exciting field of blockchain. I am thrilled that my work will eventually be included in the source code of a vast project like Fabric!

Lessons learned:

  • I got to study a new programming language, Golang.
  • I learned about Ethereum and Fabric and how to interact with these blockchain frameworks.
  • I got an exposure to version control systems like Git.
  • I grasped good software engineering principles, such as test-driven development.

I am very grateful to my mentors, Swetha Mam and Jay Sir , for patiently guiding me through this project. All in all, this project was an incredible learning experience for me!

Daniel McSheehy (Project: Hyperledger Fabric Chrome Extension)

Project goals:

The goals of my project was to build a Chrome extension that can connect to a Hyperledger Fabric network and provide an easy to use api for websites to send transactions.


The Chrome Extension is operational. Through a simple api, a website can easily prompt the chrome extension to send transactions and query the ledger. The extension also requires confirmations from the user, preventing a website maliciously sending transactions.

Lessons learned:

Sometimes the “right” way to do something doesn’t work, so I had to come up with alternative solutions to get things working. Because my project is intended to make things easy for users, I also learned the importance of reaching out to others and receiving feedback.

Martin Martinez (Project: Simulating Hyperledger Networks with Shadow)

Project goals:

We had two key goals for the project:

  • Analyzing the current Shadow tool characteristics to find compatibility with Hyperledger networks.
  • Testing the Shadow tool with platforms such a Hyperledger Sawtooth, Hyperledger Fabric and Hyperledger Iroha.


We successfully identified that Hyperledger Iroha is the most suited candidate to use the Shadow network simulation tool.

Lessons learned:

I learn more about the complexity and benefits of working in an open source community. Also, I feel grateful for the support of my mentor as well as the Hyperledger community members that I contacted through different channels such a Hyperledger chat.

Shuo Wang (Project: Design Effective Operational Platform for Blockchain Management)

Project goals:

My internship project focused on supporting dynamic blockchain configuration and integrating Fabric-CA module into Hyperledger Cello to make it more suitable for production environment. For beginners or in the testing environment, we often use an offline tool to generate all the cryptographic configuration artifacts statically. However, it is a centralized and unsafe way for a single user to generate all users’ identities in a real application scenario.


I adopted Fabric-CA module and made the generation of cryptographic artifacts dynamic, automatic and decentralized. After users login into an operator dashboard, they could easily connect to a worker node and create the blockchain on it with quite simple configuration of the network type, size and roles in the blockchain. All the orderer nodes and peer nodes will register and enroll their identities from the CA server. Then users could login into a User-Dashboard to install and run chaincode in the blockchain with a newly generated user identity from the CA server.

I will continue to work in Hyperledger Cello Project after internship, and I plan to make the process of Cello workflow more dynamic so that each organization in the blockchain network could change their own settings more freely.

Currently, I am doing my master thesis at the Southern University of California and Tsinghua University. My research is focused on the blockchain consensus. Therefore, I am quite interested in seeing the Byzantine-fault-tolerant consensus used in the future version of Hyperledger Fabric.

Lessons learned:

During the internship, I enjoyed the culture of open source and learned some great tools for open source project development. The most important lesson I learned is to be timely in following up and keep in close touch with mentors and colleagues because people work collaboratively from all over the world. I really appreciate my mentor, Dr. Baohua Yang, and his kind help and guidance. He gave me many practical suggestions and shared deep insight of blockchain industry with me.

As a bonus, we asked for the intern’s take on what they’d like to see Hyperledger do in the future. Here are a couple of our favorite answers:

“I hope Hyperledger offers or organizes hackathons at universities. I think that it could be a great way to get students involved in blockchain and expose them to open source communities. I’m always amazed at the ideas people come up with at hackathons, and think that there could be projects and use cases that have never been thought of.” – Daniel McSheehy

“I hope that Hyperledger continues to give such amazing internship opportunities to students!” – A V Lakshmy

We would like to thank these interns for all their hard work and success. We would also like to recognize the mentors for all the time, effort and input they provided. Many of them went the extra mile and provided some their take on lessons learned, what they gained by being a mentor and advice for future interns as well. We will be posting their reactions and experiences with the program in another blog tomorrow – stay tuned! As always, you can keep up with what’s new with Hyperledger on Twitter or email us with any questions:

Privacy By Design in Hyperledger Indy

By | Blog, Hyperledger Indy

The Scope and Limits of Indy’s Privacy Tech

Guest post: Daniel Hardman, Evernym

Privacy is a hot topic in blockchain circles–and across the entire digital landscape. GDPR, ePrivacy, and similar regulatory regimes have the world thinking hard and smart. Modern systems must bake privacy into their DNA; it can’t be bolted on after-the-fact. I’ve written elsewhere about why this is true, and how it must be done–and I’ve spent the last couple years helping Hyperledger Indy embody all the privacy goodness I know. I’m encouraged to hear a swelling chorus of blockchain practitioners opine that certain things must NOT go on a blockchain.

Perhaps you have heard a claim that Indy “solves” privacy. Or perhaps you’ve seen skeptics roll their eyes, muttering about how we’re all going to be correlated by the surveillance state, no matter what we do.

The truth is that both of these perspectives distort reality. Indy does offer some wonderful features to aid privacy, and these features matter! But institutions are certainly going to know some things about us, no matter what Indy does. Indy can minimize this in exciting ways. Nonetheless, what privacy we have, now or in the future, will emerge from a combination of technology, social and legal constructs, market forces, and human behavior; it can’t be trivialized as a tech problem.

What “Privacy Tech” Are We Talking About?

Today, Hyperledger Indy’s approach to privacy includes elliptic curve cryptography, pairwise DIDs, semi-trusted agents, agent-to-agent communication using techniques such as libsodium’s sealed box and authenticated encryption, zero-knowledge proofs, a separation between credentials and proofs, privacy-preserving credential revocation features, an affinity for data and key storage at the edge, and a carefully constructed wallet interface that manages personal secrets with industry best practices. In addition, privacy-preserving agent (device) revocation has been demonstrated as a proof of concept.

Indy’s roadmap includes additional privacy-enhancing features such as a user-friendly SSI tool (mobile app) with smart and safe defaults, microledgers, sophisticated policy and/or AI for agents, mix networks for transaction submitting and agent routing, and so forth.

Some of these technologies exist in other identity technologies, but Indy combines more of them, in far more powerful ways, than any similar technology I know.

What All This Tech Does NOT Deliver

Except for people who live in remote, technology-scarce  places, all of us are constantly observed and recorded. Google maps may have a picture of our front door; cell phone towers track the location of our mobile devices; credit card companies see what we spend; closed-circuit cameras watch us on the road or subway.

In such an environment, much will be known about us, even if we use Indy to prove things in zero knowledge. And, if we choose to use Indy to disclose something identifying–our email or phone number or name+birthdate, for example–then the disclosing interaction is correlatable to a much bigger digital footprint, no matter what fancy math did the proving. Even less perfect correlators like first name + fuzzy place + fuzzy time may correlate us, given sufficient context.

It might be tempting to say, then, that there’s no point to Indy’s elaborate privacy posture. But there is more to the story.

What Hyperledger Indy Privacy DOES Deliver

Hyperledger Indy allows you to construct interactions where the degree of disclosure is explicit and minimal–much smaller than what was previously possible. Nothing about the mechanics of connecting, talking, or proving in Indy is leaky with respect to privacy; vulnerabilities that emerge must come from the broader context. No other technology takes this minimization as far as Indy does, and no other technology separates interactions from one another as carefully. If privacy problems are like a biohazard, Indy is the world’s most vocal champion of wearing gloves and using a sharps container for needles–and it provides the world’s best latex and disinfectants.

Of course, this does not give perfect protection. Like a needle stick, mistakes can ruin Indy’s carefully sanitized interactions, and contamination is always a possibility. In 2017, the layouts of US army bases in some of the most dangerous locations in the world were compromised because soldiers had been using the Strava running app to track where they exercised ( If this can happen when stakes are so high, and when the organization is as careful as a sophisticated army, then similar fiascos will undoubtedly occur, both with and without Indy technology, for the foreseeable future. These are serious problems that are not to be underestimated.

Despite the imperfect guarantees, doctors consider it worthwhile–even vital–to wear gloves. And despite risk, Indy’s privacy tech can deliver real value, if we are careful about constraining behavior and understanding use cases. Any interaction that does not leak is a tiny bit of personal, private space–and chaining such interactions together can accrue significant benefits. Indy makes it possible to prequalify for a loan at a thousand banks, in a way that proves credit worthiness, income, and citizenship, without forfeiting privacy. Used correctly, it can insulate cautious whistleblowers; it can enable secure, private voting; it can make online dating safer. Many other use cases exist. In each situation, we must carefully assess privacy beyond the narrow context of Indy’s proving mechanics. Gloves are less helpful when a disease vector is airborne; the government still needs to know who you are when you pay your taxes.

Intentions And Incentives

Besides discussing what protections Hyperledger Indy offers on the technical level, and what ways there might be to defeat such protections, we can also make an argument that architectures, algorithms, data models, and cryptography always carry a certain “intention” towards the parties we interact with. In our case, this intention is to maintain the individual’s privacy, sovereignty, etc. Whether or not the technology can strictly enforce this intention, or to what extent, is an important question, but not the only argument for building it in a certain way.

If we use pairwise DIDs and zero-knowledge proofs, the message is clearly “don’t try to correlate me,” even if you could find a way to do it if you try hard enough. An HTTP Do-Not-Track header says “do not track me,” but it doesn’t offer any actual protection from tracking. The VRM community has been talking about user-defined terms for a long time. In a relationship, you can express “don’t use my data for advertising,” or “delete my data after 14 days,” or “use my data for research, but not commercially.”

Simply expressing these intentions in code and architecture has value by itself. It bears a message that privacy and sovereignty “should be honored,” even if it cannot always be guaranteed technically that it will be. Over time, we expect that through regulation, trust frameworks, reputation, and similar mechanisms, not honoring such intentions will be discouraged. Of course we must always communicate clearly the limits of intentions and guarantees, lest we create a false sense of security that can lead to severe consequences.

One of the main reasons for the growth of Internet’s re-decentralization movement (Diaspora, Bitcoin, etc.) was not only to achieve more privacy and independence, but also to build architectures that better mirror the way we want society to work in the real world (not client/service aka. master/slave). At the same time, the point of view that “technology is neutral” is getting less prevalent, being more and more replaced by an assumption that “technology has built-in values.” From this perspective, privacy tech is valuable not only as a technical defensive mechanism, but also to make a point, to convey an intention.

Importantly, Indy’s technology also enables the transformation of privacy incentives. Companies that once stored PII can now store an opaque identifier for a customer, and contact the customer’s agent to learn more–then throw away the data after they use it. This has the potential to eliminate many centralized data troves as hacking targets, and it empowers people instead of impersonal and conflicted corporate guardians. Indy also provides meaningful advances in the world’s answers to privacy regimes like GDPR. We believe that in the future, social, software, and legal constructs will evolve to take advantage of the privacy features offered by Hyperledger Indy, and that this will lead to ever more creative types of business models and digital interactions not possible before.