A brief history of R3 – the Distributed Ledger Group

What’s in a name?

I was at an event last week and someone pulled me aside asked: why do you guys at R3 typically stress the phrase “distributed ledger” instead of “blockchain”?

The short answer is that they are not the same thing.

In simplest terms: a blockchain involves stringing together a chain of containers called blocks, which bundle transactions together like batch processing, whereas a distributed ledger, like Corda, does not and instead validates each transaction (or agreement) individually.1

The longer answer involves telling the backstory of what the R3 consortium is in order to highlight the emphasis behind the term “distributed ledger.”

Inspired by IMF report, page 8


R3 (formerly R3 CEV) started out as a family office in 2014.2 The “3” stood for the number of co-founders: David Rutter (CEO), Todd McDonald (COO), and Jesse Edwards (CFO). The “R” is the first initial of the CEO’s last name.  Very creative!

During the first year of its existence, R3 primarily looked at early stage startups in the fintech space.  The “CEV” was an acronym: “crypto” and “consulting,” “exchanges,” and “ventures.”

Throughout 2014, the family office kept hearing about how cryptocurrency companies were going to obliterate financial institutions and enterprises.  So to better understand the ecosystem and drill into the enthusiasm around cryptocurrencies, R3 organized and held a series of round tables.

The first was held on September 23, 2014 in NYC and included talks from representatives of: DRW, Align Commerce, Perkins Coie, Boost VC, and Fintech Collective.  Also in attendance were representatives from eight different banks.

The second round table was held on December 11, 2014 in Palo Alto and included talks from representatives of: Stanford, Andreessen Horowitz, Xapo, BitGo, Chain, Ripple, Mirror, and myself.  Also in attendance were representatives from 11 different banks.

By the close of 2014, several people (including myself) had joined R3 as advisors and the family office had invested in several fintech startups including Align Commerce.

During the first quarter of 2015, David and his co-founders launched two new initiatives.  The first was LiquidityEdge, a broker-dealer based in NYC that built a new electronic trading platform for US Treasurys.3  It is doing well and is wholly unrelated to R3’s current DLT efforts.

The second initiative was the incorporation of the Distributed Ledger Group (DLG) in Delaware in February 2015.  By February, the family office had also stopped actively investing in companies in order to focus on both LiquidityEdge and DLG.

In April 2015 I published Consensus-as-a-Service (CaaS) which, at the time, was the first paper articulating the differences between what became known as “permissioned” and “permissionless” blockchains and distributed ledgers.  This paper was then circulated to various banks that the small R3 team regularly interacted with.

The following month, on May 13, 2015, a third and final round table was held in NYC and included talks from representatives of Hyperledger (the company), Blockstack, Align Commerce and the Bank of England.  Also in attendance were representatives from 15 banks as well as a market infrastructure operator and a fintech VC firm.  In addition to the CaaS paper, the specific use-case that was discussed involved FX settlement.4

The transition from a working group to a commercial entity was formalized in August and the Distributed Ledger Group officially launched on September 1, 2015 although the first press release was not until September 15.  In fact, you can still find announcements in which the DLG name was used in place of R3.

By the end of November, phase one of the DLG consortium – now known as the R3 consortium – had come to a conclusion with the admission of 42 members.  Because of how the organization was originally structured, no further admissions were made until the following spring (SBI was the first new member in Phase 2).

So what does this all have to do with “distributed ledgers” versus “blockchains”?

Well, for starters, we could have easily (re)named or (re)branded ourselves the “Blockchain Group” or “Blockchain Banking Group” as there are any number of ways to plug that seemingly undefinable noun into articles of incorporation.  In fact, DistributedLedgerGroup.com still exists and points to R3members.com.5 So why was R3 chosen?  Because it is a bit of a mouthful to say DistributedLedgerGroup!

Corda’s genesis

Upon launch, the architecture workstream lead by our team in London (which by headcount is now our largest office), formally recognized that the current hype that was trending around “blockchains” had distinct limitations.  Blockchains as a whole were designed around a specific use-case – originally enabling censorship-resistant cryptocurrencies. This particular use-case is not something that regulated financial institutions, such as our members, had a need for.

While I could spend pages retracing all of the thought processes and discussions surrounding the genesis of what became Corda, Richard Brown’s view (as early as September 2015) was that there were certain elements of blockchains that could be repurposed in other environments, and that simply forking or cloning an existing blockchain – designed around the needs of cryptocurrencies – was a non-starter.  At the end of that same month, I briefly wrote about this view in a post laying out the Global Fabric for Finance (G3F), an acronym that unfortunately never took off. In the post I specifically stated that, “[i]t also bears mentioning that the root layer may or may not even be a chain of hashed blocks.”

In October 2015, both James Carlyle and Mike Hearn formally joined the development team as Chief Engineer and lead platform engineer respectively.  During the fall and winter, in collaboration with our members, the architecture team was consumed in the arduous process of funneling and filtering the functional and non-functional requirements that regulated financial institutions had in relation to back office, post-trade processes.

By the end of Q1 2016, the architecture team gestated a brand new system called Corda.  On April 5, 2016, Richard published the first public explanation of what Corda was, what the design goals were and specifically pointed out that Corda was not a blockchain or a cryptocurrency.  Instead, Corda was a distributed ledger.

Prior to that date, I had personally spent dozens of hours clarifying what the difference between a blockchain and a distributed ledger was to reporters and at events, though that is a different story.  Unfortunately even after all these explanations, and even after Richard’s post, the Corda platform was still inappropriately lumped into the “blockchain” universe.

Following the open sourcing of Corda in November 2016, we formally cut the “CEV” initials entirely from the company name and are now known simply as R3.  Next year we plan to make things even shorter by removing either the R or 3, so watch out domain squatters!


As of February 2017, the R3 consortium is formally split into two groups that share knowledge and resources: one group is focused on building out the Corda platform and the other, the Lab and Research Center, is focused on providing a suite of services to our consortium members.  I work on the services side, and as described in a previous post, my small team spends part of its time filtering vendors and projects for the Lab team which manages several dozen projects at any given time for our consortium members.

The Lab team has completed more than 20 projects in addition to 40 or so ongoing projects.  Altogether these involved (and in some cases still involve) working with a diverse set of platforms including Ethereum, Ripple, Fabric, Axoni, Symbiont and several others including Corda.  Since we are member driven and our members are interested in working and collaborating on a variety of different use-cases, it is likely that the services side will continue to experiment with a range of different technologies in the future.

Thus, while it is accurate to call R3 a technology company focused on building a distributed ledger platform and collaborating with enterprises to solve problems with technology, it is not accurate to pigeonhole it as a “blockchain company.”  Though that probably won’t stop the conflation from continuing to take place.

If you are interested in understanding the nuances between what a blockchain, a database, and a distributed ledger are, I highly recommend reading the multitude of posts penned by my colleagues Antony Lewis and Richard Brown.

  1. Blockchains inspired by cryptocurrencies such as Bitcoin used blocks because Satoshi wanted identity-free consensus (e.g., pseudonymity).  That implies miners can come and go at will, without any kind of registration, which eliminated the choice of using any existing consensus algorithm.

    As a result, Satoshi’s solution was proof-of-work (PoW).  However, PoW is susceptible to collisions (e.g., orphan blocks).  When a collision occurs you have to wait longer to obtain the same level of work done on a transaction. Thus you want to minimize them, which resulted in finding a PoW on average every ten minutes.  This means that in a network with one minute propagation delays, not unlikely in a very large network (BGP sees such propagation times) then you waste ~10% of total work done, which was considered an acceptable loss rate in 2008 when Satoshi was designing and tweaking the parameters of the system.

    Distributed ledgers such as Corda, use a different design because it is an identified network, where members cannot just come and go at will, and do have to register. With Corda, the team also assumes relatively low propagation times between members of a notary cluster.  One of the key differences between mere PoW (i.e. hashcash) and a blockchain is that in the latter, each block references the prior – thus PoWs aggregate.  It can be tough to do that unless all transactions are visible to everyone and there is a single agreed upon blockchain but if you do not, you will not get enough PoW to yield any meaningful security. []

  2. The R3CEV.com domain was created on August 13, 2014. []
  3. It may look like an odd spelling, but Treasurys is the correct spelling. []
  4. At the time, I was an advisor to Hyperledger which was acquired by Digital Asset the following month. []
  5. The DistributedLedgerGroup.com domain was created on December 23, 2014 and R3members.com was created on March 15, 2016. []
Send to Kindle

Designing a Global Fabric for Finance (G3F)

Over the past two weeks there have been a number of news stories related to R3 — a fintech startup that I now work at.  The first of which was from the Financial Times, entitled Blockchain initiative backed by nine large investment banks.  Today we announced an additional 13 banks have joined our effort.

Although I cannot speak for the whole team, I can give you the vision I have with the aim of bringing clarity to the various bits of information that have been circulating.


Over the past year, the R3 team has spent copious amounts of time conducting due diligence on the greater “distributed ledger” or “shared ledger” space.  I joined as an advisor in January when they were already knee deep in the task; I am now Director of Market Research.

What I and several others on the team found is that while there were a number of orthogonally useful pieces floating around (such as multisig and ideas like Engima), none of the publicly available technology platforms that has been funded by venture capital provided a flexible, holistic base layer with the specific functional requirements for secure, scalable enterprise use.

This includes incorporating non-functionals that globally regulated financial institutions must adhere to such as: compliance, privacy, reporting and reconciliation.  Similarly, many of the venture funded projects also failed to address the business requirements of these same institutions.

In sportsball terms, the nascent industry is 0-for-2 in their current approach.

Some of that is understandable; for example, Bitcoin solves a set of problems for a niche group of individuals operating under certain security assumptions (e.g., cypherpunks not wanting to interface with banks or governments).  Regulated financial institutions do not operate under those assumptions, thus axiomatically Bitcoin in its current form is highly unlikely to be a solution to their problems at this time.  As a consequence, the technology solutions pitched by many of these startups are hammers looking for nails that do not exist in the off-chain world.

R3 is not a Bitcoin company nor a cryptocurrency company.  We are not seeking to build a “better” or even a different type of virtual currency.  Why not?  Instead of starting with a known solution, such as a spreadsheet, we are starting with the problem set which continually influences the customized solution.  This is one of the biggest reasons I was attracted to this specific effort: R3 is not a re-enactment of Field of Dreams.  Build it with the hopes that someone will come is the siren song, the motto even, for throngs of failed startups.

But weren’t the original shared ledgers — often called blockchains — robust enough to protect all types of assets and a legion of use-cases?

Many public ledgers were originally designed to secure endogenous, on-chain information (e.g., the native token) but in their current incarnations are not fit for purpose to handle off-chain titles.  For instance, Bitcoin was not initially designed to secure exogenous data — such as transmitting high-value off-chain securities — vis-a-vis pseudonymous miners.  And it appears all attempts to mutate Bitcoin itself into a system that does, ends up creating a less secure and very expensive P-o-P network.

What are we doing then?

Rather than try to graft and gerrymander our business requirements onto solutions designed for other problems, we are systematically looking at a cornucopia of challenges and cost-drivers that currently exist at financial institutions.  We will seek to address some of these drivers with a generalized agnostic fabric, with layers that fulfill the critical infrastructure specifications of large enterprises and with services that can be run on top in a compliant fashion.

What is a Global Fabric for Finance (G3F) then?  If you had the chance to build a new financial information network from scratch that incorporated some of the elements and learnings of the shared ledger world, what would it look like?

For starters, a fabric specifically built for and by trusted parties does not need something akin to mining or block rewards.  In fact, not only is there is no Sybil spoofing problem on a trusted network but there are already many known, existing methods for securely maintaining a transaction processing system.  Consequently, needing a block reward may (or may not) be a red herring and has likely been a costly, distracting sideshow to other types of utility that this technology represents.

If trust is not an issue, what use (as Arvind Narayanan and certain high profile enthusiasts have asked) is any part of the shared ledger toolkit?  There are a number of uses, many of which I touched on in a paper back in April.

What about specific use-cases?

While a number of ideas that have surfaced at conferences and media events over the past summer, R3 remains focused on an approach of exploration and ideation.

And while there will likely be some isolated tests on some use-case(s) in sand boxes in the coming year, it is important to reflect on the G3F vision which will be further elaborated on by Richard Brown (our head of technology) in the coming weeks.  If the fabric is only capable of handling one or two specific asset classes, it will fall short of the mandate of being a generalized fabric used to secure financial information for enterprises.

Why directly work with banks during this formative stage?  Why not just raise money and start building and shipping code?

To be frank, if financial institutions and regulatory bodies are not involved and engaged  from the beginning, then whatever fabric created will likely: 1) fail to be viewed as an authoritative and legal record of truth and 2) fall short of adequately address their exacting needs.  It would be a non-starter for a financial institution to use technology that is neither secure, or whose on-chain record is considered non-canonical by off-chain authorities.

What does that mean?

While some in the shared ledger community would like to believe that dry, on-chain code supersedes off-chain wet-code, the facts on the ground continue to contradict that thesis.  Therefore, if you are going to create a non-stealth fintech startup, it must be assumed that whatever products and services you create will need to operate under existing laws.  Otherwise you will spend most of your time hiding out in remote Caribbean islands or Thailand.


The R3 team is comprised of pragmatic thinkers and doers, experienced professionals who understand that a financial system cannot be built with up and down votes on reddit or whose transaction processors may reside in sanctioned countries.


Source: XKCD

While nothing is finalized at the time of this writing, it is our aim at R3 to make the underlying base layer of this fabric both open sourced and an open standard.

After all, a foundation layer this critical would benefit from the collective eyeballs of the entire programming community.  It also bears mentioning that the root layer may or may not even be a chain of hashed blocks.

Furthermore, we are very cognizant of the fact that the graveyard for building industry standards is deep and wide.  Yet, as I mentioned to IBT, failing to create a universal standard will likely result in additional Balkanization, recreating the same silos that exist today and nullifying the core utility of a shared ledger.

It is a pretty exciting time in modern history, where being a nerd — even a cryptonerd — means you are asked to appear on stage in front of decision makers, policy makers, captains of industry and social media influencers.  Some even get to appear in person and not just as a telepresence robot.  Yet as neat as some of the moon math and cryptographic wizardry may be, failing to commercialize it in a sustainable manner could leave many of the innovative forks, libraries and github repos no more than starry-eyed science fair projects.

To that end, we are currently hiring talented developers keen on building a scalable, secure network.  In addition, rather than reinventing the wheel, we are also open to partnerships with existing technology providers who may hold key pieces to building a unified standard.  I am excited to be part of this mathematical industrial revolution, it’s time to strike while the iron is hot and turn good academic ideas into commercial reality.  Feel free to contact us.

Send to Kindle