Legend:
Library
Module
Module type
Parameter
Class
Class type
The aim of this module is to manage operations involving tokens such as minting, transferring, and burning. Every constructor of the types giver, container, or receiver represents a kind of account that holds a given (or possibly infinite) amount of tokens.
Tokens can be transferred from a giver to a receiver. To uniformly handle all cases, special constructors of givers and receivers may be used. For example, the giver `Minted is used to express a transfer of minted tokens to a receiver, and the receiver `Burned is used to express the action of burning a given amount of tokens taken from a giver. Thanks to uniformity, it is easier to track transfers of tokens throughout the protocol by running grep -R "Token.transfer" src/proto_alpha.
For backward compatibility purpose, an ANTI-PATTERN is used to redistribute slashing to denunciator; this redistribution technic should not be mimicked if it can be avoided (see https://gitlab.com/tezos/tezos/-/issues/4787). The anti-pattern works as follows: The part of slashed amounts that goes to the author of the denunciation are not directly distributed to him. Tokens are transferred to a burning sink, then minted from an infinite source ( see `Double_signing_punishments, and `Sc_rollup_refutation_rewards ). Again, this is an ANTI-PATTERN that should not be mimicked.
container is the type of token holders with finite capacity, and whose assets are contained in the context. An account may have several token holders, that can serve as sources and/or sinks. For example, an implicit account d serving as a delegate has a token holder for its own spendable balance, and another token holder for its frozen deposits.
balance ctxt container returns a new context because of an access to carbonated data, and the balance associated to the token holder. This function may fail if allocated ctxt container returns false. Returns an error with the message "get_balance" if container refers to an originated contract that is not allocated.
This function is only defined on the few cases for which it is actually needed.
transfer_n ?origin ctxt givers receiver transfers amount Tez from giver to receiver for each (giver, amount) pair in givers, and returns a new context, and the list of corresponding balance updates. The function behaves as though transfer ?origin ctxt giver receiver amount was invoked for each pair (giver, amount) in givers, however a single balance update is generated for the total amount transferred to receiver. When givers is an empty list, the function does nothing to the context, and returns an empty list of balance updates.
transfer ?origin ctxt giver receiver amount transfers amount Tez from giver giver to receiver receiver, and returns a new context, and the list of corresponding balance updates tagged with origin. By default, ~origin is set to Receipt_repr.Block_application. Returns Storage_ErrorMissing_key if giver refers to a contract that is not allocated. Returns a Balance_too_low error if giver refers to a contract whose balance is less than amount. Returns a Subtraction_underflow error if giver is not a contract and its balance is less than amount. Returns a Empty_implicit_delegated_contract error if giver is an implicit contract that delegates to a different contract, and whose balance is equal to amount. Returns a Non_existing_contract error if receiver refers to an originated contract that is not allocated. Returns a Non_existing_contract error if amount <> Tez_repr.zero, and receiver refers to an originated contract that is not allocated. Returns a Addition_overflow error if receiver refers to a receiver whose balance is greater than Int64.max - amount. Returns a Wrong_level error if src or receiver refer to a level that is not the current level.