ZooBC basics

Accounts and addresses

On ZooBC your key is your account. A native account is identified by its Ed25519 public key, written as a 66-character address that starts with ZBC_. Nobody issues addresses: a wallet derives yours from your key, and it can do so offline. Every address carries a checksum, so a mistyped copy is refused before anything is sent.

What an address looks like

A native address is the prefix ZBC, an underscore, and 56 characters in seven groups of eight:

ZBC_57J5D5QV_OPO4JILA_RQW2JC77_OOIDM4VM_BHFCLTKB_2DOFOR4L_Z24K7SFR

This example was made from a hash for the zoobc.how quiz. Nobody holds its key, so never send coins to it.

The 56 characters are 35 bytes written in base32, an alphabet of the capital letters A to Z and the digits 2 to 7: the 32 bytes that identify the account, followed by a 3-byte checksum.

A 32-byte public key plus a 3-byte checksum make 35 bytes; base32 (A-Z, 2-7) turns them into 56 characters; adding ZBC_ and grouping by 8 gives the finished address.

The 32 bytes are the key

Inside the chain an account is not text. It is a 4-byte type number followed by a payload whose length the type decides. Type 0 is the native ZooBC account, and its payload is the account's Ed25519 public key itself, not a hash of it. Anyone can therefore read the key straight from the address: from version 0.5.8 the node's API answers /api/v1/accounts/<address>/pubkey for a native account from the address alone.

Other chains do it differently, and ZooBC follows them when it uses their addresses. An Ethereum account's payload is the last 20 bytes of a Keccak-256 hash of the key, and a classic Bitcoin (P2PKH) account's is the 20-byte HASH160 of the key. ZooBC accepts accounts of Bitcoin, Ethereum, Solana, Polkadot, Cardano, Ripple, Tron and Tezos, each written the way its home chain writes it and verified with its home signature scheme (keys and account types).

The checksum catches typos

The checksum is the first 3 bytes of SHA3-256 over the 32-byte payload followed by the three prefix letters. Whatever decodes an address, whether the wallet, the command-line tools or the node's API, recomputes it and refuses the address when it does not match. A random typo produces another valid address only about once in 2^24, or 16.7 million, tries. As a check for the quiz, all 1,736 single-character changes of the example address above were tried, and every one was refused.

The refusal happens before a transaction is built, so nothing is sent. Consensus itself never decodes text: transactions carry addresses as bytes, and the checksum is checked by the tools that turn text into bytes. There is no "closest account" lookup, and coins sent to a wrong but valid address would not come back by themselves.

Writing an address

Decoding follows a significant-character rule: every underscore, hyphen and white-space character is dropped, line breaks included, and what is left is turned into capitals. So ZBC_57J5D5QV_…, zbc-57j5d5qv-…, an address with no separators at all and one that wrapped across two lines of an email all decode to the same 32 bytes, and the checksum is then checked as usual. Separators and capitals exist only to help people read and copy.

Prefixes

The three letters of the prefix say what a key is for:

Prefix	Meaning
`ZBC_`	an account (type 0)
`ZNK_`	a node key (keys of a node)
`ZBR_`	a relay key (relays)
`ZBG_`	a gateway key (gateways)
`ZBS_`	a dataset object (type 10, datasets)

The API also accepts a ZTX_ form for transaction ids.

Because the checksum covers the prefix, the same 32 bytes under two prefixes share the first 51 characters after the prefix and differ only in the last five. The example key written as a node key ends in …_2DOFOR4L_Z24FR5JM instead of …_2DOFOR4L_Z24K7SFR. Swapping the prefix by hand, without recomputing the end, breaks the checksum, so the edit is caught. A node's own account is the ZBC_ form of its node key.

The same key as ZBC_ and ZNK_: the 51 characters after the prefix are the same (the key), the last five differ because the checksum covers the prefix.

Addresses with no key

Some native addresses are not keys at all. No private key matches them, so no signature can spend from them, and their coins move only under the protocol's own rules:

the protocol's pools: the longevity pool ZBCLONGV, the storage pool ZBCSTORE and the apps pool ZBCAPPS, each an ASCII name padded with zeros to 32 bytes (pools);
an account group, named by a hash of the transaction that founded it (account groups);
a multisignature account, a hash of its threshold and participants (multisignature);
a dataset object, the hash of the transaction that created it (datasets).

Everything is public

Every node holds the full state, and its API answers anyone, with no account, no key and no API key. GET /api/v1/accounts/<address> returns the balance, and the routes /history, /transactions and /movements under it list what the account has done and every change to its balance with its cause, including rent paid and rewards won. Explorers show the same data as web pages (explorer and archival nodes).

What the chain does not record is who you are. An address is a key, not a name, and nothing on the chain links it to a person unless someone makes that link. Privacy on ZooBC therefore comes from how you use addresses, not from hidden balances. A key is needed to act, never to look.

An account that holds ZBC pays a small rent, and an account whose balance cannot cover it is pruned (account rent and pruning).