What makes a perfect CorDapp?

What makes a perfect CorDapp?

I’m presenting at the awesome Corda Code Club tonight and have been asked by the indefatigable Martin Jee to give a short talk on “What makes a good CorDapp”.

It was a great question and I started making some notes. And then I figured: why not publish this rather than simply present it? So here goes. This is a “write quickly and publish” post… so might not be as polished as my usual stuff tries to be..!

First and foremost, the thing to keep in mind at all times is that Corda is built to make a deceptively simple but extremely powerful promise:

“If I see some data in my Corda node that I share with you then I know for sure that what I see is what you see”

I wrote about this here and in lots of other places too but this is an opportunity to make it concrete with a specific example: syndicated lending.

The good news is that you don’t need to be a banker to understand why it’s such a good example.

First, the market, like many markets, is highly decentralised: lots of different participants cooperate, compete and jostle alongside each other without any of them being in charge. Borrowers can speak to different banks to help them get a loan, these banks can work with different possible investors to help form a “syndicate” who will contribute to that loan… everybody is out there, pursuing their own enlightened self interest and, somehow, without any overall controller, it all kinda works out OK.

Except it’s also massively inefficient. Sure: all the participants in the industry have optimised the heck out of their IT but when it comes to talking to each other and recording the deals and calculating interest and sharing information, it’s a mess: firms are using different systems, they record information in different ways and the result is the usual story: lots of paperwork, duplicated information, inconsistencies, errors and lots and lots of reconciliation!

Now: you could solve this by introducing somebody to be in charge, of course. They could run a big “syndicated lending” system in the cloud that everybody used but imagine how much power that would give them! And a centralised solution to a decentralised problem feels a bit, well, wrong.

So some clever people at a firm called Finastra thought about this and realised that Corda could form the basis of a really elegant solution to this problem. Their insight was that Corda’s promise that “what I see is what you see” is precisely what this market is lacking!

If there was a system that each participant in the market could deploy that they controlled and owned, but which was guaranteed to be in sync with all the parties that they transacted with, suddenly a whole pile of problems would go away: each participant would know it was looking at the most current version of a loan, they would know when interest had been paid (or not..!) and all those discrepancies would start to become a distant memory.

For me, this is a near-perfect use-case for Corda.

And I think it’s because it has so many of the following characteristics:

• There are a group of participants who want to transact with each other for some purpose but who don’t fully trust each other but nevertheless want to know there are no discrepancies between their views of all the deals.
• Introducing a centralised third party is technically possible but commercially or politically undesirable.
• Most of the information should only be shared with people with a need to know: I shouldn’t get to see information that has nothing to do with me
• There are usually complex inter-firm workflows. We’re not only moving tokens around (although Corda is great for that!) But we usually also have to negotiate with each other and orchestrate multi-step sequences of events.
• Related to the point above, there are also usually rules about what updates to the ledger are valid: is this the expected payment? Was the interest calculated correctly? And people usually want to write these rules in modern languages the real-world developers understand such as Java.
• We are transacting with parties we know: the participan
  ts on the network have real-world identities and we do care that we’re speaking to who we think we are.
• We want transactions to be processed in real-time and to confirm with finality, not probabilistically.

And there are lots of others. Check out all these presentations from CordaCon from projects such as HQLAx, GuildOne, B3i, InsurWave and so many more. Sorry if I didn’t list your project in this very quick write-up!

Now, the fun thing is, I’m writing this before my presentation in an hour.

My closing message is going to be: “First write down what information synchronisation or inter-firm coordination problem you are trying to solve. Be really clear on who needs to be in sync about what. Who should receive what, when and for what purpose? Who should send it? What rules govern how updates are validated? Who signs the transactions? What is in them? What do they mean? And finally… make sure you have a killer answer to the question: why this simply could not be done with a database operated by a centralised controller?!”

I’ll be interested to see how the audience respond.. and might publish a follow-up if it turns out I missed lots of key points…