Smart Contracts

Payment isn’t a big pain in Switzerland. Bitcoin doesn’t solve a grave problem for us. But Smart Contracts, based on blockchain, still have a huge potential for services that rely on APIs. Queryable contracts, simulation, and insurance could be killer apps.

Paying is easy and seamless in Switzerland. And thanks to the public land register, even real estate transactions carry virtually no risk of fraud.  Contrast this with other countries, where you have to obtain insurance against an unpaid mortgage by a previous owner being discovered on the house you just bought. Or simply transferring money in rural Africa, where the risk of theft was high before the advent of mobile payment services.

So there’s an obvious need for efficient transaction solutions (like Monetas) in markets that lack an efficient infrastructure. But what would be the benefit in a country like Switzerland, where the population is also reluctant to try new things that don’t have an obvious benefit?

I believe that a very important element of the transaction landscape is the Smart Contract. The Smart Contract is basically an agreement that is defined by executable code instead of natural language text. So a mortgage contract would actually effect the interest payment instead of describing when it is due; a rental car contract would unlock the car instead of describing when you can use it.


The crypto transaction landscape

Quite a few solutions and frameworks have been proposed that make use of cryptographic technology to ease transactions. Most notably are blockchains, which form the basis of public ecosystems like Bitcoin or Ethereum and restricted access frameworks like Hyperledger.

Smart Contracts rely on a blockchain to add code in a non-disputable transaction. They do not necessarily involve a currency like Bitcoin, but may use one or more such currencies or other payment systems during the execution of a contract.

Blockchain ecosystem

Interactive contracts: Queries and Simulation

Smart contracts are defined by executable code. They will need a human-readable high-level programming language and suitable execution environment. I fear this will be a custom language or JavaScript and I hope it will rather be Python [see inset below]. A very high level of abstraction is necessary: There will be contracts built upon other contracts, contracts reacting to input events. Contracts may provide a query API, answering questions about possible behavior (Was this agreed? What did we agree?).

Contract conditions can also be simulated to check how contracts react. This may be used to discover gaps and expose potential risks. Will contracts ever negotiate with a mediator bot appointed by their parties to close discovered gaps?


While reading the description of a structured financial product may seem complicated, smart contracts may cause an explosion of legal complexity. But their interactive nature and simulation possibilities help taming the complexity. Instead of paying lawyers fighting for their interpretation of the contract’s text, you might simply buy insurance to protect you against contractual risks. And the regulation, instead of issuing more complex regulations, might mandate that contract holders are insured, much in the same way that car owners have to be insured.

The insurance will of course issue a smart contract, accessing the contracts it protects, along with other information about your life.

Breaking the chain of transparency

If an insurance company needs to see all my contracts and certain other life conditions, will this lead to a horror world of full transparency, as depicted by Dave Eggers in The Circle?

Not necessarily: Simulation can be done without my identity, by someone I trust. The insurance doesn’t need to know me, as long as it gets the aggregated, anonymized data. But this needs a network of trust, similar to the banking network.

Essential to this is an open way to express smart contracts. Open in the sense of open source, so everyone can inspect and vet the contractual building blocks.

Technical Opinion: Why Python for smart contracts

A full language with a broad community has advantages over a more restricted domain-specific language such as Ethereum’s  Solidity, which is JavaScript-like.

Python is an expressive language with a low conceptual overhead.  It is guided by the Zen of Python, which also stipulates good practice for development in Python. I find these principles very appropriate when applied to contracts.


  • Simple is better than complex: The most important contracts (like constitutions) should be as simple as possible.
  • Readability counts: You shouldn’t need a law degree or a computer science degree to understand a contract.
  • Explicit is better than implicit: For contracts, implicit is the worst case. You want things stated, not implied.
  • There should be one– and preferably only one –obvious way to do it: Following accepted practices helps understanding.

Python is often used as a “glue language” – which is also appropriate for contracts, as they usually bridge different worlds, notably physical world objects and cash flows.


Will crypto-based transactions find widespread acceptance? Written contracts are in wide use, and there is a huge open ecosystem built around them. As the lackadaisical use of end-to-end encryption of email shows, it’s not easy to add features in an open ecosystem unless something is severely broken.  Only if there is a clearly apparent value added, a new paradigm might succeed. I believe that insurance of contracts might be this feature, as protection against uncertainty and fear has always driven humanity.

Recommended Resources