What problem are we trying to solve with Corda?

What problem are we trying to solve with Corda?

Todd pointed me at a great piece about “crypto finance” versus “regular finance” by Bloomberg’s Matt Levine earlier.

I thought he did a good job of nailing the essential contradiction that arises if one tries naively to apply Bitcoin or Ethereum principles directly to traditional finance. He uses the example of an Interest Rate Swap (IRS) and how a fully pre-funded model would kind of defeat the point…

This caught my attention because an IRS was the very first project we ever did on Corda! So it’s something I know a little about… Anyway, I think the key to understanding the mismatch is captured in a post of mine from 2015 about how two revolutions are playing out in parallel.

In short, the problem we in the Enterprise Blockchain space are trying to solve is related to but very different to the problem being solved by public blockchains. The prize is to take the “I know for sure that what I see is what you see” promise upon which public blockchains depend for their power — and apply it to the problem of making businesses run more efficiently and capture new opportunities enabled by knowing they are in perfect sync with their trading partners.

Anyway, I left a comment there but thought I should repeat it here too as I think it could be helpful to other people trying to understand how what we’re doing with Corda is so exciting…!

Hi Matt — Richard Brown (CTO of R3) here. I only just saw this piece. Music to my ears… I’ve been saying for as long as I can remember now that the opportunity for blockchain technology in finance is to record, manage and automate legal contracts. Make the existing world run better, not to usher in an entirely new financial model.

For me, one of the fundamental technical breakthroughs of public blockchains is that, for the first time ever without requiring centralised control points or brain-numbing, productivity-sapping reconciliation processes, we now know how to build systems that allow participants to look at their own computers and know that “what I see is what you see”.

That was one of the breakthroughs needed to enable Bitcoin, of course (the technology allows everybody knows how many there are and which keys own them, etc — Bitcoin full node users know for sure, thanks to the way Bitcoin works, that they see what everybody else sees — without a central party or lots of reconciliation) but this idea is also the key to driving insane amounts of cost, duplication, waste, error and risk from existing business processes.

Sure — a far more mundane prospect than making billions from inventing the next cryptokitties but no less exciting (at least to me, but then my friends do accuse me of being dull…)

Anyway, the point is: when looked at through that lens, the IRS scenario you outline ceases to be insane. If I knew that my records were not only identical to yours but that all events (floating rate observations, etc) would be received and processed identically according to the pre-agreed CSA and ISDA Master, etc., by all participants then I would have made a huge step forward. Amazing as it might sound to some readers, this is just not the case today… every bank has different systems that work in different ways, with different assumptions, different bugs. If we could move to a model where we knew for sure that they were always in sync it would be a huge step forward.

But, to your point about counterparty risk, the outcome of the process I outline above isn’t — and shouldn’t be — an irrevocable, guaranteed-to-succeed automated payment from me to you. That could only work if everything was fully prefunded and would mean my ambition to record, manage and automate real-world contracts would have failed. If I have to change the very nature of finance to achieve any improvements then what would be the point?

So the output of the process I outline is another shared and correct-by-construction contract, one that memorialises that I now owe you so much money. Sure — I might not have the money. But that’s the point, of course… it’s a feature, not a bug from that perspective… the fact I owe you money, due by a certain date is just another contract that now exists between us and about which we are in perfect consensus. That I might not be able to deliver on this commitment is the risk you took when we entered into the original deal.

Net-net: once you look at finance as nothing more than a web of contracts (which have associated counterparty and other risk, of course) between participants then the opportunity for blockchain in finance becomes obvious: it is to record, manage and automate them and drive out a ton of cost and enable new opportunities as a result. Sure — the cryptocurrency wor
ld is massively exciting and it’s what got me into this space in the first place. But what the enterprise people (well, what we’re doing at R3 with Corda — I can’t speak for the others) is a totally different and (to me ) just as exciting endeavour.

But it only makes sense if you do what we did with Corda: start with the insight that everything is a contract… and that it’s real-world contracts that we want to record, manage and automate without error and duplication.

And this is, of course, all laid out in the Corda whitepaper. And if you want to learn more, start here.