Operations
The final stack after a contract execution is a pair containing a new storage and a list of operations. An operation is either a transfer, an account creation (a.k.a. origination), a delegation or the emission of an event.
There are no literal values of type operation. Instead, such values
are created using the following functions from the standard library:
Tezos.create_contract (origination), Tezos.transaction (transfer),
Tezos.set_delegate (delegation), and Tezos.emit (emission of
event).
Origination
The call Tezos.create_contract(e,d,a,s) returns a contract creation
operation (origination) for the entrypoint e (as a function) with
optional delegate d, initial amount a and initial storage s,
together with the address of the created contract. Note that the
created contract cannot be called immediately afterwards (that is,
Tezos.get_contract_opt on that address would return None()), as the
origination must be performed successfully first, for example by
calling a proxy contract or itself.
Transaction
The call Tezos.transaction(param, amount, contract_addr) evaluates
in an operation that will send the amount amount in mutez to the
contract at the valid address contract_addr, with parameter
param. If the contract is an implicit account, the parameter must be
unit.
The following example shows a transaction sent from one contract to
another. The former is derived from a namespace B with an entrypoint
increment; the latter is derived from a namespace A with an
entrypoint add. The entrypoint increment calls add with 1. We
assume that the contract associated with namespace A is deployed
under the address "KT1TxqZ8QtKvLu3V3JH7Gx58n7Co8pgtpQU5".
Contract (derived from) B needs to provide the parameter of the
called contract. The convention is to transform the entrypoint being
called to a variant. Here, add in A becomes Add. The variant
Add carries the value of the parameter of the entrypoint, here 1
because we show how to increment the storage (storage + delta in
A). The type of the parameter of the contract A is obtained by A
parameter_of, and it is the type of Add(1).
It is possible for a contract to have multiple entrypoints, which is
implicitly translated in LIGO to a parameter with a variant type as
shown below. The following contract:
is translated internally to a contract similar to this one:
This contract can be called by another contract, like this one:
Notice how we directly use the %sub entrypoint without mentioning
the %add entrypoint. This is done with the help of
annotations. Those annotations correspond to the name of the function
defining the entrypoints, prefixed by a %, so sub becomes
%sub. Also, as shown above, each entrypoint corresponds to an
implicit variant type whose name is the entrypoint function whose
first character is capitalised, so sub becomes Sub, as far as
parameters are concerned.
Delegation
The call Tezos.set_delegate(d) evaluates in an operation that sets
the delegate of the current smart contract to be d, where d is an
optional key hash. If None(), the delegation is withdrawn. If the
contract has no delegation, then no change occurs. If d is
Some(kh), where kh is the key hash of a registered delegate that
is not the current delegate of the contract, then this operation sets
the delegate of the contract to this registered delegate. A failure
occurs if kh is the current delegate of the contract or if kh is
not a registered delegate. However, the instruction in itself does not
fail; it produces an operation that will fail when applied.
Event emission
The call Tezos.emit(event_tag, event_type) evaluates in an operation
that will write an event into the transaction receipt after the
successful execution of this contract. The event is annotated by the
string event_tag if it is not empty. The argument event_type is
used only to specify the type of data attachment.