ZooBC wiki
Tokens and markets

Issuing a token

You are looking at an old version of this page: revision #843 by zoobc.how, 2026-10-26 22:31 UTC. See the current version

Any account can create its own token on ZooBC with a single IssueToken transaction. There is no contract to write and nobody to ask: the chain's fixed rules decide whether the transaction is valid, and once a block includes it, the token exists and the issuer holds its whole supply. The token's units then move with TransferToken and can sit in escrows, streams, schedules and swap offers, and, with 8 decimals, in orders on a market.

The IssueToken transaction

An IssueToken form with its fields (symbol, name, decimals 0 to 8, supply, optional ZBC backing, and the mintable and redeemable switches) and the issuer's wallet holding the whole supply
An IssueToken form with its fields (symbol, name, decimals 0 to 8, supply, optional ZBC backing, and the mintable and redeemable switches) and the issuer's wallet holding the whole supply

An IssueToken (type 10) states:

FieldRule
decimals0 to 8 (see decimals and the step)
flagsredeemable, and the mint mode (below)
total supplyabove 0, and a multiple of the token's step
ZBC backing0 or more
symbol2 to 10 characters (below)
name1 to 64 bytes (below)
survival paymentoptional (see token upkeep (persistence))

The flags are bits. Bit 0 makes the token redeemable. Bits 1 and 2 set the mint mode: 0 for a fixed supply, 1 for a mintable token; the values 2 and 3 are refused. Bit 3, "unbacked", is stored and reported, but no rule reads it. Minting and burning tokens explains what the two switches allow.

A token issued by a member of an account group belongs to the group.

Backing

Backing is real ZBC that the issuer puts into the token. It leaves the issuer's balance and is held by the token itself, in nobody's account; a node refuses a backing that the issuer does not hold. The ZBC comes back out in only three ways:

  • to holders who burn units of a redeemable token;
  • as the ZBC released when a fee is paid in the token (below);
  • to the holders, when the token expires (see token upkeep (persistence)).

The token id

A user token's id is the first 8 bytes of its IssueToken transaction's hash, read as a little-endian signed 64-bit integer (or 1, if that number is 0). It is therefore the issuing transaction's own id (see signing a transaction). The id is known as soon as the transaction is signed, and nodes never have to agree on a counter. The API prints ids as signed decimal strings, so an id may be negative.

Symbols are not unique: two live tokens may share one, and anyone can copy a symbol that is neither reserved nor blocked. Wallets and apps should show and check the id, not just the symbol (see chain data is untrusted input).

Symbol and name rules

A symbol has 2 to 10 characters, each a capital letter from A to Z or a digit from 0 to 9. That rules out lowercase, and look-alike letters from other alphabets. Two more rules protect well-known names:

  • Reserved: symbols of 4 or 5 characters that start or end with Z, such as ZBTC or BTCZ, belong to the bridge namespace. A 6-character symbol such as ZABCDE is allowed.
  • Blocked: a built-in list of 78 well-known tickers that nobody may impersonate: 17 currencies (such as USD, EUR, CNY and JPY), 18 stablecoins (such as USDT, USDC and DAI) and 43 major coins (such as BTC, ETH, BNB, SOL, XRP, ADA and DOGE).
Five symbols checked: GOLD25 and ZABCDE accepted; ZGLD reserved, being 4 characters starting with Z; USDT blocked as a well-known asset; gold refused for its lowercase letters
Five symbols checked: GOLD25 and ZABCDE accepted; ZGLD reserved, being 4 characters starting with Z; USDT blocked as a well-known asset; gold refused for its lowercase letters

A name is 1 to 64 bytes of valid UTF-8. It may not contain the characters <, >, " and ' or the backtick; it may not contain control, zero-width or direction-changing characters, or any space other than the ordinary one; and it may not start or end with a space.

Moving units: TransferToken

A TransferToken (type 11) carries the token id, an amount that is a multiple of the step, a recipient, an optional flag to pay the fee in the token, and an optional survival payment. Token id 0 is refused: ZBC is not a token, and it moves with SendZBC. A transfer of more units than the sender holds is a paid no-op: it pays its fee and moves nothing.

Token transfers can also be escrowed (see escrow; the fee is then paid in ZBC), streamed (see liquid payments (streams)) or scheduled (see scheduled transfers). From version 0.5.8 one transaction may carry several token transfers as a batch, all or nothing, for the sum of their one-transfer fees (see one transaction per account per block, and batches).

Paying the fee in the token

A token with ZBC backing can pay for its own transfers (flag byte 1). The token releases ZBC from its backing to cover the floor and gives up the matching units:

units given up = ceil( released ZBC × supply ÷ backing ), rounded up to the step

Both the supply and the backing fall. If the declared fee is above the floor, the overpay stays in the token.

See also