Skip to content

Tokens on Ergo#

Ergo's native tokens are incredibly versatile and can represent a wide range of assets, including shares, complementary currency units, and various tangible or intangible items. The infrastructure of Ergo is designed to seamlessly handle the representation and transfer of these diverse assets, integrating them into the blockchain as first-class citizens.

What are first-class citizens?

This means that tokens in Ergo are not just metadata attached to transactions, but they are deeply integrated into the Ergo protocol. They can be manipulated and managed with the same level of support and functionality as the native Ergo token (see EIP-0004).

It is crucial to understand that ERG, the native token of Ergo, possesses two unique characteristics:
  • ERGs cannot be burned; the total input and output amounts in any transaction must be equal.
  • Storage rent can only be paid in ERGs.
How do I mint a token?

There is no central database where tokens are registered currently, your best bet is to use community resources like supported tokens in the ergotipper bot and spectrum-finance/ergo-token-list.

Token Storage#

  • Tokens are stored in a special register R2 of a box in the form of (tokenId -> amount) pairs.
  • A single box can hold up to 255 secondary tokens.

Register Usage#

The Ergo reference implementation wallet uses specific registers in a unique way, although the protocol doesn't enforce this:

  • R4 - verbose name
  • R5 - description
  • R6 - number of decimal places
  • Additional registers (R7, R8, R9) can store asset-specific information


There are certain indirect limitations to consider:

  • The size of a box should not exceed 4 kilobytes.
  • The presence of tokens increases the computational cost of the transaction.

Asset Creation#

An exception to the rule of weak preservation (the total amount in inputs should be no less than the total amount in outputs) is that a transaction can generate tokens from thin air in its outputs if the asset identifier matches the identifier of the transaction's first input box. Given that the box identifier is cryptographically unique, it's impossible to have a second asset with the same identifier, assuming the hash function used is collision-resistant (which it indeed is). This rule also implies that only one new asset can be created per transaction.