Was hoping to have some light shed on a few questions.

Narrowing in on using Ligo, Archetype, or Liquidity.

  1. Is Liquidity kind of a dead-end right now? I noticed it's not listed on developeres.tezos.com, and with the whole Dune thing....
    (or is it in your best interest to use one of the others, if starting something new?)
  2. Do Archetype/Ligo provide everything that Michelson can currently do, or are there limitations with either?
  3. In Solidity, you can inline assembly (for optimizations, unimplemented opcodes). Can you do something similar in Arche/Ligo?
  4. How well is inheritance/cross contract communication supported in Archetype/Ligo?
  • 1
    Welcome, would be better if you split this up into multiple questions. For general discussion on these issues Agora/Riot/Reddit are better fits. For specific Q&A on this site, your first question on Liquidity will lead more to opinions so please consider restating it if you want a specific answer. The second question has already received an answer below and best candidate if you decide to edit the title of this post. The third one would be great for a new question. – cousinit Jan 10 '20 at 23:10
  • 2
    Liquidity is not a supported language in tezos. On the other hand SmartPy should probably be in your list – Ezy Jan 12 '20 at 18:37
  • 1
    @Ezy, we looked at Liquidity, along with all the others listed on developers.tezos.com, and began narrowing down to mainly Ligo/Archetype. SmartPy i̶s̶n̶'̶t̶ ̶o̶p̶e̶n̶-̶s̶o̶u̶r̶c̶e̶ ̶y̶e̶t̶ medium.com/@SmartPy_io/… ← Yay!, it's back on the list =) – Justin Jan 14 '20 at 15:45
  • @Ezy Liquidity states on their website that they support both Dune and Tezos. What makes it unsupported for Tezos? – Justin Jan 14 '20 at 19:19
  • 1
    @Justin ocamlpro who is the author of liquidity left the tezos project to follow their own path. It is not actively maintained to work with tezos so it is only a matter of time before it stops compiling on tezos. – Ezy Jan 15 '20 at 3:49

In response to question 4:

Reuse and modularity

We discuss reuse and modularity, of which inheritance is one of many mechanisms:

  • Michelson has no mechanism for code reuse, except for calling existing "library" contracts directly.
  • As far as I understand, Archetype includes no user-extendable mechanisms for code reuse. Actions (akin to methods) cannot be shared between different state machines (akin to contracts). Furthermore, actions cannot not call each other, so cannot be composed. State machines cannot be extended or composed. Archetypes contracts are composed of one file. However, Archetype contains a set of extensions, that encapsulate commonly used patterns such as signed, which requires that one argument of an action should be the signature of another argument.
  • LIGO contracts, irrespective of the syntax used, are composed of a set of functions. These functions can be reused, and are in general composable as one would expect from functions in any language, with exception of recursion. What's more, the Ligo compiler calls the C preprocessor (cpp) on input contracts, which enables a certain degree of reuse and composability through the use of #include directives. Morally, this is equivalent to copy-pasting the included file: there is no namespacing to save you from name clashes. Finally, the use of cpp is undocumented and subject to change, as testified to by this message by the following message on the #ligo channel on the tezos-dev slack:

Currently, LIGO is shipped with the C preprocessor cpp which acts as a poor man's module system a la C. There several reasons why we should get rid of it, both immediately and in the long term [...]

  • Finally, SmartPy contracts, which are actually Python programs that use the SmartPy library to construct a contract, have access to all the Python features on the meta-programming level (in other words, the code that generates the contract). That is, modules, classes (with inheritance), functions, high-level functions, decorators and compositions.

Inter-contract communication

  • Michelson has no specific mechanisms to simplify inter-contract communication. Calls to other contracts must be crafted manually through the TRANSFER_TOKENS instruction. Callbacks must be encoded (again) manually using continuation-passing style (CPS).
  • The same holds for LIGO and SmartPy.
  • In the current version, Archetype has little support for inter-contract communication. As far a I can see, there is only the transfer instruction, with which it is not possible to specify the argument nor the entry-point of the called contract (presumably, only contracts of type unit are supported targets). No specific helpers for coding CPS style. However, this is amended in future versions of Archetype, as indicated by Benoit's answer below.

Here is a complement to Arvid's answer regarding Archetype:

Reuse and modularity

Indeed Archetype's extensions are reusable codes to add features to a contract. For example, using the 'transferable' extension on a role adds to the contract the necessary actions (ie entry points) to transfer the role to another address.

For example, invoking the 'transferable' extension on an admin role:

variable admin[%transferable%] role := @tz1iawHeddgggn6P5r5jtq2wDRqcJVksGVSa

will generate the two entry points assign_new_admin and confirm_new_admin.

From a design perspective, we have tried to keep the contract in a single source file as much as possible, for ease of reading and trust-carrying purposes. Most of Ethereum's contracts, for example, are usually shattered in literally dozens of source files by inheritance mechanisms, and we thought it was the opposite as what a smart contract should look like.

Extensions are not available yet in the current version (0.1.12) but will be soon (they are a few pull requests away ...).

Inter contract communication

There is support for contract calling in Archetype. For example, the following Archetype contract calls a contract at address KT1RNB9PXsnp7KMkiMrWNMRzPjuefSWojBAm

archetype contract_caller

contract contract_called_sig {
   action set_value (n : int)
   action add_value (a : int, b : int)
variable c : contract_called_sig = @KT1RNB9PXsnp7KMkiMrWNMRzPjuefSWojBAm

action update_value(n : int) {
  effect {

action add_one(n : int) {
  effect {
    c.add_value(n, 2)

We see that the contract signature must be provided with the contract keyword and that the call to the contract is similar to invoking a method on an object.

This feature is available in the dev branch and will be available soon in the next release (0.1.13 typically in a couple of weeks).


Do Archetype/Ligo provide everything that Michelson can currently do, or are there limitations with either?

I think if something is possible in Michelson and not in Ligo, it is probably a bug worth reporting, the Ligo devs usually quickly answer these kinds of issues.

Archetype however is purposely not Turing complete and in particular you cannot do unbounded loops in Archetype (unbounded loops are supported by the LOOP and LOOP_LEFT).


With respect to question 3, following @ezy remark, SmartPy has some inlining capabilities including with new opcodes as shown in the Inline Michelson template (of the new version, currently https://SmartPy.io/dev).

It's accessible here: https://smartpy.io/dev/index.html?template=inlineMichelson.py.

import smartpy_michelson as mi


    def concat(self, params):
        concat = mi.operator("CONCAT", [sp.TList(sp.TString)], [sp.TString])
        self.data.s = concat(["a", "b", "c"])

    def seq(self, params):
        self.data.value = abs(mi.seq([mi.ADD(), mi.MUL(), mi.DUP(), mi.MUL()], 15, 16, 17))

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.