Version: 0.67.1

Main function and Entrypoints

Access Functions

A LIGO contract is made of a series of constant and function declarations. Only functions having a special type can be called when the contract is activated: we call them main functions. A main function takes two parameters, the contract parameter and the on-chain storage, and returns a pair made of a list of operations and a (new) storage.

When the contract is originated, the initial value of the storage is provided. When a main function is later called, only the parameter is provided, but the type of a main function contains both.

The type of the contract parameter and the storage are up to the contract designer, but the type for list operations is not. The return type of a main function is as follows, assuming that the type storage has been defined elsewhere. (Note that you can use any type with any name for the storage.)

type storage = ...;  // Any name, any type
type return_ = [list<operation>, storage];

The contract storage can only be modified by activating a main function: given the state of the storage on-chain, a main function specifies how to create another state for it, depending on the contract's parameter.

Here is an example where the storage is a single natural number that is updated by the parameter.

type parameter = nat;
type storage = nat;
type return_ = [list<operation>, storage];

const main = (action: parameter, store: storage): return_ =>
  [list([]), store];

Entrypoints

In LIGO, the design pattern is to have one main function called main, that dispatches the control flow according to its parameter. Those functions called for those actions are called entrypoints.

As an analogy, in the C programming language, the main function is the unique main function and any function called from it would be an entrypoint.

The parameter of the contract is then a variant type, and, depending on the constructors of that type, different functions in the contract are called. In other terms, the unique main function dispatches the control flow depending on a pattern matching on the contract parameter.

In the following example, the storage contains a counter of type nat and a name of type string. Depending on the parameter of the contract, either the counter or the name is updated.

type parameter =
| ["Action_A", nat]
| ["Action_B", string];

type storage = {
  counter : nat,
  name    : string
};

type return_ = [list<operation>, storage];

const entry_A = (n: nat, store: storage): return_ =>
  [list([]), {...store, counter: n}];

const entry_B = (s: string, store: storage): return_ =>
  [list([]), {...store, name: s}];

const main = (action: parameter, store: storage): return_ =>
  match(action, {
    Action_A: n => entry_A(n, store),
    Action_B: s => entry_B(s, store)
  });

Tezos-specific Built-ins

A LIGO smart contract can query part of the state of the Tezos blockchain by means of built-in values. In this section you will find how those built-ins can be utilised.

Accepting or Declining Tokens in a Smart Contract

This example shows how Tezos.get_amount and failwith can be used to decline any transaction that sends more tez than 0tez, that is, no incoming tokens are accepted.

type parameter = unit;
type storage = unit;
type return_ = [list<operation>, storage];

const deny = (action: parameter, store: storage): return_ => {
  if (Tezos.get_amount() > (0 as tez)) {
    return failwith("This contract does not accept tokens.");
  } else {
    return [list([]), store];
  };
};

Access Control

This example shows how Tezos.get_sender can be used to deny access to an entrypoint.

const owner = "tz1KqTpEZ7Yob7QbPE4Hy4Wo8fHG8LhKxZSx" as address;

const main = (action: parameter, store: storage): return_ => {
  if (Tezos.get_sender() != owner) { return failwith("Access denied."); }
  else { return [list([]), store]; };
};

Note that we do not use Tezos.get_source, but instead Tezos.get_sender. In our tutorial about security you can read more about it.

Inter-Contract Invocations

It would be somewhat misleading to speak of "contract calls", as this wording may wrongly suggest an analogy between contract "calls" and function "calls". Indeed, the control flow returns to the site of a function call, and composed function calls therefore are stacked, that is, they follow a last in, first out ordering. This is not what happens when a contract invokes another: the invocation is queued, that is, follows a first in, first out ordering, and the dequeuing only starts at the normal end of a contract (no failure). That is why we speak of "contract invocations" instead of "calls".

The following example shows how a contract can invoke another by emitting a transaction operation at the end of an entrypoint.

The same technique can be used to transfer tokens to an implicit account (tz1, ...): all you have to do is use a unit value as the parameter of the smart contract.

In our case, we have a counter contract that accepts an action of type parameter, and we have a proxy contract that accepts the same parameter type, and forwards the call to the deployed counter contract.

// counter.jsligo

type parameter =
| ["Increment", nat]
| ["Decrement", nat]
| ["Reset"];

// ...

// proxy.jsligo

type parameter =
| ["Increment", nat]
| ["Decrement", nat]
| ["Reset"];

type storage = unit;

type return_ = [list<operation>, storage];

const dest = "KT19wgxcuXG9VH4Af5Tpm1vqEKdaMFpznXT3" as address;

const proxy = (action: parameter, store: storage): return_ => {
  let counter =
    match (Tezos.get_contract_opt(dest), {
      Some: contract => contract,
      None: () => failwith("Contract not found.")
    });
  /* Reuse the parameter in the subsequent
     transaction or use another one, `mock_param`. */
  let mock_param = Increment(5 as nat);
  let op = Tezos.transaction(action, 0 as tez, counter);
  return [list([op]), store];
};

Access Functions​

Entrypoints​

Tezos-specific Built-ins​

Accepting or Declining Tokens in a Smart Contract​

Access Control​

Inter-Contract Invocations​