Drupal meet Blockchain, Blockchain meet Drupal.



Here at Chainfrog https://www.linkedin.com/company/chainfrog/ we’ve been working with blockchain technologies for years, well before #blockchain mania moved into the mainstream. As such, we’ve been exploring the potential in many different ways. Given the experience our engineering team has working with Drupal, at some point it was inevitable that we would start working on a way to apply blockchain technologies to Drupal, and in particular Drupal infrastructure as it is implemented in the wild.

We’ve got a client-driven prototype with an interesting use case which fully utilizes the advantages of blockchain (no #blockchain for #blockchain’s sake!). We’ve got permission to show some of the functionality to the community so I’ll go into a little bit of detail about what is happening under the hood, and of course link to the working demo!

A quick walkthrough of the user sync in action (which you can try for yourself!)

The ** point ** of using blockchain to synchronize users is to make sure that associated user data is synchronized and available throughout a corporate infrastructure, such use cases could be communication history, addresses, user profile data. This is not suitable for or aimed to be any kind of ‘user verification’ system of which there are far more appropriate and mature solutions.

In fact, this solution when implemented in production, will have no integration with user authentication. It is used solely to ensure that important used saved information is shared via a distributed ledger, which we feel is a more natural alternative than connecting many different systems with a ‘centralized’ database. User profile information, communication history, messages and other customized user information are the target for this prototype. NOT, at any point, is this intended as an authentication or user verification alternative.

1. Why would you want to synchronize users via blockchain?

First of all, why would you want to synchronize users via blockchain? A good question, with valid answers.

There are many use cases where you would want a way to securely synchronize Drupal users. A practical example is one of large companies / government institutions. It is often a ‘strategy’ to use Drupal, however within large organizations there are many departments and functions. This means that practically, separate Drupal installations are required for each business function. In a simple example Drupal A could deal with customer service / inquiries, and Drupal B deals with keeping legal information updated and maintaining compliance records. Separate sites, owned and operated by different teams, but which fall under the same corporate umbrella.

This can result in a frustrating experience for an external user signing up to a ‘company’ system. It is easy to imagine a situation where a user registers with Drupal A, then when they want to interact with Drupal B they are forced to repeat the registration process (or have a similarly frustrating experience with a separate system). The common solution to this problem is for each organization to maintain a large centralized database. As someone who has worked with Drupal for many years, it is commonplace to map user registration forms with a centralized company API, making sure that data across an institution / company is banked. It works a little something like this:

Drupal A <- Central database -> Drupal B

The problem with this integration is that it needs synchronizing in many places. First you will need logic to customize the user registration form (make sure that it is checking with the API that the user doesn’t exist etc). You will also need logic to check the data is synchronized (perhaps updating the user on every login). You are essentially ‘rerouting’ a lot of your user functionality and bypassing the mature Drupal system. Apart from the vulnerability to errors in the logic such as not updating the user object at the right time or accidentally updating the centralized database with data from the wrong system or simply the overhead of having so many API calls to the data in sync, it is also creating an ‘EXTRA’ system to maintain and use.

The end goal for this architecture is to have secure, segregated but synchronized user data in your Drupal installation. If you can keep the data in sync, but have separate user objects with custom fields and logic in each site, that is a bonus (and exactly what we have achieved!)

2. How would you sync users via blockchain?

Now I have to admit that we’ve cheated a little bit here, because we’ve already written code that encrypts and synchronizes databases via blockchain. This is no menial task, but our blockbinder product allows us to communicate via a permissioned private distributed ledger (blockchain to you and I) without exposing the data to prying eyes.

So, where Department A and Department B were previously maintaining a ‘user bank’, with an expensive API layer and quite a few potentials points of failure. We have replaced that with user synchronization via a Drupal 8 custom module transmitted via a private permissioned blockchain.

There are several parts to this, the Drupal part is simple:

function blockbinder_user_insert(\Drupal\user\UserInterface $user) {  // Get User values
$id = $user->id();
$name = $user->getAccountName();
$password = $user->getPassword();
$email = $user->getEmail();
$active = $user->isActive();
$created = $user->getCreatedTime();
$query = $connection->query(“SUPERSECRETQUERY”);
$connection = \Drupal::database();
$records = $query->fetchAll();
// If doesn’t exist, insert
date(‘Y-m-d H:i:s’,$created)
// If exists, update
‘name’ => $name,
‘email’ => $email,
‘password’ => $password,
‘status’ => $active

This code snippet will be quite familiar to Drupal developers, we are simply running a few lines of code every time that a user is added to the Drupal system. We are checking if the user exists in our ‘Blockbinder’ data table (which exists as an extra table in our Drupal db), and updating or inserting accordingly. This is where the interesting part happens. A typical workflow for an API based system would be to make a HTTP call with the new user to a centralized databank.

  1. User created in Drupal
  2. Information sent to API
  3. Response returned from API
  4. Information processed again in Drupal

At this point there are two possible outcomes, either the data has been successfully added to the centralized API, or there has been a failure or some kind of problem. In this case we need additional logic in Drupal (returning an ‘email already registered’ error for example). If the data is successfully added, then all other dependent installations now have to synchronize their out of date user data with the centralized API. The moment that the user data has been added to the API, all dependent databases are out of sync and it will rely on their code / systems to ensure that it becomes ‘in-sync’ before they start using business logic related to their users. Many points of failure, and not an entirely efficient process.

Traditional cloud API

What we’ve done with our peer to peer private distributed ledger is that we’ve removed the API in the middle and we have directly connected system A and system B.

Blockbinder integrated with Drupal data syncronization

Our new peer to peer syncronization system is far more simple.

  1. Drupal A updates or inserts user
  2. Drupal B,C,D syncronize information into their independent systems within 30 seconds

I’ve shown a snippet of the code in the module, sending the user data. Now I’ll show what happens when after the data is passed via blockchain.

function blockbinder_custom_trigger_user($bb_serial, $bb_maker) {

$users = \Drupal::entityTypeManager()
$connection = \Drupal::database();
$query = $connection->query("supersecret)";
$records = $query->fetchAll();
if($records){// If user exist, we update the user
if ($user = reset($users)) {
foreach ($records as $record) {
else {
// If user doesn't exist, create a new Drupal user
foreach ($records as $record) {
$newuser = \Drupal\user\Entity\User::create([
'name' => $record->name,
'pass' => $record->password,
'mail' => $record->email,
'status' => $record->status

Usually, a user object will propagate to every attached node in the blockchain in about 30 seconds. This means that within 30 seconds of an insert or edit being made in any of our Drupal installations, we have fully updated and synchronized user data throughout our entire network. This doesn’t have any need to expensive API calls and maintenance and we are harnessing the maturity of the Drupal infrastructure at all points (no third party systems).

3. Try it for yourself!

I’ve setup a quick and dirty prototype running two Drupal installations on separate servers, synchronizing their users with a ‘lite’ version of our Blockbinder Drupal module. To follow the demo you can do the following:

  1. https://drupal-demo-node1.blockbinder.com/user/register, setup a user here
  2. https://drupal-demo-node2.blockbinder.com/user/login, login as the user here (please give the data 30 seconds to propagate).

Obviously, this is just a taste of the potential of applying Blockchain to Drupal, but as it is a working prototype (and one of the most common pieces of feedback we get is a demand to see blockchain in action!), we thought it was a nice teaser to share with the community. We have working demos of content synchronization (common Drupal data banks) and all sorts of great client-driven projects under construction!

Anyone who is interested in Blockchain and Drupal, or exploring Blockchain in more detail feel free to contact me either via medium or linkedin / twitter (all social media links below!).

Blockchain meet Drupal, Drupal meet Blockchain!

COVID-19 Blockchain response ->

In these difficult times we’ve published a POC system for a blockchain distributed system to provide data feeds and implement a traffic light system, follow the blogs here: https://medium.com/@ed_burton/a-blockchain-covid-response-system-poc-889d9b74786e



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store