Today Algorand and Blockstack are announcing that they are collaborating on the Clarity smart contract language. Clarity is a decidable (i.e. non-Turing complete) language inspired by lisp. I am extremely excited about this development and have spent a few hours this week writing a smart contract in Clarity.

I have long argued that Turing complete smart contract languages are problematic because the only way to really understand the system as a whole is to run it and see what happens. Still this is the route most projects have chosen and even more odd to me has been the embrace of WASM as an execution environment which optimizes for speed over safety and analyzability. Given that the key point of decentralized systems is censorship resistance that has long struck me as the wrong order of priorities. After all, there is no-one you can call to just unwind a mistake (modulo the DAO hack reset, I suppose).

Clarity instead is all about safety. Avoiding costly mistakes long before they can cause millions of dollars in damage. Decidability is one key aspect of that. To give just one example of the power of decidability: with Clarity you can know the precise gas fee of a contract in advance. Another key aspect is making actions such as issuing non-fungible tokens, which are a critical component of many applications, completely straightforward. There are many more aspects of Clarity that are a delight, such as the simple and clear type system. And being inspired by Lisp, Clarity naturally lends itself to building up code out of short functions (if you have never seen Lisp before, the language may strike you as odd at first – but I promise that learning it will make you a better programmer).

Now some people may think that you lose a lot by giving up Turing completeness, so I wanted to write a non-trivial example. One came to mind easily: an all-or-none funding mechanism. There are many possible use cases for such a contract, including a system such as Kickstarter, or my personal favorite, the second coming of Kitchensurfing (I hope). For readers who may not remember Kitchensurfing, it was a wonderful service where a chef would come to a home and cook there. The key missing feature though was the ability to get everyone to split the payment upfront, so that meant the host had to put up the entire bill and then collect from guests which is more than a bit awkward.

I won’t post the (nearly) complete contract here, you can find it on github. There is a bit more argument checking I need to add in one of the functions and I also have been remiss in writing a test harness (yes, I know I should have written that first, but I was too damn excited).

Here are some key things I would like to call out. How do you define a non-fungible token in Clarity?

That’s all there’s to it. Later, when you want to issue an event-pass to someone who has paid, all you need to do is

Again, that’s it. Three lines of code and that includes the error handling!

Let’s look at a different part of the code to show another elegant feature of Clarity. With asserts! I can easily check if a condition is met and if it is not met issue an error. Doing so will abort execution and leave all blockchain state untouched

There is a lot more to discover and I encourage everyone who is interested to check out Clarity. The tooling is still growing but there is already a Clarity LSP for VS Code (which helped me find a number of mistakes). A full blown REPL running against a chain instance is in the works and will be a great way to interact with Clarity contracts during design.

Over time Clarity will become an independent project. It would be wonderful to see other chains support Clarity as a development language (possibly even the only one). In the meantime there are many amazing opportunities to contribute, from just writing contracts in Clarity (and providing feedback) to working on the virtual machine or on development tooling.