Shyft Tech Update: Intro to Shyft

Shyft Principles; Users and Their Data + Shyft System Design; Resolution, Redundancy, and CAP Formation

If everything seems under control, you’re not going fast enough. — Mario Andretti

Hi everyone :) I’m Chris Forrester, Chief Technology Officer of the Shyft Network.

Shyft was created by teams from two companies joining forces: BlockUnity, an asset-backed cryptocurrency technology company, and Paycase, which specializes in decentralized financial services, including a mobile-based platform that uses blockchain technology to assist in delivering assets internationally. Paycase has recently partnered with the Toronto Stock Exchange (TMX Group) to launch brokerage services.

We’ve been working away on the Shyft project since November of last year, and have been steadily building up our partnerships, technology platform, and operational continuum in that time. Our core team consists of alumni from Paycase, BlockUnity, and Decentral/Jaxx.

In layman’s terms, Shyft is a protocol that leverages blockchain technology to enable users to obtain, store, and work with data and identity quickly and securely. The Shyft Network Whitepaper elaborates on this context. In application, we’re going to release a dedicated blockchain of our own, aptly named the Shyft Blockchain.

In layman’s terms, we’re building cool sh*t.

While our published partnerships have so far focused on one of our major use cases — the usage of Shyft to satisfy KYC and AML requirements in order to proper fit a blockchain transactional asset model into the world at large — what we’re planning, and are actually building, has considerably broader implications and a wider variety of potential use cases we’re exploring.

The most exciting aspect of Shyft as a project is that we’ve already made great strides and have reached major operational milestones; we’re not waiting idly and hypothesizing, but instead working with our institutional and private partners to build and deliver real solutions. Before I say more about what those solutions might look like, I want to take a moment to talk about the concerns that made us want to build Shyft to begin with.

Shyft Principles; Users and Their Data

Since the genesis of the web, consumers have had their online data reviewed, abstracted, and transmitted to an enormous amount of third parties. This data (your data) is the core component of many operational businesses and how they target services to consumers. Without access to this data, most major tech firms are not only flying blind, they have no workable business model to speak of.

This practice, while seemingly benign and well-intentioned, leads to a variety of situations that are untenable. The cycle looks like the following:

  1. There are data breaches at regular intervals¹
  2. These breaches reveal personal information to malicious third parties²
  3. This cycle repeats, and because it is so ingrained in the web culture, large companies that control a majority of specific sectors become targets³
  4. The tools used to perform these breaches, as they are successful in their design, are repackaged and resold within dark markets, are refined, and result in further breaches.

A continuing spiral of this practice creates a situation of distrust towards (legitimate) product platforms, however, as there are no viable alternatives to those platforms or to the practice itself, the result is simply unrest and increased regulation that is always a step behind in the proverbial game. This increases costs towards service providers, which are of course passed along to the consumers.

Our principal motivation when developing the Identity features of the Shyft Network is to behave proactively instead of reactively in our approach. As such, we’ve created a platform that respects these key ideals:

  1. The basis must be that the consumers come first.
    All actions regarding the transfer and approval of data transfer is done with the informed consent of the consumer.
  2. The cost to the consumer must be minimal, including the time cost to set up accounts.
    All message construction must satisfy an absolute minimum requirement to perform its purpose. In the case of transactional exchanges, a “stamp of authenticity” to a particular (pseudonymous) account is placed by an institution (in our vernacular, a Trust Anchor). This account now has (with the creation of a layer we’ve called a Trust Channel that is managed by the aforementioned Trust Anchors) a transactional flow channel associated with it. This leverages any existing coalitions between Trust Anchors, and allows for a malleable construction of these Trust Channels based on a number of parameters.
  3. Transferability of these identification points should be as secure as possible.
    There is to be no transmission of actual consumer data on the blockchain layer. All transmission is using GDPR and other jurisdictional requirements towards user privacy, data transmission, and consent-first transmission methodologies.

Shyft System Design; Resolution, Redundancy, and CAP Formation.

With the Shyft Network protocol, we’re focusing on two things:

Availability (the “Shyft Ring”)
The “last mile” connection between the Shyft blockchain and the end users (mobile wallets, for example) should be incredibly robust. Instead of situations where, if a service such as Etherscan was taken down/DDOS’d, etc, there would be an inability for wallets or other services to get user balances and forward presigned transactions, any of the edges of the Shyft Network will be able to provide the same service. There are additional anti-censorship features at this layer which we’ll get into soon.

Partition Tolerance (the “Shyft Bridge”)
Having block headers being curated to other EVM compatible blockchains (and specialized software to provide these Merkle Tree proofs to other non-EVM blockchains) allows for a system design where data can be proven to exist at specific checkpoints, even without other blockchains being available for querying directly past checkpoint times. With a robust smart contract software layer (including time-locking and failsafes for asset transfers), we can create guaranteed transactional event horizons across many blockchains.

While we will be providing (a lot) more detail about the various components in upcoming posts by our systems engineers, this graphic is a good primer for the components of the protocol level of the system.

We’ll be publishing regular posts to outline the process, status, and future of our project over the coming weeks and months. You can expect a diverse series of posts from different members of our technical team that will dive deep into the inner workings of Shyft’s various components and initiatives. We’ll also be sharing demos and answering your questions about the technology and how we envision it’ll work.

Next time, I’ll be talking about what we term “The New Economy” in regards to data markets and participatory reward systems, as well as speaking more broadly to our development model and the particular joys and challenges of our unique development model. Stay tuned, and feel free to lob questions at us on our Telegram channel


¹ The 17 biggest data breaches of the 21st century: Security practitioners weigh in on the 17 worst data breaches in recent memory.

² Data Thieves: The Motivations of Cyber Threat Actors and Their Use and Monetization of Stolen Data

³ Facebook: ‘Malicious actors’ used its tools to discover identities and collect data on a massive global scale:


Shyft is building the world’s first modern, secure, multi-stakeholder Blockchain-based digital identity solution that enables KYC/AML attested data transfers. Join our Telegram (, follow us on Twitter (, GitHub ( and other channels found on