Delphus Winter 2020 Update

The Delphus team has been hard at work over the past few months, steadily improving our product with many heavily-requested features. At the same time, we’ve been busy both in and out of the country bringing Delphus to many new people!

Product Updates


We have introduced support for the standard XForms specification, used by software from the Open Data Kit ecosystem. Supporting file uploads, multiple pages, advanced skip logic, and structured data collection, it has greatly improved our support for complex forms and data submissions.

Further, we have also implemented support for XForm imports from other software. This allows researchers to easily migrate to our platform without spending time on retraining or converting battle-tested form designs.

Multi-collateral Dai Support

We have updated to support multi-collateral Dai on the Kovan testnet, connecting to Dai on the Kovan contracts powering Oasis Trade. This is a foundational upgrade that increases the security of our payment storage and compensation system.

Further, we have tested the upgrade with our automated Dai exchange functionality, ensuring that it properly continues operations into the future.

UI Redesigns

We’ve greatly improved the appearance of our landing page to more clearly convey the benefits of using Delphus, with three key points where Delphus helps:

Delphus’s redesigned landing page

We’ve also made improvements to the user interface for both researchers and participants, streamlining the interface to create a study and add data.

Sponsor Awards at ETHWaterloo

Our most interesting weekend was at ETHWaterloo, where we spent time creating Cortex, a decentralized Ethereum identity verification system. It’s our hope to integrate this as a trusted method of organizational verification in Delphus to demonstrate the identities of researchers and to provide it as a Keybase-like service for the Ethereum ecosystem.

We were happy to work with members of several development teams at the event, including NuCypher, Ethereum Name Service, and Torus, integrating their software with ours. We were also honored to be selected for the following prizes:

  • NuCypher Award
  • Ethereum Name Service Award
  • Torus Award

It was a great experience hacking in Waterloo, and we hope to return next year!

Whitepaper Update

As part of our documentation updates, we have updated the whitepaper to include a clearer description of our problem statement and an updated technical architecture. If you haven’t taken a look at it before, please check it out now!

That’s all — best wishes for a wonderful 2020 and a new decade!


nuCypher Walkthrough (WIP)

  • Person A (Alice) takes data (in this example) and enters it into the computer. She creates a policy describing what people should have access to the data and when it expires.

  • The computer (Enrico) generates a symmetric key and encrypts the data; then it encrypts the symmetric key with Alice’s public key (capsule).

  • The header (capsule) is essentially  a randomly generated key from the computer (Enrico: think password generator) that can decode the data in the rest of the message.

  • The encrypted data + header is uploaded to IPFS.

  • Person B (Bob), who wants to read the data, downloads the encrypted data + header and sends only the header to a number of proxy re-encryption nodes (Ursula), which re-encrypt the header with Bob’s public key. They send back this header, which Bob can decrypt with his private key thanks to the magic of proxy re-encryption.

  • Person B uses the header, which contains the decrypted symmetric key, to read the rest of the data.

Will be adding more explanation and nuance later, but this is a basic walkthrough about how we tried to visualize and understand nuCypher. Please feel free to correct us or connect with us!

For a more in depth explanation, see

Scintillating News

The Making of Delphus Chat: Matrix, Ethereum, & End-to-End Encryption

Delphus, our secure, decentralized research manager, just got a very important new feature: end-to-end encrypted and federated chat, voice, and video calls, powered by Matrix and Riot. Here’s how we built it.

Why Matrix?

End-to-end encryption is necessary for our private researcher-participant communications, where sensitive information is often exchanged. This made Matrix, one of the only chat protocols that truly offers end-to-end encryption, our ideal choice. Its encryption library has been audited by NCC Group and is supported on all platforms, including web, iOS, and Android. Its mission to create a global, open “matrix” of communication also fits well with our own goal to unify and share scientific research.

Further, Matrix’s Synapse server is open source, allowing us to self-host it. It has several useful administration features, such as the ability to send system alerts to all of our users or to automatically add users to a server-wide discussion or announcement room.

Matrix also has a featureful first-party client: Riot. We opted to integrate this client into our app instead of coding one ourselves to take advantage of their end-to-end encryption support and extensive efforts to improve the user experience. Riot also supports voice and video calls through WebRTC.


Unfortunately, Riot is not itself designed to be embeddable. It currently does not expose any hooks to tell when the application is loaded or to trigger specific UI actions.

Since we wanted to integrate it into our application—for example, by adding links to start chats with participants or researchers—we added these hooks by forking Riot. (Changes are open source on our GitLab instance at delphus-riot-web and delphus-matrix-react-sdk.)

At specific locations, such as to mark when the user has logged in, our fork of Riot sends a cross-frame message to Delphus:

    type: "LOAD_COMPLETE",
    matrixId: this._matrixClient.credentials.userId

Using an event listener, the main Delphus application picks up these messages and triggers an action. We save the current load state (loaded, signed in) of Riot in our local state so that buttons in the app can know when Delphus Chat is loaded, e.g. to show a specific chat window.

To show notifications from Riot, we added a similar notification cross-frame message, which is used to update a counter in our code and show a notification badge on the Delphus Chat button (The user can also enable desktop notifications in Riot, which will show notifications as popups on their computer).

To open specific views in Riot, we programmed a way to manipulate the current location of the iframe, since Riot stores its view in the URL. For example, viewing the Matrix HQ (a general chat room about Matrix) is at the URL /#/room/, while viewing my profile is at the URL /#/user/ By manipulating the iframe URL, we can effectively remote-control Riot.

Identity Verification

However, in order to let participants chat with researchers (or vice-versa), we still needed a way to link a user’s Ethereum address (their pseudonymous identifier on our platform) with a Matrix ID (a username on the Matrix side). We decided to write a simple smart contract to handle this:

pragma solidity ^0.5.0;

/// @dev Stores mappings of addresses <-> Matrix IDs as part of the chat
/// system.
contract ChatRegistry {
    mapping (address => string) public matrixIds;

    function setMatrixId(string calldata _mxid) external {
        matrixIds[msg.sender] = _mxid;

This Ethereum smart contract maps a user’s Ethereum address to their Matrix ID.

Then, when we receive the LOAD_COMPLETE message from Riot, containing the user’s Matrix ID, we can compare it to the one saved by ChatRegistry. If the two differ, Delphus triggers a transaction to update the registry.

Thus, when we show Ethereum addresses on other parts of the site (such as when we display the researcher or participants in a study), we can include a “Start chat with this user” button to provide seamless integration. This button will automatically open Riot, load it if not loaded (since Riot is lazy-loaded to reduce the performance impact), and navigate to the specified user.

The end result is that we have a user-friendly, integrated embedded form of Riot on Delphus, allowing users to easily start encrypted chats, voice calls, or video calls with other users on the site.

Interested in learning more about Delphus? Contact us at, or sign up for our mailing list. If you are interested in learning more about Matrix, check out their blog as well.


Delphus: Where We’ve Been and Where We’re Going

Over the past few months, we’ve had a blast building Delphus, a revolutionary scientific study manager built for the Ethereum blockchain. Our product is built on the premise that studies should be transparent, secure, and accessible to everyone. In this post, we’ll share the history of our project as it has evolved to become what it is today.

Where We’ve Been

commit 1a060c6d736afaa3eac1c7dab4af29fa969edde0
Author: Ajacuzzi <>
Date:   Sat Feb 24 09:20:04 2018 -0500

    Initial commit

Delphus began as a humble project developed overnight at MAHacks III, a New England hackathon. After gaining inspiration from a Forbes article that recommended using blockchain technologies in clinical trials, and gathering our own information from a sister familiar with scientific trials, we built the early-alpha version of Delphus, then called reBlock.

Delphus, then called reBlock, original hackathon version

It wasn’t pretty, but it was functional, and it had the core features still present in our product today. To our surprise, the hackathon judges awarded us first place, and we decided to continue developing it further. After meeting Erick Pinos there, the President of the MIT Bitcoin Club, he let us know about the MIT Bitcoin Expo Pitch Competition and encouraged us to submit.

Delphus v0.3.0, as presented at the MIT Bitcoin Expo

Three weeks of tireless work later, this was the result: a fully-functional, end-to-end study management platform. Against promising startups like Coconut and, we won second place and a partnership with Pillar VC, who continues to help us today.

Shortly thereafter, we went on to speak at Babson College about our product as part of Boston Blockchain Week. Then, we hunkered down for the summer developing the remaining features for our product, including participant data management, encryption, and a smoother UI flow. As the summer finished, we went to DoraHacks in Boston to develop patient data alerting, winning first place and a prize of $1.5k.

Most recently, we have gone to California for business purposes and working towards the future of Delphus.

Where We’re Going

Delphus today

We are currently seeking beta testers for our first public trials, beginning with university studies. We are expanding our market both nationally and internationally. Furthermore, we are in conversation a few impressive companies, which we hope to be able to speak more in depth about in the future.

Of course, there are always more features to implement as well, from our novel tokenized reputation system for medical professionals to a machine-learning recommendation system to automatically connect researchers to patients. We plan to finish these in the coming months to further improve our product.

We’re excited to get our product out into the world, and we believe it can benefit all of scientific research. Want to use it? Contact us at

Scintillating News Uncategorized

Interview with Will Hemond, Co-Founder of Delphus, a student-run entrepreneurial nonprofit group, recently interviewed Will Hemond, co-founder of Scintillating and Delphus.

Check out their article on Medium!

MakerDao's Dai and Delphus

Groundbreaking, Seamless Dai Integration in Existing DApps

Price volatility is the Achilles’ heel of a distributed application, or DApp for short. Nobody wants to deposit funds when Ether dipped 30% in the last month. And, while stablecoins like Dai can solve this issue, they have notoriously poor documentation, as we mentioned in our previous post. Furthermore, most existing DApps are already designed around Ether, which is relatively easy to process, and converting them to use DAI is an arduous and under-documented task.

The UX Problem

Using Dai also poses another issue: the user experience. If a smart contract only accepts Dai, new users will have to manually go to an exchange (of which there are few) to convert their Ether to Dai, then return to the DApp and deposit their Dai. Then, when taking out Dai, they have to manually convert it back to Ether to sell it for fiat on an exchange.

Enter Oasis.Direct.

Oasis.Direct is the prime example of what the UX for a decentralized app could be  a one-click transaction converts your Ether to Dai, without any manual ordering or price setting. Moreover, by integrating it into Dai-accepting smart contracts, it has the potential to make them far easier to use.

Step 1: Connecting to Maker Contracts

First, let’s take a (slightly simplified) look at how the entrypoint for our StudyManager contract looked like before Dai integration:

Ignore the other parameters, what matters is that it’s a payable function to which the user can send Ether. That Ether is then held by the contract and recorded in the new study’s paymentPool.

To convert this function to accept Dai, we have to retool it a little:

We’ve changed the contract to look much like a function that accepts ERC20 tokens which it should, since Dai is, at its heart, an ERC20 token.

However, there are two issues with this approach:

  1. The user still has to manually convert their Ether to Dai.
  2. The user has to manually call dai.approve(YOUR_CONTRACT_ADDRESS, tokenAmount) before calling this function, thanks to the design of the ERC20 standard. This means that the user has to approve two transactions.

Thankfully, we can solve both of these issues simultaneously:

Step 2: Interfacing with OasisDEX

OasisDEX is a decentralized exchange that converts ETH to DAI, running on both the Kovan test network and the main network. Its contract addresses (under “market”), along with Dai’s Kovan and mainnet addresses, can be found in the source code repository.

By interacting with OasisDEX, we can simplify the user flow, automatically converting deposited Ether to Dai for long-term storage.

Let’s see an example from our code:

(Contract interfaces from Oasis.Direct’s code.)

Here, the contract does four things:

  1. It deposits the paid Ether into the WETH contract, which is needed to trade on OasisDEX. Our contract now owns msg.value in WETH.
  2. It gives OasisDEX approval to use as much WETH as it needs to trade it to Dai.
  3. It executes an automatic trade from WETH → DAI, requiring an outcome of at least minBuyAmt DAI or else the trade will fail.
  4. It creates the study as we did in the previous step.

Note that the function has to be passed in the “minimum buy amount” of Dai that they want; it specifies the minimum exchange rate, in effect. You can calculate this on the DApp end by calling (with ethers.js/web3):

Which you can do invisibly before sending the createStudy transaction, in this case.

Step 3: Mocking Maker

Now, there’s one downside with this approach: to test your contracts in the future, you’ll have to use the live OasisDEX contracts on Kovan or the main network. This obviously doesn’t play very well with automated testing like Truffle, as each test would require actual Kovan/mainnet Ether.

First, we tried a new way of testing: with the tool ganache-cli, you can actually do a virtual chain fork by connecting to a mainnet/Kovan node and effectively creating a development blockchain that starts with all the state of the live network. This would let you test cheaply, without incurring costs on the live network, but while still connecting to “real” MakerDAO contracts.

Unfortunately, we ran into issues where our contracts either failed to deploy or didn’t work properly with this setup, so ultimately we ditched it for a more traditional, if more annoying, approach.

Let’s deploy all the Maker contracts on the Truffle development network!

The full code is pretty long, but I’ve put it on a GitHub gist at the end of the post if you’d like to use it. Here are the major steps:

  1. Deploys OasisDEX, WETH, and a FakeDAI contract (just a mintable ERC20 token) from /contracts/maker/.

  2. Whitelists the WETH and FakeDAI pair for fake-trading. This is necessary to prevent the OasisDEX contract from erroring on “untrusted” token pairs.

  3. Creates the WETH to DAI trading side of the exchange and the DAI to WETH side.

    To do this, you have to deposit WETH, approve it for use by OasisDEX, and make a fake WETH → DAI offer at a fake exchange rate. For the other side, you have to mint some fake DAI, approve it for use by OasisDEX, and make a fake DAI → WETH offer.

This creates a marginally-functional OasisDEX contract on the development network which you can use to mock Dai trading.

And there you go! That’s how you convert a contract accepting Ether to one that seamlessly converts it to Dai for long-term storage.

This code was used in our product Delphus, a DApp revolutionizing the management of clinical data in scientific studies. Find out more there!


Other interesting links:

Development Truffle migration script:

MakerDao's Dai and Delphus

Rationale for Tutorial

While Dai is a useful tool and allows for stability of a platform, there are not many instructions on how to implement this token into either a new Distributed Application or an existing one. Further, existing documentation does not appear to exist with few understandable comments, which, to be fair, is somewhat understandable with such a new implementation.

MakerDao’s official chat has been more than helpful, but we believe that it may allow for easier integration if there was a documented journey from start to finish, including the most common errors found, it may be useful for others.

We will be showing snippets of our code as we implement them, and our full source code will be released at the public release (we aim to be open source).

Thank you for joining us on this journey, and we hope that it ends up working for both you and us.

MakerDao's Dai and Delphus

Why does Delphus use Dai?

If you don’t know what Delphus is and would like to know more, please check out our earlier post here as well as our website here.

As you may already know, the one issue most have with cryptocurrencies is the overall volatility of most networks.

For example, Bitcoin, mostly due to surrounding hype and a positive relationship between investors and miners, spiked in prices, reaching $20,000 back in December, but then “normalizing” down to its current price of around $8,000.

These increasingly different prices, often with no correlation to any conventional market trends to the average user, provide for a marketplace not useful for many cases in which a static amount of value may need to be stored. This is the case with Delphus as the researcher -> participant payments cannot change in value throughout the duration of the study.

There are many viable options for addressing this issue, with new stablecoins appearing every so often. The stablecoin most prominent, trusted and well supported by developers as of now is MakerDao’s Dai. It is tied 1:1 with the US dollar with very few deviations of non-discernible value (>.01 cents). It is collateralize using valuable assets in the open-source Maker contract.

For this reason, it is far easier for researchers to set static payments that can be distributed through smart contracts, rather than relying on the rise and fall of a cryptocurrency. Since we rely on the Ethereum Blockchain, we can use the ERC20 token, Dai, in order to keep stable prices and allow both researchers and patients an easy way to receive non-volatile payments.

This allows us to garner better communication between the researcher and the patient, while reducing the risk of patients not receiving their specified payment or complaining about how what could be $1,000 the first day, is $5 the next day (they probably won’t be complaining if the price increases). Further, as Dai is being continuously developed and scaled with them introducing more collaterals to their system, it is ideal for the ever-expanding field of medicine and clinical trials.

Thus, we arrived at the logical conclusion of incorporating Dai into our project and we’d like to share with any interested parties, the entire process of its integration.

edited product name from reblock to Delphus

Scintillating News

Our Plans for the Future

Welcome to the official blog of Scintillating and Delphus.

In this blog, we would like to talk about the development of our product.

In an age of increasing lack of privacy, evidenced by corporations like Facebook and Amazon, data is easily sold off and not valued by corporations. The medical field specifically faces a large problem when dealing with the results of studies; data transparency is nonexistent in comparison to the quantity of available data from said studies. An estimated 90% of study results are never released, preventing others from building upon their work and creating an open scientific community. Even if obtained, sensitive data is difficult to secure from alteration or tampering which creates issues with study transparency and consent in the long term. Finally, discovering participants is costly and time-consuming, while the budget of many researchers is comparatively not enough to deal with these issues alone.

Researchers need software that can cut costs and save time. They require tools capable of managing payments and securing data. Patients need a greater access to their own data and a larger degree of privacy.

While other companies have developed their own clinical trial management platforms in an effort to solve these issues, these conventional systems often create new problems. They do little to preserve the results of completed studies for future researchers and breed distrust due to a lack of transparency. Thankfully, these issues can be solved via the blockchain which allows for immutable and transparent studies through smart contracts. Using Delphus, the blockchain-based decentralized study management system, all of these problems are solved.

Delphus is our flagship product that aims to improve clinical studies by modernizing the workflow of researchers’ data submission and collection.

By using the blockchain, we can dramatically cut down the costs of data management and are able to improve communication between participants and researchers through trustless smart contracts.

We aim to finish the minimum viable product of Delphus by the end of July, which includes these features:

  • COM token (with dividends)
  • Uploading consent forms, consent recording
  • The ability to create a study with custom fields
  • Integrated participant database
  • Encrypted upload of data points to IPFS
  • Distribution of funds to patients through ETH
  • DAI as intermediary currency for stability
  • Importing/exporting data points
  • Comprehensive system for adding data fields to allow for customizable studies
  • Seamless tutorial and smoothly flowing UI

By implementing all of these features, we can solve the key issues that worsen the experience for both researchers and participants. After this, we will do extensive testing before expanding to local colleges.

If you would like to learn more, you can visit our website here.

edited product name to Delphus