It is with great pleasure that we announce our partnership with Wyre to integrate USD payments on OpenCare. As we move forward with the rollout of OpenCare to physicians and patients, it is imperative that those unfamiliar with digital assets or cryptocurrency can easily use the dApp. One of those barriers (for now) is the requirement to own cryptocurrency.

Now with the Wyre widget, users on OpenCare can pay in USD. While users retain the options to pay or receive payment on OpenCare with DAI or ETH, users and clinics can now also link bank accounts in order to pay or receive payments in fiat.

On the front end, the widget appears as shown in the payment panel:

With Wyre’s simple onboarding process, users are able to use USD to obtain DAI, which then enters the OpenCare smart contracts. DAI token passes along the rails of the smart contracts to the physician in exchange for services, and the physician is able to withdraw either DAI token or USD.

About MedX Protocol

MedX is a permissionless protocol for launching medical dApps that connect patients and physicians worldwide for medical care. Applications on the MedX protocol can be used to eliminate intermediaries and international barriers to affordable care. OpenCare is the first dApp on MedX and creates a market for telemedicine that reduces global disparities in medical care. For more information, please visit us at https://medxprotocol.com/.

About Wyre

Wyre helps crypto companies operate in a fiat world. With the Wyre API, partners can grab off-the-shelf the necessary infrastructure for their business. From KYC/AML onboarding, payment processing, and liquidity, Wyre helps fintech entrepreneurs go to market quickly.

Founded in 2013 as one of the original infrastructure 1.0 crypto companies, Wyre has traded $3.5 billion in cryptocurrency assets in-house and have completed more than $750 million in bank-to-bank commercial FX payments. Wyre has expanded its global infrastructure to include relationships with counterparties to procure not only same-day settlement but deep liquidity and best pricing and execution. Funded by renowned VCs in Silicon Valley, Wyre is a well-vested company in the digital currency community, with users in 50+ countries, with features in Forbes, WSJ, NBC, Bloomberg, Coindesk and more. They are headquartered in San Francisco’s Mission district. For more information, please visit www.sendwyre.com.

MedX partners with Wyre for USD payments was originally published in MedX Protocol on Medium, where people are continuing the conversation by highlighting and responding to this story.

Decentralized projects are largely defined by their communities and the shared goals of all of those involved. At MedX, we have always understood the need for open communication and explicit, shared community goals. The majority of the MedX team has been deeply involved in the crypto space for nearly five years. As developers and the early guides of the MedX Protocol, our primary focus is on building great products that will improve the lives of many. However, before taking these roles, we were the early supporters and community members of other great projects that utilize the blockchain and digital assets to make positive differences. Our team has been on both sides. We hope through the sharing of our Mission and Values we can better communicate to the MedX community the fundamental ideas that guide our decision process as a team.

We understand the gravity of our early role as developers and guides of the initial formation of the MedX Protocol. Although we currently have significant influence over the direction of protocol development, this will not always be the case. We have now successfully launched OpenCare on mainnet as well as the beta release of our token-curated registry (TCR). As the MedX ecosystem and community begins to expand, the direction and future of the MedX ecosystem will be controlled by the community itself. The MedX Protocol will exist as a truly decentralized and globally distributed system governed by the users. This will be initially apparent in the beta release of our TCR whereby users are responsible for verifying the credentials of physician applicants. The user controlled aspect of the network is central to the MedX ecosystem and will continue to expand as the protocol matures and the community grows.

While the MedX team will continue to develop and release protocol advances and improvements, these upgrades will only be accepted with the support, testing and approval of the community. For this reason, we believe that it is imperative to clearly share our core mission and values with the community in hopes that these shared ideas will guide the MedX ecosystem as a whole for years to come.

The Problem

Affordable healthcare services are not available to all. The cost and accessibility of healthcare is limited not only by your income status but also by your geographical region. While some portion of this friction may be inherent to the demands of the medical profession and the limitation of available resources, a much greater degree is due to technological shortcomings, inefficient healthcare solutions and geographically fragmented, slow-moving regulations. These aspects of the healthcare market have minimized the supply, distribution and general affordability of medical services throughout the world. Medical services today are not available to the extent that a global, restriction-minimized system would allow. We believe that the use of a decentralized censorship-resistant solution necessitated by a sound blockchain allows for the creation of global free-market health solutions that maximize access and affordability of medical care.

Our Mission and Core Values

Our vision is of a world where access to health services is widespread and affordable, minimizing market inefficiencies and restrictions that inflate costs and reduce available care. We believe in the creation of a global, free-market driven health ecosystem in which neither geographical location nor artificial restrictions necessarily compromise access to appropriate medical services.

In accordance with the above beliefs, our mission statement reads as follows:

Build a global health system accessible by all.

We believe that the path to building this system requires the use of permissionless public blockchain infrastructure where information flows freely and all interested participants have access. Participants within this health system are not only owners of the system itself, but also the sole owners of their generated data such that they may freely grant or limit access to this information.

These closely held beliefs have helped shape the fundamental ideas of our core values.

1. Do right by the community

Decentralized projects are only as powerful as the communities that use and secure them. Projects that deliver long-lasting value to the community are best positioned to retain their supporters and further encourage an ever larger ecosystem of developers and users. These diverse participants then drive the value of the protocol as more useful products launch and economic activity within the system grows.

We strive to always do right by continuing to encourage the development of value-filled systems that can survive on long time horizons.

2. Give control to the users

A global open-access health system cannot be effectively maintained under the control of a single centralized party. Building quasi-decentralized systems that ultimately have central points of control is antithetical to the fundamental value proposition of permissionless systems. We are uninterested in contributing to a protocol that has significant central points of failure. Decentralized systems benefit remarkably from their open-access and permissionless nature. This right for users to access the network regardless of geographical location or specific restrictions is protected by the community alone. If this basic principle is upheld by the community, then we can be sure that MedX remains a protocol open to all.

We believe that the persistent ability for all people to access and utilize decentralized systems cannot be guaranteed by any central party and must be granted and protected by the users themselves. For this reason, these systems should not be under the control of a central entity but rather they should be wholly controlled by the users.

That is, a network users truly control.

3. Ship code frequently

We have consistently released updates to our core protocol to the best of our ability in accordance with our roadmap. This dedication to ship has allowed us to be among a growing group of projects that have delivered usable applications on mainnet. With the release of OpenCare on mainnet and our TCR in beta, we are committed to shipping protocol updates.

Additionally, as the MedX community grows, we will continue to encourage development from a diverse set of global developers looking to utilize the MedX protocol to launch their own distributed healthcare applications.

To find out more about the MedX Health System, please join the discussion on our Telegram or join our mailing list!

MedX Protocol: Mission and Values was originally published in MedX Protocol on Medium, where people are continuing the conversation by highlighting and responding to this story.

• Ethereum smart contracts including PLCR voting contracts
• Decentralized storage of physician credentials on IPFS
• Integration with the Civic Secure Identity Ecosystem for easy physician login
• MEDX wallet integration with MetaMask and user interface
• Near instant in-app faucet for both testnet MEDX and ETH

The MedX Physician Registry will be the gateway for physicians around the world to become part of a new, global health system. That is, an open healthcare system that is controlled by its users while simultaneously ensuring the service of qualified, licensed physicians.

We strongly encourage users to participate in testing the TCR in two different roles:

Token holders/verifiers

Verify, challenge or vote on physician applications in the registry.

Physicians

Submit your credentials to register in the health system. Of note, this is not the mainnet version of the TCR and is for testing purposes only. So there is no need to submit actual physician credentials at this time. Anyone can try it!

Lastly, as we approach the upcoming mainnet launch of the MedX Physician Registry, we want to provide our community with a statement on the Mission and Values that has guided and will continue to be a navigational beacon for our team in the days to come. We will publish the MedX Mission and Values early next week.

Happy Holidays everyone!

MedX Token Curated Registry in Open Beta was originally published in MedX Protocol on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this post, we outline the basic protocol for an objective TCR. This will be followed by a formal quantitative analysis of the security guarantees and potential attack vectors. We assume familiarity with adChain’s original TCR design and encourage the reader to review our prior work on TCRs.

We prefer to call Objective TCRs: Trustless Incentivized Lists (aka TILs). We consider these a type of oracle and treat them as work tokens.

The entire protocol centers around one goal: providing an incentive for a verifier to actually check the validity of an application. In the original TCR paradigm it is assumed that the subjectivity of the application will naturally cause friction amongst token-holders. Such friction cannot be assumed in a TIL. In other oracle designs, such as Augur, the protocol assumes that, in the context of a prediction market, a self-interested market participant will check the validity of an outcome to prevent being cheated. Such self-interested participants cannot be assumed in a TIL.

The protocol is inspired by Truebit. The team at Truebit introduced the concept of “forced errors” to motivate verifiers to expend computational resources in search of these errors. Anyone who discovers a forced error receives a reward. The forced error concept draws upon the idea that, for a given objective task there should be a deterministic outcome. Input a → Output b. We distill this idea and eliminate the need for forced errors.

Simply: if one individual (applicant) commits to an input/output pairing and provides another individual (verifier) with the same input, that individual should be able to produce the same output. In the absence of communication between the two individuals, if they produce the same output, we can conclude with great confidence that the input/output pair is valid across some function. Thus, the crypto-economic goal of the protocol is to prevent collusion between the applicant/verifier.

Protocol

I. Pre-amble

1. A TIL requires a “native token”. We use a standard ERC-20 contract.
2. The protocol involves 3 types of parties: applicants, verifiers and voters. All three require native tokens. A single individual can perform all 3 roles.
3. The applicant & verifier are incentivized by ETH rewards. The voters are incentivized by native token rewards.
4. There exists a pool of verifiers who are available to review new applications to the registry. To become a verifier, one must stake a fixed amount of native tokens in a work contract. We use a fixed amount of tokens due to computational complexity that arises when allowing a variable stake size.

II. Application Phase

1. An applicant submits a hint and a secret, such that a verifier who is provided the hint can deterministically derive the secret (examples: token-name/ticker→ token contract address; physician name/specialty →license number).
2. The applicant generates a random number in their browser.
3. The applicant commits the following on-chain: i) his hint, ii) a hash of his random number and iii) a hash of the concatenation of his secret and random number. Note, the secret cannot be credibly revealed without also revealing the random number.
4. Along with the above transaction the applicant sends x native tokens and y ETH. The ETH is used to pay the verifier. The native tokens are used to stake in the registry (for a successful application).
5. The following block is mined and the block hash is used as a source of pseudo-randomness. This pseudo-randomness is used to randomly select a verifier from the work contract.

III. Verification Phase

1. 2x native tokens are transferred from the selected verifier’s work contract to the application contract.
2. The verifier is presented with the hint and is given a fixed amount of time to derive and submit the corresponding secret.
3. If the verifier fails to respond in time, the applicant selects a new verifier, is rewarded x native tokens from the original verifier and the original verifier is returned x native tokens. If a verifier’s staked tokens falls below a given threshold, they are removed from the verifier pool. Repeat step III-1.
4. If at any time prior to the verifier submitting a secret, the applicant’s random number becomes known, one may “blow the whistle” by submitting the random number. If the hash of this random number matches the hash stored on chain, the whistle-blower is rewarded x native tokens and y ETH from the applicant. The protocol terminates.
5. Assuming the absence of a whistle-blower, the verifier then submits a corresponding secret along with y ETH within the time window.

IV. Secret Reveal Phase

1. Following the verifier committing to a secret, the applicant is given a fixed amount of time to reveal their random number.
2. If the applicant fails to reveal their random number in time, the verifier is rewarded y ETH. The verifier’s 2x native tokens and y ETH are returned. The applicant’s x native tokens are returned. The application is not admitted to the registry. The protocol terminates.
3. Otherwise, the applicant reveals their random number and secret. If the applicant and verifier secrets are the same, the applicant is admitted to the registry with x native tokens staked. The verifier is awarded y ETH for their diligent curation. The verifier is returned their 2x native tokens and y ETH. The protocol terminates.

V. Power Challenge Phase

If the applicant and verifier secrets differ, a “power challenge” commences in which the voters determine if the application hint/secret pair are valid. Here, we replace the traditional PLCR style voting with a round-based game of escalating stake. Each round signals a tentative outcome and lasts a fixed window of time. If the tentative outcome is not disputed during the time window of a given round, the tentative outcome becomes the final outcome and all voter stake that supported the losing outcome can be claimed by voters who supported the final outcome.

The amount of stake required to dispute a tentative outcome is: 2*(total tokens staked) - 3*(current stake on alternate outcome). By nature of the prior applicant-verifier interaction, the starting state of every power challenge is:

A power challenge that continues through 6 rounds would appear as follows:

We prefer the power challenge over PLCR voting for several reasons. First, voting notoriously suffers from poor voter turnout. This makes it likely that a single ‘whale’ can dictate the outcome of a vote. Over time, this deters smaller voters from participating. Second, PLCR voting rewards are unpredictable. Typically, the number of tokens in the minority are so small that rewards to the majority token holders are simply not worth the effort (in fact, sometimes the gas costs associated with PLCR voting are greater than the actual rewards for winning). In the power challenge, a voter on the winning side is guaranteed a 50% ROI in native tokens. This is heavily inspired by Augur’s dispute round mechanism (white paper section C-8). Third, PLCR voting requires voters to return and reveal their vote during a “reveal window” — this leads to a poor UI. The power challenge does not rely on obfuscation of votes (it is secured by the credible threat of a fork, see section VI below), and requires only one period of voter interaction.

1. If the power challenge resolves in favor of the verifier, the verifier receives y ETH and x native tokens from the applicant. They are returned their deposit of 2x native tokens and y ETH. The applicant is not admitted to the registry.
2. If the power challenge resolves in favor of the applicant, the applicant receives y ETH and 0.5x native tokens from the verifier. They are admitted to the registry with x native tokens staked. The remaining 1.5x native tokens of the verifier are rewarded to voters who supported the final outcome. Of note, the verifier forfeits both his 2x native tokens and y ETH.

VI. Forking Phase

The power challenge can, in theory, be won by the individual(s) who possess the largest amount of native tokens. To prevent plutocracy, the ultimate security backup is a fork. When the amount of native tokens involved in a power challenge exceeds a certain threshold, the registry forks. Following a fork, there exists a version of the registry with the new applicant included and a version with the new applicant rejected. For simplicity, in a forking scenario the applicant and verifier are returned their respective y ETH. All pending applications are aborted and participants in these pending applications reclaim their respective ETH and native tokens. All native tokens currently involved in the power challenge are automatically migrated to the version of the registry they signaled support for. All tokens not involved in the power challenge must manually migrate to the version they believe is valid. Users of the registry and token-holders determine which version of the registry they wish to continue using. Presumably, the tokens in the valid version will retain their value, whereas the ones in the invalid version will become valueless. In this forking paradigm, even an attacker with >51% of the native tokens could be incapacitated by off-chain coordination that would render her native tokens valueless in an invalid deprecated registry.

Qualitative Protocol Analysis

In this section we will qualitatively describe 2 possible attack vectors. Following this post we will provide a more rigorous quantitative (LaTeX) analysis of the security guarantees.

TILs rely on the truth as a Schelling Point. If the property being curated in a TIL is truly objective there should be a way to construct a hint → secret pair that is deterministic.

Because we have adopted a work token model with slashing conditions, verifiers in a TIL will lose native tokens if they neglect to review applications that are assigned to them (Step III-3) or provide a secret that does not match a valid hint/secret pair. This provides an incentive for verifiers to routinely check for new applications (e-mail/text notifications are possible with some degree of centralization) and perform the necessary work to derive a secret from the provided hint. Verifiers who perform their jobs appropriately will receive predictable rewards in ETH.

A malicious actor who wishes to admit a faulty application to the registry has two attack vectors: 1) attempt to communicate with their verifier or 2) verify their own application by owning the assigned verifier account.

The protocol dissuades attack vector #1. A verifier should never trust an applicant who reaches out in an attempt to “help by telling the secret”. As can be seen in step V-2, a rational applicant should attempt to trick a verifier into committing to an inaccurate secret for a valid hint/secret pair because the applicant is rewarded y ETH from the verifier in such a scenario. A verifier cannot be sure that the provided secret is the actual secret committed on-chain, because what is stored on-chain is a hash of the secret plus a random number that is unknown to the verifier. If an applicant truly wanted to “help out” a verifier, he would have to reveal both the secret and the random number. However, as can be seen in step III-4, a rational verifier that knows the applicant’s random number should simply whistle-blow. The reward for whistle-blowing is greater than the reward for providing accurate verification. For these reasons, it is in the verifier’s best interest to simply do the work of deriving the secret himself.

Attack vector #2 is akin to the well known 51% attack and other brute force attacks. These attacks are technically unpreventable. Our only option is to design the protocol such that they are extremely expensive, not profitable and (hopefully) not worthwhile even to a spiteful attacker. A malicious entity could set up a verifier account and submit consecutive applications to a TIL until the application is assigned to his own verifier account. At this point, he would know the secret to an otherwise bogus hint/secret pair and gain admittance to the registry. Each failed application costs the attacker x native tokens and y ETH. The cost of such attack is therefore related to the number of verifiers in the work contract (akin to the hash power of a PoW chain), the cost in ETH to apply (value of y * price of ETH) and the cost in native tokens to apply (value of x * price of native token). We presume that, as the registry becomes more desirable, the price of the native token will increase, therefore providing some built-in protection from this attack. However, the parameters should be set such that this attack is prohibitively expensive.

Future Work

Private Transactions

Both primary attack vectors are related to collusion. This could be made far more difficult by making the verifier assignments private.

1. Currently the assigned verifier for an application is publicly known. If this was not the case, it would prove very difficult for an applicant to attempt to bribe a verifier using an off-chain agreement or even another smart contract.
2. One way to make attack vector #2 prohibitively expensive is to require multiple verifiers for each application. This allows us to exponentially increase the cost of the attack. While presently possible, there is the concern that co-verifiers will either attempt to coordinate their secrets or worse, co-verifiers will mimic the response of the first verifier who submits a secret.

General Trustless Oracle

While our burning passion at MedX is to improve healthcare, we have also found ourselves quite far down the decentralized oracle rabbit hole. The crypto ecosystem is still maturing and we may end up building key infrastructure pieces along the way as we build MedX. We are exploring modifications to the TIL protocol which could serve as a trustless and secure method to migrate virtually any piece of objective data to a blockchain.

Give it a TRY

The Objective TCR (TIL) protocol is in beta 1.0 on the Ropsten Testnet using ERC-20 token metadata as a use-case: https://tokenregistry.medxprotocol.com/. Expect bugs!

A TCR Protocol Design for Objective Content was originally published in MedX Protocol on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the development of nascent technologies, protocol design breakthroughs can often be applied broadly. This is certainly the case in the recent explosion of decentralized ecosystems. While a particular development may be designed with a specific use-case in mind, the fundamental game theory, incentive scheme and protocol is likely widely applicable.

One contemporary example is SpankChain’s state channels. While originally launched in 2015 as a payment system for adult content, SpankChain’s state channels have been widely praised as a potential solution to increasing throughput and decreasing gas costs in the Ethereum ecosystem.

alex van de sande on Twitter

When I first heard about @SpankChain I've dismissed as "whatever, porn's an early adopter and they want to jump the ICO bandwagon". Then they started shipping production state channels and working apps and I found it a funny curiosity. But Chelsea makes it about something bigger.

Crypto Bobby on Twitter

Malta highlight: hearing someone talk down to @ameensol as he describes SpankChain, then their jaw drops when he discusses an algorithmic stablecoin and state channels

For us, what started out as a Token Curated Registry (TCR) of physicians, has evolved into an entirely new TCR design for curating any list of objective content.

The MedX TCR was designed for the purpose of creating a decentrally maintained, global network of physicians where verifiers worldwide reviewed physician credentials for admission to the registry. This network of physicians could then be instantly accessed for free by any healthcare or telemedicine application (more details can be found here). This TCR design, however, can be used for a multitude of other applications. Specifically, I’d like to discuss the potential utility of our TCR in decentralizing the token listing process for decentralized exchanges (“DEXs”).

One step closer to fully decentralizing DEXs

Since the public release of the SEC report on EtherDelta, DEXs fell under public scrutiny when it became apparent that decentralized exchanges are, in many ways, actually centralized.

Today, nearly all DEXs have a centralized token listing process whereby exchange owners manually list tokens. Even for DEXs with public/open token listings, the exchange owners manually mark or rank the legitimate tokens so that traders can avoid confusion with undesirable tokens. This process is carefully monitored to ensure that the listed or “verified” tokens have correct contract owner addresses, ticker symbols and logos to prevent any confusion or costly mistakes by traders. This information is currently maintained by exchange owners, MetaMask personnel and other centralized third parties.

This process can actually be quite burdensome, as stated by the MetaMask team in the MetaMask GitHub under Submission Process.

“Maintaining this list is a considerable chore, and it is not our highest priority. We do not guarantee inclusion in this list on any urgent timeline. We are actively looking for fair and safe ways to maintain a list like this in a decentralized way, because maintaining it is a large and security-delicate task.”

We believe that our TCR could be the decentralized solution that the MetaMask team describes.

The Token Registry for DEXs

We propose The Token Registry as a decentrally curated list of verified ERC-20 tokens. The output of this registry is a list of tokens with the following curated information:

• One unique name/ticker symbol per token
• One contract owner address per token

With this verified information, traders on exchanges need not worry about being accidentally or intentionally spoofed into buying undesirable or fraudulent assets. Moreover, by requiring a fee and deposit to register a token on The Token Registry, the registration of spam tokens will be minimized.

The Token Registry is now available for testing on the Ropsten Testnet at https://tokenregistry.medxprotocol.com. With app-native faucets and an easy UI, users can begin registering tokens and verifying submissions in minutes (as shown below).

After a brief period of bug fixes, we aim to deploy The Token Registry on Ethereum mainnet in early Q1 2019. As the list of registered tokens grows, we foresee this as an affordable and expedient option for exchanges to decentralize the token listing process.

How does The Token Registry relate to MedX?

Over the past year, we set out to develop a TCR of physicians. After carefully studying and testing the existing TCR models, we concluded that the incentive structure of these TCRs could be improved for the curation of lists of objective information. This is expounded on in greater detail in Dr. Praver’s article on Subjective vs Objective TCRs. In brief though, the incentive structure for the adChain TCR model is dependent on disagreements between token-holders in verifying subjective content (e.g. America’s best colleges, New York’s worst restaurants). In the curation of objective content, however, there is rarely disagreement and, in turn, rarely rewards for curating content. This is a problem for decentralized platforms that use the adChain TCR for curating objective content. Despite this challenge, most existing TCRs are still based off the adChain design, which is detailed further in Mike Goldin’s seminal blog post.

For the MedX Protocol, we needed a TCR that properly incentivized verifiers of objective content — physician credentials. This required an entirely new TCR design whereby verifiers are properly incentivized to perform quality work even if there is little friction or disagreement with other token holders/verifiers.

From the ground up with entirely new smart contracts and user interface, we built a new TCR model for objective content.

Stay tuned next week when Dr. Praver and our development team will publicly release a detailed description and parameters of our TCR protocol!

Conclusion

The Token Registry could be useful for taking DEXs one step closer toward, well, decentralization. By implementing a decentralized token listing process that is trader-friendly, DEXs would no longer be responsible for manually listing or verifying new tokens.

Lastly, The Token Registry will serve as a great way to test our new TCR protocol before launching the MedX physician TCR on Ethereum mainnet. This is critical to avoid a situation where potentially fraudulent, non-credentialed physicians could enter the MedX Health System.

A TCR that decentralizes token listing on DEXs was originally published in MedX Protocol on Medium, where people are continuing the conversation by highlighting and responding to this story.

I am pleased to formally announce our partnership with MakerDAO! Maker provides the MedX ecosystem with a “stablecoin” called Dai. The most important thing to know about Dai is that 1 Dai = 1 USD. This means that patients and physicians who use dApps in the MedX Health System do not have to worry about the volatility of cryptocurrencies like ETH and MEDX.

The most important thing to know is that 1 Dai = 1 USD

Interestingly, our partnership with MakerDAO uses their ecosystem in three different ways. Let’s dive into the details.

Direct ERC-20 Payment

The most direct way that we use MakerDAO is by supporting direct payment from patients to physicians using Dai. Like many other tokens including MEDX, Dai is based on the ERC-20 standard. This means that the smart contracts we write can send Dai just as easily as any other ERC-20 token.

On-chain ETH:USD price feed

At this time ~62M Dai are in existence and they are held in ~7,000 different accounts. While this number keeps climbing, it is still much smaller than the market cap of ETH (currently ~$21B) held in ~44M accounts. Knowing that our users need ETH to pay for gas fees anyway, we wanted to find a way to support payment in ETH and offer users a stable price quote.

Fortunately MakerDAO has an excellent on-chain ETH:USD price feed. This price feed is critical to the underlying collateralized debt position system that is the backbone of the MakerDAO design. This price feed is public infrastructure and we make use of it to quote prices in ETH but fix this to a constant USD value.

Trading ETH to Dai

Finally, because we support payment using ETH, we want to offer our physicians an easy method to switch their ETH into Dai to avoid the possibility of future volatility. MakerDAO provides an extremely easy-to-use on-chain exchange called Oasis Direct. We offer Oasis Direct to our users by providing a link to the Oasis Direct exchange within the MedX wallet.

With the MakerDAO integration now complete, it becomes quite straightforward to add this functionality to additional dApps in the MedX Health System. Here’s looking forward to future collaboration!

About MedX Protocol

MedX is a permissionless protocol for launching medical dApps that connect patients and physicians worldwide for medical care. Applications on the MedX protocol can be used to eliminate intermediaries and international barriers to affordable care. OpenCare is the first dApp on MedX and creates a market for telemedicine that reduces global disparities in medical care. For more information, please visit us at https://medxprotocol.com/.

MedX Partners with MakerDAO was originally published in MedX Protocol on Medium, where people are continuing the conversation by highlighting and responding to this story.

Worker Selection Algorithms

tldr; In this article we outline two approaches to Worker selection in a Work contract: Stake-weighted and Fair. Stake-weighted selection uses a probability proportional to the stake size, while fair has a uniform distribution. We found Stake-weighted worker selection gas usage, at best, grows linearly with the number of workers. Fair worker selection gas usage is constant, making it possible to support a large number of workers.

Introduction

A Work contract is a mechanism that determines who is able to participate as a “Worker” in a cryptoeconomic system. To become an eligible Worker, a user must stake tokens. When a new Job is available, a Worker is selected to complete it.

There are two approaches to the selection of Workers from Work Contracts. The first method is Stake-weighted Worker Selection, which permits a flexible stake size and selects workers using weighted probability. The second method is Fair Worker Selection, which ignores the stake size and instead selects workers using a uniform distribution.

Stake-Weighted Worker Selection

This method uses the proportional size of a worker’s stake to determine the probability that they are selected for the next job.

For example: imagine there are two workers where one has staked 1000 tokens while the other has staked 2000 tokens. The workers can be mapped to the probability space using their tokens:

[0, 1000)[1000, 3000)

The space consists of intervals, whose length is determined by the number of tokens a Worker has staked. When we wish to select a Worker, we generate a pseudo-random number in this space and select the worker to whom the chosen interval belongs.

More formally, we are looking to sample from a discrete probability distribution. This is a well-known problem and there are a number of algorithms we can use, each with their own advantages and disadvantages. I will detail the linear search, binary search, and the alias method.

Linear Search

Linear search is the most naive approach of the algorithms. Here we store a list of Workers that represents the order of the intervals in the space. When we wish to select a Worker we generate a pseudo-random number then iterate through the list to find the interval that contains it.

We assume we are using a doubly linked list with an index that maps Workers to list nodes.

Time Complexity

• Insertion: Updating the list of workers would be extremely fast; we can simply append to the end of the list. This can be done in constant time, as the time needed to insert remains constant no matter how many workers are in the list. Constant time is O(1).
• Removal: if we use a doubly linked list and index the nodes then we can perform removal in O(1) by using the index to look up the node and unlink it.
• Search: To find the correct interval we would need to look at (potentially) every single worker in the list. Thus it’s O(n), as the time to search would increase linearly with the number of workers.

Space Complexity

• Insertion: O(1)
• Removal: O(1)

Binary Search

This method improves on the Worker selection by sorting the list of Workers and subdividing the search space in iterations.

We assume that we are using an array to store the sorted intervals.

Time Complexity

• Insertion: First we find the right spot for the element in the list, and then we insert into the array by shifting the elements. O(log2(n)) + O(n)
• Removal: First we find the element in the list, then we remove it and shift the elements of the array back. O(log2(n)) + O(n)
• Search: O(log2(n))

Space Complexity

• Insertion: We would make n writes at worst case, so O(n)
• Removal: We would make n writes at worst case, so O(n)

Alias Method

The alias method allows us to select a worker in constant time. The method works by aliasing elements that are weighted below average to ones that are above average. There are two arrays; the first stores the probabilistic weight of each worker, the second stores the alias of each worker.

When a worker is to be selected a pseudo-random number between 0 and 1 is generated. That number is normalized to the number of workers and rounded to the next lowest integer to select a worker from the first array. The remainder from the rounding is then used as a ‘coin toss’ to determine whether to select the first element, or it’s alias. If the remainder is less that the probability of the worker, then select the worker. Otherwise select the worker’s alias.

Time Complexity

• Insertion: The algorithm is known to need O(n) to calculate the arrays
• Removal: We’d need to recalculate the arrays, so O(n)
• Selection: Selection always take the same number of steps, so O(1)

Space Complexity

• Insertion: O(n) to store the two arrays
• Removal: O(n) to re-calculate the two arrays

Limitations

If we start to consider space complexity in terms of gas, we can see the limitations of each algorithm using rough estimates.

As seen below, implementing a weighted selection algorithm isn’t feasible for high numbers of Workers with the current Ethereum gas limits (8,000,000). Linear search is fast to update, but the selection is expensive. At 1,000 workers linear search costs 200,000 gas, and that estimate only includes the SLOAD opcode. Binary search and the alias method don’t even begin to approach that efficiency; at 100 workers they’re already hitting 2,000,000 in gas costs.

For this reason, most Work protocols that utilize Stake-weighted selection limit the number of Workers numWorkers = _numWorkers;

Fair Worker Selection

Selecting workers using an even probability simplifies the cost dramatically. By removing the weighted probability we no longer need to search to find the matching interval, instead we can simply pseudo-randomly select a worker from an array.

The most equitable way to structure such a Work contract is to explicitly define the stake size per worker require(msg.value == workerStake); This, admittedly, has the down side of requiring Workers who hold large amount of stakes to run multiple Worker accounts and would disqualify Worker candidates who do not meet the minimum required stake.

Array Storage

Assume we store the workers in an array and have a mapping from worker to array index.

Time Complexity

• Insert: We can push a new worker onto the end of the array in O(1)
• Remove: We can find the array index using the mapping, then put the last element into that slot in O(1)
• Select: We generate a pseudo-random number in the range [0, n) and use that to index the workers array in O(1)

Space Complexity

• Insert: inserting one element would write once onto the end of the array O(1)
• Remove: Removing one element will clear the old value and transfer the last in O(1)

Conclusion

We have outlined two broad categories of Worker selection: Stake-weighted and Fair. Stake-weighted worker selection selects workers with a probability proportional to the size of the Worker’s stake, while in Fair selection all Workers have an equal chance of being selected. We found that the gas costs of stake-weighted selection algorithms increase along with the number of Workers, whereas Fair selection gas costs remain constant.

Some stake-weighted approaches limit the number of workers, such as LivePeer which limits it’s number of workers to twenty. If the number of workers is small or capped to a few hundred workers or less, then a stake-weighted algorithm may be feasible. Gas costs for linear search would only be in the hundreds of thousands. If you select a worker far more often than you update the workers an algorithm such as the alias method may be more gas-efficient.

Fair worker selection, on the other hand, can support an unlimited number of workers (potentially). Its only drawback is that it’s not possible to favor particular workers.

In summary, the worker selection algorithm you choose will be highly dependent on your use-case. It’s important to consider the limitations of the algorithms before deciding on which one to use.

Creating a Work Token — Part I was originally published in MedX Protocol on Medium, where people are continuing the conversation by highlighting and responding to this story.

After a year of development and four months of public testing, OpenCare is now live on Ethereum Mainnet! To our knowledge, this is the first ever healthcare application that uses Ethereum smart contracts to achieve true peer-to-peer consultations.

In the initial launch, OpenCare makes it possible for referring healthcare providers worldwide to quickly obtain diagnoses and recommendations from a global network of physician specialists.

About half of the world population — 3.8 billion people — do not have access to basic healthcare. Even fewer have affordable access to physician specialists, such as dermatology and ophthalmology. In the USA, according to HRSA, 28% of the population does not have access to specialty care.

Access to primary care is far from a guarantee that specialty care is available if needed.

OpenCare makes it possible for every primary care provider to treat ailments that would traditionally require separate visits with physician specialists.

Imagine primary care clinics now empowered with a user-friendly app that allows them to quickly access a global network of specialists via telemedicine. For any patient with, for example, a skin ailment, a primary care provider could use the app to snap some photos, provide a brief description and submit the case to a global network of board certified dermatologists attached with a small payment. Minutes later, a medical diagnosis and treatment plan will guide the primary care provider in prescribing treatment and follow-up. Primary care clinics that use OpenCare to support subspecialty services will be more convenient and affordable for patients — drawing larger patient volumes. Everybody wins.

On-boarding primary care providers to OpenCare is a big step toward adoption. While patients individually may only use a healthcare app a few times a year, primary care physicians encounter multiple patients daily who need specialist attention.

A good experience on OpenCare can result in a single primary care provider using the app hundreds of times a month.

With just 100 primary care providers worldwide on OpenCare, it would be possible for OpenCare to become one of the most popular dApps on DappRadar.

Why doesn’t Teladoc do this already?

Teladoc is presently the largest US telehealth company, and is valued at about 5 billion USD. As a centralized company that controls the storage of patient health information, Teladoc cannot launch a global healthcare market. The regulatory framework for cross-border telemedicine and 3rd party control of health information (e.g. intermediary between patient and physician) does not allow it.

OpenCare is different from Teladoc in that the entire encounter is controlled by the user. There is no company behind OpenCare that views or stores patient health information. OpenCare uses Ethereum smart contracts to guide the encounter, client-side encryption for health information and IPFS for decentralized cloud storage. This effectively makes OpenCare a “bulletin board” for healthcare services allowing it to bypass international barriers to cross-border telemedicine. The technology and infrastructure to build this didn’t exist 2 years ago. Now it does and OpenCare will be the first platform to make a global market in telemedicine.

OpenCare is available for public testing or use at opencare.medxprotocol.com. If your MetaMask or Coinbase dApp browser is on the Ropsten testnet, you will be able to demo the app for free, although you will not receive a true medical evaluation. However, for a small fee of 10 USD per evaluation, the live version is available on Ethereum mainnet.

OpenCare is just the first of many potential applications to be powered by MedX Protocol. As an open system, we look forward to working with health innovators around the world to launch healthcare dApps that eliminate intermediaries and artificial boundaries in today’s health systems.

About MedX Protocol

MedX is a permissionless protocol for launching medical dApps that connect patients and physicians worldwide for medical care. Applications on the MedX protocol can be used to eliminate intermediaries and international barriers to affordable care. OpenCare is the first dApp on MedX and creates a market for telemedicine that reduces global disparities in medical care. For more information, please visit us at https://medxprotocol.com/.

OpenCare powered by MedX is now live on Ethereum Mainnet was originally published in MedX Protocol on Medium, where people are continuing the conversation by highlighting and responding to this story.

If the current sentiment of crypto enthusiasts could be summed up in one word, it would be build. Here at MedX, that’s what we’ve done. Instead of obsessing over the cryptocurrency price slump, we have taken advantage of this time to increase our development efforts to be one of the few platforms to successfully launch on Ethereum mainnet in 2018.

From the day we first conceived the vision for MedX in 2016, our mission has been to create a global healthcare market that is freely available to patients, physicians and developers worldwide.

The technology and infrastructure to build this open healthcare market is just now approaching a state of maturity, and could not have been accomplished even 2 years ago. Let’s take a step back to see why.

When I mention that our team is building an “open global healthcare market,” the first question or comment I receive is either Is that legal? or Healthcare is so regulated, tech progress is slow. Good luck. I agree. These are nearly always prudent comments regarding healthcare innovation. However, they actually highlight the advantage of what we are building here at MedX Protocol.

One of the key regulation checkpoints in healthcare is storage and transfer of patient health information (PHI). There are pages upon pages of compliance guidelines both locally (in the USA, at the state level) and nationally (e.g. HIPAA, GDPR). These guidelines can be difficult to navigate and costly. Moreover, the guidelines for the international storage and transfer of patient health information are not well delineated. These compliance burdens are a barrier to innovation for startups. Even for established companies or systems, the penalties for a breach or mistake in an uncertain area of compliance can be intimidating.

In the USA, a breach of HIPAA can cost an HHS fine up to $1.5 million/violation, State Attorneys General penalty up to $6.8 million, FTC fine of $16,000/violation, and a lawsuit up to $1000 per record.

Given the penalties, it is no surprise that centralized companies cautiously tiptoe toward technological progress when the stakes are so high. As long as centralized companies control patient-physician encounters and are liable for storage of patient health information, it is unlikely that a global healthcare market will exist in the near future.

What if the direct control of both health information and selection of healthcare provider was entirely in the patient’s hands? Without a centralized company acting as the custodian of PHI and managing healthcare providers, these compliance burdens disappear.

In essence, I’m describing an open global healthcare market that can be interpreted as a “bulletin board” for health services. This is the MedX Protocol advantage. Patients worldwide can immediately connect with a global network of physicians, and provide the relevant health information for diagnoses and treatment plans via telemedicine.

Studies shows that up to 75% of in-office health visits can be addressed via telemedicine over video or pictures.

On MedX, at no point does a centralized company have the power to view, control, store or transfer patient health information. It is entirely in the patient’s hands what health information is shared with a physician.

Again, the technology to build this decentrally maintained global health market was not available until just recently. It requires a public blockchain with smart contract functionality (e.g. Ethereum), IPFS for decentralized cloud storage, mobile dApp browser (e.g. Coinbase wallet dApp browser), and client side encryption. All of this technology is employed in the MedX Protocol. The result is a global healthcare market controlled by the people who use it.

Since 2016, we have built out the critical infrastructure to move that mission forward and are rapidly becoming well-positioned for a successful launch of the MedX health system. Let’s go ahead and dive into the layers of the MedX health system that we have developed thus far.

Protocol Layer

The protocol layer consists of our decentralized physician registry, MedX. We have developed the first token-curated registry (TCR) of physicians. For those unfamiliar with TCRs, a TCR is a decentrally maintained list judiciously curated by token holders in exchange for economic rewards. Upon launch of MedX, verifiers around the world will carefully curate and decentrally maintain a global pool of licensed and certified physicians in exchange for MEDX tokens and ETH.

The MedX Physician Registry will be freely available for any 3rd party healthcare application or dApp dev team to access. This means that any healthcare application will have immediate access to a global network of physicians from a multitude of specialties.

The Alpha release of the MedX Registry has been privately tested since June 2018, but is now available at registry.medxprotocol.com. Alternatively, a video demonstration of the registry is now available.

MedX Registry Development Milestones

• MedX physician registry smart contracts deployed on Rinkeby testnet
• Integration with IPFS for decentralized storage of physician credentials
• Integration with the Civic Secure Identity Ecosystem for convenient physician login
• MEDX wallet integrated with MetaMask and user interface
• Friendly user interface for reviewing, flagging or verifying physician credentials

DApp Layer

Any 3rd party developer or existing healthcare application can access the MedX registry for an instant pool of physicians. After months of rigorous development, we built OpenCare as the first dApp to be launched on the MedX Protocol.

OpenCare will give patients and referring healthcare providers access to a global network of specialists for diagnosis and treatment recommendations. Dermatology for the diagnosis and treatment of skin ailments will be the first specialty supported on OpenCare, but it will later include ophthalmology, radiology, psychiatry and general practice medicine.

OpenCare is a true dApp in the sense that the patient-physician encounter is controlled by Solidity smart contracts, patient health information is encrypted on the client side and uploaded to IPFS for decentralized cloud storage, private keys are patient-controlled and physicians are granted access to health information directly by patients in signed transactions. At risk of ad nauseam, the MedX Team cannot view or control patient health information, and OpenCare is essentially a “bulletin board” that connects patients with physicians.

In public beta testing since July 2018, OpenCare will be launched on Ethereum mainnet by October 11, 2018. The product video demo can be viewed here or you can test it for yourself at opencare.medxprotocol.com.

OpenCare Development Milestones

• Integration with IPFS for decentralized storage of patient records
• Automated image compression for faster uploading/downloading
• General-purpose redux-saga library to interact with Ethereum Virtual Machine
• Online/offline pubsub for efficient distribution of patient cases to online physicians
• Built-in faucets for maximum convenience
• Friendly user interface for both patients and physicians with notifications, status bars and MetaMask integration
• Partnership with MakerDAO and integration with DAI token and ETH for payment
• Compatibility with mobile Coinbase wallet dApp browser

Formation of OpenCare Clinical Advisory Board

• Arjun Dupati, MD
• Dhwani Mehta, MD
• Noor Tazudeen, MD
• Nikhil Shyam, MD
• Mario Mitkov, MD
• Ryan Trowbridge, MD
• Newsha Lajevardi, MD
• Ivanka Kovalyshyn, MD
• Geeta Patel, MD
• Rohit Kakar, MD

Final Words

As is the case with most decentralized systems, there is some initial degree of centralization during the infancy state to ensure that there is a smooth mainnet launch. For OpenCare, this will initially consist of a small pool of licensed dermatologists available to provide recommendations for skin ailments.

However, once the MedX Registry is launched on Ethereum mainnet in Q1 2019, OpenCare will access the MedX physician registry to be a fully decentralized ecosystem from Ethereum blockchain to application layer, and will support a multitude of medical specialties (not just dermatology). Moreover, any 3rd party will be freely able to launch their own unstoppable medical dApps on the MedX Protocol.

Lastly, we would like to thank all those in our community for testing and providing feedback these past few months!

For any questions, we are available on Telegram or you can visit us at https://medxprotocol.com/.

Preparing for the launch of MedX was originally published in MedX Protocol on Medium, where people are continuing the conversation by highlighting and responding to this story.

TLDR; I’ve developed a tool called Truffle Deploy Registry that separates your deployed contract addresses by network from the Truffle complication artifacts. Compatible with all versions of Truffle (up to the latest 5.0)

Continuous deployment is achieved when changes to a codebase are automatically pushed live, whether to a staging or production environment.

Typically:

1. Code is pushed to a repository
2. Tests are run on a continuous integration (CI) server
3. If tests pass, code is deployed.

Continuous deployment allows us to iterate rapidly with a product.

Truffle is a fantastic tool for smart contract development that makes testing and deploying contracts a breeze. The only issue preventing it from smoothly integrating with continuous deployment is the fact that it generates very heavy artifacts.

Truffle artifacts contain the addresses at which the contracts are deployed. These artifacts can be pulled in or referenced by front-end code so that we can interface with them. However, the artifacts also include local filesystem paths that make them unsuitable to commit to the repository. Continuous deployment can only pull information from committed files, so how do we get around this?

I’ve developed a tool called Truffle Deploy Registry that separates the deployed contract address from the artifacts into files separated by network. You can .gitignore the local development networks, and commit testnet files so that the CI server can pick them up.

Truffle Deploy Registry

Truffle Deploy Registry works in two stages:

1. New deployment entries are recorded in a network-specific JSON file.
2. The latest deployment entries are merged with the truffle artifacts after compilation.

Typically with Truffle you’ll be using migrations to deploy and update your smart contracts. To add contracts to the deploy registry, you must append them within your migrations:

// migrations/1_initial_migration.js

var append = require('truffle-deploy-registry').append
var Migrations = artifacts.require("./Migrations.sol");

module.exports = function(deployer, network) {
  deployer.deploy(Migrations).then(() => {
    return append(
      deployer.network_id,
      { contractName: 'Migrations', address: Migrations.address }
    )
  })
}

Now that contract address will be appended to the registry for the deployed network. If you have deployed to mainnet and Ropsten, you will now have the files:

networks/
  1.json
  3.json

Inside each of those files will be a list of deployed contracts. You would see something like:

# networks/1.json
[
  {
    contractName: 'Migrations',
    address: '0x3383c29542b8c96eafed98c4aafe789ddb256e19'
  }
]

Now you have a registry of where those contracts are stored. To merge those addresses back into the Truffle compilation artifacts you would use the apply-registry command. It takes the path to the build artifacts as a parameter:

$ apply-registry build/contracts

This ensures that the artifacts contain all of the *newest* addresses defined in the registries in the networks directory.

Now, when your CI server builds your front end code and pulls in the artifacts they will all have the correct addresses.

I hope this helps you in some way. Check out Truffle Deploy Registry on Github!

Brendan Asselstine

Medium: Brendan Asselstine

Github: https://github.com/asselstine

Continuous Deployment with Truffle was originally published in MedX Protocol on Medium, where people are continuing the conversation by highlighting and responding to this story.