So we've done a lot of context now and looked at why we have contracts what they are how they work what
the remedy is and we build on top of that smart contracts.
The topic that this session is focused on smart contracts if we draw a Venn diagram are curious because
you would think that they would be a subset of contracts when lawyers think about small contracts they
would draw big circle for contracts right inside it they draw a smaller circle for smaller contracts.
Not quite.
I'll explain why.
So the history of smart contracts goes back to Nick Tsavo a famous person in the world of futurology
and technology.
Definitely worth reading.
And he introduced popularized the concept of smart contracts by using the example of a vending machine.
You go to the vending machine you put in your coin you press the button THE MACHINE DISPENSES the bag
of crisps and you have entered into what looks like an automated economic transaction.
So that bargaining that we talked about in the context of contracts exists one party makes a payment
the other party provides.
In this case goods.
So there is a Sale of Goods contract but it's been entirely automated.
There isn't a written contract and you can see in real time in real life this transaction taking place.
So how are it looks like a contract.
How are smart contracts potentially outside the lawyer's description of contracts.
Well after an example bow before lawyers got hold of this principle coders worked on smart contracts
and what coders mean by a smart contract is an arrangement between two parties or entities that is self
executing by the code.
So we're a code of rights into a contract in their terms a piece of code that says if this then that
they will view that as a small contract a lawyer might not seem like a curious thing.
So the distinction goes back to what I was describing about the intention of parties to enter into legal
relationships and some lines in software code that provide in the form if this then that may not be
a standalone legal relationship of a type that could be taken to the courts and enforced.
So the reason for giving that background on contracts at the start is that lawyers have quite a specific
thing in mind when they talk about contracts.
Their thinking can you get this to court and you can only get it to a court if it has the characteristics
that I described that there are identifiable parties that they have an evidenced intention to enter
into legal relationships that there has been some element of bargain on both sides that none of the
consumer protection rules are triggered in such a way that the regulator would look over the top of
it and tell the courts not to support that type of contract.
So in the big Venn diagram we got a huge circle of contracts and we've got a huge circle of smart contracts
like they're overlapping for sure but not that much.
And the purpose of this session is went on and I have conversations part of the
life of crypto currencies and fintech more broadly is that it's brought into sharp focus this distinction
between coders contracts and lawyers contracts.
So it depends who you are a contract for a code a piece of code a contract for a lawyer is something
that doesn't have to be established in a formal way but it does have to meet some formal criteria.
Take the best known example of a crypto currency is bitcoin a contract.
Well famously it doesn't have a help line a phone number and it doesn't have the ability to sue parties
under that transaction.
Bitcoin is a smart contract of the type that coders describe.
In other words if this then that the transfers and the bitcoin and of the type envisaged by Nick szabo
you have an automated transaction transferring assets it doesn't have the characteristics that lawyers
are looking for in a smart contract.
And in fact there's nothing to enforce because the transaction will either take place or not take place.
These things are happening by and large in real time obviously the nodes must be updated but there isn't
a period of time that lawyers would be concerned with either the transfer takes place or it doesn't
take place.
You don't have a contract between identifiable parties because the parties are standing behind their
pseudo anonymous IDs.
So bitcoin has some of the elements of a contract in that it can be used to effect the transfer of value
but it doesn't have all the legal attributes of a contract.
So is sticking with bitcoin for a few more moments because there has been litigation about bitcoin the
last 12 months have been particularly interesting for lawyers because we've had court cases about bitcoin.
How do we characterize it and the various laws how do we characterize the transfers of bitcoin under
various laws and what happens if Bitcoin is stolen again under various laws.
The cases that we've seen by and large in Singapore the UK and the US we've seen different rules applied
to this but we don't see people bringing claims in contract.
So we generally see cases that start from some sort of hack or loss or theft and the party that's lost
out looking for a legal remedy saying to the courts I had this coin and I don't have the coin and I
haven't received value for it.
Please help me.
So parties are going with those economic problems to lawyers and saying how do I frame this.
What legal case do I have here.
And the lawyers can't fall back on the traditional case and say Well that was a bargain relationship
between two parties.
It was written in a contract we can identify the clause where the party has failed to comply with its
obligation and therefore we can bring a contract claim under that clause.
There's no clause in the case of Bitcoin it is simply the software.
So the way that it's approached by lawyers is to say one we need to establish that Bitcoin is property
and to we need a remedy for the unauthorised transfer of that property or the transfer of that property
without a corresponding payment of value.
Why do we need bitcoin to be property.
Well the courts have a dilemma because in the facts that we're looking at is a fairly obvious case that
a party that has had their coin stolen should have some sort of legal remedy.
The legal remedies that are obvious come from theft criminal law here not contract law but theft relates
to theft of property.
If you look at any of the national or international legislative definitions of theft they all assume
that what is being stolen is property.
It's a problem for the legal systems that are still catching up with bitcoin.
If we look at English law to found a theft case that requirements that property has been appropriated
must be established to establish that we need the courts to accept the Bitcoin is property.
English law broadly defines property as real.
By which they mean you can touch it so real and tangible property are generally the same thing.
Intangible property built up over time so things that are obviously property but can't be touched.
Intellectual property that's established by a lot of legislation and contracts in the broad sense.
All contracts have value if you look at a company's accounts.
A lot of the value that it shows that is amount due to be received by it under contracts.
So it's clear in corporate and accounting terms that the contract has value.
That means it's property.
The courts struggle with bitcoin so clearly not tangible.
There's not real property.
The intangible property categorizations have been established for quite some time and the courts have
previously been keen in their decisions to say we're not going to extend this definition of the types
of intangible tangible property that our property for the purposes of.
In my case English law.
So faced with this dilemma the courts in the last year or so have found themselves needing to extend
that definition of intangible property and say something is wrong with the law in circumstances where
we can't take forward a theft case because no property has been stolen.
It's only Bitcoin doesn't work.
So the courts in the three or four jurisdictions that have heard these cases are now addressing this
problem.
In England we have the benefit of the UK jurisdiction Task Force.
November 19 paper on smart contracts established two things.
According to the senior judges in England one that's crypto currencies can be property and second that
small contracts can be enforceable.
So we have a significant development in English law in the last few months and it enables the judges
now who are looking at theft cases to say OK Bitcoin cryptocurrency is property so we can have a theft
claim around it and we can give a party those rights back.
English law as I said flexible and the conversations that we have around this area at the moment have
given rise to us thinking that there are probably other remedies that would apply to crypto currencies
and similar without having to go down the route of criminal law.
So we use criminal law cases around theft to establish that Bitcoin crypto is property we can then bring
it back in commercial non-criminal cases to say we don't need a contract in order to bring a claim because
there is property that has been taken from one person to another.
In England it looks like we will use principles old old principles known as unjust enrichment and similar
we can say the party that has now got possession or control of this valuable asset to the stolen crypto
has been unjustly enriched by its actions and must be required as part of a civil claim to return that
value.
So we've now got a broad context where even if there aren't contracts we still got remedies under English
law for crypto.
The more interesting case for lawyers is smart contracts falling within the lawyers definition of contracts.
So these are contracts that are beyond the coded software generally beyond New types of crypto or token.
And we're into a more conventional world of contracts that have traditionally been long form written
contracts only enforced by a trip to court we're now at a world of contracts that are a kind of hybrid.
So we've introduced principles of smart contracts i.e. automation into the broader field of contracts
the long form written agreements intended to be enforceable at law.
What does that mean.
So the use cases in this area generally focus on those relationships that are fairly simple binary where
one party is entering into an economic transaction with a second party.
So if we have a situation where the first party agrees that on the occurrence of a particular event
say we have the third Tuesday in May it will make a payment to the other party.
The other party pays some consideration or performs some service so that there's a bargain on both sides.
The contract is written setting out the two parties intend to be bound by a critical requirement for
lawyers.
But then there's a part of the contract here which falls into this software code type context that if
this then that if we have the third Thursday of the month then this party will make a payment to the
other party and that can be automated by a piece of code.
So that term that particular term of the wider contract can be established by code where the party that
is due to make the payment on the occurrence of that event signs up to its bank making a transfer on
the occurrence of that event under the terms of some code.
So what we're looking for here is examples of provisions of existing contracts that can be turned into
computer code and can be automated.
Generally we're looking for efficiency.
So the alternative to this coding and the coding is the clock ticks round to midnight on the day when
the payment is made and instruction is made by the code to the bank of the person that is transferring
and the transfer takes place simply as a function of that code.
How does that happen now.
Well midnight ticks by 8:00 in the morning people wake up and go to work 9:00 in the morning.
They get a reminder on their calendar that the payment is due nine thirty.
They instruct the payment.
O'clock someone at the bank receives the instruction instructs the payment to be made through the chaps
or backs network in the UK the payment is made and received.
So there is a kind of analog and human element to this process.
It's starting to be unbundled and taken out of them.
We're looking for easy use cases to begin with where an existing contractual relationship has some of
these simple.
If this then that aspect to it and those are capable of automation that the parties that are required
to have obligations automated or happy with the automation they are technically automate able they can
be converted into code.
And these are the early use cases for smart contracts.
So when we're writing smart contracts at the moment there is still generally a written contract but
there are parts of the contract that are now lifted out embedded in code and automated.
There is reporting that's associated with it.
So the parties can see the effect of that automation when it goes through.