Ergo supports custom tokens as first class citizens. Namely, a special register (R2) of a box contains (tokenId -> amount) pairs. Hard limit for number of tokens per box or per transaction is pretty liberal, namely, there could be up to 255 secondary tokens in a transaction or a box, however, there are indirect limits (box could be no more than of 4 kilobytes, and also tokens add to estimated computational cost of the transaction).
Erg amount is written directly (with no identifier) as a number into register R0. There are more significant differences between Ergs and other tokens:
- Ergs can not be burnt: total amount of ergs in transaction inputs should be equal to total amount of the outputs. Unlike ergs, other tokens can be burnt: total amount for a token in transaction inputs should be no less than amount of the outputs.
- Storage rent (see Sec 5 of the whitepaper) could be paid only in Ergs.
Tokens can represent shares, complementary currency units etc. In the UTXO model a token issued with amount of exactly 1, which we call the singleton token, could also be used to imitate long-living accounts existing in Waves, Ethereum Classic etc. Namely, a transaction spends an old box with the singleton token, and creates a new one, and script of the old box can demand the new box to have certain properties (e.g. a particular script, or a particular amount). Thus the smart account marked with the token can live and have its state changed as prescribed by the smart account contract through a transaction chain.
A particular case for a singular token is an oracle. One can create a token for e.g. ERG/EUR exchange rates oracle. Then a box which contains the token has exchange rate encoded in a certain register. As the oracle is long-living account, contracts can know oracle token identifier in advance, and refer to it.
How new asset could be created? There is a notable exception to the weak preservation rule (total amount in inputs is no less than total amount in outputs), namely, a transaction can create out-of-thin-air tokens in its outputs if asset identifier is equal to the identifier of the first input box of the transaction. As box identifier is cryptographically unique, there’s no chance to have second asset with the same identifier while hash function being used is collision-resistant (and it surely is). This rule also means that only one new asset per transaction can be created.
Ergo reference implementation wallet is using certain registers in a certain way, though this is not required by the protocol:
- R4 - verbose name
- R5 - description
- R6 - number of decimal places
- additional registers (R7, R8, R9) could be used for asset-specific information
This convention can be used by applications, however, again, the protocol is not enforcing it.
Should we have specific conventions for oracles as well?