So here at bitquant, we’ve been issuing smart contracts for small business lending and African trade, and the language we’ve been using is Javascript. We’ve also been working very heavily on the Hyperledger fabric blockchain, and the reason that we’ve been using that is that it appears pretty straight forward to create a module in hyperledger fabric to run Javascript.

So why Javascript….

Well from a computer science point of view javascript happens to be a very good language for smart contracts. It turns out that a lot of smart contract programming involves writing down event driven programming statements of the form “if event X happens, then you owe me amount Y.” It turns out that javascript was very well designed for this sort of thing “if someone presses on button X, then popup window Y.”

In order to write these sorts of constructs, it turns out that you can use a lot of technology from computer science that uses functional programming concepts like lambda functions and closures, but one thing that javascript does a good job of doing is making these concepts usable by mere mortals, and that becomes important for legal reasons.

The big problem with financial contracts is one of consent. Put simply in order to have a valid contract in common law, you have to show that both sides knew what they were agreeing to. If someone shows that I signed a piece of paper in Swahili, that means nothing since I can’t read Swahili. This becomes a particular problem in financial contracts. Everything is fine if I owe you money, but if it turns out that you owe me money, you are going to look for a way out and it turns out that one standard way out is “I didn’t understand what I was signing.”

It becomes an even bigger problem if you go to a judge or arbitration panel, and you have to explain to the judge or arbitration panel what was signed. The last thing you want is a confused judge that is sympathetic to someone saying that they didn’t understand what they were signing because the judge doesn’t understand the contract. At that point, you may have to bring in expert witnesses, which can be expensive, and if it turns out that the other side brings in expert witnesses that claim something different, then you really have a big problem.

Now this poses a problem for computer languages. The way we settled on javascript was that we were originally using python, because Python happens to be used by major banks like JPMorgan and Bank of America for their derivatives systems. Our first set of contracts were with a company of computer programmers. We showed them our python contracts. They said that was o.k. but it would take them a few days for them to figure out the python. We asked them what language they would prefer to write the contract in, and the answer was javascript.

It turns out that javascript is a good choice because there are huge numbers of people that can read javascript. It’s also a good choice, because once you have written a module in javascript, it’s pretty easy to write a web page that displays the contract to the client or the judge what’s in the contract. So instead of showing the judge the source code, you show the judge a web page that breaks down the contract, and at that point you have someone testify that what the judge is seeing was what the client was seeing, and you have someone else show that the web page is an accurate representation of what the contract was.

There are some other good reasons for using javascript. I don’t control javascript, and neither does the other side. The other good thing about javascript is that it’s likely to stay around for a while. Suppose I invent my own contract language. Now suppose there is some sort of contract dispute 30 years from now. It’s possible that no one around understands that language, which is going to be a very big problem. However, javascript does a good job at backward compatibility, and its widespread enough so that there will be people around that can explain what a javascript program in 2016 was intended to do.

So that’s the reason that we use javascript. Also we started writing contracts about a year ago, and at the time we didn’t know which technology would win. But part of making technology decisions is to “future-proof” your code, and we figured that someone would make a blockchain that would work with javascript, and it turns out to be pretty straightforward to do with Hyperledger fabric.