A plethora of reasons

JavaScript as a smart contract language

Dr Joseph Chen-Yu Wang

JavaScript word button image via Shutterstock

In this article Dr Joseph Chen-Yu Wang, Chief Science Officer at Bitquant Research Laboratories, explains why JavaScript is the perfect language for creating smart contracts.

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 heavily on the Hyperledger fabric blockchain, and the reason why 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….

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 like “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 this type 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. One thing JavaScript is great at is making these concepts usable by mere mortals, and that becomes important for legal reasons.


One big problem with financial contracts is related to 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 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 who 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 who claim something different, then you really have a big problem.

When JavaScript comes into play

Now this poses a problem for computer languages. The way we settled on JavaScript was that we were originally using Python because it happens to be used by major banks like JPMorgan and Bank of America for their derivatives systems. Our first set of contracts was with a company of computer programmers. We showed them our Python contracts. They said it was fine, but it would eventually take them a few days to figure it out. 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 many people who 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, so the client or the judge can see (and actually read) 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 someone testifies that what the judge is seeing was what the client was seeing, and someone else is showing that the web page is an accurate representation of what the contract was.

SEE ALSO: Adam Bien interview: “Java EE is easier than JavaScript”| JAX 2016

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 it is widespread enough so that there will always be people around that can explain what a JavaScript program in 2016 was intended to do.

So that’s the reason why 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 that it’s pretty straightforward to do with Hyperledger fabric.

This post was originally published on Bitquant


Dr Joseph Chen-Yu Wang

Dr Joseph Chen-Yu Wang is Chief Science Officer at Bitquant Research Laboratories. He has almost a decade of experience in developing C++ quantitative finance libraries and a decade and a half of working experience in developing a wide variety of commercial software with development lead experience. Dr Wang also has over two decades of working experience developing scientific and academic software.

Inline Feedbacks
View all comments