By Bart van Maarseveen

Smart Contracts are generally considered as a very valuable addition on blockchain technology platforms. This is reflected in the integration of smart contract engines on most popular blockchain platforms out there. Examples are Ethereum, Cosmos or Binance Chain. It makes these platforms immensely flexible and powerful, but it also introduces serious security challenges and risks. 

As described in the previous blogpost on interoperability, Open Food Chain has a layered design in which the batch and claim administration are executed in Layer-1 ledgers conform to Bitcoin design. We deliberately chose to have a clean design for this administrative layer. A design without a virtual machine smart contract engine like you see on Ethereum (EVM) and most other platforms. This choice was made by us for various reasons and this blog tells you why we think this is actually a good idea.


Virtual machine based smart contracts are Turing complete machines, which means that they are capable of expressing all tasks accomplishable by computers. This is of course a blockchain super power (!), but with super power comes great responsibility. Having the option of a smart contract engine like this on the base layer has great consequences for security. Every week bugs and hacks are reported on audited contracts resulting in millions of dollars damage. Companies are reporting to spend huge parts of their budget on software audits because of these risks. You can imagine that for this reason we were happy to conclude that we don’t need or want Turing complete logic on our base administration. It would only be a security hazard.


Bitcoin introduced the UTXO model for a ledger system that is constant in balance which can be verified by anyone. Verified without the use of a virtual machine. Example: It is very similar to a network of cash wallets, one just has to look into a wallet to see the actual bank notes and calculate the balance. Let’s say you see two notes of 10 and one of 5. Your total cash is in that case 25. This can never be wrong. This is the design OpenFood Chain adopted for its base layer. As there are no virtual machine based smart contracts, this ledger holds little surprises and offers transparency without the need for extensive contract audits. We benefit from the robustness and transparency of the Bitcoin network, logic as it has been peer reviewed and battle tested for years.


As we are here to serve the Agrifood industry our focus is on inclusion and retaining cost efficiency even on huge volumes. For these reasons we want to keep the base layer as light as possible. In practice this means we separate smart contract applications and data storage from the base layer. The base layer is what the name suggests, a base layer. The result is we keep our full nodes light. They grow with only a few GB per year and the CPU of a Raspberry Pi would be enough to run one.

No smart contracts?

On our base layer we neither need or want smart contracts for the foregoing reasons. But of course we recognise the super power of smart contracts. 

We use the smart contract champions

By powering up our cross chain $FOOD ecosystem token (Ethereum, Binance Chain, Cosmos) we enable a blockchain agnostic approach for smart contracts. Smart contracts on any platform can work with the industry chain base layers by the use of their virtual machines and the $FOOD token. It won’t interfere with the base layer transparency, security or costs. It leverages the virtual machines and infrastructure of Ethereum, Binance Smart Chain and Cosmos. Smart contracts on these platforms can for instance offer insurances or financing based on proofs, data and triggers in the base layer. They can add claims and proofs to that base layer as well. It all interoperates by the use of the $FOOD token.

Close Menu